Aesop's fable of the Tortoise and the Hare
Engineering Productivity focuses on systematically improving the flow and quality of value to customers' and teams' happiness. In my previous posts, I touched on two ways to improve productivity - through Quality Control (QC)/Quality Assurance (QA) and by keeping your technology lean (like going serverless-first).
I've saved the best tip for last: continuous improvement culture is, by far, the best lever for improving the agility (small 'a'), resilience and happiness of teams and customers alike. Volumes of research and case studies of success and failure across Agile, Lean, DevOps and Resilience Engineering all agree that a culture of smaller improvements made voluntarily by teams far outperforms any tool, framework or transformation program for achieving truly transformational business outcomes. Tools and frameworks (quick to implement) rely on culture (slow and steady) to be effective over years instead of months.
Part 3: Energising an Engineering Culture
The Improvement Paradox
Socio-technical Systems
Tuning engineering productivity is done in the context of the dynamic network of interactions in the socio-technical system of goals/metrics, people, processes, infrastructure, technology, and culture.
The system is constantly changing. What was the top constraint last month may no longer be so. When we go beyond perhaps 20 people and multiple customer segments, it becomes impossible to wholly 'understand' the system for more than a moment.
The best approach to improvement in this complex and adaptive system is running multiple small improvements or experiments within smaller areas we can comprehend. The choice of these improvements needs to come from the team culture, but what if the culture itself is what needs improving? 🤔
It's easy for engineering leaders to treat cultural improvement similarly to solving a technical issue. We may inadvertently pre-design an idea of what they would like their team's culture to look like and force-fit the team. Culture is one of the most complex parts to build and change because it needs to transpire organically.
The good news is there are helpful patterns that I and others have learned by trial and error to be effective with Software Engineering teams.
🩺 First, Observing
If we consider culture as a collection of values, expectations, and practices that guide a team or individual's choices. When I think about a team's culture, a helpful question is…
If a team or individual was given an extra week, what would/do they choose to do?
Asking or observing what teams are currently choosing to do with extra space (like 20% time, hackathons, improvement sprints etc.) gives a strong signal to the current culture. In a healthy culture, over time, teams show a mix of productivity, reliability and team or customer outcomes.
⚠️ Watch out for:
🪫Low engagement and enthusiasm in using extra space. E.g. "I'll just work on some bugs", no/late idea submissions, no data to inform choices
Overly focused on technical excellence over team/customer outcomes. E.g. Try [insert new SDK/ developer experience concept], using a new language to rewrite existing functionality.
Ideas are unrelated to the context or strategic direction of the team. E.g. Improving a soon-to-be redundant service, making an overloaded database query faster when it's time to re-architect the solution.
While the these examples may sometimes be sensible investments, over time, be wary if all the team chooses them. In talking with the team, tease out their rationale for selecting the initiatives. Given our observation, if it ain't broke, don't fix it. If, however, we need a more balanced culture of improvement culture, consider checking the following tactics.
🔋 Energising the Culture
Realisation, Permission, expectation, and recognition of improvement
Tactics for rebooting an improvement culture in Engineering teams
Engineering culture is one based on continuous improvement. Leaders need to set expectations and give permission to allow their teams to make improvements to foster a culture of continuous improvement.
We choose to do things that will reward us or avoid pain, which is why it is essential to celebrate improvements to encourage more. Over time, this builds consistency in improvement, and before we know it, we've achieved systemic change. In the long term, mastery, autonomy and purpose are more potent motivators. The hack is to experience these motivators through the act of continuous improvement.
On the flip side, the team will make mistakes as they experiment with improvement. Permitting them to improve also means accepting that sometimes things will go wrong and even get worse or slower before it gets better.
Engineers need to think like product owners.
While empowering the team to improve the things they want is essential, it's also crucial for them to do the most important things first - regardless of personal or group preferences. Just like product management, Engineering improvements need a hypothesis for outcomes of shipping value faster, safer or improving overall team or customer happiness.
The hypothesis can turn into one or more small experiments - some of which may partially succeed or fail.
Critical thinking can be new to technically-minded teams who are traditionally rewarded for shipping features but pairing the Engineer, and the Product Owner on the hypothesis helps each role understand the other and avoid local optimisations. Next, the team needs data on their blindspots to make a reasonable hypothesis or OKR.
Engineering Culture - Aligning the improvement shoulds and wants
⚖️ Balanced scorecards and improvement trends
We cannot manage what we cannot measure and only improve what we measure.
Measuring against balanced scorecards is an objective view across people, processes and products that drive business performance and provides a balanced perspective to measuring progress. I describe it as a single-system view that the team use to influence goals, KPIs, and culture. A balanced scorecard makes it far easier to associate an improvement with a customer, team or organisational outcome.
High-performing teams don't necessarily talk about measuring delivery performance or eNPS but always know instinctively what their baselines are and pay attention to signals of areas under stress. Generally speaking, suitable measures help us to:
Prioritise resources on the following most valuable pieces of work;
Validate their actions, and most importantly,
Stay motivated.
Data helps with blindspots. The team is still best decider of what's important today.
Start on day one (..or today 🙂)
Fostering and maintaining a great engineering culture, whatever that might look like, starts on day one. There's no better time to communicate the team's culture, which can include:
Setting expectations, giving permission, and showing recognition for improvements;
Empowering them straight away;
Getting them inspired by the business and product vision and strategy;
Clear coaching the team in establishing objective measures
Build trust by using metric trends instead of specific targets and comparisons.
Then observe. We can only control what we can control. Give the team time and see what the culture is.
Any improvements made anywhere besides the bottleneck are an illusion
- Gene Kim, The Phoenix Project, DevOps Handbook, Accelerate
Wires Uncrossed Engineering is uniquely positioned at the intersection of people, process, and technology to identify bottlenecks and help organisations achieve holistic improvement across crucial challenge areas. We specialise in software teams' productivity, reliability and work satisfaction.
Originally published on LinkedIn.
Comments