Engineering managers are former individual contributors

weltview2 pts0 comments

The best engineering managers are former individual contributors

Better than Random

SubscribeSign in

The best engineering managers are former individual contributors<br>Empathy from experience beats corporate-robot feedback

Better than Random<br>May 25, 2026

Share

Photo by Eric Krull on Unsplash<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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?”.<br>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.<br>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.<br>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...

business from because like learn problem

Related Articles