The expectations for engineering and engineering leadership have changed tremendously in the last 20 years.
In the early 2000s, Engineering was a cost center, and almost every large organization was outsourcing their talent, which led to lousy outcomes for many companies. But today, we know that software is the core of most businesses. As a result, we now have more demand than supply for engineers, which creates challenges for finding talent and keeping it.
This is where engineering-first culture comes in.
If you look at software engineering, it is very much a creative endeavor. It’s not people standing in an assembly line, putting things together. It’s problem-solving, and a lot of creativity is involved in that. An engineering-first company culture places engineering at the heart of the company because there’s a clear understanding that engineering is where the rubber meets the road.
Today I will explore what it means to create an engineering-first culture through the lens of Daniel Pink’s Drive Theory, look into how data and metrics can help enable engineering-first cultures, and how to maintain this culture as you scale.
🚨 Not to be confused: An Engineering-First Culture is not the same as an Engineering-First Company. Eng. First Companies build products for developers. Eng. First Cultures are easier to foster in these companies because the purpose is evident when building for your peers. However, this doesn’t mean you can’t create this culture in companies not primarily building developer-oriented products.
The Three Pillars of Engineering-First Culture
We can look at Engineering-First cultures through Daniel Pink’s lens to try and evaluate whether you’re fostering an engineering-first culture. Pink believes that it all comes down to motivation, and the three pillars of motivation are:
Autonomy: The desire to direct our own lives.
Mastery: The urge to get better and better.
Purpose: Working towards something larger than ourselves.
Let’s explore each of the pillars.
Autonomy
Engineering is a creative job, and when you're in a creative career, you want to be able to make decisions, to create without having to jump through hoops and without having others gatekeeping you.
We want to enable the engineers in our organization to move fast and autonomously. Excellent developer experience fosters Autonomy and it's infinitely linked with how we impact the end-users.
As an engineering leader, you need to ask yourself: Is an engineer here able to work on things and bring them to the end-user? Can they deliver software themselves to that end-user without blockers in between?
Mastery
Mastery is giving the engineers in your organization the opportunity to continue to grow and learn more about their field by giving them access to all the resources to do so. From conferences, to books, to meet-ups, to a career ladder where they can continue to improve and have interesting challenges.
At the end of the day, most of the learning in an engineering organization comes from having people work on problems that are interesting to them. It’s not just about writing the code but actually being challenged with difficult problems to solve as they grow in their careers.
Purpose
I’ve talked about how purpose happens when your teams can see the impact they are having on the business. But finding metrics that can show your team’s impact on the business can be challenging.
So I like to divide purpose into two domains:
👉 Business Purpose: “I am working somewhere where I know that I’m having an impact as an engineer.”
👉 Organizational Purpose: “I am helping a team, pushing things forward, and having an impact on the organizing.” (eg., writing an internal document that improves communication)
A Few More Key Practices for Building an Engineering-First Culture:
🔑 Not having people drown in meetings.
🔑 Empowering engineers to pick the technologies and tools they use.
🔑 Creating an interview process that reflects the actual work of the company instead of arbitrary challenges.
🔑 Giving engineers the freedom to work on Skunkwork projects and the kind of things that move the business forward. This signals that we value you as a member of the team, and you’re not here just to move tickets from left to right.
🔑 Having high psychological safety and accountability:
How Data and Metrics Play a Role in Enabling Engineering-First Cultures
You can only have an engineering-first culture if you're invested in continuously improving how you build software and the developer experience - data and metrics are essential in that.
Engineer organizations aren't static. If you're growing as a business and a team, time builds up the organizational and tech debt. When you build software, you're constantly building on top of something. So having a culture of continuous improvement is critical early on.
Metrics and data help you answer questions like:
“Is the team enabled to deliver software really fast to the end-user or are there a lot of bottlenecks for it?”
“Is the team able to spend more time on adding new features than just fixing bugs the whole time?”
“Is this an organization in which we're constantly shipping new features to our end users or is it one where an engineer joins and the changes she makes today don't show up for another six months to the end customer?”
It’s very demoralizing to do creative work and not see the impact of it. This is where velocity metrics really matter. Velocity metrics tell us:
👉 How quickly we go from starting on something to getting it to the end-user.
👉 What percentage of effort from the team is going to tech debt.
This will help us ensure that we're not building a codebase in which we're unhappy. It helps us understand where frustrations are coming from and what the experience for developers is. The metrics and data give us an understanding of where we're at and where we can improve. And we can attach something actionable to that. For example, a goal to improve X, Y, or Z, will then translate into the happiness of engineers.
At the end of the day, the ultimate metric in an engineering-first Culture is whether engineers are motivated (or churn) - and that’s where those three pillars come in.
Three Tips For Maintaining an Engineering-First Culture as You scale
1. Most of the processes you’ve had before you scale break down the moment you’re undergoing scale. So, you need to understand the impact of growth on your teams and your processes. This is where metrics and data are absolutely key. They can help you understand the impact of these changes.
Important reminder: The number of communication lines and dependencies will increase exponentially when you scale. Here’s a visual representation of this:
.jpeg)
2. Build a process and culture of continuous improvement where you’re constantly working on the things that either slow you down or impact the quality of your software and the happiness of your engineers. Be proactive about it by looking at data, talking to people, and setting initiatives in your company.
3. Have someone - ideally an engineering ops team, - responsible for building and maintaining an engineering-first culture. Some companies will do this at 50 engineers, or 100 engineers, others even earlier. But it’s important that developer experience is owned by someone, so that it’s more proactively improved than just being a part of every engineering leader's role.
I’ll leave you with a recent twitter thread where I asked engineering leaders to share their communication tips and tools 👇
