Creating a culture of engineering excellence and team progress
In the first post of this series about building high-performing teams, I highlighted the most critical factor for developer performance: skills! The second post touched on the importance of fostering a generative culture. Now, I want to delve into a more controversial topic 🙂: performance, and how to cultivate a culture of high performance.
Having led organizations ranging from a single engineering team to over 100 engineers, my north star has been the same with these three fundamental pillars:
- Developing leaders with a growth mindset
- Investing in goal setting and measurement
- Accountability
Growth mindset
The most talented and impactful individuals I’ve encountered are those who are impressively eager to learn and push the boundaries. This is what I mean by a growth mindset. People with a growth mindset embrace challenges, persist through obstacles, learn from criticism, and find inspiration in the success of others. They see effort as a path to mastery and view failures as opportunities to grow and improve. This is why having a generative culture is so important—failure is part of the process!
Setting the right attitude and approach towards achieving goals is critically important as it significantly influences the motivation and behavior of individuals. Goal orientation typically divides into two main types:
- Approach Orientation: Focuses on achieving success and mastering new skills. Individuals with this orientation are motivated by the desire to improve, learn, and accomplish goals. They tend to engage in behaviors that promote learning and growth, viewing challenges as opportunities.
- Avoidance Orientation: Focuses on avoiding failure and negative outcomes. Individuals with this orientation are motivated by the desire to prevent mistakes and protect their self-esteem. They may avoid challenging tasks to minimize the risk of failure and criticism, which can limit their learning and growth.
Understanding goal orientation helps create environments that foster a positive, growth-oriented approach, encouraging individuals to pursue success and view mistakes as part of the learning process rather than as setbacks.
When building from scratch or up-leveling a team, the key for me is to first hire leaders with a growth mindset and the ability to coach and mentor, as these people become the biggest lever for team performance. Experts who have achieved a certain level of mastery don’t necessarily know how to share that knowledge, so I look for those who can do both. When hiring more junior developers, I prioritize eagerness to learn and coachability over specific language expertise or knowledge. The goal is to upskill the team because ultimately, skill is what enables delivery performance as measured by the DORA metrics.
With engineering leaders who have a growth mindset and the right attitude towards achieving goals, you are in a good spot. This leads to the next crucial part: goal setting and measurement.
Goal setting and measurement
We can’t discuss performance without addressing metrics and measurement. However, this isn’t about measuring developer productivity, a hot topic recently highlighted by a McKinsey article. Many weighed in on this, including Dan North:
Just don’t try to measure the individual contribution of a unit in a complex adaptive system, because the premise of the question is flawed. DORA metrics, for example, are about how the system of work works, whether as Westrum culture indicators or flow of technical change into production. They measure the engine, not the contribution of individual pistons, because that makes no sense.
Delivery performance and DORA metrics are better proxies for team productivity, but they are not sufficient on their own. While DORA metrics measure the efficiency of the “engine,” businesses care about the direction: where are we going, and when will we get there?
This is where business outcomes come into play, and these outcomes should be shared by the whole team. Customers care about the business impact of processes, tasks, or activities, not just the immediate output. Outcomes can be challenging to measure as they may be long-term consequences. In such cases, define smaller units of value toward the outcome that can be delivered in a week or quarter rather than defaulting back to output metrics. Here is an example:
Assume as part of a team developing a test management tool, we plan to release a new feature using GenAI to automate manual tests. We have several definitions of success:
- The feature being released 🚀. This is still what a lot of teams use as a success definition. Don’t 🙅🏻♂️. This is just the output and users may not care about the new feature. It may be just a waste of time.
- The number of users #️⃣. This is slightly better. Usage of this next-gen test automation feature is an indicator but not nearly good enough to be a proxy of the value delivered.
- Change in behavior and benefits 😇. The real outcome of a new feature is often a change in behavior that leads to a benefit. We could track, for example, the average number of tests automated per organization thanks to this new feature and correlate that number to a benefit: $x saved by test run.
Using outcome-oriented metrics as shared goals is a game changer for the teams because they stop thinking about just releasing a feature but now work creatively to deliver an impact to the business. Delivery performance (and DORA metrics) tracks doing things right, while outcome-based goals ensure you’re doing the right thing.
Accountability
For developers, being accountable means taking ownership of their work, responsibilities, and the outcomes of their actions. Accountability around DORA metrics and business goals involves a commitment to delivering high-quality code, meeting deadlines, and adhering to best practices. It extends beyond completing tasks to ensure the code is efficient, maintainable, and free of critical bugs. Accountable developers understand the impact of their work on the overall project and strive to contribute positively to the team’s success.
Accountability also means being transparent and honest about progress and challenges. Developers should regularly communicate with their team and stakeholders, providing updates and alerting them to any issues or delays. This openness builds trust and ensures that problems are addressed promptly, minimizing their impact on the project. Taking responsibility for mistakes demonstrates a commitment to continuous improvement and learning, essential for personal and team growth.
Accountable developers actively seek feedback and learn from their peers. They recognize the importance of collaboration and knowledge sharing in a successful development process. By participating in code reviews, pair/mob programming, and team discussions, they contribute to a culture of mutual support and collective responsibility. This collaborative approach enhances code quality and fosters a sense of shared ownership and accountability.
Ultimately, accountability for developers means high agency. They anticipate potential issues and continuously seek ways to improve their skills and the development process. By embodying these principles, developers enhance their professional growth and contribute to their teams’ overall success and resilience.
Final thought
Creating a culture of engineering excellence and team progress hinges first on developing leaders with a growth mindset, who not only learn aggressively but also mentor and upskill their teams. It also means aligning teams with ambitious business goals, pushing boundaries, and fostering accountability. By focusing on these pillars, organizations can cultivate high-performing teams that achieve their goals while continuously improving and building new talents. This has been my recipe for ensuring that teams do the right things, the right way, ultimately driving business success.