Fog Creek

Becoming the Leader Your Engineers Need – Interview with Oren Ellenbogen

Looking for audio only? Listen on and subscribe


Up Next
Why We’re Bad at Interviewing Developers

In this interview with Oren Ellenbogen, author of ‘Leading Snowflakes’, we discuss development team leadership. We dive into the things great engineering managers focus on, how to ‘code review’ management decisions, keep code quality high and developers happy, as well as work effectively with other teams. You can keep up with Oren’s thoughts and resources about Engineering Leadership via his newsletter, Software Lead Weekly.

Content and Timings

  • Introduction (0:00)
  • Engineering Management (0:45)
  • Managers Who Code (3:28)
  • Code Reviewing Decisions (4:58)
  • Maintaining Code Quality and Keeping Developers Happy (8:38)
  • Working with Other Teams (11:28)
  • Recommended Resources (12:54)

Transcript

Introduction

Derrick:
Oren Ellenbogen is an experienced engineering leader who is currently Head of Engineering at Forter. He is also the builder and curator Software Lead Weekly newsletter and author of ‘Leading Snowflakes: The Engineering Managers Handbook’. Oren, thank you so much for taking the time to join us here today. Do you have a bit more to share about yourself?

Oren:
I spent most of my career in the startup scene, this is actually my fourth one. In the past eight years I find myself more and more enjoying the world of building teams and companies just as much as building product and software.


“If you are finding yourself always shutting down and getting back to writing code all the time, that is a red flag”


Engineering Management

Derrick:
To be a great engineering manager what are the main things you should be focused on?

Oren:
Honestly, it’s a really long list. I’d like to touch on some ideas I might have. I would definitely advise you to earn your teammates’ trust first. Don’t take it for granted. 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 its a mix of everything. Don’t take it for granted and think because you have a title that everyone should do what you say. This is first.

Second, I think that as engineers we have the luxury of a really fast feedback cycle. Where we have code review and we can deploy the code, and see tests running, and run in production. We have so many different feedback loops and when you are moving into the management world, it sounds scary right? Kind of feeling alone, it’s kind of a journey where you don’t really know the rules. You have a Computer Science degree, but there is nobody to teach you precisely what it actually means to lead others. I’m definitely thinking you should clear the path to getting more feedback. I think it is great engineering management for managers to have good ways to bring in feedback. Rather than sitting in the dark and feeling alone.

Third, I would talk about getting to know the business inside out. 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. It’s not my job I’m just here to build software. I believe this is B.S. because you can spend many, many days at the office writing software just to find out that nobody uses it right. If you are trying to protect your teammates then you should really understand the business and think how can your team help the business scale. I have been working in a few startups where we build products, we build features, and eventually nobody used it. We can say we don’t have technical debt, the software is great, but if nobody uses it then what is the point? So figure out the business, understand the risks, understand the current capabilities that will help your business scale and how you can convey the message to your teammates.

Managers Who Code

Derrick:
Engineering managers need to be able to switch between being a manager and being a maker. What is the right balance of time to spend in each mode?

Oren:
It really depends on the size of the team and your experience as a manager. Say if you have a really small team, like one or two people, then you can probably spend at least 50% of your time still writing code. I would advise to focus on feeling comfortable with your role as an engineering manager first. 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, on the business aspect, and stop writing code, even for a few months. You have to feel like your teammates are being productive and you are not being called to save the day everyday. Once you are feeling more comfortable with that you can go back to writing code.

Derrick:
It can be difficult for managers to get time to code and focus on specific tasks. What types of maker things should you own as a manager?

Oren:
I would focus on fixing bugs. Dealing with nasty performance issues, reducing technical debt. Doing customer support is a good one. And also work on tools that will increase the productivity of your teammates. The idea is to keep your technical skills at a high level so you will be able to help with prioritization and make sure you are a part of the conversation when your teammates need you, but you should avoid being on the critical path.

Code Reviewing Decisions

Derrick:
You say you should code review your management decisions. What do you mean by that, and why is it important?

Oren:
It is kind of a trick that has really worked well for me. I was referring before about lack of feedback that we are missing as managers. One thing that I try to say and think of is, “How can I take the concept of code review and apply it to management?” So what happens in code review? You are talking about a problem and you share it with someone else. You show them the code and the solution you have and you have a discussion around it. Is it the right approach? Do you have some comments about the way the code is written? Can I make it better?

In terms of management I was thinking to use the same thing. Meaning I tried to capture one or two dilemmas I had during the day and then what I did is I had some peers in the company, and I had my boss in the company, and I would ask them what they would do in this situation. What questions would you ask? Only then I would say how I handled the dilemma and the answer I gave them and we had a conversation around that. Just having a discussion around the dilemmas you have can really open up the way you are thinking and asking questions and also provide some feedback because in the beginning my boss always told me that I tended to fix everything on my own. I tended to provide solutions too fast. Ask more questions, let them lead the conversation.

