The Innovation Triangle | DaveBirchall.com on Business Technology (via Mowser)

Why you don’t need to be a technologist to start a technology company.

August 4th, 2009 |

The Innovation Triangle

I’m not going to claim that this is my idea or my concept, that belongs to my good friend and collegue Brett Raven. He has been talking about the innovation triangle for some time now. Its such an easy way for clients to get their head around the partnership needed in order to be successful on any project. It forms a large part of our conversations with clients so I guess its worth sharing via the blog.

This is largely common sense but it’s worth really giving this some thought if your evaluating relationships and capabilities around software engineering (internally or externally). I’ll explain this firstly by going through and discussing the three elements, then I’ll talk about what happens when people get this wrong. That’s the really interesting bit.

Finance - Software projects take time and time usually means money. Unless your in the position where you can develop the software yourself of course. Its not just the development that bleeds your bank balance dry however. The new solution to be marketed even if its an internal project (its then called education). The project needs to be thought through from conception to implementation and adoption and you need to put realistic figures around what that will cost. Do try and get value for money but don’t try and boot strap the development, it just never works and you lose in the long run.

Domain Expertise – You can have all the money in the world and you might have won ‘king coder of the month’ for the last three months running, but unless you know enough about the domain that the solution is intended for, you’re the equivelant of a ship without a rudder. Your sailing in no particular direction but hoping you will hit land. This, I believe is the most important element of the triangle because the other two piece of the puzzle can be acquired from else where. To be a domain expert, you need to have an indepth knowledge of the problem you are trying to solve and business goals and drivers you need to meet. Software Engineering Expertise – Okay so your building a software solution so you need to bring some expertise to the table in the form of dedicated software engineers. No surprises here I am guessing for most people. Why is it then that people get this wrong so often? Successful software projects involve so much more than writing code. Think about it. If the only barrier to entry for every wannabe facebook owner would be to buy a copy of PHP for dummies then there woul be alot more millionairres out there right now. In the real world, there are a multitude ofÂ factors to consider – What methodology is to used. What project management skills does the team have? Do you have the set up and infrastructure such as continuous integration to be able be efficient in the build?

So hopefully by now you are starting to get an idea of the team that you need to put together in order to be successful. I have never met an individual that possesses all of the attributes to be able to cover all of these success factors. I have however a great deal of respect for the entrepeneurs that I have met who understand their limitations and bring in the neccesary expertise to get the job done. Often they are commercially savy domain experts who understand how to engage a software development team.

Why would you rather be?

Imagine you wanted to start a new web based technology business and you were looking to build a team. Who would you rather be?

1) Lots of capital, no domain expertise, no software engineering talent: While this is a nice problem to have (of the three) , its not sustainable. You can fund a development, your software team will gladly help you spend it but what result can you get without good domain knowledge

2) Software engineering, no finance or commercial awareness and no domain expertise: We meet these people all the time. The open source world is full of them. Back bedroom coding experts who spend so much time thinging about the solution that the business never gets a look in. The best we can hope for here is that they partner with someone who can level them out and stop them writing code for codes sake and also find a domain expert who can tell them honestly what is in scope and what’s not.

3) Domain expert, no finance, no technical expertise: The domain expert can bring in a third party for commercial direction and capital raising. Money is easy to find if you know where to look. They can also engage the services of a professional software development team who can systematically extract the requirements of the solution from your knowledge of the domain.

Its about team spirit

Don’t get me wrong I love clients who have money to burn, but thats only part of what we need to get a successful project over the line. If you also want to be a happy customer, you need get involvedwith your team and often. If you’re the domain expert then we need to get the requirements from your head and let the technology experts do their job.

Hands up!

Hands up? Who reading this owns a software programming business? My guess is not a lot of you right? Now hands up if your a business owner or director of a company that isn’t a software engineering business but you hire developers. Yeh you not so keen to admit it now are you but I know your out there. I talk to you every day…

Okay I’ll get off my judgemental high horse for a second or two. I’m not saying that every company should outsource their IT but I am saying that you should really have a think about why you want to do it. It costs money to own a software engineering department so why not share that cost with someone else?

Outsourcing has come a long way in the last few years. If you can have a team that is outsourced on paper but feels in every respect like they are part of the company, then why wouldn’t you do it?

Share and Enjoy: