Managing engineering teams through constant change

I recently spoke at Fluent and Velocity, and the following is an abridged version of my script on managing engineering teams through constant change. You can listen to the complete talk with stories and examples here.

You wouldn’t know it from my LinkedIn profile, but I can be a risk adverse, change avoidant person. My career traverses an interesting course from structural engineering to management consulting and startups through to my current job as an engineering manager at Twitter. But I started out by choosing my college major, civil/structural engineering, at 17 and never changing it, working straight through to the completion of my master’s degree, and landing the plum job with my dream structural engineering firm. I’ve lived in the same house for 17 years, and I’ve been married to the same person for 20. I’m a planner. I have plane tickets for a trip in 2018 that were purchased in April 2017.

As a software engineer with this planning mindset, I’ve known the temptation to think that my goal was to create the perfect project, or the perfect team, or the perfect build process, where everything is right and in its place. Then, lock it down and just maintain. Stay in control.

But in the tech industry, even if you somehow crafted that perfect team, the next day, there would be a reorg that changes the roadmap and sets up all new priorities. And the day after that, three people would resign. And the day after that, you’d get a new boss. Now what? So much for your perfect team.

As a Silicon Valley engineering manager, perfect control, in a perfectly static environment where everything goes smoothly, is not your goal. Your goal is to build a resilient team that can withstand the swirl of constant change. And more than that, your goal is to harness change to generate opportunity and growth for your team.

When we managers build teams, we tend to focus on processes for improving efficiency, retention, and performance. But when it comes to change, what you especially need are systems that will build in resilience. Some of the suggestions below are common management techniques, but I’ll point out how they contribute to building resilience.

8 Ways to Build Resilience

1. Know your people and cultivate trust

Commit to regular 1:1s. Mine are bi-weekly for 30 min. We talk about career goals, where a person is the promotion process, team dynamics, and projects. As a manager, you should be mostly listening. Knowing the goals of your people will be very helpful later if you need to shift projects or people.

During 1:1s, commit to 100% follow through. I often have action items that come out of 1:1s — questions I said I’d get answers to, articles I want to pass on, introductions to make. Following through on little things builds trust that you will also follow through on the big things — that you are a person of your word. Later, when you explain changes, you’ll be credible.

Don’t make promises you cannot keep. It’s tempting to want to promise promotions, projects, etc., but if you don’t have the authority to make it happen, or if the timing is far off in the future, there are too many things that could jeopardize that promise — so don’t make it. Stick with things you will do: “let’s put together your promotion packet” is a lot different than “you’ll be promoted by the end of the quarter.” Broken promises feel chaotic which just adds to the noise in a changing environment.

2. Focus on fewer high impact goals.

We get trapped into thinking we can do multiple big projects at once. Some of the most successful, ambitious projects I’ve worked on have only shipped because we asked our stakeholders for space to complete something important, like a platform migration, without working on features at the same time. Mark Zuckerberg famously talks about the crucial time when Facebook shifted all efforts to going mobile first. They stopped feature development for two years to get that done! Also, if you have fewer projects, you’ll have fewer things that might pivot when priorities shift.

3. Break things down into short term projects.

You need to be thinking minimum viable products (MVPs), phases, modularity in deliverables. If you are in a fast-paced, dynamic environment, you probably don’t want to plan year-long projects. I try to stick with projects that can ship within a quarter. Break things down so that you can be constantly successful shipping smaller features. When you’re asked to change priority, it’s easier to ask for a week or two to wrap things up than to ask for months or quarters.

4. Foster a collaborative environment by valuing open questions and vulnerability.

Change often thrusts people into unfamiliar roles and new technologies. The more psychological safety people feel on the team, the more willing they will be to take on something new and challenging when change comes. I try to model vulnerability by being open about what I’m learning and what I don’t know, and I encourage team members, especially the most senior ones, to do the same.

5. Be a predictable, stable manager.

You don’t want to add to the change and chaos — you want to be the calm port in the storm. Your team will need you to reassure them that everything will be okay. Avoid adding emotional drama, avoid being erratic, and if you’re feeling stressed, find a safe person to whom you can vent away from your team, like a peer in another department.

6. Put information in obvious, intuitive places.

At Twitter, we use go/links, which are short urls that can redirect to anything in our network. Usually, you can guess where to find something just by going to go/teamname (directs to the team page on our wiki), go/project (directs to code documentation), go/service (directs to runbooks and API information), etc. Taking the time to invest in documenting your team, your code, your processes, your runbooks will pay off dearly when you’re dealing with attrition or onboarding new people.

7. Increase your bus factor.

The bus factor is a measurement of the risk of having one person be the only holder of important knowledge, based on “if they get hit by a bus on the way in to work, we’re screwed.” Actively look for ways to cross pollinate team members across projects and technologies to prevent knowledge drain if people switch teams or leave the company.

8. Shield the team from unnecessary politics and speculation.

As a manager, you will likely be aware of power plays in upper management, open discussion of reorgs, and platform decisions that could affect people’s roles. Just because something is discussed, doesn’t mean it will happen. Try to keep this noise away from the team until you’re sure plans are stabilized.

Responding Through the Change

Assuming you’ve built resiliency into your team using some of the strategies above, you’ll be in better position to weather changes such as reorganization, sudden roadmap or priority shifts, and management changes.

Once a change hits, you’ll want to:

  • Understand the source of the change so you can share it with the team at the appropriate time.
  • Acknowledge your fears and think through your worst case scenarios, then be prepared with possible options to present to the team.
  • Communicate changes to the team with timeliness and transparency, and provide the logic behind the change.
  • Empathize with the team. Expect initial resistance. Listen to their concerns. Be patient while they adjust to the new reality and come around to acceptance.
  • Adapt to the change with input from the team. Tackle the problem together.
  • Convert the change into opportunity and growth, based on knowing the aspirations of your team members.

My talk includes some specific stories and examples of working through the phases of change. In each case, the key takeaway is to use your leadership and insight as a manager to identify opportunities that might come out of a change, and then map those opportunities to your team members. For example, if you’re dealing with attrition, there’s often an opportunity for someone to take on a bigger leadership role. If you’re onboarding a lot of new people, your veteran engineers will gain valuable mentoring skills and have a chance to improve onboarding processes.

These days, I am more welcoming of change. When I open myself to the possibilities, change becomes a chance to dig out hidden opportunities for my team members. This doesn’t mean I pretend it’s all sunshine, but it does mean that I try to frame the change as something people can actively adapt to and leverage for benefit. If we’ve built up our resilience as a team, we can move people through fear and resistance to opportunity.

Comments are closed.

Blog at

Up ↑

%d bloggers like this: