Developing technology is about so much more than mastering lines of code. The reality is, if you don’t have the right mix of technical talent, available capital and market understanding, you’re likely to come unstuck. But anyone with an open mind who is strong in just one of these areas can succeed.
I’m not going to claim that this is my idea or my concept – the credit for this belongs to my good friend and colleague, Brett Raven. He has been talking about the innovation triangle for some time now. It’s 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 it’s worth sharing.
The innovation triangle (below) 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).
Software projects take time and time usually means money. Unless, of course, you’re in the position where you can develop the software yourself. It’s not just the development that bleeds your bank balance dry, however. The new solution needs to be marketed, even if it’s an internal project (it’s 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 bootstrap the development, it just never works and you lose in the long run.
You might have all the money in the world and have been awarded ‘king coder of the month’ for the past three months running, but unless you know enough about the domain that the solution is intended for, you’re the equivalent 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 pieces of the puzzle can be acquired from elsewhere. To be a domain expert, you need to have an in-depth knowledge of the problem you are trying to solve and business goals and drivers you need to meet.
Software Engineering Expertise
Okay, so you’re building a software solution. You need to bring some expertise to the table in the form of dedicated software engineers – no surprises here. 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 was buying a copy of PHP for Dummies, then there would be a lot more millionaires out there right now.
In the real world, there are a multitude of factors to consider: What methodology is to be used? What project management skills does the team have? Do you have the set-up and infrastructure, such as continuous integration, to build it efficiently?
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 entrepreneurs that I have met who understand their limitations and bring in the necessary expertise to get the job done. Often they are commercially savvy 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. Which scenario would you rather be faced with?
1. Lots of capital, no domain expertise, no software engineering talent. While this is a nice problem to have (of the three), it’s 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 talent, 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 thinking 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, stop them writing code for code’s 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.
It’s about team spirit
Don’t get me wrong, I love clients who have money to burn. But that’s 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 involved with 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 who reading this owns a software programming business? My guess is not a lot of you, right? Now hands up if you’re a business owner or director of a company that isn’t a software engineering business but you hire developers. Yeh, you’re not so keen to admit it now, are you? But I know you’re out there. I talk to you every day…
Okay I’ll get off my high horse for a second or two. I’m not saying that every company should outsource its 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?