The best engineering managers are former individual contributors

Empathy from experience beats corporate-robot feedback

Photo by Eric Krull on Unsplash

I was sitting in a 1-1 with one of my engineers. He had prepared a proposal, a real-time analytics architecture, complete with an ADR, architectural diagrams and a plan for a PoC. It was well-researched and technically sound, but we literally had zero need for it.

Suddenly a feeling of deja-vu kicks in. I have seen this before, because I did kinda the same when I was an IC. It was circa 2018, I was a data scientist and deep learning had been around for a few years now, leaving academia and reaching the mainstream. I wanted to get a sense of the topic because I perceived that it was quite different from the more “traditional” ML that I was already good at. It was not another boosted tree algorithm implemented in scikit-learn, it felt quite revolutionary.

I took a Coursera course by the amazing Andrew Ng. At the end of the course, there was a practical assignment. I didn’t want to pick a toy problem like distinguishing cat from dogs, or hot dogs from non hot dogs

So I picked a business-relevant problem. It was a type of prediction problem that the business invested in for a while, there were a lot of expectations around it, but the people working on it were never been able to credibly solve it. It was quite a hard problem and I was also not very sure about my attempt, but at least it was fitting very to be solved by the convolutional neural networks (CNN) that I studied in the course. So the plan was to get my hands dirty with some python and learn how to train CNNs and produce something potentially useful.

Nobody had asked me to work on that problem, and the previous attempt belonged to another team. I put together a PoC, got some results, started socializing my results, and the boundary between “side project to learn a skill” and “proper initiative” became very fuzzy very fast. My VP wanted a demo, there was awkwardness and some tension because the other team felt like I was stepping on their turf.

My manager at the time gave me a piece of feedback that sounded like “It seems like you wanted a pretext to play with cool tech without a clear business need nor alignment”. Was he right? Partially. I did want to learn deep learning, but I also made a real effort to aim that curiosity at something that mattered for the business. I didn’t fully agree at the time and I guess I don’t fully agree today either.

The feedback was not wrong on the surface, but it missed something. It was too corporate, it didn’t have that level of empathy of someone that could feel the motivation underneath because they lived it.

Now that I am on the other side of the table and one of my ICs keeps proposing new technology, I need to give him the same perspective my manager had given me, but with a different framing. When I sat down with my engineer, I didn’t deliver corporate-robot feedback, saying something like “your proposals need to be more aligned with business priorities”. Instead, I shared with him my own similar story. I told him that I understood the pull, that wanting to learn new things is good, and that curiosity is part of what makes someone a strong engineer. But then I also explained him that as he grows in seniority, the target starts shifting. The question would go from “is this technically interesting?” to “does the business need this?”.

When you move into management, the business makes it clear that now “you are one of us”. You receive training material that explicitly says that from now on you represent the company and its shareholders. You are at the bottom of the management food chain, of course, your equity stake is nowhere close to C-level, and you are still cannon fodder that can be laid off like anybody else. But the framing and the verbiage is pretty clear. You are a soldier for the business, slightly less a normal employee, slightly more an agent of the company. For ICs, this is never made explicit, but the expectation starts creeping in at the senior level and becomes critical at staff+. The higher you climb on the IC ladder, the more you are expected to act on behalf of the organization rather than your own curiosity or growth plans.

This framing was effective, because his next proposal were more tied to business problems and worked backward to the technology. The conversation landed because I have been an IC.

I am a strong believer that people in leadership positions need to come from IC backgrounds (I wrote about it here), otherwise they are closer to program managers that keep people on track. Technical credibility is the common argument. At any level a lead in a technical org needs to be able to read the code, challenge architecture decisions, tell when something is overly simple or overly complex. A non-technical manager in a technical team will always have a credibility gap, regardless of how good they are at everything else management involves.

But there is an additional value from being an ex-IC: pattern recognition from lived experience. When you have done the job yourself, you recognize behaviors because you have exhibited them, so it’s easy to empathize. A manager who was never an IC sees the behavior, they don’t see the motivation underneath: curiosity, career anxiety, boredom with the current stack, maybe all three at once. That recognition gives you a better starting point for asking the right questions, and it changes how you frame the feedback. The difference between correcting and redirecting is quite big. Having been there does not mean you automatically understand what is going on, but it puts you in a better position to know what questions to ask and to earn trust faster.

If you are hiring engineering managers, hire people who have done the work as IC, and the rest can be learned in the role.

---

Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews