Introduction
Software continues to eat the world, and technology powers nearly every facet of a business's operation, from internal processes to the goods and services offered. As a result, enterprises spanning a variety of sectors - from retail and banking to manufacturing - need to cultivate an environment that increases their software development investments by maximizing the engineering team's ability to innovate.
Building high-performing engineering teams includes providing the right tools, honing the team's product management skills, and creating an environment where engineers can thrive. Companies that learn to build better software engineering teams can leverage technology to deliver stronger business outcomes and increase market competitiveness. Let's look at some of the patterns that can help to maximize an engineering team's performance.
Companies with strong tools to enhance planning, development, collaboration, and continuous delivery are 65 percent more innovative than others, according to a 2020 McKinsey & Company report. Having access to the right tools at each stage in the development process contributes to engineering team satisfaction and member retention.
An engineering manager may have a lot of knowledge about the development process and team effectiveness, but it's important to be aware of pain points the team experiences using internal tools. Cognitive load refers to the overhead required to do common tasks and is often related to technical debt. High cognitive load might be the result of having a lot of repetitive process steps or manual interventions that reduce developer productivity. It might also be a result of relying on tribal knowledge -- undocumented expertise that team members gather with experience, but that creates steep learning curves for new engineers.
The solution to high cognitive load is to prioritize automation for common tasks, work to reduce technical debt and make process documentation a priority. Your goal as an engineering leader is to work with and listen to your team about which tools are needed for each part of the dev process. I'm not necessarily advocating for a democracy where each member gets to choose their own tools, but as a leader, you should be in tune with what tools will help reduce friction and streamline the development process.
Pattern: Hone Product Management Skills
Product management has a wide variety of definitions and associated roles, and processes and capabilities can differ widely across organizations. I'll define product management as the practice of managing the life cycle of an organization's product. Think of product management as the glue that unites business, design, and engineering with customers, ensuring the product meets your customers’ requirements, is salable, and ships on time and on budget. Ultimately, product management is about delivering customer value.
Engineering and product management are related disciplines, and like other types of leadership, you'll find many commonalities. The intersection of product and engineering management expertise includes strategic and technical skills, business acumen, a maniacal focus on the customer, and of course, the ability to lead your team.
Even a lightweight version of what full-fledged product management looks like is beyond the scope of this article, but it involves understanding what users of your product want, prioritizing work based on those requirements, and building/upgrading the product. Note the similarities with engineering!
Product problems relate to feature, growth, scaling, and product fit work. Feature work correlates to capturing value by fitting a product's functionality with its target market. Growth work has to do with accelerating market acceptance, usage, and adoption. Scaling comes when you've done a great job with feature and growth work, and your (very positive) problem is ensuring the product scales to meet demand. Finally, product fit or expansion relates to moving beyond linear growth, including adjacent (or even vertical) markets. Your job as an engineering manager is to help your organization be successful with product-adjacent leadership. This includes making your team aware of the different types of product problems and helping them navigate the complexities of working on the right product at the right time.
Pattern: Create the Culture
...the totality is not, as it were, a mere heap, but the whole is something besides the parts -- Aristotle
We work in teams to get more done, increase our collective IQ, and build better systems with increased quality and innovation. To me, that sentence stands on its own merits. But don't take my word for it -- much brighter people have studied teams and have come to similar and more rigorous conclusions. Several years ago, Google set out to do just that.
A project was undertaken by Google researchers in 2012 with the goal of understanding what made some teams excel. Code-named Project Aristotle -- a tribute to the phrase often misquoted as "the whole is greater than the sum of its parts" -- and a reference to researchers' belief that employees can do more together. Their goal was to answer the question: "What makes a team effective at Google?"
The team began by reviewing fifty years of academic studies, looking at how groups worked, and combing through data from 180 Google teams. They were expecting to leverage their market prowess in search and find a set of quantitative metrics that could explain what distinguishes a high-performance team.
To their surprise, the data didn't point to a specific pattern. Instead, the researchers concluded that what distinguished a "good" team from dysfunctional groups was how teammates treated one another. The right norms, in other words, could raise a group’s collective intelligence, whereas the wrong norms could weaken a team, even if, individually, all members were exceptionally bright.
Shared beliefs shape team outcomes.
Amy Edmondson, a professor from Harvard University, has previously defined psychological safety as a "shared belief held by members of a team that the team is safe for interpersonal risk-taking." Shared beliefs shape team outcomes. Psychological safety is a sense of confidence that the team will not embarrass, reject or punish someone for speaking up.
The Project Aristotle researchers found that while it was important to cultivate a sense of member dependability and ensure the team has clear goals, the biggest factor in applying strength to the underlying fabric of a high-performance team was a shared sense of psychological safety.
In addition to clear goals, team members need to understand how their work relates to the mission of the organization and how their projects contribute to customer value. In that environment, engineering leadership needs to exemplify being "direct and straightforward," which helps create space for team members to take risks.
Your job as an engineering leader is setting the example for psychological safety, including modeling and getting buy-in on team norms of behavior. Team norms can include things like conversational turn-taking and practicing empathy so members know it's ok to share something scary without fear of recrimination. It's also important to encourage collaboration and knowledge sharing and keep the group focused on continuous improvement.
The team is the molecular unit where real production happens, where innovative ideas are conceived and tested, and where employees experience most of their work. But it’s also where interpersonal issues, ill-suited skill sets, and unclear group goals can hinder productivity and cause friction -- Google's Re:Work
In her book, "Dare To Lead," Brené Brown compares armored to daring leadership. Creating a culture of belonging, inclusivity, and diverse perspective is an example of daring leadership. Daring leaders fight for the inclusion of people, opinions, and perspectives because it makes everyone on the team better and stronger.
The opposite or anti-pattern of psychological safety is shame. Embracing vulnerability means taking off our armor as leaders and opening up to shame. Shame is primal and universal. Shame is uncomfortable and difficult to talk about and is the intense feeling of believing that we are flawed and unworthy of love, belonging, or connection. When the team is open and connected, and leaders listen, there is better decision-making, critical thinking, and powerful experiences of empathy, self-compassion, and resilience. Empathy is the antithesis of shame. Empathy is at the heart of connection -- it is the "circuit board" for leaning into the feelings of others, reflecting back a shared experience of the world. Part of providing psychological safety for our teams is practicing empathy.
Empathy is at the heart of connection--it is the circuit board for leaning into the feelings of others, reflecting back a shared experience of the world...
If you're wondering if all of this is worth your time, note that there is a real cost in terms of team performance and engagement in distrust and disconnection. Your job as a leader is to invest a reasonable amount of time attending to empathy and psychological safety or an unreasonable amount of time managing poor performance.
In May of 2023, Noda, Storey, Foresgren, and Greiler published an article in ACM that frames the idea of Developer Experience (DevEx) -- focusing on those things that reduce points of friction and drive business performance through "increased efficiency, product quality, and employee retention." DevEx examines the lived experience of developers with the goal of reducing the things that slow them in their everyday work. The DevEx framework distills developer experience to its three core patterns: feedback loops, cognitive load, and flow state.
Feedback loops refer to the speed and quality of responses to actions taken. The idea is that developers can respond more quickly and thereby reduce friction when quality feedback is provided in a timely manner. To improve feedback loops, organizations should identify areas where development tools can be automated (for example, build and test processes, development environment setup, etc.) and hand-off processes and communication can be improved. Your goal as a leader is to help streamline team interactions to minimize delays.
Cognitive load elongates timelines and slows down the thing that we are trying to maximize: value delivered to customers. Reducing cognitive load means removing unnecessary hurdles and creating well-organized and documented processes and code. Educate leadership on what technical debt reduction means and why reducing it will lead to better team performance and productivity.
Flow state is when a developer is energized, focused, and has the ability to delve deeply into algorithm creation or problem resolution processes. Frequent experiences of flow state lead to higher productivity, innovation, and employee development, and your job, as a leader, is to maximize that capability by managing work-in-process or WIP and reducing task switching.
Conclusion
Software continues to eat the world, and leveraging a company's development investment is of paramount importance in staying competitive. Building high-performing engineering teams includes providing the right tools, honing the team's product management skills, and creating an environment where engineers can thrive. Companies that learn the patterns for optimizing software engineering teams can leverage technology to deliver stronger business outcomes and increased competitiveness.
What's worked for you in creating high-performance engineering teams?
