There’s a problem with tech people – they like tech.

If they were building a vehicle, they’d want to build a spaceship, not a Ford Fiesta. A spaceship has so many cool features that the engineering team would love to focus on building. It would look great on their CVs and it sounds great in a seminar or podcast episode.

This may sound obvious but engineers get a buzz out of building tech. This is why they come to work. Sounds like a good thing, but have
you considered that this might be a problem?

There’s often an assumption made by technical teams that a business wants the best solution, whereas what they typically want is a fast solution followed by incremental improvements that transform it into the best solution over time.

All business software is an investment and every business wants a return on its investment as quickly as possible, hence fast, followed by better and eventually, best.

There’s a critical mindset mismatch between stakeholders and engineering teams for businesses trying to leverage tech. The business doesn’t want tech, its not a goal in itself.

It wants what tech can deliver: customers self-serving, back office staff doing things in a consistent way, tracking usage data to drive process improvements, making things easier, removing friction, adding business functionality, increasing efficiency and revenues, etc.

It doesn’t want tech, it wants what happens after tech is put in place. It wants the results of tech.

We’ve seen ambitious startup companies draw up tech architecture plans that look more like Netflix than MVP. A developer’s mind is motivated to design and build the dream system (the spaceship).

The business just needs it to work (the Ford Fiesta), and quickly.

Users won’t see your beautifully organised microservices architecture or your neatly indented code. They won’t know if you’ve used camelCase, snake_case or PascalCase. But they will experience your UI / UX and functionality and they will vote with their feet if it isn’t simple and a pleasure to use.

The ‘dream’ architecture can come in time, if its needed – a ‘champagne problem’ as we’d say.

It is critical to business success that your tech team sees tech as a tool, like a craftsperson would. It’s important to match the maturity of the business with the maturity of the tech.

Unlike a traditional craftsperson, there is never strictly a finished article as improvements and iterations are always possible over time.

Sure, you may be in the lucky position of being able to justify the dream system. Whenever we’ve done this, it has been very definitely a Version 2 or 3 of a solution.

The business has grown to a point using what it has and now the systems are becoming a constraint. Their shortcomings are now clear to see for customers and users and something needs to be done.

There will have been some invaluable lessons learned by using immature systems. There are often no shortcuts to this insight. Once their shortcomings have been established and the business is able to justify the existence of the next generation system, you’re in a great place.

If you try to go to something as mature as System 2 as a first release (even if you can afford to), you’re missing out on the hard-won insights that you’d get from time spent at the coalface using System 1.

Once the tech has been built and delivered, the tech team is at their happiest. But the business has yet to get any value from their investment. Their happiest time comes after the tech has been delivered.

So your tech team wants the tech and your business wants the result of tech. Different things.

Recommended

• DIGIT Deal Roundup | February 2022
• South of Scotland’s tourism sector set for digital tech boost
• Scots research reveals how colours affect behaviour in VR

The two types of people are motivated very differently.

So, when commissioning software, be very clear about the needs for it now, into the foreseeable future (things it will need to do next) and into the possible future (things it might be required to do).

Also, be decisive on MVP features – where good-enough is the focus. I also like to get engineering teams to think about two different scenarios, the first being the fastest possible solution – design it as if your life depended on it being delivered and working by an ambitious date in the near future (earlier than the real delivery date).

In this scenario the platform will never change, so the MVP is the enduring solution.

The second scenario is the spaceship solution: what’s the absolute best solution you can design, money and time no object.

The optimal solution will clearly be somewhere in between. It’s such a luxury that software can be improved iteratively, the key thing is to use this to the advantage of the business. After all, that’s why you’re a developer, right?