What corporate IT can learn from software start-ups

By Graeme Frost, CEO Brilliant Software

Traditionally, corporates struggle to innovate in their IT. For very good reasons.
They are orientated towards profitable business, predictable costs and reducing risk. Their employees have those goals strongly ingrained.

Software start-ups on the other hand accept that profits are years away, costs are guesses, and risk is their middle name. Their best members are good at breaking rules and trying new things without fully understanding the consequences.

Ironically, nearly all successful companies are based on products developed in innovative environments akin to start-ups, but as the companies grew the emphasis necessarily moved from product innovation to operational efficiency. Over time, the innovators left and the consistent deliverers took over.

Now, with the accelerating adoption of technology, corporates need to bring more innovative products to market quickly just to maintain their market position, let alone grow. Software is now often used to interact with prospects and customers making its ease of use, reliability and intuitiveness important brand issues.

So what is the middle ground? How can corporates get innovative software products to market without “betting the company”? Here’s a ten point plan.

1. Accept that corporate IT has a big millstone around its neck when it comes to innovation.
2. The main focus of corporate IT is to ensure that mission critical applications and equipment is available 99.95% of the time. No excuses. At the same time, they still have to enhance the systems to keep up with business and technological change. To achieve this they are damn careful. The implications of this risk adversity are huge. From project plans, business cases, risk evaluation and mitigation, rollout plans, rollback plans, all the way through to user training, the number of people involved grows exponentially and then countless meetings are required to plan and replan, and to “keep everyone on the same page”. The need to check, double check and triple check everything just takes time.
3. Understand that developing great software is an iterative learning process.
4. Even really clever buggers don’t get it 100% right first time. Not even close. Writing and agreeing a specification is an important starting point, but many IT organisations insist on their users “signing it off in blood” – which is just an exercise in arse covering. Great software is developed in a prototyping mode where all the stakeholders can regularly see how their ideas work in reality and have plenty of opportunities to fine tune them. Or change them completely. Getting it a bit wrong initially is allowed and should be considered as positive proof that the team is open to learning from its experiences.
5. Small teams are much more productive.
6. Folklore says that IBM spent US$50 million trying to develop its initial Virtual Machine product in the 1970s. After they abandoned the project as unachievable, they found that a three man group elsewhere in the company had already developed the technology as a bi-product of their other work. Small teams can trial new ideas and “hunches” quickly without the need for meetings and lengthy discussions on the merit of an idea. Good ideas can be tested and then be further built upon, while bad ideas are quickly eliminated, with no lingering questions as to their merits.
7. Only superstars can sit at the table!
8. With small teams trying to crack big nuts, there is no space for anyone but the very best on the team. Combine the best possible software expertise with your best possible business expertise. You get the best out of the ingenious people by surrounding them with other ingenious people. No skimping.
9. Consider clever outsourcing – with the emphasis on clever.
10. IT outsourcing is often associated with sending your development to India or getting a large IT supplier to help. Both of these groups are usually great at delivering to specification. Exactly. And they can apply hordes of developers to your project.
12. Clever outsourcing is very different. You don’t want hordes of developers, you want a small group of highly innovative superstars who will bring lots of ground-breaking ideas to further enhance your business concept and produce brilliant software. With modern tools, producing the actual software is usually surprisingly quick. Which means you can produce average software quickly or outstanding software at the same speed.
13. Let the business take control.
14. Especially if you are taking the clever outsourcing option – have them work directly with your business users. There should be no reason to have “translators” from IT involved on a day to day basis. Certainly they need to be the guardians of security and approve the technologies used etc., but the team needs to be able to act at speed. There is sometimes an element of risk in moving very quickly, business users are best placed to access the risk, considering the business benefit on the flip side.
15. Control costs by keeping the team small.
16. Traditional wisdom says software development will cost twice as much as first expected. The same may apply to innovative development too, but for different reasons. Much more reliable development tools mean that good software developers are far better at estimating development times, but they can only estimate based on what is in front of them – and that will constantly change. But by keeping the team small and avoiding the overheads which are part and parcel of a larger team, the multiplier effect won’t hurt nearly as much. And if it does go wrong (which is far less likely), then the exposure is minimised.
17. Get a minimal viable product up and running ASAP.
18. There is nothing like customer feedback, obtained either directly or by analysing how they interact with the software. Rather than trying to complete the vision in one hit – look for ways to deliver a partial product early. This can be tricky when the software has any level of interaction with existing systems – but if users understand they are using “beta” software, you will have some latitude. Real live customer feedback is invaluable to the team to tune and prioritise requirements.
19. 
    

1. Enterprise enablement is best done on the complete, proven product.
2. Before the system is taken into the corporate environment, with all the rigour that requires, it must be as complete and proven as possible. From that point, change is going to be slower and more expensive – so you really want to leave that as late as possible.
3. Software as a Service (SaaS) is a great approach for ongoing reactiveness.
4. If the software is likely to be changed on an ongoing basis, a standalone SaaS type approach is a great option. Security is a consideration, but with companies like Salesforce, Amazon and Microsoft leading the charge, this path is well trod. The advantage is that ongoing upgrades can be developed, tested and implemented in a fraction of the time.

It disappoints me every time I read of what large companies and government departments spend on developing new systems and how often they fail. I always wonder what they could have achieved with 20% of the budget and a small clever team. 99% of the time the answer will be: “A lot more”.

‍