Become the Leader Your Engineers Need

*Oren Ellenbogen is the author of ‘Leading Snowflakes’, and in this interview, he discusses some important tips for those moving into Developer team leadership. Read more interviews with some of the world’s best developers on our *blog or follow us on Twitter.

“I would definitely advise you to earn your teammates’ trust first,” begins Ellenbogen. “If you want them to follow your authority as a manager, you have to make sure you know how to build the trust of others, starting with your teammates. Figure out a way to earn their trust - maybe it’s your technical skills, maybe it’s your business understanding, maybe it’s a mix of everything. But don’t take it for granted and think that just because you have a title, that everyone should do what you say.”

With your credibility established, Ellenbogen suggests you then “clear the path to get more feedback”. He explains that “as engineers we have the luxury of a really fast feedback cycle. We have code review, we can deploy code and see tests running, and run it in production.” But we don’t have such established mechanisms in management decision making. However, Ellenbogen says that this should not stop you — “great engineering management develop good ways to bring in feedback, rather than just sitting in the dark and feeling alone.”

“A trick that has really worked well for me”, says Ellenbogen, is code reviewing management decisions. Ellenbogen took “the concept of code review and applied it to management.” By this he explains that he would “capture one or two of the dilemmas that I had during the day” and then he would ask some trusted colleagues “what they would do in this situation”. What he found was that by “just having a discussion around the dilemmas you have, you can really open up the way you are thinking,” explains Ellenbogen.

Another key aspect for any engineering leader is “to know the business inside out,” says Ellenbogen. “I know there are many engineers and engineering managers that feel that business is not our job — it’s the sales guys, it’s the marketing guys… but you can spend many, many days at the office writing software just to find out that nobody uses it.” So if you want to do what’s in the best interests of your team, then figure out the business so you can “understand the risks, understand the current capabilities that will help your business scale and how you can convey the message to your teammates,” suggests Ellenbogen.

A concern for many considering a move into management is whether they still get to code. But Ellenbogen suggests that at least at first, “I would advise you focus on feeling comfortable with your role as an engineering manager.” Coding is a safe activity for any developer, so “if you are finding yourself always shutting down and getting back to writing code all the time, that is kind of a red flag. That means you should probably just avoid writing code and focus more on the people aspect, or on the business aspect, and stop writing code,” says Ellenbogen. “You have to feel like your teammates are being productive and you are not being called on to save the day. Once you are feeling more comfortable with that, then you can go back to writing code.”

But it is important that you do still write code in the long-term, says Ellenbogen. At the very least you want “to keep your technical skills at a high level” so that you can “make sure you are a part of the conversation when your teammates need you”. When you do so, “focus on fixing bugs, dealing with nasty performance issues, reducing technical debt… or work on tools that will increase the productivity of your teammates.” But regardless of what you do, “you should avoid being on the critical path.” Interruptions are common and you don’t want to be your team’s bottleneck.

To get the best out of your team, sometimes it’s necessary to push members out of their comfort zones. But what’s the best way to go about this? “Start by setting an example that people can emotionally connect with,” advises Ellenbogen. “I shared my struggles with the team… I was just honest with my teammates… but later on when I talked with them about pushing them out of their comfort zone, just being able to relate to the way that I have been honest about my struggles just made the conversation a lot easier.”

Beyond that, Ellenbogen suggests that you provide “examples from inside the organization so they can see how it could be. For example, if I want to push someone out of their comfort zone regarding the way they are communicating their progress, I would forward emails from other teammates or other teams in the organization who are doing a brilliant job at it,” explains Ellenbogen. They can then pick a few things up from these and we can then “talk about it next time in our one-on-one and have a discussion around that.”

“Often engineering managers try to own everything,” says Ellenbogen. “They try to own the people aspect, try to own technical aspects, strategy, business”. There’s just one problem with this approach — it doesn’t scale. So what you must do, according to Ellenbogen, is “leverage the fact that you have great people working with you”. He recommends that you delegate ownership of key areas like code quality, to team members with a passion for them. Regardless, “I make sure that every time someone comes to me and says, ‘hey, we have a problem that we need to fix’, I write it down. I never ignore it,” says Ellenbogen. Then “I make sure we pick a few things we want to work at every couple of weeks or every month… so the team feels like things are not being ignored.”

Finally, a key part of the success of any team isn’t just individual team brilliance, but your ability to work well as part of the wider organization. To this end, Ellenbogen suggests that a great first step is to “share your plan for the next few months or the next few weeks with your peers”. “It might sound obvious,” says Ellenbogen, “but from my experience, very few do it.” He suggests that you “try to share as much as you can with others so they can understand what’s the plan and where you are heading.” Then follow this up by “asking for their opinion” and getting feedback from their perspective. Then “if things change, and that is alright, make sure that you keep everyone in the loop.”

*Read more interviews with some of the world’s best developers on our blog or follow us onTwitter.