Managing Engineers: Minimizing Risk and Surprises [Podcast]
Are you a new team lead? Just promoted to manager? Here's a great list of tips for you to keep in mind to help your team succeed.
Join the DZone community and get the full member experience.
Join For FreeThe DevTeam Project is a library of stories from successful engineering managers around the world about growing, managing, and motivating excellent dev teams. Our mission is to help dev teams learn from the top global engineering leaders about trends today and what’s shaping their industry. To achieve this we’re going to release a podcast episode and a blog post with highlights from the conversation every other week. In each episode we’re traveling to meet a prominent engineering leader and talk about their unique perspective and insights.
We are excited to launch the DevTeam Project in collaboration with DZone.
You may also like: My Top 10 Technology Podcasts
What Dev Managers Need to Know
Jeremy Stanley is the Senior Engineering Manager at Thumbtack, and an experienced engineering leader who previously worked at Facebook, Pinterest, and Medium. Over the years Jeremy has led and developed large teams of software engineers in re-architecting VR and web platforms. At one point he managed a team of 16 software engineers — half of whom went on to become engineering managers or leads within two years. I sat down with him to get his thoughts on how to manage the growth of a software engineer into a tech manager.
Short on time? Here are 3 key takeaways from Jeremy on the role of the Senior Engineering Manager:
- Minimize risks and surprises. Set clear expectations early and check in on them at a regular cadence. Expectations evolve with time.
- Grow your team so they don’t need you anymore. And don’t be afraid to step away from your desk — a team should be able to function with or without you.
- Invest in a robust recruiting pipeline. A robust pipeline means that you have a backup plan when a rigorous performance review pipeline brings underperformers to the surface.
What follows is a long-form write up of the key topics we discussed in our interview.
I think everyone has a superpower.
When it comes down to any kind of leadership position, you need to be aware of the value that you can bring. What makes you different? For Jeremy, it's his ability to be a universal adapter. If you’re trying to get from point A to point B and the path isn’t clear, then Jeremy is the person to help you get there. Creating a path forward is something that he's mastered over the years.
In fact, within two years Jeremy grew half of his 16-person software development team from engineers to managers or leads. This was a result of several factors.
"When you progress through your career you end up having to trade off tactics at lower levels for strategy at higher levels."
Managers need to think about why they're even doing the work in the first place, not about the code that's being written on a day-to-day basis. Remember that the tech manager manages people, not code.
One of the most valuable things that an individual contributor (IC) can do is free up their manager's time to focus on strategy. Jeremy reports to the Head of Engineering at Thumbtack and is "always thinking about what [he] can do to alleviate [the Head of Engineering's] workload."
He expects the same from the teams that he manages. "I look at my teams and try to figure out if they are interested in a certain area — cause if they take ownership of what they’re interested in, then I have more time for strategy."
The Transition to Manager
When asked about his prior professional experience, it became clear that Jeremy has a deep technical background. He was an IC before becoming a manager — a natural progression — and so is familiar with the transition. "I think being able to speak competently is important — speak to ICs like you are peers, not as a hiring manager trying to bring someone on their team."
So when considering the transition to the manager, it's important to ask ICs: “are you sure you really want to do this?” There’s a fundamental difference between an engineering manager and a tech lead.
Managers are responsible for people and the direction of the company (to an extent) — they have to be people-oriented. Tech leads are different because they’re responsible for the code, infrastructure, and architecture.
After you determine that an IC is sure about moving to management, the first step is to ask them “why?” What are they trying to accomplish?
It differs based on the individual. At Pinterest and Facebook, Jeremy cited having to be at a certain level to request being a manager but this likely will be different for smaller companies, such as startups.
The next question becomes: “how do I ease you into this?” Interns are a fantastic way to ease someone into management.
For more senior candidates, figure out how they can run and interact with a small team that functions autonomously. How do they take control of the overall direction and strategy?
Jeremy tries to see the potential in people. He regularly has deep career discussions with his team so that he's aware of the type of work that gets them energized. What are they passionate about? If someone hints that they are interested in accountability, this is something that is a strong basis for management.
He's also hired managers to his team in the past because they simply voiced wanting to be a manager. These are great conversations to have. His response is always: “great, let’s do that once you convince the people on your team that you’d be a good manager.”
"I’m not of the mindset that a manager needs to start out as an IC, but when a new hire comes in and builds up the team and proactively seeks 1x1s, that’s a significant indicator."
The team needs to be bought into the person who wants to be the manager. It’s not a requirement but it helps a lot and is fundamental to being successful as a leader.
Plan for Failure
What about engineers who try to become managers but fail? Jeremy smiled and said he had a good analogy for this. He explained that his two kids used to run all over the house as soon as they could walk. "The rule that I went by is that generally a child can fall from anything that’s their own height, and they will be fine." Our bodies have evolved so when you fall over, you’re built to take it.
"This is the tactic that I take for my teams — for people who want to be managers or really any leadership position in general, I always try to set them up so that if they 'fall,' it's from a manageable height, not a 12-foot cliff.” Remember that even falling a little bit is a learning process and it’ll be ok.
The most often cause for failure is not setting expectations clearly. Managers should try to do as much due diligence upfront as possible. If it turns out that something is missed — try to learn from what happens and avoid making the same mistake again.
People fail if they don’t understand all of the complexities that go with taking on a leadership role.
"I’ve seen cross-functional programs where someone leads it, but doesn’t know how to get other teams to resource appropriately." You need to set expectations on both sides. Is everyone on board? Are you checking on expectations with reasonable cadence?
Know Your Strengths
Imposter syndrome is something that Jeremy has experienced at different points in the past. The manager or not, this is a common experience — but there’s more to imposter syndrome than just considering someone for a leadership role. Imposter syndrome can affect performance reviews and how peer feedback is given. As a manager, you have to look at the people that you’re interacting with. What is their participation style like? How about the conversation style? Figure out how you can build mechanisms to encourage maximal participation from everyone.
Meaningful interaction goes a long way. A good engineering manager will step away from their desk every once in a while. While at Facebook, a director once told Jeremy that one of the most powerful things a manager can do is “not be so available all of the time. If the team can do well and operate without you there, then you’ve effectively done your job.”
Jeremy reiterated that he knows plenty of managers who subscribe to the mindset that your job is to make yourself not needed. You need to be iterating in a direction where the job that you’re doing is no longer there, and instead, you're focusing on the next tier of work. Be able to deprecate your job in order to move forward while training people to take on the work.
It’s also great when engineering managers practice empathy and good intentions. A good manager will try to figure out why things are done a certain way, if they’re optimal, and align with them on the approach. The responsibilities of a tech manager may differ based on company size and tend to not be as well-defined for startups.
It Starts With Recruitment
"These days I find myself injecting into the recruiting pipeline and thinking about why we are recruiting people ... an inordinate amount of my time is being spent on meta-engineering."
How do we recruit? Are we intentional about it? How do we measure recruitment efforts? What does success look like? You need to position your pipeline so that if competition cropped up for your company, you’re able to respond. The goal should be to not only get candidates through the door but to make sure that 1 year later they are happy, successful, and growing.
"I think the general industry consensus is that tech hiring is bad and it needs to be better — but nobody knows how to make it better. I make the argument that 4-5 hours with a candidate should give you a decent signal but there’s also the fact that people can be good at positioning themselves as colleagues."
We’re in a buyer’s market — there aren’t enough people relative to the jobs. Remember that people have options.
Published at DZone with permission of Kuba Kucharski. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
-
Observability Architecture: Financial Payments Introduction
-
The SPACE Framework for Developer Productivity
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
Comments