Failures of engineering management (Part 1)

I currently work as an engineering manager @ Doordash. Most recently, one of my directs asked me something that I’ve been pondering over for the last couple of weeks.

“Anderthan, we have a culture of shipping fast, and a culture of celebrating wins, but we never talk about our failures. What are your failures?”

I’ve had many failures in many parts of my life. I wasn’t sure where to start. I told my direct, Rohit, that I was happy to dive into different failures, but it would make more sense if I did this in a scalable way so that everyone that cared to learn could learn from my experiences which would be a superset of my failures. So here I am — this story will be one of many to follow.

My first time firing someone

About 4–5 years ago, I started managing a mobile team at a small startup. There was someone on my team (let’s call him Scott). Scott was a smart engineer, but never really put in the hours everyone else on the team was. During our 1:1s, I would tell him he needed to work harder but not really give any targeted and actionable feedback. I thought it was obvious he would understand why he needed to work harder! We were in a pinch to raise our series A, every hour he put in would be an hour extra in his career, and if we were successful he would be well off in his career and financial.

After a couple months (yeah, I waited that long), Scott was still not performing up to par. At this point, I was dreading talking to him in our 1:1s. In my mind, I was hoping that he would be really unhappy working with us, and would leave and both sides would be better off that way. Scott stayed. I ended up giving him an awful PIP (performance improvement plan). It was something like “If you don’t improve in the next 6 weeks according to my standards, we will terminate you. Areas to improve are: become a killer iOS dev, and build cool shit so we can raise our series A round.”

It was clear after 6 weeks that Scott didn’t improve at all. I scheduled a meeting with him to talk about termination. Going into the meeting, I was super nervous. We sat down and I told him I didn’t think he improved at all, and that we would be parting ways. Honestly, I don’t know who felt worse.. me or him. My delivery was awful, I was looking at the ground the whole time, and I was getting close to crying. Scott was confused at the outcome. He brought up the fact that he was a better iOS developer, and that he felt like he was contributing a lot to the company. I didn’t budge, and we parted ways.

Reflection

To this day, I spend time reflecting on my experience with Scott. As a manager, I failed terribly to be a good manager to him. Here are some of my learnings from the experience:

• Spend time to understand what motivates an individual. A lot of times people will tell you what they think is their motivation, but you need to understand their true motivation. By understanding one’s true motivation, you can better align the business needs with people’s passion.
• Actionable feedback is super important and depends based on the level of your direct. Nothing is worse than “just improve” or “I want this done faster”. As a manager, if there is a disconnect between your direct’s performance and your expectations, you need to figure out why, and address it swiftly. Junior engineers will require very specific feedback (i.e. I want to make sure 100% of your business logic code is covered by unit tests). Theoretically, senior engineers/leads/EMs at most companies operate at a higher level than just feature development, so I tend to look at metrics (i.e. Our DB load is trending upwards, may be good for you to take a look and reprioritize accordingly). Also don’t be afraid of giving harsh feedback. It’s better to give it (be mindful of the execution!) than to be afraid and hold it in.
• Being able to manage someone is a privilege. It’s a two way protocol (as a manager, you are doing your best to get them to succeed, and they are attempting to do their best in the environment you constructed for them). An environment is more than the physical environment. I would think of it as “how do I set up this individual to succeed?” For example, asking a junior engineer to work on research communication patterns between micro-services may not be good, or asking a mobile engineer that is strong in architecture to work on only making things pixel perfect would be a terrible use of talent, interest, and skill.
• When writing PIPs and delivering them, it’s important for you to see it as a chance for success and not as a necessary evil before terminating someone. Change your mentality to root your employee for success. Give them reasonable and actionable ways to improve and outcomes they can actually control. Make sure you give them a fair chance and make sure you try your best. That way, whatever the outcome is, you’ve done all you can and you can move forward with no regrets.

Conclusion

I still have a lot to learn myself. I’d like to thank Scott for putting up with me. If you are reading this, I’m sorry and I know I messed up. I can’t change the past, so what I can do is make sure I learn from all of my past experiences and move forward and be the best I can. I’m hoping that someone else will read this and not make the same mistakes I did.

More to come,

Anderthan