light My Insights: building great engineering cultures is not trivial. They take time to build, they are not “projects” with a due date, they are a continuum, an infinite cycle of improvements. Make this explicit and make the core elements of your culture visible so people can see it and know how to contribute to it and improvement it. Another important aspect is the creation of systems that support the culture and its continuous improvement, e.g.: make sure decision making is clear and people understand scopes of decision making - team can decide things within their team, but if it crosses to multiple teams this is decided by people working on that multi-team scope. This openness and systems will enable autonomy and participation of every engineer while managing complexity (i.e.: balance autonomy and alignment), and with that bring in the ingredients needed to make a great engineering culture.

Analysis & Summary

This is a great presentation by Patrick Kua on “secrets” of Strong Engineering cultures, i.e.: things to cater for in order to have an organization that moves at high-velocity, but also is a great place to work, where people feel motivated and can thrive in their activities. By having such traits, organizations also have higher changes of attracting and retaining great talent - a big challenge in our current market. Apart from the secrets (and challenges to cater for on each secret), Patrick also shares some interesting and useful recipes on how to start developing such culture and make it “more explicit”.

The three big secrets presented are:

  • Impact: (good) engineers don’t want to be “feature factories”. They love being challenged, seeing the impact of their teams’ contributions on the end customer (without having to go through long processes and handoffs). To accomplish this several we can look into several aspects, such as: enabling engineers “shadowing customer services” and see what are the problems customers are facing, this will show the real problems - don’t restrict these customer interaction activities to UX people; Work on small iterations, making sure improvements are continuously being released and validated with the customer; and make sure that team OKRs are aligned with the overall company strategies (i.e.: team sees how they are impacting and contributing to the overall org strategy). These elements and metrics are also the base of high-performing organizations, as shown in research done in the Accelerate Book (and DORA project). Patrick’s principle for Impact: “cultivate impact by reducing feedback loops”.
  • Choice: choice has to do with the degrees of flexibility of “how to work”, “how create a solutions” and “how to take decisions”. Basically this is about “Autonomy”. This is rather sensitive topic, as many times organizations want to have streamlined processes, consistent ways of working, tools, etc. However, following very rigid approach will go against the “degree of choice” that people find very attractive in working cultures, which also limits people from identify “better ways of doing things”. Patrick shares some interesting points here: stop trying to go in such a mode of “full-control”, and instead focus on providing clear principles that enable you to manage complexity. Example: observe common elements over teams, identify issues and based on that create systems that ask the right questions to validate that people don’t add unnecessary complexity (e.g.: let’s not introduce a new programming language or framework unless the gain outweighs the complexity of having a new element on out stack). Create culture where teams get clarity on the “What” they need to solve, and then get out of their way and enable them to find the “best How”. However, the scope of being able to choose must be clear, i.e.: set they choice boundaries clear - some things can be decided within teams, but for company-wide (or multi-team) elements a designated group will most likely decide, preferably with the input from teams. Bottom line: enable autonomy (i.e.: Choice) while provide some good principles and constraints to enable alignment and risk & complexity management, so that there is clarity and we avoid creating “waste” for our teams and organization. Patrick’s principle for Choice: “Cultivate choice by making the right thing easy”.
  • Improvement: improvement relates with enabling people to grow, participate of improving the company’s mission and make sure there is an environment that hears people’s feedback and take action to address issues. “Bored people will quit”: so it is very important to enable people to find exciting challenges and actually with that grow and bring growth to the company. To accomplish this it is really important to be transparent on the priorities of the company, so that people can clearly see where their work is contributing to those priorities. Finally, having a culture open to improvement, which fosters contribution from people to make things better is important. This is a culture that enables people to try things out without always going through endless processes (i.e.: “ask for forgiveness not permission”). This is a great ingredient to empower people to improve things at a faster pace. To make this work, we need to have systems in place that enable triggering improvements based on observed issues or inefficiencies (e.g.: results of retrospectives or post-mortems). Patrick’s principle for Improvement: “Cultivate improvement by making small changes easier”.

After introducing the secrets Patrick shares a 5 step recipe to create and continuously improve their culture:

  • 1: Gather input (understand why people work in your company)
  • 2: Publish you Tech Culture (synthesize the input gathered and publish this, make it explicit)
  • 3: Prioritize key improvement areas (from the learnings, prioritize areas that need improvement)
  • 4: Decide on actions (set clear actions to improve the points prioritized)
  • 5: Repeat (this is an infinite loop… be always in the lookout on how to improve things)

The final point of the presentation is a check we can do to measure if we are improving our engineering culture (i.e.: sort of metrics to measure health of an engineering culture):

  • 1: How many hand-offs do you have between Software Engineers and customer?
  • 2: Are software engineers involved in the HOW they solve a business problem?
  • 3: What opportunities do Software Engineers have to grow?