I built something new, and it is free. It takes about three minutes, and there is nothing to buy at the end of it.

It tells you what kind of engineering leader you are actually becoming. Not the one you put on your CV. The one your team experiences on a Tuesday afternoon.

There are five types. Each one has a real strength, the thing you are genuinely good at, and a blind spot that grows straight out of that same strength. The Mentor who grows everyone but keeps avoiding the hard performance conversation. The Operator who ships reliably but misses the resignation coming. The quiz scores you across all five and shows you where you actually sit.

At the end you get a personalised results card to download, your type and your scores across all five, ready to keep or share.

Take the free quiz now

Fair warning. Most people read the five types and confidently pick the flattering one. The whole point of a blind spot is that you cannot see your own, so the result may not be the one you expect. That is the useful part.

Reply and tell me which type you got. I read every one.

Ryan

No big tech. Earning £16,000 a year and £100 a night to lay carpet.

Subscribe now

If you’d told that version of me what I’d be earning a decade later, he wouldn’t have believed you. If you’d told him about the company names on his CV, the speaking gigs, the courses, the audience size, he’d have assumed you had the wrong Ryan.

He’d also have assumed that the Ryan in that future felt completely different on the inside.

He didn’t. I don’t. The numbers changed. The feeling didn’t.

The training I wish someone had given me when I was figuring it out.

The work doesn't get easier by waiting for the next title to fix it. It gets easier when you stop figuring it out alone.

EM Accelerator is the premium training platform I built for engineering leaders managers who are done piecing this together from podcasts and Twitter threads.

Launch offer 42% off. Reply to this message, and I’ll give you an extra 10% off for this newsletter edition only.

Join EM Accelerator

Most people in tech are operating on the assumption that the imposter syndrome stops at some point. Senior engineer. Staff engineer. FAANG offer. Big enough audience. Their own company. Pick the milestone. The belief underneath the milestone is that once you get there, the voice in your head telling you that you don’t really belong will finally shut up. I am here to tell you that it doesn’t. The voice doesn’t stop. It just finds something new to be loud about.

The £16,000 version of me

I worked for a local furniture company in my first “proper” tech job. SEO and web development by day, carpet fitting at night to make the numbers work. £100 a night was real money to me. The day job was a real job to my parents. I felt extraordinarily lucky to be doing either of them.

I remember sitting with a book on object-oriented programming and feeling completely lost. Objects, classes, inheritance, polymorphism. I read the same chapter three times and still couldn’t tell you what I’d just read. It felt like the kind of thing other people understood and I didn’t, and that there was something fundamental about being a real engineer that I was missing.

The story I told myself was simple. Real engineers understood this stuff. The people at the big companies, the ones writing the libraries I was using, they got it. I didn’t. Once I understood OOP, once I got a “proper” engineering job at a company you’d heard of, the feeling would stop. The feeling was the gap between me and the real engineers. Close the gap, lose the feeling.

That was the deal I made with myself. Get good enough and the discomfort goes away.

It didn’t stop. It moved.

Every day I was becoming a better programmer. I got the “proper” job. Then I got a better one. Then I worked at Yelp.

The first week at Yelp I sat in a room with engineers who were, by any honest measure, some of the sharpest people I’d ever met. I felt exactly the way I felt reading the OOP book. The room had changed. The feeling hadn’t. The gap I’d been trying to close had quietly moved further away the moment I caught up to where I thought it had been.

This is the bit nobody warns you about. You think you’re chasing competence. You’re actually chasing a feeling. And the feeling isn’t tied to your skill level, it’s tied to whoever you decide counts as a real engineer in that moment. The reference point keeps moving because you keep moving.

If junior-me could look at where I am now, he would be completely overwhelmed with pride:

• 6 x course creator on Dometrain with some of the biggest names in the industry.

• Leading engineers at big American companies with a 100% manager satisfaction score for 3 years running.

• Programming committee for LeadDev 2 years running.

• Speaker at CTO Craft.

• 60,000 followers on LinkedIn and a combined 20,000 on newsletters.

• Turning down interviews at places like Meta, Apple, Reddit, Microsoft and Amazon so I could dare to dream and eventually run my own business.

• Worked at Yelp and met people I could only ever dream of being in the company of.

Read that list back as a stranger and you’d assume the person behind it has it figured out.

I don’t. I sit at my desk most weeks and feel like the carpet fitter who got lost reading about objects. The only thing that’s changed is what I’m comparing myself to.

The threshold you’re waiting for doesn’t exist

Most engineers organise their careers around the belief that there’s a threshold, and once you cross it, the feeling stops. Some people pick salary. Some people pick title. Some people pick the company logo. Some people pick the size of their audience or their bank account or their LinkedIn followers. The threshold is different for everyone. The structure of the belief is identical.

It works like this. You feel like a fraud now. You assume the people one rung up don’t. You assume that getting where they are will fix the feeling. So you push. You take the job you don’t really want for the title you think will help. You burn yourself out trying to close a gap that’s already closed. You sacrifice things that matter to you because you’ve convinced yourself the prestige on the other side will be worth it. You get there.

The feeling shows up too. It just brought new material.

The senior engineers you assume have it figured out are watching the staff engineers. The staff engineers are watching the principals. The principals are watching the people at the next company over who got promoted faster. Everyone is looking up and seeing the people they assume have stopped feeling it, and everyone is wrong. The people at the top of the ladder you’re climbing are not on holiday from imposter syndrome. They’ve just learned to do good work while feeling it.

Free worksheet this week: The Imposter Audit

Paid subscribers get The Imposter Audit worksheet today. Five questions to catch the voice in the act and decide what to do about it.

Here’s what comes with being a member:

• The How to Be Taken Seriously field guide on signup

• A worksheet and short video walkthrough with every weekly article

• A monthly 4,000-word deep-dive, paid subscribers only

• Monthly live office hours with me

Become a paid subscriber →

Your career is the amount of stress you can handle

I heard a line recently that has stuck with me. Your career, in the end, is a direct reflection of the amount of stress you can handle. I think that is one of the truest things I have ever heard about working in tech.

Every step up the ladder is not really a step up in skill. It is a step up in the volume of uncertainty, ambiguity and pressure you are willing to carry without flinching. The skill side mostly takes care of itself if you keep showing up. The stress side is the actual bottleneck. And the stress, more often than not, is the imposter feeling in working clothes.

Which means the thing you are training, whether you realise it or not, is your relationship with that feeling. Not your relationship with OOP, or system design, or one-to-ones. Those are the surface. The deeper skill is staying functional while the voice is loud.

This connects to something I wrote a couple of years ago about fear, and I still believe every word of it. Fear is not the enemy. Fear is information. The career-defining moments I have had all sit on the other side of a moment where I almost talked myself out of it. The interview I nearly cancelled. The first course I nearly didn’t record. The first newsletter I nearly didn’t send. Every time, it was not me trying to walk away. It was fear. Once you can tell the difference between you and the fear, you stop letting the fear make decisions for you. You start using it as a signal that the thing in front of you matters.

The imposter feeling is the same machinery in a different costume. You don’t beat it. You learn to recognise it, and then you do the work anyway.

Final Thoughts

The thing junior-me got wrong wasn’t that he was bad at OOP. He genuinely was. The thing he got wrong was thinking that being bad at OOP was the reason he felt like a fraud. It wasn’t. The feeling was looking for a reason and OOP was the reason it found. Once he got good at OOP, the feeling found a different reason. It has been finding reasons ever since.

If you are reading this and waiting for the next milestone to make the feeling stop, it isn’t coming. The senior title won’t do it. The bigger salary won’t do it. The job at the company you’ve been chasing won’t do it. The audience won’t do it. The business won’t do it.

So give yourself a damn chance. You have achieved so much just to be here reading this.

If you can let tomorrow be a good day, imagine how good next week can be. Imagine how good next year can be. The feeling is going to come along for the ride either way. You may as well bring it somewhere worth going.

Liked this, even a tiny bit or feel sorry for me? Hit the like button ❤️

Think someone else might need to read this, or you just want to make fun of me together? Share this post 🔗

• EM Accelerator is open. Premium training platform for engineering leaders, managers and the people becoming them. Launch offer 42% off. Reply to this and get an extra 10% off.

• Become a paid subscriber and get the How to Be Taken Seriously field guide, weekly worksheets, monthly deep-dives, and monthly live office hours. £8/month or £80/year.

• Find me on LinkedIn. 58,000+ followers and counting.

• New videos every week on YouTube.

• Want to write a guest post? Reply and tell me what you’d write about.

Today’s the day. EM Accelerator is live. I actually can’t believe it.

I’ve been building this for months and I’ve talked about it a few times in this newsletter. Today it’s open and you can actually join.

EM Accelerator is for all leaders and dreamers. For engineering managers and the people maybe becoming them. You get the full EM Foundations course covering everything you need to lead an engineering team properly, through 1:1s, prioritisation, delegation, communicating like a leader, and so much more. You get the private community. Monthly live office hours with me. The expert interview library with new conversations released every month. The full worksheet and template library. And direct access to me throughout the year.

Standard pricing is £1,199 for the first year.

For the launch, there’s a special offer. The first year is £699. A saving of £500.

If you’ve been thinking about levelling up as an engineering manager, or you’re a senior engineer thinking about the move, or an experienced leader looking to simply learn and enhance your craft, this is the training I wish someone had built for me.

Have a look.

Claim your launch offer

Any questions, just reply. I read every one.

Ryan

I’ve spent the last month writing an e-book. It’s called How to Be Taken Seriously: A Field Guide for Software Engineers, and it’s about the non-technical skills that decide what happens to your career after the code stops being the hardest part.

Communication. Influence. Reading rooms. Managing up. The conversations every engineer ends up needing to have but nobody trains you for.

It’s 24 pages, designed properly, and from today it’s free for every paid subscriber to The Software Engineering Times.

Upgrade to paid

While I’m at it, three other things are changing

The weekly article is now permanently free. No more time-based paywall. No more “subscribe to keep reading” on older pieces. Every article I’ve ever written here, and every one I write from now on, is fully readable by anyone forever. The reasoning is simple: I want the writing to do the work of finding the readers it’s for, and a locked archive gets in the way of that.

Paid pricing is changing to £8/month or £80/year. The founder tier is gone. Paid subscribers now get:

• The field guide on signup

• The worksheet and a short video walkthrough for each weekly article

