Why is Engineering Effectiveness important?
The importance of engineering effectiveness is best understood through the lack of it, which we will try to explain here. Engineering leaders manage many competing priorities, among which:
- delivering features
- hiring towards ambitious growth goals
- managing rising infrastructure costs
The speed at which tech companies move can also make it easy to fall into a reactive mode of management, or “fighting fires”. Put another way: the focus is on the what - what project to start, what technology to build or buy - at the detriment of the how - the construction of a resilient “engine” for the engineering team.
When this mode of operations becomes the cultural norm inside the organization, dysfunctions appear quickly. Let’s illustrate this from the point of views of various actors.
From the point of view other executives and the board of directors
When an engineering team is not productive, outside actors notice it through the lack of output and in the form of catastrophic events.
Lack of output usually creates a sentiment that “engineering is a black box”, with executives or board members trying to get more directly involved. The CEO might increase the frequency of engineering-focused meetings, ask for metrics and for more detailed reports. This problem usually happens in the growth phase of the company, which is exactly when engineering productivity should be taken seriously.
Catastrophic events are often major production incidents (and subsequent code freezes) or unexpected attrition. We have seen situations where entire sub-departments quit on a single day and code freezes that have lasted for weeks at a time. When several of these signs appear in a short period of time, it indicates an unstable organization, where there is no coherent system or “engine” by which the inputs are transformed into successful projects. Or there might be some system, but not enough attention paid to how productive the system is.
From the point of view of developers
As we wrote above, developer experience - as in the many workflows and social interactions needed to create working code - is the core input of an engineering team. Working on an unproductive team is painful: pushing new features takes forever, the tooling is inadequate, dubious meetings and on-call pages turn into a never-ending stream of interruptions.
The learned helplessness that permeates the daily experience leads to disengagement, which leads to leaving the company. High performers are disproportionately affected by this type of issues and will self-select out of unproductive organizations.
In our experience, a productive team is almost always an engaged team, and vice-versa - the key, again, is to focus on building an efficient engine free of bottlenecks and annoyances.
From the point of view of the leader themselves
As former engineering leaders, we’ve had our fair share of awkward moments where we had to acknowledge we could have done better. The dominant emotion in these cases is the impression of getting blind-sided by what is happening.
For example, you may think that you have implemented efficient DevOps practices with healthy on-call rotations for your new service-oriented architecture. One day, you find out through a series of one-on-ones that one of your teams has been woken up at night, every night, for the past 2 weeks because of noisy alerts, with one team member dangerously close to burning out.
This emotion is actually rooted in an objective loss of control, as it usually happens when the company is scaling fast. What worked with 10 direct reports - anecdotal evidence through one-on-ones and daily stand-ups - just won’t work with an organization of 70.
This is when building a system of signals and metrics to replace the anecdotal evidence becomes critical.
To conclude, measuring and improving engineering effectiveness is a precondition to building a healthy engineering team: attracting talent, building an efficient system where they can produce their best work, and retaining that talent. The score - i.e. the features and projects - will take care of itself, as long as you pay attention to removing bottlenecks faced by your team.