This tweet got me thinking about change, and how software engineers (and especially, Platform teams) can drive cultural change throughout companies.

First, let’s take the question. You want to change the engineering values that your company is expressing. You don’t just want to create a heavyweight process (your checkin fails if you don’t reach X code coverage, for example), you want engineers to start to value these things enough that they don’t need a process to enforce them.

I’ve driven and watched culture change happen enough times to know how to do it from the position of senior leadership. You change what you reward and focus on, and repeat that change enough that people will start to naturally change their perspective (or, sometimes, leave). If you go from putting all of your focus and attention on new projects and turn your prioritization to stability, taking the time to praise teams who improve their stability, promoting engineers who complete projects that are related to stabilization, and crucially, set prioritized goals for your teams to work on stability, your culture will change from prioritizing new projects to prioritizing stability. …

Have you ever worked on a team that felt like it was just stuck in a rut? Somehow things were always just one fix away from improving: the next project, the next quarter, the next hire, this would turn the situation around. And yet these projects came, the quarters went by, new people were hired and joined and left and nothing ever really improved. It’s a sadly common situation, and one of the few that I believe can be laid squarely at the feet of the team’s manager.

I’ve spent a lot of time over the past few years thinking about how you know whether a manager is great. When everything is going well, all a decent manager has to do is not screw things up, and it’s not always easy to tell on paper whether a manager is merely good or truly excellent. A person might have thorough training, they might have a large team, they might even have smart things to say on Twitter, but are they actually great at the job? …

For the past 3 years, I have been running a platform engineering organization. Since that term is vague, where I work it means the software side of infrastructure. Compute platforms like kubernetes, storage systems, software development tools, and frameworks for services are part of the mandate. Our customers are other engineers at the company.

I also oversee the product team for this area. Now, I’m not a product manager (which I’ll shorten to PM for the rest of this post, not to be confused with project manager), and I rely on my PM team heavily for their expertise. …

A hard lesson for me over the past several years of my career has been figuring out how to pick my battles. I’ve seen many friends and colleagues struggle with this as well: how do you know when to involve yourself in something, and how do you know when to stay out of it? How do you figure out where the line is?

The setup

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. …

I got feisty on twitter today and wrote up some tweets on manager READMEs, a recent hot trend in management. Let’s break them down:

Well, what can I say, I’m sick of this trend. I’ve been a skeptic from day one, but what pushed me over the edge was watching one of my senior engineer friends react to this article on the concept. It mirrored the loathing I’ve heard from several senior engineers as well as the general negative reaction most managers in my trusted circle have about the concept. …

When I wrote “The Manager’s Path” I talked about what it means to work at the various levels of leadership, but I didn’t really talk as much about how you actually climb to those levels. For some people, it just happens as a consequence of being in a growing organization, and succeeding at growing with that organization. But how does that work, really? And how can you show that you are ready to take on bigger things when the opportunity comes along?

First, look at the role you are currently playing. If you are still spending most of your time deep in the technical details of the projects, you are probably not really working on the skills needed to manage managers. You need to develop the ability to leverage your attention and time through more people and projects, and that generally requires that you start looking outward (at people, teams, and related projects) and forward (to identifying opportunities, strategies, and potential pitfalls), rather than deeply down into the technical details. Be honest with yourself: Are you ready to spend less time in the technical details? If not, you are probably not going to enjoy managing managers. Is your team set up for you to spend less time in the details? If not, you need to fix that problem by developing new technical leaders, before you are likely to be tapped to manage more people and eventually managers. …

I’m often asked about the characteristics of great engineering managers. This is a question that almost always has a long answer that involves “well, she’s good at X, and he’s good at Y, and then there’s Z…” Every management role is slightly different, and a great engineering team will have managers who reflect a set of complimentary skill sets (such as operations, people management and coaching, product-focus) that are aligned with what their subgroup most needs.

However, for most of us, there is one characteristic that is not optional or debatable, which is that a great engineering manager is capable of creating a highly productive engineering team. This is one of the distinguishing characteristics of the management side of engineering. Call it what you will — drive for results, goal-oriented — if you are not great at getting your team to be productive, this is a critical growth opportunity. …

Effective delegation is one of the most critical skills a manager can learn. Without effective delegation, you fall victim to micromanaging your team, losing control of your time, and eventually failing to put yourself in a position where you can take on more and lead bigger things. There are many facets of effective delegation, and in this post I’m going to talk about one that tends to come from an otherwise good instinct: The failure to delegate because you are trying to be helpful.

“How can I help?”

I want my team to be happy and successful, and I want to feel useful and needed. So it’s not surprising that, when people bring me problems, my first instinct is to think of ways I can help them with these problems. Can I escalate it to one of my peers or my boss? Can I talk to the difficult employee for them, and try to improve the situation? Can I review the project plan and find the areas that are lacking detail and likely to cause the timeline to slip? …