Developer productivity receives disproportionate attention considering the share of organizations where it happens to be a bottleneck.

With tech being at the center of value creation engine for an increasing number of businesses, it's natural to look into every opportunity to be more efficient. There is however a misleading assumption that developer productivity is a universal leverage to an organization's performance.

Scaling productivity

A single team has little collaboration overhead and, constrained by its limited capacity, tends to have few goals and strong focus. Delivery performance in that context can therefore be directly attributed to developer productivity.

This ideal however tends to break down as early as having two or three teams. As an organization scales, the influence of individual developer productivity on the performance of the whole diminishes. A group of locally-efficient teams does not make an efficient organization: there is a point where collaboration, dependencies, and team cognitive load become the bottlenecks.

One of the reasons for this is that as an organization grows, the number of independently taken decisions increases. A fraction of these decisions result in the fascinating phenomenon of ✨ creating work ✨, for example by prioritizing the development of a new feature, or planning a technical migration.

The ability to make design and product decisions is, as Andy Budd pointed out in this excellent thread, a lot of fun. It's also one the most consequential decisions one can make because it spends an organization's crucially valuable resource: focus.

From developer productivity to organizational e*ffectiveness*

Developer productivity matters at all stages of a company, if only because it contributes to no small part to the broader developer experience. But developer productivity is, and should remain, a concern to the builders first and foremost.

While comfortable to management, it is a trap past a certain size to continue considering developer productivity as the main leverage to the organization's performance. First, there's an upper limit to efficiency which an untamed ability to create work will eventually exceed. Second, there are inevitably initiatives which contribution to goals does not justify their cost in engineering focus. Or as Peter Drucker puts it:

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”

Engineering managers who disproportionately focus on measuring and improving developer productivity are not only doing their team a disservice, they are also failing on their mission to bring clarity of goals, alignment, and focus. As Pedro Franceschi pointed out, the difference between the best and worst projects is not found in their individual contributors skills, but in their leadership.

For all these reasons, Echoes does not pretend to measure or improve developer productivity, or at least not in the commonly-understood sense. How Echoes makes developers more productive is by helping management create the right context for them to deliver their best work.

Echoes shines a light on the reality of the day-to-day, so that the complexity of execution informs planning decisions. Echoes shifts focus away from local efficiency and individual developer productivity to the bigger goal: the organization's collective ability to succeed.

Interested to learn more? Check out https://www.echoeshq.com.