In the early beginnings of a startup, there is a huge push to get “it” out there. You need to launch the MVP, get it in front of potential customers, and see what sticks. During this phase of initial development, a typically very small engineering team will be hyper focused on pulling all the pieces together, cutting necessary corners to deliver value as quickly as possible. Turnaround time is pretty rapid, features come quickly because there is very little cruft around the edges of the code base, and communication is simpler due to the small team.

For startups lucky enough to discover product-market-fit and begin generating revenue, it can be difficult to give up this sense of instant gratification. Founder’s I’ve advised have said “I don’t want to introduce process, won’t it slow us down? we move very fast”, or “We have feature x, why is my engineering team taking so long to deliver feature y?”, “Why do we have so many bugs all of a sudden?”.

The engineering team believes they are doing the best they can with what they have been given . They will show you their backlog, and their burndowns, and how much they continue to deliver one. But, expectations of timing don’t hit the mark with stakeholders, quality becomes and issue.

In my experience this is caused by a misalignment of expectations. One mistake teams make is to measure performance by the output of teams. While output, or throughput of work done, is an important metric to track, it’s not the most important. Outcomes are significantly more impactful to the bottomline of a business. Aligning everyone in an organization around outcomes over output, helps reinforce expectations across the board.