• A monthly 4,000 word deep-dive on a specific career or leadership situation

• Live office hours on the last Thursday of every month.

If you’re already paid, you’re grandfathered at your current rate forever. No change, no eventual hike. You’ll be able to download the e-book right now.

Why now

The honest answer is that this newsletter has been going for years, has been sporadic for most of them, and I want to actually make a proper go of it. The field guide is the start of that. The new offer is built around the work I’d genuinely enjoy doing every week.

Get your e-book now

If you’ve been around through the quiet stretches, thank you. If you’ve just arrived, welcome. Either way, the weekly article hits your inbox the same as ever from next week.

Most engineers are good at the technical part. That’s how they got the job.

The thing that decides what happens next, whether you get the interesting work, the influence, the promotion, or whether you watch someone less technical pass you by, is almost never technical. It’s the stuff nobody teaches you. How to write a doc people actually read. How to push back without burning trust. How to handle the conversations you’ve been avoiding. How to be taken seriously by the people who make the decisions.

Get the field guide now

I wrote a field guide on it.

How to Be Taken Seriously: A Field Guide for Software Engineers is the playbook I wish someone had handed me earlier. Covers the parts of a career that determine whether you keep moving or get stuck. Written from a decade of managing engineers, coaching them through the same hard moments, and watching the patterns repeat.

It’s free when you become a paid subscriber to The Software Engineering Times.

What paid gets you

• The field guide on signup

• Weekly worksheets and short video walkthroughs to go with each article

• A monthly 4,000 word deep-dive, paid subscribers only

• Monthly live office hours

• £8/month or £80/year, cancel any time

What’s free, and will always be free

The weekly article. Every week, no paywall, no archive that locks up after a month. If you just want the read, the free tier is the whole thing.

Get the e-book now

About me

Ryan Murphy. Former Engineering Manager at Yelp. ~60,000 followers on LinkedIn. Speaker at CTO Craft. Two-plus years on the programming committee for LeadDev. Author of six courses on Dometrain. Creator of EM Accelerator. I’ve coached engineers from junior to staff to director, and I write the things I now tell them.

If you’re a strong engineer who keeps getting passed over for promotion, the problem isn’t your manager. It isn’t politics. It isn’t that the company doesn’t reward technical excellence. The problem is you, and the model of the job you’ve been carrying around in your head for the last five years.

You thought it was about the code. It was never about the code.

The engineers sitting in staff and principal seats right now didn’t get there by being the best technical person in the room. Most of them aren’t. They got there because they worked out something the rest of the industry is only just being forced to confront. A technical bar is assumed. Everything that actually decides whether you go further, and whether you stay there, sits on top of it.

This week’s newsletter is brought to you by EM Accelerator.

Most engineering managers learn the job by making expensive mistakes. EM Accelerator is the platform built to fix that. A 90-day foundation that teaches you what nobody trained you on, then a monthly rhythm of articles, office hours and expert interviews from leaders at Stripe, Google, Meta and AWS and new courses every quarter. All sitting inside a private community of EMs who actually answer when you ask.

Free to join the waitlist at emaccelerator.com.

p.s. Everyone on the FREE waitlist gets a no-obligation founder offer on release, which is the cheapest it will ever be.

AI didn’t change this. AI just made it impossible to ignore.

When any competent engineer with Claude Code ships at the best on your team used to, the part of the job that everyone was obsessing over stops being the differentiator. The technical bar didn’t move up. It got easier to clear. And now the thing that was quietly doing the work of separating promoted from passed over is the only thing left in the room.

The smart ones already knew. The rest of you are finding out the hard way.

The thing nobody told you about staff and principal

You don’t get promoted to staff for being a better individual contributor. You get promoted for stopping being one.

The job past senior is not about how much you personally can ship. It’s about how much everyone around you can ship because you exist. The moment you accept that you as an individual do not scale, and that enabling others does, the path opens up. The moment you refuse to accept it, you stop moving.

There are engineers reading this right now who have been stuck at senior for four years telling themselves the company doesn’t value technical depth. The company values technical depth fine. It just stopped paying a premium for it past a certain point, because past that point, depth on its own isn’t worth what you think it’s worth.

What the people above you actually do

After watching this play out across more calibration cycles than I can count, the pattern is brutally consistent.

They turn fog into direction. Hand them a vague business problem and they walk out with a plan everyone agrees with. The engineers who stay stuck wait for someone else to write the plan and then complain about it.

They make other engineers better without anyone noticing. Not in scheduled mentoring sessions. In code reviews, in pairing, in the docs they leave behind, in the question they ask in standup that reframes the whole problem. Their fingerprints are on work they never wrote.

They own outcomes. They don’t close tickets. A stuck senior tells you the ticket is done. A promoted senior tells you whether the thing actually worked. They follow the work through to the metric, the user, the business result. The PR merging is the boring middle of the story.

They make their managers look good. This is the bit people pretend isn’t real because it sounds political. It is real. If your manager cannot defend your impact in a room you’re not in, you do not get promoted. Full stop. The work being good is not enough. The work being legible to the people who decide is the actual job.

Their name comes up in other teams. Not because they posted on LinkedIn. Because people who worked with them six months ago still talk about them. That cross team reputation is the unlock for the bigger scope staff and principal roles require, and you cannot fake it.

They use AI honestly. Not as a crutch hiding their thinking, not as a threat they pretend isn’t there. They’ve worked out where it accelerates them and where it would quietly hollow them out if they let it. They are clear eyed about it because they have to be.

Free Above The Bar Worksheet for Paid Subscribers

If this article made you uncomfortable, the worksheet is the next step.

✅ 7 honest questions drawn from the promotion criteria above

✅ Private space to answer the things you avoid saying out loud

✅ One closing prompt that tells you exactly what to work on for the next 90 days

Most engineers won’t sit with these questions. The ones who do find out which gap is actually keeping them where they are.

👉 Subscribe and get the worksheet

The part that’s going to sting

This is hardest for the engineers who built their identity on being the strongest coder on the team. Years of being the technical anchor have trained a particular muscle, and that muscle still matters. It just stopped being enough years ago, and you didn’t notice because nobody told you to your face.

The engineers in real trouble right now are not the average performers. They’re the strongest individual contributors who never built the second skill set, who watched less technically capable people get promoted ahead of them, and who told themselves it was unfair. It wasn’t unfair. The criteria were never what you thought they were. The people who got promoted weren’t worse than you. They were operating on a more accurate model of the job.

That is a hard sentence to read. It’s a harder sentence to sit with.

So what do you do about it?

Look at the last person on your team who got promoted ahead of someone more technically capable. Not to be bitter. To learn.

What did they actually do? How did they handle ambiguity? Who advocated for them in rooms they weren’t in? What did their manager say when their name came up in calibration? How did they show up when something went wrong?

That gap is your work. It’s not a new framework. It’s not a faster AI workflow. It’s the part of the job you’ve been treating as beneath you, that has quietly been the job all along.

Closing thoughts

The engineers getting promoted in 2026 aren’t better coders than the ones who aren’t. They worked out, often years ago, that past a certain point coding stops being the thing being measured. The technical bar is assumed. Everything else is the game.

You can keep telling yourself it’s unfair. Or you can accept that the people above you saw something you didn’t, and start doing the work you’ve been avoiding.

Your call.

Subscribe now

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• The FREE waitlist for my new premium training platform for Engineering Managers is now live.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >58,000 followers now.

If you could give junior engineers one piece of advice, what would it be?

I expected a few replies. Maybe ten, fifteen if I was lucky. What I got was 45 comments from senior engineers, VPs, CTOs and engineering leaders working at Apple, Amazon, GitHub, Sony, HashiCorp, AWS, Barclays, incident.io, Proofpoint and more.

I thought I knew what they’d say. AI is everywhere right now. Junior engineers are scared. Half the headlines tell them their jobs are over. The other half tell them to learn AI or fall behind. So I expected the advice to be about AI.

It wasn’t. Almost none of it was about AI

Today’s sponsor: Luma AI

I used Uni-1 to generate today’s thumbnail. But the news isn’t about thumbnails.

Uni-1 is now an API.

Luma’s reasoning image model - already powering serious creative work in production - is now available as infrastructure. Build it into products, wire it into pipelines, embed it in bespoke tools. Anywhere code runs, Uni-1 can think.

Build with the Uni-1 API → lumalabs.ai/api

#LumaPartner

Go build anything at scale

What they actually said

The first thing that hit me, reading through the responses, was how un-modern the advice was. These people aren’t grandparents. Many of them are building the future. VP of Engineering at incident.io. Field CTO at HashiCorp. Senior SWE at Apple. Staff EM at GitHub. And what they kept telling juniors to do was the same thing senior engineers have been telling juniors for thirty years.

Be reliable. Ask questions. Find a mentor. Don’t burn out. Learn the fundamentals before reaching for shortcuts.

The themes were remarkably consistent.

Be the person other people can count on.

This was the most common theme by a distance. , Staff Engineering Manager at GitHub, put it in a clean three-pointer:

Tehn Yit Chin echoed it almost word for word: “Do what you say you will do. It is an amazing work ethic and it builds trust.”

, who you’ve probably seen on your feed at some point, given his 300K followers, distilled it to four words: “Underpromise and overdeliver.”

The pattern across these responses isn’t subtle. The senior engineers responding aren’t telling juniors to be brilliant. They’re telling them to be reliable. Brilliance can’t be hired for. Reliability can be earned.

Find a mentor, and don’t always make it your manager.

Matt Syp put it like this:

He went further in a follow-up: “Someone telling them it is OK to go around your manager for info. Maybe because some managers are threatened by it, but it is something I always encourage.”

said it more directly: “Get one senior 2 levels above you to be your mentor.”

This goes against the grain of what most juniors are taught. The chain of command says: ask your manager. The reality, according to people running engineering teams at GitHub, Amazon, and incident.io, is that your manager is one of many people you should be learning from, and often not the most useful one.

Make “why” your most consistent question.

Subscribe now

Demitri Swan, Senior SWE at Apple (ex-Google, ex-DigitalOcean), gave one of my favourite lines from the entire thread:

This isn’t a trick. It’s a way of being. The juniors who get ahead aren’t the ones who execute the most tickets. They’re the ones who keep asking why a ticket exists, why the architecture looks that way, why the team made the decision they did. Curiosity compounds.

Jorge Baranda, who’s worked at CrowdStrike, Amazon and Blizzard, added the second half of it: “Do not be afraid to ask for help, ego can get in the way of you learning.”

Asking why and asking for help are the same skill in two contexts. Both are about admitting you don’t know yet. Both are how you get to know.

Now, the AI thread

Here’s where it gets interesting.

The handful of responses that did engage with AI directly were brutal. Not anti-AI. Anti-shortcut. And they all said the same thing.

Robert Ruby II didn’t bother with subtlety:

, a founder building practical AI implementations, said exactly the same thing in lowercase: “same as it has always been - learn fundamentals.”

Thomas Woodhams, Senior Talent Acquisition Partner at Sony Sports Technology, brought it to a specific use case juniors actually face:

Patrick Herzberg gave the most useful framework I read. Three questions to ask yourself when working with LLMs:

And Brian Jenney offered the smartest practical move in the entire thread: “Identify the strong devs on your team and study them. How do they handle PRs, docs and AI tool usage? Steal what works for them.”

That last one is the key. The senior people answering aren’t anti-AI. They’re anti-shortcut. The advice isn’t don’t use AI. It’s don’t use AI to skip the work that builds your judgment.

You need the fundamentals to know when AI’s output is right. You need critical thinking to question what it gives you. You need senior peers to study so you can see how good engineers actually use these tools.

The AI advice and the rest of the advice aren’t separate categories. They’re the same advice, applied to a new tool.

Closing Thoughts - What I’d tell a junior engineer in 2026

Here’s what I’d say.

The shift to an AI-augmented industry doesn’t change the fundamentals of how you get ahead. It amplifies them.

The juniors who’ll thrive aren’t the ones who learn the most AI tools fastest. They’re the ones who do what they say they’re going to do. Who ask why obsessively. Who find people two levels above them and earn their attention. Who learn the fundamentals deeply enough that they can tell when a tool, any tool, including AI, is producing rubbish. Who protect their energy for the long career, not the short sprint.

That’s not new advice. It’s the oldest advice in engineering. And in 2026, it matters more than ever, because the noise around shortcuts has never been louder.

The leaders responding to my post aren’t telling juniors that AI doesn’t matter. They’re telling them something subtler. AI is a tool. Tools amplify whoever uses them. If you’ve built the judgment to use it well, AI will multiply your impact. If you haven’t, it’ll multiply your mistakes.

The work that builds the judgment is the same work it’s always been.

If you found this useful, the people I quoted deserve a thank you. They didn’t have to take time to answer a stranger’s question on LinkedIn. They did it anyway. That’s the kind of generosity that built the engineering community in the first place.

Here’s a link to the LinkedIn Post.

Ryan

Most engineering managers are thrown into the role and left to figure it out alone. No training. No community. No one to ask.

That’s why I built EM Accelerator. 7 self-paced modules, a private community, monthly office hours, direct access to me, expert interviews, worksheets, and lifetime updates. Everything an EM actually needs, in one place.

The first 25 founding members get founder pricing. Get on the waitlist. The waitlist IS FREE.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• The FREE waitlist for my new premium training platform for Engineering Managers is now live.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >58,000 followers now.

That is the relationship. That is what loyalty actually gets you.

And while that spreadsheet is being built, someone who joined your team three months ago, who still does not know how half the system works, is probably earning more than you.

Subscribe now

This week’s newsletter is brought to you by EM Accelerator.

Most engineering managers are thrown into the role and left to figure it out alone. No training. No community. No one to ask. EM Accelerator is premium training built around everything you actually need. 7 self-paced modules, a private community, monthly office hours, direct access to me, expert interviews, worksheets, and lifetime updates. Everything in one place. Free to join the waitlist at emaccelerator.com.

The psychological contract that does not exist

Most engineers operate under an unspoken assumption: if I stay, work hard, and deliver consistently, the company will take care of me. Promotions will come. Pay will keep up. Loyalty will be recognised and rewarded.

This assumption is wrong.

Companies do not think about loyalty the way employees do. When budgets get cut, tenure does not save you. When redundancies come, the spreadsheet does not have a column for “has been here the longest and really cares.” The relationship you think you have with your employer is not the relationship they think they have with you.

This is not cynical. It is just how businesses work. The sooner you understand that, the sooner you start making career decisions based on reality rather than a contract that was never written down.

The salary trap

Internal pay rises almost never keep pace with the market. A 3% annual raise feels like a reward until you realise the market has moved 15% in two years. The gap between what you earn and what you could earn elsewhere widens silently, year after year.

Your company knows this. They know that internal rises are cheaper than market rate offers. They are banking on the fact that you will not leave. That the comfort of familiarity and the fear of the unknown will keep you in place. For most people, they are right.

Free “Am I Staying For The Right Reasons?” Worksheet for Paid Subscribers

I’ve created a Career Loyalty Self-Audit Worksheet for paid subscribers. It’s a simple, honest tool with:

✅ 7 questions drawn directly from the traps covered in this article

✅ Space to answer honestly without anyone else seeing

✅ A reflection prompt to help you figure out whether you are staying on purpose or staying by default

✅ The one question most engineers avoid asking themselves out loud

If any part of this article made you uncomfortable, this worksheet is worth 10 minutes of honesty with yourself. Most people never do it, and then wonder why they woke up five years later in the same seat.

👉 Subscribe and get the worksheet

The comfort trap

You know the codebase. You know the people. You know how decisions get made and how to navigate the organisation without thinking about it. That familiarity feels like an asset.

It is not. It is the thing keeping you stuck.

Comfort and growth rarely exist in the same place at the same time. When everything is familiar, nothing is challenging. When nothing is challenging, you stop improving. And when you stop improving, your value in the market starts to decline even though your value inside the building feels stable.

The dangerous part is that this happens slowly. There is no single moment where you cross from “I am comfortable and productive” to “I have been standing still for two years.” It just drifts.

The identity lock-in

After several years at one company, your professional identity becomes entangled with it. Your network is mostly internal. Your reputation exists inside the building but not outside it.

Ask yourself this: if your company disappeared tomorrow, how visible would you be in the market? How many people outside the organisation know your name, your work, your track record? For a lot of long-tenure engineers, the honest answer is uncomfortable.

The skills gap you do not see forming

Every company has its own stack, its own processes, its own definition of good engineering. The longer you are there, the more you normalise it. You stop noticing that your technical breadth has narrowed. You stop noticing that the tools and practices you use every day are not universal. You stop noticing that you have not interviewed in years and the thought of it fills you with dread.

The market keeps moving. If you are only exposed to how one company does things, your understanding of the industry slowly shrinks to the size of your building.

The moment of realisation

For most people it is triggered by something external. A recruiter call that goes surprisingly well. A friend at another company describing a culture that sounds completely different. A redundancy round that reminds you the relationship was never as secure as it felt.

Or sometimes it is smaller. A promotion cycle that passes without explanation. A conversation with a newer colleague where you discover they earn more than you for less responsibility.

Most people who have stayed somewhere too long can point to a specific moment when they knew. The problem is that knowing and acting are two different things.

When staying is genuinely the right call

This article is not anti-loyalty. Some companies are exceptional. Some engineers find exactly the right environment and grow consistently for a decade without needing to leave.

The difference is intentionality. Staying because you have made a clear-eyed decision that this place is still growing you, still paying you fairly, and still aligned with where you want to go is a strong career move. Staying because you have not updated your CV in four years and interviewing makes you feel sick is not loyalty. That is fear dressed up as commitment.

Subscribe now

Final Thoughts

You do not owe your company loyalty. You owe yourself honesty. The best engineers treat their career like something they actively manage, not something that happens to them while they sit in the same chair year after year. If you are staying, stay on purpose. If you are uncomfortable with the questions this article raises, that discomfort is telling you something. Listen to it before someone else makes the decision for you.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• The FREE waitlist for my new premium training for Engineering Managers is now live.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >58,000 followers now.

They were in a stand-up this morning. They merged a PR this afternoon. And sometime this week they have a final round interview at another company.

You have no idea.

This is how it almost always goes. The resignation letter feels like it comes out of nowhere, but the decision was made months ago. The CV was updated, the interviews were done, and they had mentally moved on long before anyone noticed. The letter is just admin.

The signals were there. They usually are. Most people just do not know what to look for.

Subscribe now

This week’s newsletter is brought to you by EM Accelerator.

If you’re navigating the move into engineering leadership, EM Accelerator is the practical training built specifically for engineering managers who want to stop figuring it out alone. 7 modules, real frameworks, community access, and direct access to me. Join 110+ engineering leaders already on the completely free waitlist at emaccelerator.com.

They stop investing in outcomes

Good engineers care about the result, not just the task. They push back on decisions they think are wrong, flag risks before they become problems, and have opinions about how things should be done.

But this does not only show up in naturally loud people. For vocal engineers, disengagement looks like silence where there used to be challenge. For quieter engineers, it shows up differently: shorter PR descriptions, less async input, fewer contributions in planning docs or design discussions. The common thread is not volume, it is a shift from their own baseline. Someone who always left thorough code review comments and suddenly stops. Someone who used to drop detailed thoughts in Slack threads and now just reacts with a thumbs up.

Pushback requires caring. When someone stops investing in outcomes, it is often because they do not expect to be around for them.

They stop talking about the future

Listen to how people talk about upcoming work. Engaged engineers insert themselves into future plans. They say things like “when we ship this in Q3” or “I want to own that project when it comes up.” They are thinking ahead because they expect to be there.

When someone becomes vague about anything beyond the current sprint, when they stop volunteering for future work or go quiet in roadmap conversations, that is worth noticing. They may not be planning to be around for it.

They stop treating the work like a craft

Strong engineers care about quality. Not in a perfectionist way that blocks shipping, but in the way that means they stay curious, push for the better solution, and care whether the thing they built was actually good.

When that changes, it is noticeable. They start doing the minimum viable version of everything. PR’s that are functional but lack the thoughtfulness you would expect from them. Problems they would previously have dug into that they now just close out quickly. They are still doing the job. But the craft has gone. And when an engineer stops caring about the quality of their own work, something has already broken.

Why it gets missed

Strong engineers do not make it obvious. They keep delivering, keep showing up, keep doing what is expected of them right up until the day they hand in their notice. There is rarely drama, rarely a confrontation, rarely a moment that feels like a clear warning sign.

Teams are also busy. When nothing is visibly on fire, there is no obvious reason to dig deeper. The assumption is that no news is good news, and for a while with a strong engineer, that assumption holds up.

By the time the resignation lands, most people feel blindsided. But in hindsight, the signals were usually there.

Free "Is This Me?" Self-Reflection Worksheet for Paid Subscribers

I've created a Self-Reflection Worksheet for paid subscribers. It's a simple, honest tool with:

✅ 7 questions drawn directly from the warning signs in this article, turned inward

✅ Space to answer honestly without scoring or judgment

✅ A reflection prompt to help you figure out whether what you are feeling means it is time to leave, or time to have a conversation

✅ A final question most engineers never ask themselves out loud

If any part of this article made you think "wait, is this me?" or you are just curious, this worksheet is worth 10 minutes of honest self-reflection. Most people ignore that feeling until the decision makes itself.

👉 Subscribe and get the worksheet

Exit interviews do not tell you the truth

When someone finally sits down for an exit interview, they are not being fully honest. Not because they are dishonest people, but because they are professionals who do not want to burn bridges. They are leaving, and they still need references, still work in the same industry, still might cross paths with these people again.

So they say it was the money. Or a great opportunity they could not turn down. Both of which might be partially true. Neither of which is usually the whole story.

The real reasons tend to run deeper.

The moment trust breaks

Early in my career as a senior engineer, a new hire casually mentioned their starting salary in conversation. They were joining on more than I had worked my way up to over several years.

It was not a huge number. But in that moment something shifted.

It was not really about the money. It was about what the money said: that my years of contribution, context, and loyalty were worth less to the company than someone fresh off the market. That feeling of being disrespected, of trust quietly cracking, is something a belated pay rise rarely fixes. Once it sets in, it has a habit of staying.

This is what people do not say in exit interviews. Not “I was offered more elsewhere.” But “I found out what I was actually worth to this place, and it changed how I saw everything.”

What else drives it

Feeling unchallenged is one of the most common reasons strong engineers leave. They need hard problems. When the work becomes routine and there is nothing left to learn, the job becomes a slow drain rather than a source of energy.

Progression that feels opaque or stalled is another. If someone cannot see a clear path forward, or watches others get recognised while their own contributions go unacknowledged, they start asking why they are putting in the effort.

And finally, a loss of belief. In the product, the leadership, the direction of the company. When someone stops believing the thing they are building matters, it is very hard to get that back.

What to do about it

Once the signals are there, there is still a window. Not a huge one, but a window.

Ignoring it and hoping things improve rarely works. But a clumsy conversation that puts someone on the spot can make things worse.

What tends to work is something direct but low pressure. Not “are you thinking of leaving?” but something more like “I want to make sure this place is still working for you. What would make the next six months genuinely good?”

Then the harder part: act on what they say. One conversation where nothing changes does not help. It often accelerates the decision, because now they have said what they need and watched it go nowhere.

You cannot reach someone who has already fully checked out. The goal is to have this conversation before that point, when it can still change something.

Final Thoughts

The best engineers always have options. They stay because the work is interesting, the team is good, and they believe in what they are building.

When those things erode, they leave. Quietly, professionally, and with far less warning than anyone would like.

The teams that hold onto strong engineers over the long term are not the ones with the best counter-offers. They are the ones who noticed something was off, asked the right questions, and actually did something about the answers.

Someone on your team is interviewing right now. The question is whether you will notice before it is too late.

Subscribe now

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• The FREE waitlist for my new premium training for Engineering Managers is now live.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >58,000 followers now.

Suddenly you’re looking at what feels like a fork in the road. Tech Lead or Engineering Manager. Both sound like progression. Both come with more responsibility. But they are not the same thing, and choosing the wrong one, or choosing for the wrong reasons, is one of the most common career mistakes I see engineers make.

Before we get into the differences though, there’s something worth saying upfront.

Subscribe now

This week’s newsletter is brought to you by EM Accelerator.

If you’re navigating the move into engineering leadership, EM Accelerator is the practical training built specifically for engineering managers who want to stop figuring it out alone. 7 modules, real frameworks, community access, and direct access to me. Join 110+ engineering leaders already on the completely free waitlist at emaccelerator.com.

It’s Not a One Way Ladder

A lot of engineers assume the progression goes: engineer, tech lead, engineering manager, and so on up the chain. That EM is simply the next rung after tech lead. It isn’t.

These are two separate career paths, not steps on the same one. And there are others too. The staff engineer and principal engineer route is a legitimate, well compensated, highly respected path that keeps you deeply technical without asking you to manage people. Some of the most impactful people in engineering never manage anyone.

The other thing worth knowing is that you are not stuck once you choose. Plenty of great EMs spent time as tech leads first. Plenty of great tech leads tried EM, realised it wasn’t for them, and came back to the technical path better for the experience. It is not a one way door. But the earlier you get honest with yourself about what you actually want, the less time you waste going in the wrong direction.

What Both Paths Have in Common

Here’s what most people miss when they’re weighing this up. Both the tech lead and engineering manager paths ask for the same fundamental shift.

Whether you go one way or the other, you have to genuinely make peace with becoming less and less hands on over time. Not grudging acceptance. Actual peace.

As a tech lead you write less code and review more. You spend more time in conversations, documents, and decisions. As an EM you may stop writing code altogether. The craft that made you successful as an engineer, probably the thing you love most about the job, becomes something you do less of, then rarely, then perhaps not at all.

This is what trips people up. They spend weeks debating tech lead versus EM without sitting with the more important question underneath: am I actually ready to let go of being an individual contributor?

The people who thrive in either role are the ones who find real satisfaction in what replaces the hands on work. Influence, mentorship, technical strategy, watching people grow because of something you did. If that doesn’t appeal to you yet, neither path is the right move. Knowing that is its own kind of clarity.

Free Scored Role Reality Checker for Paid Subscribers

I’ve created a Role Reality Checker Worksheet for paid subscribers.

It’s a simple, practical tool with:

✅ 14 statements across 4 categories to help you understand how you’re actually wired

✅ Three columns to tick - Tech Lead, Engineering Manager, or Neither

✅ A scoring guide to interpret where your answers cluster

✅ A reflection prompt to help you sit with the bigger question underneath the choice

If you’re genuinely weighing up which path is right for you, this is worth 10 minutes of honest self-reflection. Most people never do it, and then wonder why they ended up in the wrong role.

👉 Subscribe and get the worksheet

Nobody Trains You for Either Role

Here’s something else nobody talks about enough. Both the tech lead and engineering manager roles come with almost no formal training. You are largely expected to figure it out as you go.

You get the title. You get the new responsibilities. And then you get thrown in. Most people learn through trial and error, picking up what they can from managers they’ve had, articles they’ve read, and mistakes they’d rather forget.

This is one of the reasons the transition is so hard. You spent years getting good at engineering. There were clear problems, clear feedback loops, clear ways to measure progress. Leadership doesn’t work like that. The feedback is slower, the problems are messier, and there’s rarely a right answer.

Knowing this going in doesn’t make it easy. But it does mean you can be more intentional about seeking out learning rather than assuming it will just happen.

The Tech Lead Reality

The tech lead role is one of the most misunderstood in engineering.

You carry high expectations. Architecture decisions, technical direction, code quality, raising the bar across the team. That sounds straightforward. The catch is you carry all of that with almost no formal authority. Nobody reports to you. You cannot tell people what to do. You have to lead through influence, through the quality of your thinking, the strength of your relationships, and your ability to bring people with you rather than directing them.

That gap between high expectations and low formal authority is where most new tech leads struggle. You need to convince rather than instruct. You need to earn trust rather than assume it. And you need to be comfortable with the reality that the team might not always follow your recommendation, and you have to find a way to move forward anyway.

If that kind of challenge energises you, the tech lead path has a lot to offer. If that ambiguity frustrates you, it will wear you down.

The Engineering Manager Reality

The EM role asks something different. Your job is no longer to be the best engineer in the room. Your job is to make everyone else in the room better.

Your success is measured through other people. Their growth, their performance, their output, their wellbeing. That is a completely different success metric to the one that got you here. As an engineer you could point to things you built. As an EM the things you build are invisible. A team that trusts each other. A culture where people do their best work. An engineer who got promoted because of conversations you had with them months ago.

You will also have hard conversations on a regular basis. Performance issues. Conflict between team members. Difficult feedback. Redundancies. These don’t get easier just because you get more experienced. You get better at handling them, but they stay hard.

The Tech Lead and EM Relationship

One thing that often gets overlooked in this conversation is how important the relationship between tech lead and EM actually is.

When it works well it’s one of the most powerful partnerships in a team. The EM handles the people side, the processes, the organisational noise. The tech lead drives technical direction. Together they give the team both strong leadership and strong technical guidance.

But it only works when there’s genuine trust and honesty between them. They need to be aligned. They need to be able to challenge each other behind closed doors and present a consistent front to the team. When that relationship breaks down, or when they’re not honest with each other about what’s working and what isn’t, the team feels it even if nobody says anything out loud.

If you’re choosing the tech lead path, the quality of your relationship with your EM will shape your experience of the role more than almost anything else.

Four Questions Worth Sitting With

Rather than a checklist, try sitting with these honestly:

Do you get energy from problems or from people? Not which sounds better. Which one actually fills your tank at the end of a hard week.

How honest are you being about giving up the hands on work? Sit with the idea of not shipping code for a month. Does that feel like relief or dread?

Do you want to own outcomes or influence them? EMs own outcomes but often can’t control exactly how the work gets done. Tech leads influence technical decisions but rarely have the final word. Which feels more natural to you?

How do you feel about hard conversations? Not technical disagreements. The human ones. If you avoid those conversations now, the EM role will put them in your calendar regardless.

The Career Paths

Tech lead opens toward staff engineer, principal, distinguished engineer. Deeply technical, increasingly strategic, and some of the most valued roles in the industry.

EM opens toward senior EM, director, VP of engineering, CTO. Broader people and organisational responsibility, eventually owning the entire engineering function.

Neither is better. But knowing which direction you want to head tells you which path to start building on now. And remembering that you can change course, especially early, takes some of the pressure off making the perfect call today.

Subscribe now

Final Thoughts

There is no universally right answer. There is only the right answer for you, right now, based on what you actually want. Not what sounds impressive, not what your manager is nudging you toward, not what your peers are doing.

