Engineering management is a career change, not a promotion
Ryan Murphy on what actually gets engineers promoted, why delayed feedback is cruelty, and the manager who told him on day one that he was a resource
I heard once from my manager that I’m a good resource. I didn’t like that wording, but it stuck with me for a long time. Then I had an opportunity to talk with Ryan Murphy, who shared a similar story. This was the reason he quit a job and decided to train other managers.
Before this, Ryan spent five years as an engineering manager at Yelp, leading teams that owned purchasing infrastructure. Those systems took customer money and reported it to Wall Street.
He now builds EM Accelerator. His argument for why it needs to exist: he has never met anyone who got real management training outside their own company’s HR-approved internal course. We keep handing people direct control over other people’s careers and hoping they figure it out. The teams pay for that education.
A few of his answers here will annoy engineers. I left them in.
In this issue:
Who Ryan is. Twenty years split between trading platforms for banks and brokers, then ad tech. Also how a layoff wave pushed him into writing, and into an audience of 80,000 across LinkedIn and his newsletter.
What he got wrong as a senior engineer. He chased the tech lead role by trying to be the best engineer on the team. That is the wrong path, and it cost him time.
What managers actually evaluate. Level by level: initiative from juniors, early roadblock detection and coaching from mid-levels, and from seniors, evidence you can lead the leads without taking the hard tickets yourself. Plus his honest note on what to do when your manager is the problem.
How management changed his definition of good engineering. His answer is direct: nobody is paying for your perfectly refactored function. They are paying for the seconds it takes off a support call.
Features versus outcomes. The distance between “works on my machine” and owning a metric is wide, but Ryan says it isn’t all on the engineer. Environments breed both kinds.
The engineers who were easy to promote. They adjusted the message for each audience and treated stakeholder updates as seriously as debugging. They were also the ones visibly holding things together during an outage.
One message to his mid-level self. Go sit with sales for three days. Go sit with support for two. A CTO once made this part of his job description, and it changed his career.
Where managers fail engineers. They postpone the hard conversation for two weeks, then two months. Ryan’s position: a significant share of the PIPs he has seen were created by a manager who couldn’t give feedback on time.
How to test whether management is for you. Be a tech lead first. One of the hardest roles in tech, no formal authority, and none of the skills that got you there will help.
Why he left Yelp. He was grieving his recently passed mother at the time, and it drove him to dare to bet on himself and be self-employed. Throughout his career, many things bothered Ryan, such as untrained managers, stalled careers, and teams that don’t feel safe speaking.
So, let’s dive in.
1. Who is Ryan?
I have been in Software Engineering for the best part of 20 years. I recently left my job as an EM at Yelp, where I spent 5 years leading teams that own the infrastructure behind purchasing.
My career has been in 2 phases: the first part was working on trading platforms for banks and stock brokers, and the second part has been in advertising. So I have a fairly good understanding of technology’s role in the world’s financial systems and also how that underpins advertising technology, which is the internet’s most famous business model.
My destiny was to always lead people, all the way back to when I got my first management gig leading just one person; it would be the most enjoyable part of my week. I also learned that being a manager comes with the role, but being a leader is earned.
I started creating content online about 4 years ago when a terrible wave of layoffs was sweeping tech, and I wanted to build a brand to try to get ahead of needing to find a job in the future. Fast forward 4 years, and I have a following of over 80,000 across my LinkedIn and newsletter. I have been on the LeadDev programming committee for 2 years running, spoken at CTO Craft, am a 6x top-rated course instructor on the prestigious Dometrain, and now am trying to build EM Accelerator. It’s been a wild ride.
2. Looking back with a manager’s eyes, what did you get wrong about what made you valuable as an engineer? What did you overvalue, and what did you undervalue?
I spent a lot of time as a senior engineer focusing on my technical skills. I wanted to be a tech lead so badly that I thought if I could prove I was one of the top engineers on the team technically, then the job, next time it came up, would surely be mine.
It took me longer than I wanted to realize that what makes a good tech lead and above, the very senior IC roles, is not about technical ability; that’s assumed at that level. It’s about how much you enable others. How much of a multiplier you are. How comfortable are you at handling high expectations with low formal authority?
3. Many engineers believe their manager evaluates them mostly on technical output. From the other side of the table, what actually drives how a manager sees an engineer?
It’s different at different levels, and it’s multi-faceted. At most levels, sure, technical output definitely plays a part; I am not going to sit here and pretend you can be successful in this job without a good technical base and producing, ultimately, business outcomes backed by solid technical foundations.
Juniors - I want to see you caring about learning and your growth. I don’t want to be the person forcing you to grow through different challenges. I will do that; however, I need to see that initiative, that passion to do this on your own behalf.
Mid-weights - I need to see you beginning to unearth substantial potential roadblocks to potential projects before they happen and also becoming a great coach and mentor to others.
Seniors - I need to see you looking beyond your role. If you want to progress, it’s not about you anymore. If you want to stay a senior, sure, that’s fine; keep delivering good work, etc.; that will be fine. But if you want to grow beyond that, I need to see behaviors that demonstrate you are capable of being a lead-of-leads role. So not necessarily taking the lead in the most important projects, the hard tickets, but showing that you can lead the leads through those from the sidelines.
I want to be frank that it also depends on how good your manager is. I have had managers in the past who, if I didn’t act and think exactly like them, no matter what I did, wouldn’t be good enough. But if you have a manager who genuinely cares about you, make it clear to them that you plan to take full advantage of that; they will love that.
4. Did managing change your definition of good engineering? Is there code or a technical decision from your IC days you now judge differently?
My answer to this often surprises people as it can sound quite harsh.
The harsh truth of our role and industry is that you are there to deliver business value. That’s the bottom line. Above everything else. No one cares if you tackled this behemoth function into a perfectly engineered masterpiece; they do care if that enabled CS teams to reduce their average call waiting time by 40 seconds, therefore increasing customer happiness and the lifetime value of a customer by $450.
I am being purposefully obtuse there, but it’s on purpose to paint a point. A good professional software engineer is capable of blending what the business needs with what the technology requires over the long term and not leaving it in a worse place for the developer who will come after them.
5. At Yelp, you led the teams responsible for reliable purchasing, where mistakes cost money directly. What did that environment teach you about the gap between engineers who ship features and engineers who own outcomes?
Our teams owned the infrastructure that not only was responsible for the money being taken, but also reliably reported it to Wall Street in a timely and honest manner. Get that wrong, and it can, literally and without exaggerating, kill a company overnight. So it was quite a serious domain to have ownership over.
There is a significant gap between those who pass the work over the fence (i.e., ‘ah well, it works on my machine’) and those who work to an outcome (i.e., reduce MTTR on purchases of product x by 12% to allow outcome y).
It’s not all on the engineer though. They are bred by environments. So an engineer might be in a team where the ticket reads ‘speed up database writes by creating this index, bla bla bla’ and they don’t have much more say or aren’t safe enough to have much more autonomy than that. Others are in an environment where the team will be presented with: ‘the MTTR of product X is Y, which is causing problem Z for a specific customer base’. The team would then iterate on ways to solve that, from minor code optimizations to event-driven architecture rewrites and opening additional availability zones.
I hope that point comes across.
6. Which engineer on your teams was the easiest to advocate for in promotion and calibration discussions, and what did they do differently from equally skilled peers who stalled?
The engineers on my teams who were easiest to get promoted were the ones who knew how to communicate progress. So they understood exactly how to alter the message, the level of detail given, and the additional information for each audience, and they took keeping those stakeholders updated as seriously as discovering the next technical execution roadblock.
Also, the ones who showed leadership skills in times of crisis. For example, we have a high-priority outage. How visible is their response to keeping everyone informed and tasks flowing to the right people?
7. If you could send one message back to yourself as a mid-level engineer, knowing what you know now about how organizations actually make decisions, what would it say?
Go and spend time with other departments. I had a CTO I only started working with as a senior, and he used to literally make it part of people’s jobs to work with other departments. Not as a side thing, but as a dedicated part of people's jobs. For example, I had to go and work with sales for 3 days to learn about the customer voice we use. I had to go and work with CS for 2 days to learn customer pain points, etc. Ever since, I have tried to do this wherever I have worked, and it’s one of the less thought-about tips that actually levels people up. You get exposure, but more importantly, you get domain knowledge that the people who just sit in the technical arena every day will never get. And that makes you 10x more valuable.
8. You’ve said you want to make engineering leadership more thoughtful and more human. Where do you see managers, including your past self, failing engineers most often?
The place most managers fail is by not giving timely feedback and avoiding the hard conversations. They say to themselves: ‘I’ll give it another two weeks; it will sort itself out’. And that goes on for two months. By that point it’s a much more serious problem than it needed to be. If you had just had the conversation with them as soon as you noticed a signal, it would be a much easier correction for the engineer than it is 2 months down the line. You are not being kind to them by not having that conversation; you are being cruel. A significant number of the PIPs I have seen have been because of weak feedback skills on behalf of the manager.
9. Plenty of engineers consider management because it looks like the only path up. How should someone honestly test whether they’d be good at it, and who should stay far away from it?
The first thing people need to understand is that going into Engineering Management isn’t a promotion; it’s a career change. If you want to go up, you can be a tech lead, staff engineer, principal, distinguished engineer, etc. You should not be a manager because you think it’s a step up. That’s one way to regret your life choices and fast. It’s a career change. The skills you learn are like being a junior all over again. It’s a brand new learning curve; you don’t get to rely on the skills that got you here.
My honest test for whether you would be good at it is probably to experience being a tech lead. That role, in my opinion, is one of the hardest in tech. You have extremely high expectations but no formal authority. Engineering managers have those expectations as well, but at least they have authority to back them up. Practice being a good one as well, enabling others, realizing that you don’t scale, but the team does, never touching a mentee's keyboard, etc.
10. You left Yelp to build EM Accelerator and train the next generation of engineering leaders. What gap in how the industry prepares new managers pushed you to bet your career on fixing it?
We have generation after generation of talent being thrust into this role, where you have a huge and direct effect on people’s careers and their lives, and you are not trained for it. Really? I have never spoken to anyone who received formal engineering management training outside of their companies’ in-house training, which often trains them to handle particular scenarios the way their HR team wants.
The teams bear the brunt of managers learning on the job. Engineers’ careers stall because managers don’t know how to advocate for them or coach them.
The teams who are stuck in the trenches because the manager can’t let go of being an IC, the thing that got them here, and still takes the critical path tickets.
The teams who don’t feel safe to speak up because their manager assumes their new role makes them a leader, when in reality people are only still listening to you because you are a manager.
When I was a mid-weight engineer, I started work for a finance company in London. It was my first job in London as a stockbroker; I had made the big leagues, so I was proud of myself. I had a newly promoted manager, and on my first day he said to me, ‘Never forget you are a resource here’.
I vowed to create EM Accelerator to make sure we stop putting the burden on our teams.
You can use code milan to get 25% off on all products in the EM Accelerator.
📔 The Laws of Software Engineering book is out
The book began as a document I wrote over the years. During my 20+ year career in Tech, I saw the same things happening at companies with different technologies and teams. I wrote down what I saw. I learned about Galls Law from a project that did not work out. Brooks’ Law was observed in a team that grew larger, and everything slowed down. Goodhart’s Law arose from a time when we met all our goals, yet the results were no better. They have been even worse.
Later, I met engineers who had figured out the same things. Most of them learned these lessons the hard way, as I did. They had a failed project, a tired team, or a messy codebase. This is how engineers usually learn these lessons because no one tells them. It is true, and it costs a lot.
This book is a list of what I learned.
This issue covers 20 laws in software engineering. My book covers 56 laws across architecture, people, time, quality, scale, code, and decision-making.
Each chapter discusses what the law says, where it comes from, when it applies, and what it looks like in a project. Some chapters also include connecting ideas such as The Two-Pizza Rule, The Cobra Effect, and Impostor Syndrome.
This book is something you can keep at your desk and look at when you need help.
Forewords are written by Dr. Rebecca Parsons, CTO Emerita at Thoughtworks, and Addy Osmani, Engineering Director at Google Cloud AI. Reviewed by 20 engineers and leaders from Google, Amazon, Uber, Oracle, Yelp, Nutanix, and CodeScene.
Want to advertise in Tech World With Milan? 📰
If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.
Love Tech World With Milan Newsletter? Tell your friends and get rewards.
Share it with your friends by using the button below to get benefits (my books and resources).