Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Too often, people involved in engineer productivity are either in conflict with the very engineers they're trying to help, or are simply disconnected from those engineers and therefore not able to genuinely support them.
This is because most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Productivity has always been an excellent way to measure the impact and results of machines. For humans, however, those measurements get tricky.
When we talk about measuring engineer productivity, we usually refer to measuring their outputs and not outcomes, especially not long-term outcomes.
Similarly, when we refer to increased productivity, we’re referring to increased outputs without considering their quality and the results they generate for stakeholders. This is because the metrics and KPIs employed (for example, lines of code) are quantitative. The result is outputs that don’t align with stakeholder value because increased outputs do not necessarily mean better outcomes/results.
More lines of code ≠ more optimal code.
So “engineer productivity” often frustrates engineers, plummeting their morale and hindering innovation, ultimately draining the engineer mentally and emotionally, especially when compensation is tied to those quantitative outputs.
Genuine experimentation and innovation require engineers to try different things that may not yield tangible output right away but result in substantial results in the long run. However, when traditional and quantitative productivity metrics that cannot accommodate experimental activities are used in an organization, engineers are forced to put their emotions and intellect behind them and focus on only numerical outputs—affecting not just their well-being but the organization as a whole.
Engineers, like most people in other professions, have certain conditions in which they work best.
Still, most productivity metrics (and KPIs) ignore the vital context of the place, the way, and the reason an engineering team's work is done. Instead, they oversimplify, which is why many organizations have adopted more encompassing frameworks like DORA and SPACE.
As previously mentioned, many productive metrics are also counterproductive.
For example, two engineers may build a similar feature, one with more code volume than the other. Indeed, the one with more lines of code may have hit their monthly target by writing more lines. But while according to most metrics, the one with more code has been more “productive,” their version may be inefficient or harder to maintain, thus rendering that KPI counterproductive.
Another example of how productivity metrics may become counterproductive is when developers make their "pull requests counts" look excellent by making minimal changes that require less work or getting creative with opening several tickets only to fix the tickets themselves.
Many productivity metrics also don't account for invisible factors such as intellectual capital (learning a new coding language, for example, or trying new work dynamics) and innovative work that yields long-lasting benefits.
Others don't consider the individual efforts that go into team projects, such as reducing technical debts, defining requirements, and maintaining hardware—measures crucial to a team's progress.
Thus, using these metrics is quite frankly, a redundancy and a waste of resources.
Geuine performance, the kind that delivers real value to your stakeholders, comes from trust, which isn’t earned in specific sweeping grand gestures but built in small moments.
The truth is, everyone can sense when they are under the leadership of someone who genuinely cares.
So, an excellent engineering leader must create the right conditions for the engineering team to grow and thrive, and that includes providing trust and clarity (in seemingly insignificant situations like morning standups or team retros), which ultimately fosters the team's performance.
On the other hand, a leader obsessed with productivity, especially in quantitative and selective terms, creates poor dynamics, which lead to the inefficiency of the engineering team and poor overall team performance.
One of the struggles many engineering leaders face is knowing when and how to let go and allow their teams to move forward with their daily work. Thus leading to problems of micromanagement, impaired team performances, and death of leadership and direction.
The urge to step in to become the hero is human and driven by fear—fear of losing one's reputation or even one’s job. Still, an engineering manager must let go of that inclination and empower the team (rather than micromanage them) to build an excellent team that does outstanding work.
This is especially true because micromanagement brigngs about the exact consequences the manager intends to avoid: poor morale and productivity.
After all, engineering is a team sport, and leaders are only as good as their teams—which is how retros help.
Retros are a more effective way to ensure all team members are on the same page with their leaders. During retrospectives, engineers can review what works and doesn't to determine their subsequent actions and establish the team's dynamic in a way that works for most.
However, this is the basic retro format, and while it’s helpful, it doesn’t life up to the meeting’s full potential.
The truth is engineering (and engineering management) is evolving to a scientific and data-driven dynamic where valuable data-driven insights are obtained to identify systemic problems and opportunities across teams.
In many ways, it’s similar to the evolution of sales. In the early 2000s, sales was an art; charisma was all that was required to generate results. Today, with tools like Salesforce, and People.ai, sales has transitioned toward scientific and data-based processes.
Luckily, ScatterSpoke brings this scientific process right to the doorstep of engineers.
Scatterspoke takes regular retros a step further by using intelligent tracking to not only analyze retrospective data and provide more insights into team morale, bottlenecks, and conflicts but also ensure that the improvements that come from retros are actually implemented—an effective way of putting engineers in charge.
Squeezing your engineers to the point of near-exhaustion by making them churn out the maximum possible lines of code, complete a certain number of sprints, or close several tickets a day, just so they can fit the factory-style definition of productivity usually creates poor outcomes.
Eventually, "productivity" ends up making them unproductive, since, besides these approaches not doing justice to the complexities of their jobs, the traditional productivity style can negatively affect employees and resources, stirring them away from objectives that will grow the organization. As a result, the engineers do things that don’t reflect the organization's objectives.
A more efficient option, however, is the empowerment of engineers with the right tools that enhance their performance, development, and overall well-being.
Engineers are no strangers to creating things and are delighted when they establish new or better solutions and create better outcomes, so an engineer may not necessarily need more motivation but tools that empower them and treat them like adults.
Ready to empower your engineers, scale up your retros and make better changes? Sign up for free today. Have more questions instead? Send us an email or contact us, and a team member will reach out to you as soon as possible.
Join the ranks of data-driven companies seamlessly acting on feedback and driving substantial improvement with less effort.
ScatterSpoke helps you eliminate waste in your dev process.