Both paths will ask you to grow in uncomfortable ways. Both will ask you to let go of things you’re good at. Both will give you something new and genuinely meaningful in return, if you pick the one that fits how you’re actually wired.

If you’re leaning toward the EM path and want to understand what the role actually looks like day to day, I’m building something specifically for that. Join 110+ engineering leaders already on the waitlist at emaccelerator.com.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• The FREE waitlist for my new premium training for Engineering Managers is now live.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >58,000 followers now.

If you’re the one leading every single meeting, you’re either inexperienced, insecure, or haven’t been shown how to be a real manager yet.

If that stings a little, that’s okay. Maybe it should.

There are a few exceptions. Sure, incidents. Maybe a gnarly stakeholder review or a performance conversation. But even in those high-stakes moments, there’s usually room to coach. Let someone else run the show. As long as someone is clear on decision-making, you don’t need to be the one running the room every time.

That’s not what good leadership looks like. Good leadership is about building people who can do the job without you.

Why You Keep Grabbing the Mic

Most managers hog the meetings for one of a few reasons:

• It’s faster if I do it

• They’re not ready yet

• What if they mess it up?

• I’ll be blamed if it goes wrong

• I’m the one accountable

If that sounds like you, you’re not alone. I’ve heard them all before. I’ve said a few of them too, early in my career.

But you need to realise what those excuses are actually saying to your team:

You’re not ready.
I don’t trust you.
I don’t care enough to help you grow.

Not great.

What It Looks Like to Coach Instead

This isn’t about disappearing. It’s not about sitting out. It’s not delegating and walking away.

It’s about showing up differently.
Coaching in real time.
Supporting from the side, not from the front.

Let them lead the standup. Let them chair the retro. Let them run the stakeholder sync.

Then debrief.

What worked?
What would you do differently next time?
What was hard?

That’s coaching. That’s how they get better.
That’s how you build a team that can do hard things without you steering every move.

The Real Reason You’re Still Leading Everything

Sometimes, it’s not about fear. It’s about ego.

If everything runs through you
If you always need to be in the room
If you secretly like being the person with the answers

That’s ego.

It’s not sustainable. It’s not leadership. It’s how you end up with a team that stays stuck at the same level while you burn out trying to do it all.

Start Small

You don’t have to flip the whole thing overnight.

Start with one meeting a week.

Hand it off to someone. Give them a little prep support. Stay in the room. Debrief after.

See what happens.

This is where your next generation of leaders gets built. Not in private 1:1s. Not in performance reviews. But right here. In meetings. In public. In the mess.

Bonus for Paid Subscribers - Downloadable Worksheet

If you’re a paid subscriber, I’ve put together a Team Meeting Delegation Worksheet to help you get started.

Inside you’ll find:

• A self-audit to see how often you really lead

• A meeting inventory worksheet

• A guide to identify what to delegate and who to delegate to

• Coaching questions to ask before and after

• Real examples and space to plan your next 30 days

👉 [Download it here] (paid subscriber link)

Subscribe now

Final Thoughts

You don’t build strong teams by leading everything.
You build strong teams by coaching them to lead.

Let someone else drive. Stay in the room.
Support them.
Back them.
Debrief.

That’s the job.

I've been creating content for over 3 years now, and in that time, I've worked with or got to know creators all across the spectrum, from people with a thousand followers to those with over a million. I've worked with creators who've genuinely become millionaires from this stuff and others who've never earned a single penny.

In reality, most LinkedIn creators fall into one of five buckets.

Subscribe now

Bucket 1: The Do-Gooders

A huge majority of creators fall here. Most creators in this bucket earn either zero or less than $1,000 per year. Despite this, they produce daily short-form content, weekly long-form posts, record videos, and lay their thoughts and experiences out there for everyone, people they know and people they've never met.

They earn a few dollars here and there from the occasional sponsored post, a handful of paid newsletter subscriptions, affiliate marketing, or maybe the rare paid speaking gig. (Most speaking is unpaid, often just travel expenses.)

But the money isn't the motivation. They share their stories because they genuinely want to help. Their reward? Connections, helping others, and the satisfaction of making a difference.

Some in this bucket also create content to build their personal brand and improve their career security. Money isn’t the immediate goal; longevity and opportunity are.

These creators grind for years, with many people assuming they’re "making bank," but the truth is most of your favourite LinkedIn creators are making next to nothing.

Bucket 2: The Small-Reach Sellers

These creators dream of becoming the next Alex Hormozi or Justin Welsh.

They’re mainly creating content to sell something. Helping people might happen, but it’s really a byproduct of selling their product or service.

Their posts often follow the same format, long personal stories with a call-to-action like "message me if this resonates." The audience tends to be other small-reach sellers or potential customers, creating a kind of unofficial, informal engagement circle.

You'll rarely see deep interactions between the do-gooders and the small-reach sellers. They might engage occasionally, but it’s usually surface-level.

At best, maybe the top 1% in this bucket could earn up to around $20k a year. Most, though, earn far less, frequently jumping from one product or service to the next.

Bucket 3: The Grown-Up Do-Gooders

These are the creators who started in Bucket 1 but got quite big. They're the 1% of the original do-gooders.

They built a sizeable following by consistently providing genuinely valuable, honest content, exactly the kind of audience brands adore. Having spent years sharing value for free, these creators start looking to monetize their effort. Courses, newsletters, YouTube channels, they try it all.

For some, it clicks, and they move on to real financial success. For many others, monetization leads to a bit of stagnation. Their audience senses the shift from purely valuable content to monetized content. Growth slows, and many creators feel discouraged or even quit at this point.

Some of these creators might see between $10k and $50k per year, but realistically, the majority will earn around $1k to $5k annually.

Subscribe now

Bucket 4: The Ones You Read About

These creators usually come from Bucket 2 or Bucket 3, the small-reach sellers who figure out genuinely valuable content, or the grown-up do-gooders who master monetization without losing their audience.

