Software Does Not Negotiate

Over the course of my career, I’ve tried to strike a balance between an engineer's expertise and capabilities and the associated costs, in order to build the most cost-effective team. In this article, my intention is to discuss the other ways businesses pay for the software they are trying to build — beyond the salaries paid to the developers.?

When you trade-off the experience of the engineers you hire, you pay for it in the time it takes you to get your product into the market.?

By experience I mean hiring developers who have worked on similar problems, projects, technologies before. This allows you to short circuit decisions that need to be made in order to get the product or feature shipped.?

So when you hire developers who do not have the relevant experience you are paying for it in time it’ll take you to go to market, largely because of the unknown unknowns you will uncover as you work on the project and find answers through lengthy research and trial-and-error.

In my opinion this trade-off makes sense when you are building things that are non-mission critical where timelines can be adjusted to accommodate the pace of development. Another alternative would be to have a couple of team members who bring the necessary experience to short circuit decisions.

When you trade-off abilities like critical thinking and communication of the engineers you hire, you pay for it by having to focus more on people management vs product management.?

This is one of the more popular trade-offs I’ve seen where team leaders hire engineers thinking they just need hands to be punching code in order to get the product shipped. The expectation here would be that the team leader writes effective and detailed tickets, the engineers pick it up and get it done without any issues. In practice, this requires more effort than initially thought.

What these leaders end up realising is that they now need to work harder in order to communicate details very clearly and explicitly about what needs to be done, and have more oversight on the output. This can reduce the amount of time and energy you have to focus on other matters like customer/product development.?

This trade-off can make sense in cases where the solution to be built is quite straightforward with examples already available in the market, allowing the business to quickly put together a spec that is detailed and filled with relevant examples.

When you choose to fix time and scope of the software you are building, you make your customers pay by shipping software of poorer quality.

Software development comes with a lot of unknowns and in many cases these unknowns appear during the course of development, taking time in order to resolve it.?

So whenever someone decides that they want all the features shipped within tight deadlines, it leaves teams with a very narrow margin for error. This leads to cutting corners, rushing through implementation and software riddled with bugs and technical debt. Your customers end up paying the price in the poor experience they face when using your software.

This is the trade-off that I recommend the least because with this trade-off, no one wins. You will end up with a team that is burnt out, a product that frustrates its customers.

You can choose pay by reducing the scope of the software you want shipped.?

As a consultant, I’ve had clients telling me that they wanted the most cost effective team we had and be able to still release high quality software. In those cases, I’ve always told clients to significantly reduce the features they want shipped.

This is usually the option I lean towards most because it forces teams to prioritise what they want more carefully, allowing teams to ensure every feature they’ve shipped is well built. This leads to a better customer experience and a team that is motivated because customers love the products the team is shipping.

I hope the above shares some insight on the other ways teams end up paying for the software they are trying to build.

These are some of the lessons I’ve learnt when I’ve made these trade-offs and there are many others out there. I would love to hear more about some of the trade-offs you’ve made and the lessons you’ve learnt from them.