Tech’s Surprisingly Bad Math in Team Design

Tech’s Surprisingly Bad Math in Team Design

How often have you seen this happen: The business is anxious that the product team is not kicking enough goals. They want better business outcomes faster, so they hire more software engineers.

Makes sense at first glance, right? Engineers write the code. They’re the final step in value creation for the business. But is that really where the company’s spend has the most leverage? We want to maximise our return on investment, and as we’re about to see, hiring more engineers is one of the most expensive ways to achieve that. Surprisingly, hiring more engineers can actually cause revenue to drop compared to staying the course with the current headcount!

A primer on value chains

To understand the following analysis, we need to understand value chains. A value chain is every step involved in creating a business’s product. In a manufacturing business, this might be

  1. acquiring raw materials,
  2. shipping them to a refinery,
  3. refining them,
  4. shipping the refined materials to a manufacturing plant, and then
  5. manufacturing the final goods.

Each step in this process takes its inputs from the previous step, performs some operation on them, and produces outputs that will be the inputs for the following step. Often, upstream improvements in efficiency have a multiplicative effect on the outputs downstream.

So what is the value chain in a software company? It’s roughly

  1. Research: Identifying valuable problems to solve
  2. Designing a feasible, viable, valuable, and usable solution
  3. Experimenting to de-risk that solution: Usability testing, tech spikes, wizard-of-oz tests, fake door tests.
  4. Creating the solution via code

Discovery & Delivery.excalidraw-2.png

There’s a much simpler way I like to think about this: Every solution you build is a gamble; engineers let you place more bets, and product and design help you choose the bets with the greatest odds of winning.

The Software Value Chain

Let’s explore each of these steps. Every company does them to some extent, but the quality of execution at each step is not equally distributed amongst software product companies. In companies without a strong product culture, the early parts of the software value chain happen in a haphazard design-by-committee way from various stakeholders.

Research: Identifying valuable problems to solve

This is the responsibility of Product Managers. Many companies mistake Product Managers for Project Managers. They wind up paying lots of money for someone to spend their time writing tickets and micromanaging smart people. That is not the job of a Product Manager. Their primary responsibility is identifying problems worth solving and then de-risking those solutions.

That de-risking aspect is critical. Solutions are incredibly expensive to implement, and we have a limited number of bets we can place per year on features we hope will have a material impact on the business. But Product Managers cannot and should not do it alone. This brings us to the next step.

Designing a feasible, viable, valuable, and usable solution

Excellent product design doesn’t happen in a vacuum, and it isn’t a one-and-done process. If you think design is about aesthetics, you have completely misunderstood design. The goal of design is to marry the behaviour of the solution with the customer’s mental models of the problem, the task, and your application. Aesthetics are one tiny component of that incredibly complicated process. During the design phase, designers and product managers work together to address the four risks:


  • Value risk: Will the solution solve the problem in a way that provides adequate value for the customers and the business?
  • Viability risk: Can the business actually execute on this solution? Is the solution defensible and profitable? Do stakeholders in legal, marketing, customer support, and other functional departments have any objections to the solution?
  • Usability risk: Will a large enough segment of our customer base be able to understand and use this feature well enough to unlock value?
  • Feasibility risk: Are we sufficiently confident that engineering will be able to complete the feature in an acceptable timeframe? Will we be able to meet our non-functional requirements, such as performance?

To address these risks, we can use several discovery techniques, such as usability testing, empathy interviews, contextual enquiries, prototyping, tech spikes and proof of concepts, as well as working with stakeholders. The more experiments we can run, the more iterations design can create, the higher our confidence that the solution will provide value, AND the more value that solution will provide to customers and the business.

The critical thing to understand here is that every problem has multiple solutions, each of which has many variations itself. It is 100x cheaper to iterate through these solutions in the design phase than in the implementation phase.

Delivering the solution

The solution has been de-risked through several design and experiment cycles until we were confident it would achieve our desired business outcomes. Now, we’re ready to build it. Building and releasing software is hard. This is the most expensive and complicated part of the value chain.

Optimising The Software Value Chain

Now that we have thought about the entire value chain, let’s think about optimising it. We can’t do that without first considering how much we spend on each phase. For the sake of simplicity, I’m going to say every person gets paid $150,000 per annum, and I will only count the base salary cost. If we have

  • 1x Product Manager
  • 1x Product Designer
  • 5x Software Engineers

We are spending

  • $150,000 on Product Management
  • $150,000 on Product Design
  • $750,000 on Software Engineering

Which is $1,050,000 in total.

What does this spending get us? Spending on Product Management and Product Design increases our confidence in our solutions. Spending on Software Engineering increases the number of solutions we can ship each year. Or, to put it another way, spending on Engineering increases the number of bets we can place, and spending on Product increases the likelihood those bets will succeed.

Discovery & Delivery bets.excalidraw-2.png

However, there is a critical second-order effect here. As the software engineer-to-designer ratio tips further towards engineering, the workload on Product & Design increases, decreasing their ability to contribute to the solution's success. That is, spending more on engineering can actually cost you revenue due to a reduction in winning bets.

This is a lose-lose outcome for the business. They spend more to make less revenue. If you double the number of engineers, you don’t get twice as many bets per year because diminishing returns eat productivity pretty hard. But you do create twice as much work for Product, and double the salary spent on engineering, which already accounted for over 70% of expenditure.

Why does this happen? Simply, the Product & Design team have less time per feature for experimenting and iterating. Fewer tests and fewer iterations mean a lower chance of success.

Unfortunately, most companies don’t make time for Product & Design to do their discovery work at all. They simply build their best guess, which can work if you have plenty of cash to burn finding out what sticks, but in this climate, an ill-advised strategy.

So, what can we do to maximise our successful bets for the least expense? To maximise the company’s profit?

Well, we can’t increase the number of Product Managers per squad. That centralisation of context and stakeholder comms is critical to the role's success. Instead, we can double the number of designers. This is approximately only a 15% increase in expenditure, but it will almost double the capacity for discovery and research.

Discovery & Delivery spend.excalidraw.png

What impact does that have on profitability? Well, I built a spreadsheet to model this system! It shows that a 15% increase in spending results in over 50% more winning bets. It makes sense; you’ve effectively doubled the quality of the inputs going into engineering for a fraction of the price of the whole value chain.

Feel free to copy my spreadsheet and play with the numbers yourself. If you’re a weirdo like me, it’s actually a lot of fun.

Conclusion

It seems insane to me that the tech industry has been working on the assumption of one designer per squad for almost 15 years without questioning it. Yet, nearly every designer in tech I speak to is burned out and scrambling to get designs ready for engineering, let alone having time to run proper usability testing and discovery. Instead, the solution most tech companies choose seems to be to ask engineers to do more, and hire more of them. Not only is it addressing the wrong part of the value chain, but it makes the problem worse!

This also comes back to the theory of constraints and bottlenecks. It looks as though engineering is the bottleneck because that is where the most activity occurs. But if you change how you measure the system, from the number of bets placed to the number of bets won, then the bottleneck shifts upstream in the value chain. The bottleneck is product and design.

If we address this problem as an industry, not only might we make much better products and regain some credibility after a glutenous frenzy on VC funding that has come crashing down. We might also make tech companies a great place for product designers to work, reduce the pressure on engineers, and save people from needless burnout and the health risks that come with it.