They’re the top 0.1%. The creators earning anywhere from $50k to well over $1 million annually (and yes, I've genuinely seen this myself, working with some of the biggest tech creators out there).

These are the keynote speakers, the people getting press coverage, and the creators you probably follow everywhere.

They're incredibly rare. They’re the exception, not the rule.

Bucket 5: The For The Love Of It Creators

This group mirrors the grown-up do-gooders but they’ll never have an interest in monetization.

They simply love creating content. Their engagement is authentic because their passion and lack of financial incentive shines through.

Brands and conferences desperately want these creators, but they rarely manage to persuade them.

Final Thoughts

Look at the creators you engage with regularly, I guarantee you can easily place them into one of these five buckets.

For 99% of creators, creating content is essentially a second job. It’s a huge time investment, usually without meaningful financial returns.

I’ve had people assume I'm doing this for the money, if only they knew. For most of us, this started as a way to build our brand, improve career security, and genuinely help people. Sometimes, I need to remind myself why I started.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• I’m building a brand-new platform called EngLeadExpert, where I help you become better engineering leaders. Check it out here.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m now at over 57,000 followers.

Subscribe now

See my latest YouTube Video:

If you’ve been working hard for years but still feel stuck in your career… if you’re wondering why you’re not getting the big projects… if you’re frustrated that other people are getting promoted while you’re still grinding away… it’s probably because you’re a doer, not an owner.

What’s the Difference?

Here’s what a doer looks like:

• They wait for tickets.

• They do what they’re told.

• They focus on the task in front of them.

• They care about their work, but they don’t think beyond it.

Here’s what an owner looks like:

• They think about the outcome, not just the task.

• They ask questions. Lots of them.

• They don’t wait for permission to spot problems and fix them.

• They look for ways to make the system better, not just the feature.

• They realise that we are there to deliver business value, not code.

Owners think bigger. They zoom out. They care about why the work matters, not just what the work is.

Subscribe now

Why This Matters

You can be the best coder in the world, but if you’re only doing what’s assigned to you, you’ll stay in the same place for a long time. You’ll get told, “Just keep doing what you’re doing.”

Meanwhile, the people who own their work, the ones who take initiative, who see problems before they happen, who think about business impact, they’re the ones who get promoted. They’re the ones who get the stretch projects. They’re the ones who get noticed by leadership.

Your company doesn’t promote people who just get the job done.
They promote people who create business value.

Want to Go Deeper? Get The Included Worksheet

I’ve created a Doer-to-Owner Worksheet for paid subscribers.
It’s a simple, practical guide with:

✅ 5 mindset shifts to break out of the doer trap
✅ Reflection questions to uncover where you’re stuck
✅ Prompts to help you step up and own outcomes
✅ A checklist to track your growth over the next 30 days

If you’re serious about growing in your career, this is the kind of self-reflection and action planning most people never do — but it makes all the difference.

👉 Subscribe and get the worksheet

The Doer Mindset: What It Sounds Like

If you catch yourself saying things like:

• “I’m waiting for my next task.”

• “That’s not my problem.”

• “I wasn’t told to do that.”

• “I did my part, someone else can figure the rest out.”

That’s a doer mindset. It’s safe. It’s comfortable. But it’s also why your career feels stuck.

You’re not showing leadership potential. You’re not demonstrating that you can handle bigger, messier, more important work.

The Owner Mindset: What It Sounds Like

The best engineers I’ve worked with don’t stay quiet. They don’t wait to be told.

They say things like:

• “This ticket doesn’t make sense. Can we clarify the goal?”

• “I noticed this feature might introduce a risk. Should we address it now?”

• “I think this part of the system is fragile. Here’s how we could improve it.”

• “If we build this, how will it impact the customer experience?”

They care about the bigger picture. They care about impact. They’re not just building features. They’re solving problems.

Final Thought

If you’re not growing… if your career feels stuck… it’s time to ask yourself:

Am I a doer? Or am I an owner?

I don’t say this to upset you or trigger you… I say this because I was stuck in this trap for so long. Honestly? Sometimes I still am.

Because the engineers who get promoted, who get trusted with the big stuff, who make an impact on the business… they’re the ones who step up. They’re the ones who own.

Stop waiting for tickets.
Start thinking in outcomes.

That’s how you grow.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• I’m building a brand new platform called EngLeadExpert where I help YOU to become better engineering leaders, check it out here.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >57,000 followers now.

Subscribe now

“We’re like a family.”

It sounds nice. Makes for a good careers page slogan. Looks great in a slide deck. But here’s the thing.

Your company isn’t a family. It’s a business.
Your team isn’t a family. It’s a team.

And when you treat it like a family, you create problems that hold people back, frustrate your best engineers, and stop your team from actually delivering.

What Happens When You Call a Team a Family

You start avoiding hard conversations because “it might upset the vibe.”
You let people stay in roles they’ve outgrown because “they’re part of the family.”
You reward loyalty over impact.
You let problems fester because you don’t want to rock the boat.

And while you’re doing that, your best engineers are quietly looking for their next job.

What a Team Actually Needs

Your team doesn’t need a family vibe.
They don’t need forced “bonding” or vague talk about how we’re all in this together.

They need:

1. Clarity
   What’s the goal? What’s the standard? What’s expected of me?
   If you can’t answer those questions, don’t be surprised when your team’s confused, frustrated, or disengaged.

2. Feedback
   Not once a year. Not when things go off the rails.
   Consistent, honest, actionable feedback. Early and often.

3. Ownership
   Stop treating people like task-runners.
   Give them real problems to solve. Let them step up.

4. Accountability
   If someone isn’t delivering, you need to say it. Early. Directly.
   The longer you wait, the harder it gets, and the more damage it does.

5. A Manager Who Leads
   Your team doesn’t need a best friend.
   They need a leader who makes the hard calls, protects focus, and doesn’t let things slide because it’s awkward.

Want a Practical Guide to Get This Right?

It’s one thing to know what a team needs.
It’s another thing to actually do it.

That’s why I’ve put together a short, no-fluff, impactful worksheet to help you put this into action.

Inside, you’ll get:

✅ 5 questions to challenge how you lead right now
✅ A checklist to hold yourself accountable
✅ Prompts to tackle the hard conversations you’ve been avoiding

This is for paid subscribers only.
Because building a team that delivers isn’t about reading a post. It’s about doing the work.

👉 Subscribe to get the worksheet

Subscribe now

Here’s the Truth

It’s easy to talk about culture when things are going well.
It’s easy to act like a family when there are no deadlines, no conflicts, and no pressure.

But that’s not the job.

The real work is:

• Giving feedback when it’s uncomfortable.

• Saying no to a bad idea, even when it’s unpopular.

• Making the hard call when someone’s not working out.

• Holding the standard, even when it’s easier to let it slide.

That’s what your team actually needs.

Not a family vibe. Not empty slogans.
Just clear expectations, honest conversations, and a leader who leads.

Final Thought

Stop calling your team a family.
Start building a team that knows where they stand.
A team that delivers.
A team that trusts you to do your job because they see you doing the hard stuff that matters.

That’s how you build a team people want to work on.

Not a family. A team.

Liked this, even a tiny bit or feel sorry for me? Make sure to click the like button ❤.

Think someone else might find this useful or you just want to make fun of me together? Make sure to share this post 🔗.

• Want to write a guest post for this newsletter? Let me know!

• I’m building a brand new platform called EngLeadExpert where I help YOU to become better engineering leaders, check it out here.

• I’ve launched a new YouTube channel.

• Check me out on LinkedIn. I’m at >57,000 followers now.

  Subscribe now

"What do you think is a fair annual price for this platform?"

The offering is simple but ambitious:

• Two flagship self-paced courses at launch

• Interviews with engineering leaders from companies like Google, Meta, and Netflix

• A growing library of templates, worksheets, and resources

• Community access

• Office hours

And it's just getting started, I plan to keep building on it throughout the year.

The results were fascinating. The majority of responses suggested a price below £200. 60% of people suggested under £100. A small percentage selected higher tiers, including a few for £500+.

At first glance, that could feel discouraging. If I’d gone purely by the numbers, I might have felt pressure to launch at a low price point just to make it feel "accessible." But the more I looked at the poll, the more interesting things became.

I noticed that some of the people voting for under £200 were course creators themselves. Creators I know are charging £500–£1000 for short cohort-based courses. These are often 2–3 live sessions, a Slack channel, and a few resources. Good content, no doubt… but limited in scope and time-bound. Once the cohort ends, so does the experience.

Meanwhile, EngLeadExpert.io is designed to be a living, evolving platform. It starts with two full-length, high-production courses but will grow over time. By the end of the first year, it might include five courses, 50+ interviews, and dozens of templates and guides. It also includes regular office hours and a community of peers working on real leadership challenges in engineering.

So I had to ask myself: why are people offering much less, suggesting I charge much less?

That question led to a few important realisations about building in public, listening to feedback, and trusting your positioning.

Polls Reveal Opinion, Not Always Insight

When someone answers a pricing poll, they’re often thinking: "What would I like this to cost if I were buying it today?" They’re not necessarily considering the value, the transformation, or how it compares to other offerings they’ve paid for in the past.

That’s not dishonesty — it’s just human nature. But it means that polls tend to bias toward lower prices, especially if you offer a low-priced option first. It also depends on who sees the poll: a first-year engineer in a small company may answer very differently than an experienced manager with a training budget.

Not All Feedback Should Carry Equal Weight

One of the most valuable things that happened after the poll was the number of experienced course creators who reached out to me privately. People whose names you will probably know. These weren’t people who just voted in the poll or commented for visibility. They’d built platforms, shipped high-ticket products, and understood the realities of pricing.

Their advice?

“Go high, much higher than those polls are saying.”
“Be careful with pricing polls, they often reflect wishful thinking, not willingness to pay.”
“Serious learners value serious products.”
"Premium products deserve premium pricing."

It was a good reminder: if you’re building something you truly believe in, you can’t crowdsource your pricing strategy.

Premium Products Require Premium Positioning

Pricing low doesn't just reduce your revenue. It can also lower how people perceive the quality and seriousness of what you’re building.

If someone sees "£99/year," they think: "Oh, cool, another course library."

But if they see "£750/year," they stop and ask: "Wait… what exactly is included? What kind of results is this going to get me?"

And that’s exactly the conversation I want them to have.

I’m not selling a handful of videos. I’m building a platform that helps engineering leaders grow into the kind of managers and strategic thinkers teams actually want to work for. That doesn’t come from a checklist. It comes from depth, from lived experience, and from ongoing support.

Building in Public Means Filtering as Much as Listening

One of the reasons I chose to build in public was because I believe in transparency. I like being open about what I’m building, what decisions I’m making, and why. It keeps me accountable, and it helps others learn from the process.

But that doesn’t mean every piece of feedback should drive the strategy.

Sometimes the best thing you can do is say:

"Thanks for the input. I’m still going to do it this way."

Not because you’re stubborn, but because you know what you’re building, who it’s for, and why it matters.

So Where Did I Land?

The platform will be £750/year.

For founding members, the early believers, it will launch at £450/year for a month.

After that, it will never be on sale again.

And I feel good about that.

Because if I’m going to ask people to take their leadership seriously, I should do the same with how I position the platform that helps them grow.

If any of that sounds interesting to you, you can sign up here to follow along.
You’ll get early access to what I’m building and see it all unfold: raw, messy, honest.

More soon,
Ryan Murphy

Subscribe now

Just quickly, whilst I have you:

• Want to write a guest post for this newsletter? Let me know!

• Check out my courses on Dometrain.

• Check me out on LinkedIn. I’m at >57,000 followers now.

• Check me out on Threads. I’m at a whopping 40 followers.

• Check me out on X (Twitter). I’m at a monstrous 50 followers.

What if I fail?
But… what if I succeed?

I’ve decided to go out on my own and start building something I’ve been thinking about for a while.

It’s called EngLeadExpert.io - a platform to help you become better leaders.

That means individual contributors trying to step up… or
Tech leads finding their footing… or
New engineering managers thrown into the deep end… or
Even experienced EM’s who never got the training they needed.

For a long time, I built courses in partnership with other platforms. I’m proud of that work and grateful for the experience.

But lately, I’ve felt a strong urge to do something more personal.
To build something fully my own.
Something I can shape from the ground up, with my voice, my values, and no ceiling.

Right now, it’s just a landing page with a big dream.
Some early sketches.
A few course outlines.
A notebook full of scribbled ideas.

And a gut feeling that says: you have to try.

If any of that sounds interesting to you, you can sign up here to follow along.
You’ll get early access to what I’m building and see it all unfold: raw, messy, honest.

More soon,
Ryan Murphy

Subscribe now

Subscribe now

There are typically two ways to get promoted:

1. Get promoted internally at your current company by going through their promotion process.

2. Seek promotion externally by moving to a new company in your desired role.

It’s unlikely that everyone will always be one or the other. The truth is that your career will be a mix of both: some internal promotions here and there, with a mix of external move-ups scattered in.

Let’s take my career as an example; I have worked in software engineering for ~15 years, with ~5 of those in management. I have had a mixture of internal and external promotions. For all of the external promotions, it was a mixture of backing myself when others wouldn’t and deep thought of the pros and cons.

After going through a few external promotions, I have taken my fair share of time to think about the pros and cons of internal vs external promotions. In this post, we will go through those, helping you decide which option might be best for your career goals.

Subscribe now

Benefits of an Internal Promotion

Familiarity

You’re already immersed in the culture, have established relationships with your team, and know the systems. This makes it easier to hit the ground running in a new role. You are aware of the ins and outs, the landscape and discovering the landscape of a new role will be drastically reduced in this area vs a new role.

Existing relationships and visibility

Working with managers and colleagues who know your strengths and contributions can smooth the promotion process. You’ve already built a foundation of trust and reliability. You will have worked damn hard getting the visibility for yourself which has shown your capability at the next role, and that will carry forward with you.

Track record

Your previous contributions and achievements within the company speak for themselves. An internal promotion allows you to continue expanding on those accomplishments. You are starting from a solid base of achievements here and not starting at zero, trying to build that foundation in your track record.

Challenges of an Internal Promotion

Existing perceptions

Managers and colleagues may already have fixed ideas about your role and capabilities, making it harder to prove that you’re ready for the next level. For example, in a previous role, I sent an update about a project that didn’t contain the level of detail the CTO wanted (who was three levels above me at the time), and no matter what I did, I could never shake that.

Subscribe now

Money

While internal promotions often come with pay increases, these may be more modest than what you could negotiate in an external offer. Negotiating a substantial raise can be more challenging if you stay within the same company, it’s not unusual to be met with the attitude: ‘This is what you are getting’. This is how it has been in my experience.

Promotion cycles and It’s Not Guaranteed

Some companies only offer promotions during specific review periods, which can be frustrating if you’re ready for a new challenge now. I have seen it before where someone was passed up for a promotion with feedback that, in my opinion, was a nitpick, and they had to wait another year for the promotion cycle to come around. It was no shock when this top performer left the company.

Benefits of an External Promotion

Fresh start

Starting at a new company brings a fresh perspective and new challenges, which can be invigorating and help you learn quickly. Sometimes, it’s nice to get away from those inherent biases internally and start on fresh ground. A chance to go again. The grass isn’t always greener, but you never know until you take a look.

Salary

Companies are often more flexible in negotiating offers for new hires, which can mean a larger salary increase than what’s typical for internal promotions. Whereas when getting an internal promotion, it can often be the case that you get given a raise, and that’s the end of the conversation, externally, it’s much more common to negotiate.

Targeted search

When looking externally, you can seek out a specific role or company that aligns with your career goals, culture preferences, and growth ambitions. For example, when I left working in finance as a software engineer, I wanted to try something that was the opposite of that, so I went to work for a company which builds software for charities.

Diversify experience and network

Moving to a new company allows you to diversify your experiences and expand your professional network, which can be valuable throughout your career. Some of my greatest opportunities have come from people I never would have met.

Challenges of an External Promotion

Unfamiliar

There are a few parts to this. Firstly, you will have to re-establish relationships and the trust which inherently comes with those. It will be a cultural adjustment; all the good and bad things about the last company which you got used to might not be the case anymore, so it will be an extra mental load getting used to the cultural nuances and adapting to a new environment.

Subscribe now

Impact starts at 0

When getting promoted internally, you would have built a list and timeline of achievements and business value that you delivered. At a new company, this will start at 0. This can be both daunting and refreshing.

Not realised expectations

Hopefully, the interview process will be good, and the pre-onboarding process will be solid, giving you an insight into the expectations of your role. However, there is no process good enough to fully prepare you for the true expectations of the role, which are realised once you dissect the culture, your boss, and your team.

*Stuff* to Consider When Deciding

1. Personal career goals

2. Timing

3. Company growth

4. Work-life boundaries

Final Thoughts

In your career, you will get promoted internally within an organisation and also you will get promoted externally via another company giving you a chance.

The chances are that you will spend many years working as a software engineer, so don’t be too hard on yourself. Give yourself a chance.

Your value and ability are your story to tell.

This newsletter recently hit 5,400 subscribers, that’s so wild. Please like this (click the heart button) and subscribe. It keeps me motivated and gives me heaps of help.

Subscribe now

Just quickly, whilst I have you:

• Want to write a guest post for this newsletter? Let me know!

• Check out my courses on Dometrain. Use the code CMURPHYLAUNCH for 20% off.

• Check me out on LinkedIn. I’m at >55,000 followers now.

• Check me out on Threads. I’m at a whopping 40 followers.

• Check me out on X (Twitter). I’m at a monstrous 50 followers.

Subscribe now

In my experience, there are three types of people when it comes to career progression:

1. Those who seem to keep jumping ahead.

2. Those who seem to take a bit longer.

3. The ‘somewhere betweens’. Those who jump quickly for a period and then take a bit longer in a repeatable pattern.

I’ve been around and managed all three types over my 15 years in technology. I’m number 3, a ‘somewhere between’.

Now and then, you will encounter the number one’s, the leap froggers. Every year or two, they will move up the career ladder, and before you know it, they have gone from a mid-weight engineer to a staff engineer, and the imposter syndrome starts to feel real.

In my experience, it comes down to three things: luck, ownership and doing your job.

Some People Seem To Be Damn Lucky

They are, and they aren’t.

From the outside, it can seem that a lot of people are in the right place at the right time. They join a company that is growing, and opportunities seem to fall in their lap.

I understand this point of view it happened to me, but it doesn’t tell the full story.

The chances are that if you join a fast-growing start-up, the chances of promotion are going to be much higher than if you join a larger company with more competition and more well-established level boundaries.

The two playing fields are not the same.

The truth is, though, that you have to be willing to be in that game to win it, and a lot of people like the brand recognition that comes with being at a larger company such as MAANG.

Subscribe now

Even if someone is in that environment where opportunities are fruitful, and they keep landing in their lap, there are not many successful founders who will just give those positions away. They will still be earning them; they haven’t sat there, done nothing, and been given a promotion in an environment such as a start-up where these decisions are crucial to its growth and success. These people will still be seen as doing the other two things on my list, which make them trusted and good candidates for that role: they take ownership, and they do their job.

You will also find people in those environments who don’t get the opportunities.

All of this is true no matter what environment you are in; you need to take ownership, and you need to be doing your job well.

You Need To Do Your Job Well

As a manager, one of the key traps I see people falling into when chasing a promotion is trying to demonstrate they can do the desired job and letting their current job expectations falter.

This isn’t a true rule that applies to everyone; it is a common problem I see people making. The more time and effort they spend putting into showing they can do the next role, the more they let go of what makes them a top performer in their current role.

This is a problem, more seriously, it can turn into a performance problem for you now while you chase your future.

When I go to promote you, I need to be able to demonstrate that firstly, you are great in your current role and that you nail the aspects of that, and I need to be able to give demonstrable evidence that you will be able to perform at that next role.

It’s a fine balance, and you need to do both.

I don’t want this to read that luck and circumstance doesn’t play a part, because they absolutely do!

Subscribe now

You Gotta Take True Ownership

Ownership is more than just writing code. It means being accountable for the outcome of a project, a product, or whatever you said you would do.

Many of us focus on honing our technical skills but often overlook the importance of true ownership in our projects. Ownership requires moving beyond just technical competency and considering the entire life cycle and business value delivered by our work.

There are several things you need to consider, below I have listed 5 of them and discussed what it means, given an example and told you why it matters:

1. End-to-End Impact

• What it means: You aren’t just concerned with your specific piece. You understand how your work fits into the broader system and how it impacts other areas of the project. ‘That’ll do, they can work it out’ isn’t good enough here.

• Example: If you’re building a microservice, for instance, you’re not only thinking about your service’s performance but also about how it interacts with other services in production, its impact on latency, and how it integrates into the overall system architecture. Are you thinking of how this effects marketing, sales and customer service teams?

• Why it matters: People who think this way are seen as valuable because they are proactive thinkers. They reduce bottlenecks and anticipate future challenges.

2. User Benefits

• What it means: Being deeply aware of the end-user’s experience. It’s not just about writing clean code. It’s about understanding how your code will affect the user and making decisions that improve their experience.

• Example: If you’re working on a UI feature, it’s not enough to make sure it functions correctly. You also need to think about how intuitive it is for the user, whether it solves their problem efficiently, and whether there are edge cases that could lead to degradation.

• Why it matters: Engineers who focus on user outcomes build more impactful products. There are no two ways about it. This ability to align technical solutions with user needs is an asset that will see you through your career. Build this habit early

3. Business Alignment

• What it means: Aligning your work with the company’s business objectives. This requires understanding the context behind what you’re building. How does it contribute to the company's success? What’s the larger goal?

• Example: If you are working on optimising a feature for performance. Beyond improving speed, you also consider how this optimisation could reduce infrastructure costs, which aligns with the company’s goal of improving profitability. How might customer service be able to utilise this? Is this something sales could benefit from when selling?

• Why it matters: Engineers who think about the business impact of their work are seen as strategic thinkers. They deliver business value which ultimately is what we are their to do.

4. Stakeholder Communication

• What it means: It’s all about communication. Owning a project means proactively keeping all stakeholders (managers, designers, product owners, etc.) informed about progress, potential risks, and changes. Be honest. No one wins from saying something is rosy if it’s not.

• Example: If a critical feature’s timeline is at risk, instead of waiting until the deadline to inform the team, you communicate early, offering potential solutions or alternatives to mitigate the impact.

• Why it matters: Proactive communication builds trust. It shows that you’re thinking about the project from multiple angles, which builds trust.

5. Measuring Progress Beyond Your Part

• What it means: Don’t just track the completion of your tasks. Care about the success of the entire project. You’re aware of how other parts of the project are progressing and whether they might impact your work.

• Example: If you’re building a feature that relies on a backend API from another team, taking ownership means regularly checking in on the status of that API, identifying any blockers, and helping to solve them. Even if it’s outside your core responsibility. ‘That’s not my job’ isn’t good enough here.

• Why it matters: Engineers who adopt this mindset are often seen as natural leaders. They think all around them. Having a cross-functional awareness is a key trait of more senior engineers and leaders.

Closing Thoughts

It might seem like some people leapfrog their way up the career ladder with ease and at a sharp pace. Just looking from the outside is not always the full story.

Sure some might just be truly lucky, but this run of luck is extremely rare and always catches up.

More often is the case is that they can demonstrate absolute capability at their current role with taking true ownership.

When I go to promote you, I need my peers to say: ‘Ah yeah, no brainer, let’s do it.’

When I asked my LinkedIn audience about this topic I got some valuable insights:

This newsletter recently hit 5,300 subscribers, that’s so wild. Please like this (click the heart button) and subscribe. It keeps me motivated and gives me heaps of help.

Subscribe now

Just quickly whilst I have you:

• Want to write a guest post for this newsletter? Let me know!

• Check me out on LinkedIn. I’m at >54,000 followers now.

• Check me out on Threads. I’m at a whopping 30 followers.

• Check me out on X (Twitter). I’m at a monstrous 50 followers.

Subscribe now

Saying no is one of the more challenging skills you must learn as a leader, whether thats as a Software Engineer or as a Manager.

This guide aims to give you an insight into one of the toughest parts of leadership: saying no.

For me, it was a learnt skill. When I was entering a conversation with either my team, stakeholders, my manager, or anyone that I knew I was going to need to say no in some form, my anxiety would go through the roof. I would get nervous. As a result, there was more than one occasion I didn’t quite say what I wanted to, I agreed to something I shouldn’t have for an easier life. As a result, I learnt the importance of being able to say no, the hard way.

Saying no is all about setting boundaries and priorities.

Subscribe now

A Personal Lesson

I once started as a new manager on a large team in disarray. They had three managers in the last two months and five new starters in the last three months. Delivery had ground to a halt, priorities were constantly shifting, and the team were burnt out.

They had no one to protect them or fight their corner. They had no one to coach them on how to set priorities, how to mentor each other, and how to set boundaries.

During my first six months as the manager of this team, I felt like I was known as ‘that person’ who just said no every day to everyone. I went through a conscious period of being overprotective and saying no to everything unless it was business-critical because the team needed stability, they needed to get the feeling of bonding together and knowing that they would not have to deal with constant pressure changes for a prolonged period. That team transformed, and that stability was huge for their growth. All because me and the team learnt to say no, more.

This wasn’t easy as a new person in the company, being the person to come in and just be seen as standing overly firm and not making friends outside the team by saying no to everything. It was incredibly anxiety-inducing and pressured to say no as people escalated requests to stand firm.

I was lucky to have a great manager who completely understood and agreed with my direction, and who had my back.

How to Say No and It’s Importance

Sometimes you say no because the request isn’t a high enough priority, sometimes you do it to protect the welfare of your team. Not every request will be the same.

My point with the above story is not to pat my own back; it’s to demonstrate that there will come times in your career when you need to change your tactic of saying no and how frequently you do it.

You should always try to compromise. The other person is unlikely to be coming to you because they have nothing better to do. They are looking for you to help because they have a situation that needs improving; ‘We can’t do this right now because of <x>. We would be able to help with <y> around <z>. Does that work for you and your timelines? Happy to discuss further.’

It’s tempting to say yes. Saying no doesn’t have to be negative. You can reframe it as part of a broader discussion on priorities. For example, "That’s a great idea, but let’s focus on <x> first to ensure we’re delivering quality work."

Saying no also means you’re guiding your team toward the long-term vision instead of getting distracted by every new task that comes your way. As a manager, one of your roles is to focus on sustainable growth.

Subscribe now

The Eisenhower Matrix

The above writing has largely been born from experience and personal struggles to learn hard lessons I want to share. I want to also give you exposure to a more universally well-reasoned tool: The Eisenhower Matrix.

I’ve also seen this called the urgency matrix. It’s ultimately a tool, a matrix, which helps you prioritise tasks. I like to call it The Eisenhower Matrix over The Urgency Matrix because it has a cool backstory.

It is named after Dwight D. Eisenhower, the 34th President of the United States, who famously used this method to prioritise his work.

I see it as a way of allowing yourself to be a little ruthless. If you sort your tasks or an incoming request into this grid, be honest about where it falls. If it falls into the low urgency and low important quadrant, as much as you might want to please everyone, as much as you might want to get everything done, just drop it. You have more important and impactful things to be doing. Focus, focus, focus.

I have an upcoming newsletter that dives into the Eisenhower matrix in great detail, so I will leave detailed advice for then as it’s much more involved than I feel is right to go into for this specific topic of saying no. I did want to share it with you so you can do some research, as I have found it to be a helpful mental model..

Closing Thoughts

Saying no is a learnt skill. I had to learn it the hard way. As a Software Engineer I had managers that were good at the skill, and I never appreciated how difficult it could be.

Saying no is not an excuse to just say no to everything because you can’t be bothered. You need to have a good reason or be willing to compromise.

There are mental models and tools to help understand what to prioritise and what to not, but the art of actually being able to say no can largely come from experience and going through it.

This newsletter recently hit 5,100 subscribers, that’s so wild. Please like this (click the heart button) and subscribe. It keeps me motivated and gives me heaps of help.

Subscribe now

Just quickly whilst I have you:

• Want to write a guest post for this newsletter, let me know!

• Check me out on LinkedIn. I’m at >53,000 followers now.

• Check me out on Threads. I’m at a whopping 20 followers.

• Check me out of X (Twitter). I’m at a monstrous 50 followers.

Nick Cosentino and I are excited to announce our new course ‘Nailing the Behavioural Interview’, which is coming soon to Dometrain. Watch the trailer below.

For 20% off use my code: CMURPHYLAUNCH. Send me your proof of purchase for a free 20-minute call.

Well… meet Peter White a 2x founder and Senior Product Engineer with over 10 years of startup experience.

I asked him to share with me his take on Product Engineering vs Software Engineering, deciphering that and what it could mean for you!

Over to you Peter.

Once, tech was neatly divided:

• Product Managers handled the “what”

• Software Engineers took care of the “how”

But no more. Enter the mutant superhero of the tech industry, the Product Engineer.

As companies race to deliver value faster while balancing technical quality, the Product Engineer bridges the gap, driving user-focused results with technical execution.

So, is it just another fad? Or are startups being cheap, trying to squeeze two roles into one bargain pack? Or is it something else - the future of building software?

Why Should You Listen to Me?

I've been a Product Engineer since before it was cool. 

Back in the day, SWE colleagues thought I was a “PM in disguise”, whilst the PMs felt I was stepping on their toes. 

I switched between the roles, trying to figure out where I fit.

I found a solution - startups, where wearing multiple hats is a feature, not a bug. 

Today, I’m a Senior Product Engineer at Graphy. I focus on building a product that users love. 

Want more insights? Follow me on LinkedIn (Peter White) for daily posts about life as a Product Engineer and navigating startup challenges.

Product Engineers vs. Software Engineers

Subscribe now

So, what’s the actual difference between Product Engineers and Software Engineers?

Both write code, but here’s the key difference:

• Product Engineers focus on customer outcomes and speed of iteration.

• Software Engineers focus on technical excellence and stability.

There are engineers out there who do all four by having a “product engineering mindset”.

But we can focus on achieving specific outcomes by making them distinct job titles. 

Why Are Product Engineers Suddenly Popular?

In today's tech landscape, it is being first that matters.

Product engineers are the special forces of the software world – they parachute in, get stuff done, and move on to the next challenge.

They're perfect for:

1. Startups needing to move fast

2. Big companies trying to stay nimble

3. Any team that's sick of the "throw it over the wall" silo approach between product and engineering

They’re not great for:

1. Projects where long-term technical stability is more critical than speed.

2. Teams that need deep technical specialisation over generalist versatility.

3. Large organisations with established structures that don’t need fast pivots.

Day in the Life of a Product Engineer vs. Software Engineer

The best way to understand the difference between these roles is to see a typical day in the life:

Subscribe now

Product Engineer:

• Morning: Huddle with PM, sales, and customer support. You're a product detective, piecing together user feedback. 

• Midday: Quick prototype of a new feature, demo internally and with pilot customers

• Afternoon: Push out a functional (if rough) version for feedback

Software Engineer:

• Morning: Deep dive into a persistent bug, syncing with the PM to get some extra context

• Midday: Optimising database queries for better performance

• Afternoon: Tackle scaling issues to ensure the system can handle growth, ensuring long-term stability and efficiency.

Product Engineers + Software Engineers: A Powerful Partnership

The best tech companies aren't choosing between product engineers and software engineers. They're using both.

Product engineers bring the speed, the user focus, the "let's ship it and see" mentality. 

Their Product Engineers might even be part of marketing, GTM, activation, analytics directly, rather than placed in a dedicated engineering team.

Software Engineers bring the depth, the scalability, the "let's build this to last" approach.

Together? They're unstoppable.

Product Engineering vs. Software Engineering - Which Is Right for You?

Product Engineering Path:

Ask yourself:

1. Do you get a rush from seeing users interact with your features?

2. Are you comfortable with ambiguity and changing requirements?

3. Do you enjoy thinking about the "why" as much as the "how"?

Then Product Engineering will be a great fit for you. But you'll find it frustrating if:

1. You want deep specialisation - Product Engineers trade depth for breadth.

2. You prefer clearly defined roles - this job feels like straddling two worlds.

3. You dislike ambiguity - things move fast, often without a clear roadmap.

4. You hate context-switching - expect to juggle projects and priorities constantly.

5. You’re not a fan of explaining technical details to non-technical stakeholders.

You’ll also likely find yourself working in startups or fast-moving companies, rather than larger more traditional companies or FAANG engineering teams.

Consider if this works with your risk tolerance, life and career goals.

Software Engineering Path:

If you're more excited by:

1. Solving complex technical challenges

2. Building systems that scale globally

3. Diving deep into specialised tech fields like AI, infrastructure, or security

Then software engineering is likely right for you. But you might find it frustrating if:

1. You crave fast user feedback

2. You dislike working on systems that aren't always visible to end users.

3. You get bored working on one big project for an extended period

4. You want direct influence over the product direction and strategy

Your Path:

Don’t get hung up on job titles.

Subscribe now

Want to dive into technical challenges but also shape product strategy? Do it.

Prefer getting fast feedback from users but still love optimising systems? Do it.

The modern tech landscape is flexible, and the best engineers are those who mix and match skills to identify and solve the right problems. 

Whether you lean toward the deep technical focus of software engineering or the fast-paced, user-centred world of product engineering, it’s all about achieving your goals and driving impact.

The Takeaway

The rise of product engineers isn't about replacing anyone. It's about evolution.

As the tech world gets more complex and user expectations skyrocket, we need people who can bridge the gap between raw code and real-world impact.

Whether you call yourself a product engineer, a software engineer, or just "that person who builds cool stuff" what matters is this:

Are you building products that users love?

If the answer is yes, you're on the right track.

Enjoyed this post? You’ll find more every weekday on my LinkedIn -  I post daily about life as a Product Engineer and the challenges of a career in startups.

A Thanks From Ryan to Peter

As a Software Engineer for over a decade of my life, I had the potential to be a bit touchy about this write-up. I wanted to push myself outside of my comfort zone and have someone write an article for us who might not see things exactly the way I do and write about them in the same way I do.

Peter did a perfect job of injecting his personality into this and I love that he put an emphasis on choosing your path and laid that out for you.

He encourages us to think about choosing the path which leads down not only the path that users love but also hints at the path that you love. Which is crucial. Some of us will have four decades in this industry, and I for one want to know I made at least some impact on others and my personal growth.

I strongly recommend following Peter on LinkedIn where I was personally drawn to his imagery and humour.

This newsletter recently hit 5,000 subscribers, that’s so wild. Please like this (click the heart button) and subscribe. It keeps me motivated and gives me heaps of help.

You can subscribe for free and get weekly issues straight to your inbox. Paid subscribers get the full archive of issues, access to free resources, templates, special offers, 10% off mentoring, and access to a private community.

Subscribe now

Just quickly whilst I have you:

• Want to write a guest post for this newsletter? Let me know!

• Check me out on LinkedIn. I’m at >54,000 followers now.

• Check me out on Threads. I’m at a whopping 23 followers.

Nick Cosentino and I are excited to announce our new course ‘Nailing the Behavioural Interview’, which is coming soon to Dometrain. Watch the trailer below.