Four engineering leaders from Trello, PagerDuty, Datto, and Algolia shared their vision of what it means to be an Engineering Manager during the Plato event hosted on June 29th, 2017 in Paris.
What is engineering management?
If you’ve never been a manager before, it can be difficult to know what to expect. Especially since the transition from engineer to engineering manager is a big one. That’s why we hosted a panel called, “What is Engineering Management?” as part of our “Engineering Management Talks with Plato” event on June 29 in Paris. The panel participants were engineering managers in successful companies:
- Sylvain Utard — Vice President of Engineering at Algolia
- Andrew Miklas — Cofounder and CTO at PagerDuty
- Benjamin De Point — Senior Engineering Director at Datto, Inc.
- Brett Huff — Engineering Manager at Trello; also the panel moderator
What you will NOT do as an engineering manager
Whenever you accept a new position, you spend a lot of time thinking about the different things you’ll be doing in your new role. But the important thing to remember is that as an engineering manager, the things that you will not do are equally significant. This is especially important for those who love to code and then take a manager role where there is no code involved, or it is involved but to a lesser extent. The panel participants shared a few of the newfound responsibilities that come with a management role:
1. Developing team members’ decision-making skills. Sylvain challenges the people on his team to make their own decisions based on the input. He may guide them with questions and pointers about what might happen, but in the end, they make the final call.
2. Delegating technology solution decisions. Andrew, on the other hand, removed himself from the equation when it comes to choosing a technology solution to use, and let senior engineers make that decision.
3. Deploying code. While he still has access to the code, Benjamin distanced himself from day-to-day code development. However, he still reviews the code during team member evaluations.
How to be a good engineering manager when you don’t have formal authority
It’s no secret that many companies, especially startups, are ditching the hierarchy and adopting a flat structure — some of them don’t even have a formal CTO. From an engineering manager’s point of view, when there is no formal authority figure, things can easily go haywire. The panel members shared how they deal with it in their companies:
1. Benjamin said that Datto has self-organized scrum teams, and while the tech leads are not above all, they are part of the team. The tech leads are not the only person in the room — the scrum team makes decisions based on consensus. Additionally, you can define a framework that you can use for making decisions.
2. Sylvain made a mistake of creating a flat structure in Algolia, and quickly realized that when you scale a company, flat teams don’t work — at some point, you will have too many people at the same level with different opinions, and decision-making will become harder. He points out an example of what Spotify did — they created squad organizations where every squad is in a flat organization, but each of them has responsibilities and accountabilities, so when you want to do something, you don’t need to ask the other 59 people in the company that are exactly at the same level as you.
3. From Andrew’s experience, both flat and centralized structures may work from company to company. You want to make sure that you decentralize decisions, but don’t go overboard. Avoid situations where you have each team picking its own languages and databases, because it could make things severely complicated, especially if people move to different teams. You can make a decision with the CTO on the top, or you can have the senior engineers make a collective decision.
How to effectively disagree with people
Whether your organization has a flat or centralized structure, there are always going to be disagreements — with team members, managers, and possibly clients. Knowing how to deal with these disagreements without burning bridges is crucial. The participants shared some tips.
- “There is something we do a lot at Algolia — it is really trying to solve problems,” Sylvain said. He pointed out that the other person needs to realize there’s a problem, so guiding the conversation in the problem’s direction can help, e.g., “Why did you use that specific programming language when you are the only one who knows how to solve potential issues with it company-wide?” Make sure each person takes ownership of something — a topic, product, etc., and makes all final decisions and takes full accountability for whatever he or she owns. If it fails, the whole company learns from it.
- Brett and Andrew both agreed that you should take time to define failure.In engineering, people can take it very personally when someone votes down their particular choice, product, feature, or technology. When failure is defined, it’s easier to explain why that particular choice may be bad and causing failure.
- Distance people from their code or product in a way that they still care about it, but not too much as to get offended when you point out a flaw or improvement area. Benjamin gave a great example of how he asks people this particular question: “If you would use the human relationship to describe the relationship with your code, what would it be?” Many engineers describe their code as “their baby.” Benjamin pointed out the problem that may arise if you tell someone that their baby is ugly. The best way is to look at the code like it is your third cousin.
Don’t think of code as your baby. Think of it like your third cousin.
How to manage the fear of losing contact with technology if you don’t code
As an engineering manager, you either reduce your coding time or stop coding completely. Since technology is constantly changing, it’s hard to keep up with everything, especially since you’re no longer in the thick of it. It’s understandable why engineers fear falling behind on technology trends once they become engineering managers. Here’s what you can do to prevent that:
- Do peer reviews and challenge engineers to point out the quality in the code that they produced, as Benjamin does.
- Just like Sylvain, you can still code if you focus your attention on quick fixes and wins, that way managing the feeling of missing out.
- Review the code and architecture, diagrams, and artifacts, like Andrew does. You can do that by basically staying in constant communication with other people and your team, and asking them about what they’re building, what they enjoy, their pain points, and their biggest accomplishments.
Watch the full video of the panel discussion below, and be sure to check out our YouTube channel to see the rest of the presentations from the event!