Derrick:
To get the best out of our teams we sometimes need to push members out of their comfort zones. How can you go about doing that successfully?

Oren:
I would start by setting an example that people can emotionally connect with. When I was a manager I had a lot of struggles and I really tried… Well not in the beginning because I was kind of bad at it in the beginning, but later on I shared my struggles with the team. So when things didn’t work so well for me as a manager, when I wasn’t sure what was the right path for the team, or how to deal with the technical debt, or how to prioritize the technical debt. I was just honest with my teammates and people thought I was really struggling and 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 with them.

Next I would try to provide examples inside of 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, and say “Hey, look, this is a great way to summarize the status of a feature or the version. Check the way he wrote it, see if you can pick a few things and lets talk about it next time in our one on one and have a discussion around that.” So, use someone inside of the organization.

Third, I would really try to focus on making sure they understand their career growth really means a lot to me. Making sure they understand that I truly believe that if we are putting our people at the front it will make everyone’s lives much easier and much better. Make sure you send them to conferences. Try to help them prepare if they want to provide or give technical talks. Just be their biggest fan and make sure they understand you are there for them. This in the long term will help them and also help the company attract more talent.


“Earn your teammates’ trust first. Don’t take it for granted.”


Maintaining Code Quality and Keeping Developers Happy

Derrick:
A difficult management task is scaling an engineering team, like you mentioned you had experience with before, but doing that while keeping code quality high and developers happy, how can you go about doing this well?

Oren:
One thing that I would focus on is … We usually have, as engineering managers, we have technical leads inside of the team. These are the people who are the architects or technical leads. So my focus is making sure they are accountable for the code quality instead of trying to own it myself. Most often engineering managers try to own everything, they try to own the people aspect, try to own technical aspects, strategy aspect, business. I think that what you can do if leverage the fact that you have great people working with you and say, “Hey, the code quality is something on you. Yes I am going to be here if you want to talk about how to prioritize things or to make sure we have enough time to reduce technical debt, but I don’t want you to only point fingers and say hey, everything is really bad. I want to make sure you are part of the solution and that you are owning it.” So this is first.

Second I would make it very clear that I take technical debt seriously. That means I would definitely say to my teammates, “hey, if we have no technical debt then we are in trouble”. That means we are just writing code and probably nobody is using it because we are moving so slow and we are only focused on making the code better and better. The problem is there is no business around it. If we have too much technical debt then people probably just hate their job and leave. So you have to find some balance.

The way that I do that is to make sure that every time someone comes to me and says, “Hey we have a problem here we need to fix that.” I write it down. I never ignore it and say that it is not important. I make sure we write it down. I make sure we pick a few things we want to work at every couple of weeks or every month so the teammates can see that they are putting in new technical debt and we are removing it every week, every month. So they feel things are not being ignored and things are actually getting done. On your one on one with them make sure you ask them if they feel it’s under control. What I feel about technical debt is that it’s really hard to measure … there’s no real, like … We have no technical debt or we have 100% technical debt. When it comes to the feeling that we have a problem in our technical debt, make sure you own these feelings by acknowledging it and paying attention to it. That for me is like 80% of the solution.


“You can spend many, many days at the office writing software just to find out that nobody uses it”


Working with Other Teams

Derrick:
A common source of inefficiency and problems for engineering teams is a lack of trust between engineering and the teams they depend on. How can you build trust with other teams?

Oren:
It might sound obvious, but from my experience very few do it, is to share your plan for the next few months, next few weeks with your peers. Talk about the constraints that you have. They may be people related or technical issues but make sure that you are saying, “Hey, I am trying to go this way.” Try to share as much as you can with others so they can at least understand what’s the plan, where you are heading, instead of just shutting down and not saying anything.

Second, I would ask for their opinion. Like, “Do you think that the prioritization I have in place sounds right? Do you feel that I have forgot something? Is there something I am not seeing in terms of business? In terms of technical aspect that I am neglecting? Do you hear something else from my teammates that I am missing that they felt comfortable sharing with you, but maybe they are not sharing it with me?” Ask your peers and your boss’s opinion about the plan that you just shared with them.

Third is, make sure you are communicating the changes that you have in the plan. Let’s say that you are communicating for the next two months I am going to work on this and that. If things change, and that is alright, make sure that you keep everyone in the loop.

Recommended Resources

Derrick:
Beyond the book, what resources can you recommend for those seeking to become a better engineering manager and leader?

Oren:
There is a great Slack channel you can join by Michael Lopp. Also there is a wonderful blog post by Jason Evanish. It is filled with great, great leadership books. And lastly, it is just a shameless plug, I would add my weekly email Software Lead Weekly.

Derrick:
Oren, thank you so much for joining us.

Oren:
Thank you so much. Thank you.