Software development is notoriously difficult to manage successfully, and non-technical managers are expected to deliver results without understanding the complexities of code, infrastructure or development workflows. I hope these six tips will help avoid some common traps.
1. Make sure you know what you want your app to do
I know this sounds basic, but in reality the biggest risk to the delivery of software development projects is uncertain business requirements. This causes changes and scope creep (more features added) as you go along, which increase costs and delays.
If you know exactly what you want, then document it clearly. Remember that even simple apps can have complicated user journeys when you get into the details.
If you’re not sure about all the details of how you want your app to work, and this is often the case, then adopt an Agile approach using experienced Agile practitioners. This is a systematic method of creating iterations and evolving your requirements based on user feedback. It helps you avoid spending time and money on features that your users don’t need or want.
2. Expect optimism bias
Many people are naturally optimistic about how quickly projects can be completed, and software is no different. It is easy to overlook time needed for testing and fixing unforeseen problems. Also, digital technology is unforgiving for engineers and if something doesn’t work it cannot be ‘fudged’ – it needs to be fixed and that will take as long as it takes.
When talking with your team, the following rules of thumb might be useful:
- "We're about half way through" means the project is about 10% complete.
- "It's nearly done, except for..." means it is about 40% complete (at first use of the phrase 'nearly done'). You will hear the phrase 'nearly done' a lot throughout the 'long middle' of a project.
- "It's done, except for..." means it is about 75% complete (at first use of the phrase 'done')
- "It's live" can mean >90% complete, as there are often problems that emerge on a live system which weren't picked up before.
3. Don't trust appearances
What I mean by this is that features which seem very complicated to you may actually be very easy to implement technically, and vice versa. So always discuss feature ideas with the technical team and don’t make assumptions. Sometimes the killer feature which adds a huge amount of value might be trivially simple to implement.
Also, when work is in progress, sometimes apps can look a lot more unfinished than they are. An app which is 99% complete may look completely unfinished if the user interface is the last thing that is done, and this is scary for managers. Conversely, an app may look 99% finished when in fact there is a lot still to do behind the scenes. Don’t rely on your visual impressions and keep in close touch with the technical team to understand where things are.
4. Learn about technical debt and always give the dev team as much time as you can afford
There is always pressure to get things done as soon as possible, but forcing teams to deliver very fast will increase the quantity of technical debt in your codebase. This happens when developers use shortcuts and hacks to meet a deadline. This saves time in the short term but it needs to be ‘paid back’ in future because the code is harder to understand and more expensive to maintain.
Sometimes it is a conscious and necessary business choice to accept technical debt in order to release faster – see this article by Martin Fowler for more discussion – but giving teams more time to build apps in a cleaner, more maintainable way usually pays for itself many times over.
And never tell the team they have one month to build something when you could have given them two!
5. Make sure you have a 'translator'
Remember that technical teams will not necessarily understand your business objectives.
You might know that the purpose of your app is to reduce the cost of some process, or to measurably improve customer satisfaction, or to sell a particular product.
However, your technical team will be preoccupied with technical things, like reviewing infrastructure options, whether to use version 18 or 19 of something, or how to make their development workflow more efficient.
It is important you have a ‘translator’ who can understand and explain your business requirements to the technical team and can explain technical problems back to you. On larger projects this might be a technical product manager or Product Owner (a designated role in the Agile SCRUM methodology), or on simpler projects it could be an experienced client-facing software developer on the team. Either way, explain your business objectives to them clearly, and ask them to repeat the objectives back to you to make sure that you have been understood.
6. Ignore anyone who suggests you 'just build it with ChatGPT'
Don’t let evangelists talk you in to using AI to build your new app, at least not yet!
If you just need to create one or two pages of simple HTML then by all means try it, but for anything remotely complicated which needs to be maintained over time, you still need a professional team. Your team will of course be using AI in their workflows, but the AI will be under their supervision and they will refine the code and keep the technical debt under control.
What challenges have you faced? We’d be interested to hear any suggestions or experiences.