Why is comparing sales and software engineering a disaster?

Table Of Contents

Recently, we saw a massive backlash on Mckinsey’s article by a lot of industry leaders like Grady Booch, Kent Beck, Gergely Orosz, etc.

I am happy that someone as big as Mckinsey is talking about dev productivity which shed some light on the seriousness of this subject.

While I liked their direction of breaking the black box of software engineering and also their focus on decreasing time spent on non-core activities like compliance, meetings, etc., I didn’t like the tactical frameworks they have suggested.

Another thing that bothered me was the parallel drawn between sales and engineering regarding the measurement of work or (in simple terms) the ROI of each department.

No matter how lucrative and obvious this sounds to non-tech executives, it is a disaster to draw a parallel between the 2 functions.

square peg in a round hole

Let’s find out why!

As a primer, function of :

  • Sales => Bring in revenue
  • Engineering => Build an idea into a product

Measuring output for sales is straight forward because the core function of sales is to bring in revenue to the organisation. However, engineering output might not necessarily impact business results.

The flow below shows the function of engineering.

Engineering function

It starts with an idea, a market insight, mixed with a design of a product and engineering builds it into a real product!

Now, it is entirely possible that even if engineering does a great job but we had:

  • Great product but poor idea: The engineering team might create a great product but the idea might not be a good business idea. You can easily recall many of the big tech product launches which had to be shut down.
  • Great idea but poor product design/messaging: The idea was great but the product experience/messaging didn’t ring a bell with the end users and the business still fails.
Success dependency on idea and product
Success dependency on idea and product

In both scenarios, the engineering metrics might have looked great but the business couldn’t be successful.

Hence, tying engineering performance to the business outcome might be totally unrelated.

This doesn’t mean one should not consider making the building process efficient. We would still benefit (a lot) from an efficient software delivery pipeline. The pipeline broadly looks like:

Software Delivery Pipeline

Having a smoother pipeline will result in either or all:

  • Predictable product delivery timeline to the customer
  • Alignment with marketing and operational teams for great launches
  • Quicker product iteration

Software engineering is complex and hence over many decades any attempt to measure output like lines of code, velocity has resulted in change of focus from development into gaming of the metrics system.

However if you unblock your engineering team to do more, it will not change their focus and hence work in everyone’s favour.

Easy first steps


  • The team is not blocked on someone
    When a member is blocked on another, it adds further delay, developer fatigue and work imbalance in the team
Source: Middleware’s dependency insights
  • The team is not working back-n-forth
    Back-n-forth while keeps everyone busy, but results in no progress. It leads to failure in meeting timelines and reduction in developer morale.
Source: Middleware’s cycle time insights
  • The team is not getting a lot of ad-hoc work
    All planned work commitments will spill if the team’s energy is spent in fulfilling unexpected work. This work is often termed as “urgent” and soon becomes a trick up the product manager’s sleeve to expedite anything they’d want. Stopping the buck at a threshold will help the team cater to really urgent requirements and the planned work!
Source: Middleware’s Sprint Analysis

Unblock engineering and productivity will follow

In summary, it is hard to correlate engineering efforts to business outcomes. Nevertheless, it remains crucial to ensure the efficiency of the engineering function, facilitating the seamless transformation of ideas into products. This, in turn, empowers faster iteration on your ideas and enhances the product experience, ultimately driving positive business results!

Engineers start their career to change the world by creating something meaningful. Pushing them solely on output can potentially discourage them rather than motivate them.

Instead, unblock them to change the world and soon they might 🌎!

Recent on Middleware blog