Here’s the thing nobody tells you when you become an engineering manager: your job isn’t just helping your team do great work. It’s making sure the right people know your team is doing great work.

Yeah, it feels gross. Self-promotion by proxy. Corporate theater. All the stuff you probably hated about management before you became one.

But here’s what you need to understand: visibility isn’t vanity. It’s currency. And if you’re not spending it strategically, you’re watching your engineers’ careers stagnate while less talented people with louder advocates get promoted ahead of them.

The Wake-Up Call

A manager I know recently tried to get one of his engineers promoted. This person had been at the company 6+ years, consistently delivered solid work, beloved by their immediate team. Easy promotion, right?

Wrong.

Senior leadership had a “bad taste in their mouth” about this engineer. Not because of anything recent, mostly due to projects that failed for reasons completely outside the engineer’s control. Victim of circumstance, not incompetence.

The manager’s frustration: “Everyone on our team loves them. Everyone who works closely with them doesn’t have bad things to say.”

Translation: Being good at your job isn’t enough. The right people need to see you being good at your job.

The Brutal Math of Promotions

Nobody tells you this when you become an engineering manager, but promotions aren’t primarily technical decisions. In all sizes of engineering organizations, they’re political ones.

Not “political” like backstabbing. Political like they require building consensus among stakeholders, managing perceptions, strategic narrative control, and spending social capital wisely.

Persuasion, influence, politics. All the things you probably never wanted to care about in a tech role.

You can have all the performance data in the world. Every metric trending right. But if one senior engineer with a “pretty big voice” in the organization thinks your person underperforms? You’ve got an uphill battle.

I’ve had senior leaders who just hated an engineer on my team. One or two weird interactions. Their mind was made up. “This engineer suuuuuuucks,” worst dev they’d ever seen.

The engineer in question? Actually, really good and ready for promotion to senior.

This is the world we’re operating in. Fair or not, perception shapes reality when it comes to career advancement.

Let’s Get Po-litical, -litical

The political nature of organizations is frustrating. It feels like a waste of time, and the effort spent trying to “Little Finger” your way to a resolution is better spent elsewhere. But it’s an unfortunate reality in many organizations.

So how do you advocate effectively without becoming insufferable? Here are the tactics that actually work:

Name-Drop in Context

The wrong way to advocate: “Jill is doing amazing work, we should promote her.” Weak, vague, non-helpful.

The right way: During a meeting with senior leadership, when discussing a technical challenge they mentioned last week, drop it naturally: “Yeah, you should see the impact Jill’s work is having right now. Not only did she solve [that complex problem you were worried about], she did it faster than we expected, leading to [X Outcome].”

The difference is context. You’re giving your boss the platform and connection to understand how everything ties together. Make it easy for them to digest.

Tactical Tip: Keep a running doc of your team’s wins with context about what leadership cares about. When the right conversation happens, you’re ready.

Expand the Circle of Awareness

If senior leadership has a negative perception of one of your engineers, you need to do the detective work. Figure out exactly who holds that perception, then create opportunities for new, positive interactions.

This might mean getting your engineer invited to cross-functional meetings, having them present technical work to broader audiences (this has worked really well for me), facilitating mentorship relationships with senior ICs, or creating documentation that showcases their expertise.

I mentioned this in a previous post, but pound that pavement. Figure out who you need to talk to for the next milestone.

Seeing Is Believing

When credibility is damaged, direct repair beats advocacy from a distance every time.

Here’s what this looks like: An engineer on one team gets negative feedback from a well-respected senior IC on another team. Rather than defending your teammate from afar or arguing about the feedback’s validity, create opportunities for new, positive interactions between the two.

Have them work together on onboarding, rewriting documentation, mentorship strategies, or greenfield POC. Check in with the senior IC regularly to see how things are progressing.

This works because it creates new positive interactions that override old negative ones. Fresh experiences carry more weight than stale impressions. It also gives the senior IC a stake in your teammate’s success—once someone is mentoring or collaborating closely with your team, they become invested in positive outcomes.

The key insight: you can’t argue someone out of a negative opinion (trust me, I’ve tried). But you can create enough new positive data points that the old opinion becomes outdated.

Control the Narrative Early

Don’t wait until promotion time to start building the case. The groundwork happens months before. Remember those big reveals at the end of Oceans 11, 12, and any of the other resuscitations they did of that series? It wasn’t a smash-and-grab; it was methodically planned.

During regular meetings with senior leadership, casually mention when your engineer is crushing assigned work, running with it beyond expectations. Plant those seeds. Build a pattern of positive associations. Don’t lie, don’t embellish—show the results. Keep them in the conversation, but not as the heaviest part of the discussion.

Think Inception. By the time the formal promotion discussion happens, you want senior leadership to respond with “Yeah, that makes sense” rather than surprise or skepticism.

Think of it like a squirrel gathering nuts for winter. Each small mention, each casual update accumulates. When promotion time comes, you’re collecting on investments you’ve been making for months.

Celebrate Strategically, Not Constantly

There’s a fine line between advocacy and becoming the manager who thinks everything their team does is world-changing.

Doing their job adequately is not the same as being promotion-ready. I’ve made this mistake, and I’ve watched new managers make it too.

Not every pull request merged deserves an announcement. Not every bug fix needs to be broadcast to senior leadership. That kind of noise actually hurts your credibility and makes people tune you out when you do have something important to share.

Instead, make noise when an engineer:

• Solves a problem that was already on leadership’s radar

• Unblocks another team in a meaningful way

• Ships something that moves a key metric the business cares about

• Demonstrates significant growth in a skill area they’ve been working on

Use emojis, pick a great GIF, celebrate the win publicly, but focus it on the outsized impact. Something like:

”Yoooooo, Angie just dropped one of the biggest cost-saving changes of the year. With just two lines of code changed, she’ll save us $800k through [insert relevant outcome here].”

Tactical Tip: Track what leadership actually cares about. If they’re not talking about it in all-hands or leadership meetings, they probably don’t care if your team fixed it.

The Moral Conundrum

All of this can feel like performance theater. Like you’re playing a game instead of letting good work speak for itself.

And you’re right. It is a bit of theater, ya gotta give ‘em the ol’ razzle dazzle. Think Silicon Valley meets The Prestige, but with less cloning and no Michael Caine.

Here’s the reframe that helps me: Your job as a manager isn’t to evaluate whether this system is fair. Your job is to help your people succeed within the system that exists.

You can work to change the system over the long term. Push for better promotion processes, more objective criteria, and reduced bias. But while you’re doing that, you still have engineers who deserve to advance their careers now.

A manager I know framed this candidly for their engineer, who was facing a difficult path to promotion. He committed to being an ally, to working hard on the promotion, to being in the engineer’s corner. He’d throw every pitch he could. But he was also clear that the engineer needed to swing at those pitches, build their own promotion packet, advocate for themselves, and maintain their own accomplishments list.

That’s the deal. You can’t guarantee outcomes, but you can guarantee effort and advocacy. You can guarantee support and clear expectations. Most importantly, explain the game that must be played, as gross as it seems.

When Visibility Work Backfires

Not all visibility is good visibility. Here are the failure modes:

Over-promoting weak work. If you’re constantly hyping mediocre contributions, you’ll damage your own credibility. Senior leaders will stop trusting your judgment. When you do highlight something, they’ll discount it.

Creating resentment among peers. If other EMs feel like you’re always grabbing credit or taking up too much airtime, they’ll be less likely to support your people when it matters. Promotion decisions often involve consensus among peer managers.

Neglecting the actual work. Visibility without substance is just noise. Make sure the work actually justifies the promotion you’re pushing for. No amount of strategic communication can paper over weak performance. This is the “outcomes over “They completed 80 points this sprint!” “Did the work have any impact?” “Uhhhhhhhh, no.” 😬

Ignoring your team’s preferences. Some engineers genuinely don’t want visibility. Some don’t even want to be promoted, and that’s okay. Your job is to advocate for their career goals, not impose your vision of success.

The Meta-Game

While you’re doing all this visibility work for your team, you’re also establishing your own reputation as a manager.

When you advocate effectively—thoughtful about timing, strategic about channels, accurate about capabilities—you build trust with senior leadership. You become known as someone who develops people effectively, has good judgment about talent, delivers results consistently, and can be trusted with bigger teams and harder problems.

This compounds over time. The better your reputation, the more weight your advocacy carries. The more weight your advocacy carries, the easier it becomes to get your people promoted. The more success you have getting people promoted, the stronger your reputation becomes.

Round and round we go.

Look, I get it. We all want to live in a world where great work speaks for itself. But that’s not how most organizations run.

Great engineering managers are great translators. You translate technical work into business impact. You translate individual contributions into team success. And you translate quiet excellence into visible career advancement.

Is it uncomfortable? Yes. Is it gross? Sometimes. Is it necessary? Absolutely.

Your engineers are counting on you to do the one thing they often can’t do effectively for themselves: make sure the right people see them winning.

What’s your approach to visibility work? Have you struggled with the balance between advocacy and authenticity? Drop it in the comments.

While it was not my team, I had to sit in on a few standups for a cross-functional project. I had a 1:1 with the manager shortly after and gave a few pointers on how they could be more effective and trim the timing in half. They looked at me as if I’d intentionally spilt beans on their best tuxedo, and they replied, “I know what I’m doing.”

They were angry, they shut down, and we ended the conversation.

I still think about that interaction a lot. I was attempting to be helpful, but I’d neglected a key factor.

As managers, we’ve been taught to give feedback. On performance, on decisions, on day-to-day team operations, for potential hires, all over the place. There are whole books dedicated to delivering feedback (Radical Candor being the book I recommend most). Delivering feedback well is vital to a manager’s survival.

How exactly to deliver feedback well is likely its own post, but an interesting starting point that’s rarely discussed is that not everyone wants your feedback.

Shocking, I know, but when people say “feedback is a gift,” we tend to forget that some people are bad gift-givers, but there are also bad gift-receivers. I find that when someone doesn’t receive feedback well, it’s an opportunity to learn on both sides, making it productive instead of leaving a sour taste in our mouths.

For me, it’s a chance to question how I delivered the feedback, what was and wasn’t heard, why it wasn’t well received, and whether I should leave it alone or revisit it with them later.

In the case above, I was overstepping the comfort zone for the other manager. They held their ceremonies near and dear to their heart, had always done it that way, and didn’t want to change. While I disagreed, I needed to back off. (I also wasn’t in a position to force them to do it a different way, regardless of how I felt).

The easiest way to approach feedback in these cases is by asking questions. There was likely a reason this manager was running the standup the way they did. Don’t assume that they want the standup to be an hour; there may be more to it.

If you still feel like you’re not making any headway you can jump to one of my favorite questions by asking “are you open to some feedback about XYZ?”

This can help diffuse tension and gives the receiver a chance to opt out. If they don’t want the feedback, leave it alone.

Sure, feedback is a gift, but sometimes people throw your gifts directly in the trash.

Sometimes people just want to be mad about it, which is also totally fine. You are not in control of how someone responds to feedback, you are only in control of how you deliver that feedback. Approaching the individual on their level, and with empathy, will help the feedback land.

My commitment is to delivering clear feedback with support. I know it will not always be received well, but I would rather assume everyone wants to grow than never give direct feedback again.

If you’re looking for two reads in 2026 to help with delivering feedback well, I highly recommend:

• Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott

• Holding the Calm: The Secret to Resolving Conflict and Defusing Tension by Hesha Abrams

Some quicker reads, especially in the engineering world:

• Your Code Reviews are unknowingly silencing your Intern and Junior Engineers

• Constraints on giving feedback from Will Larson

Employee writes their performance review with AI.

Manager reviews the review with AI.

Manager responds with an AI review of the AI-reviewed, AI-written review.

Employee responds to the response about the review of the review...

Stop. Put down your AI and come out with your hands up.

Please, I beg of you, don’t perpetuate this loop. We already live in a world of performance review theater, where everyone’s pretending to care while secretly trying to survive Q4. And now? You’re adding an AI wrapper on top like a little parsley garnish of detachment. It doesn’t make it better. It makes it hollow.

There are two sacred spaces where I implore you to keep the robots out: 1:1s and reviews.

These moments are personal. Human. Messy. They are not meant to be automated. You are responsible for the person sitting across from you. You owe them your actual, unfiltered thoughts about how they’re doing, not a prompt-engineered paragraph about “growth opportunities.”

“But it’s too much text! How can I read it all?!”

Really? The employee spent time thinking, writing, and sweating over this document. If you want something shorter, say so. If you only care about bullets, ask for bullets. Don’t make them write a novel you’re just going to feed to ChatGPT so you can pretend you read it.

Set expectations. Make it humane. Let people spend their brain space on real reflection instead of trying to come up with another synonym for “above and beyond.”

The Tax Analogy (And Why Everyone Hates It)

In most companies, reviews feel like filing taxes:

• The employee fills out their best estimate of their worth.

• The manager (a.k.a. the IRS) already knows the answer.

• Then they tell you why your math is wrong, and you owe them another 10%.

We don’t need AI to solve this. We need honesty, clarity, and a shared understanding of what actually matters.

Make It Easy. Make It Human.

If you’re giving real, honest feedback in your 1:1s, the review should never be a surprise. It should feel like closing a book you’ve already read together. A few nods about the past. A bigger conversation about what’s next.

Here’s the simple 3-line template I swear by:

Reviews Made Simple For Employees

1. Write down three things you’re proud of from the past [X time period] and the impact they had. (celebrate these!)

2. Write down three areas you’d like to improve and why.

3. Write down three things your manager can do to support you in those areas.

Reviews Made Simple For Managers

1. Write down three things the employee did well in the past [X time period] and the impact they had. (celebrate these!)

2. Write down three areas you’d like to see them improve and what that looks like.

3. Work together to write down three goals the employee will aim for, and you will support. I tend to break this into one personal, one team, and one broader career goal. After all, we likely only have the employee for 1-3 years, so what can we do to prepare them for the future?

That’s it. Review? Done. Goals? Done. Support? Done.

No AI. No theater. Just two people having an honest conversation about work.

And if you’re not comfortable putting your review together? Reach out! I’d much rather we chat about how you can put together a great review experience than have you turn into one of those managers who fill their reviews with fluff.

Helpful Links

• “Is performance management over?” [Hebba Youssef]

• “Why the annual performance review is outdated” [Dominic Joyce]

• “Rethinking the Review: Why We Are Getting Performance Evaluations All Wrong” [Inc.com]

• “Workers Want Fair, Accurate Performance Reviews” [Business News Daily]

• “The fairness factor in performance management” [McKinsey & Company]

• “How Effective Feedback Fuels Performance” [Gallup]

• “Preventing Surprises in Employee Performance Reviews” [WorkStory]

• “The future of feedback: Motivating performance improvement” [PMC]

New format for links, are they more helpful?

Waffle House somehow managed to create a universal menu language from scratch, using only the items in their restaurants. They’re using the system to make sure everybody is on the same page, everybody understands the same system across all of their locations, and even in the chaos of a bustling restaurant, they can flawlessly keep orders coming out of the kitchen.

No tickets needed, no deciphering speedy scrawls, pure efficiency. Waffle House has hundreds of locations in the U.S., and every single one follows the same system.

I’ll give you the short version because again, even I don’t fully understand exactly what’s happening. The Magic Marker system at Waffle House is about teeing up an order by arranging items on a plate like some sort of Guy Fieri fryomancer.

You place items (like jelly packets) on the plate to then indicate “here is what I need you to cook and how”, all the way down to how eggs are prepared (scrambled, over easy, over hard, etc). The placement of an item on the plate dictates how those eggs or that item will be cooked. It’s pretty ingenious, and seems a little insane (as with most great ideas).

Here’s the training video for the system, and a quote pull to give you a sense of what we’re dealing with.

Cheese omelet or a mushroom omelet: these are marked using a horizontal jelly packet in the number four position and a piece of the corresponding ingredient. Here you can see a cheese omelet also the Fiesta omelet which is indicated by a horizontal jelly pack with a right side up salad dressing.

If that sounds like nonsense, you’re right, but that’s also because you haven’t been onboarded appropriately.

Unwritten Rules

There are a lot of unwritten rules and micro-habits in organizations. I’ve recently gotten to onboard a few engineers at Trellis, and it’s interesting to try to figure out what all of those unwritten rules are and if we’ve appropriately written them down, or codified them. How do we create our own Magic Marker system so that new folks can learn quickly and slot right in within the team?

Especially in startups, you grow your teams because you are feeling the strain of too many problems, not enough people. As soon as someone walks in the door, you want to hand them a problem to begin reducing risk. Waffle House reminds us that while you may want to get your new hire involved right away, you have to teach them the system first.

We have language, but I think the beauty of this system, and the beauty of some of these more bespoke rules, are that it surpasses that. It gives you a quick chance to review and visually understand what something means. Think of this as architecture diagrams, or Loom walkthroughs showing every step in the path of your system, connecting the concept, the visual element, the code itself, and the data.

Other things to note are the visual queues a new hire is likely to see. We use 👀 reactjis in Slack to show we’ve seen something. Some orgs it ends there, but we know we mean “I’ve seen it and am taking action.” If there is both a 👀 reactji and a ✅ reactji, it means I’ve seen this, and we’re good to go. Even then we’ll usually add some notes with proof of why we’re good to go.

Consider how you’re arranging the plates at work and be sure to jot down the system so others can easily review and adapt.

Regardless of how bizarre the system seems, you have to write it down and you have to be able to get that information out and understandable to other people that will join your organization. Instead of having different words for things, a symbol can sometimes be enough.

@hotsoupandcrackerReply to @yostmalone1 #wafflehouse #linecook #eggs #fyp #foryoupage #blowthisupforme #shortordercook #linecook #fypシ #cooking #tiktok #foodtok #pov

Tiktok failed to load.

Enable 3rd party cookies or use another browser

System Flexibility

Similar to the systems and rules that we build for both organizations and in software, the system also has to be flexible in case something changes in the future.

Think about current state of Waffle House. I’m no Waffle House expert, but the menu probably hasn’t changed much across its existence. Once you have the menu, it’s pretty set. In a fairly unchanging system, the Magic Marker method works great. But what if Waffle House added 18 new menu items. Could the current system handle the items? What would break?

Thankfully for Waffle House, their system creators were savants and each item has multiple dimensions, with different meanings for upside down, rotated horizontally, vertically, or diagonally, and stacked on top of each other. The system is flexible

Reactjis give a similar flexibility, especially because you can add more to your Slack workspace without issue. As the system evolves, so to will the documents that highlight that evolution. Your system won’t be perfect on the first go, nor should it be. I follow the “aim small, miss small,” method of people systems which lets you reap rewards without major change management overhead.

Try something new out this week, look at your communication channels and see where items are dropping. Is there a visual signal you can add that helps your team know immediately what to do with that item? It might not be as efficient as upside down butter on a plate, but we all have to start somewhere.

I’ll leave you with one more, because I’m still amazed and horrified.

Butter next to a jelly packet = biscuit

Helpful Links

Engineering Leadership & Management

• Why Great Engineering Managers Shouldn’t Code
  You might think coding makes you a great manager, but think again. This article slices through the myth that hands-on programming is the key for leaders. Instead, discover how empowering your team and focusing on strategy can turbocharge results and drive success.

• Clarity
  Stop the chaos and create laser focus in your team. This article dives into how leaders can strip away confusion, foster clear communication, and energize decision-making. By mastering clarity, you turbocharge team productivity without the burnout.

• High-Performance Teams That Scale
  Unleash the power of high-performing teams. This book dives into strategies for creating clarity, minimizing decision chaos, and safeguarding focused work periods. You will discover actionable insights that elevate your team’s productivity and morale, helping you lead with purpose and impact.

• Small Teams, Big Results
  Small teams can pack a punch when managed right. This article reveals how to harness streamlined decision-making and unshakeable focus to maximize impact. You don’t need a big crew to drive innovation; you need the right mindset and tactics.

• What happens when we eliminate the Agile leader
  Ditching the Agile leader might sound radical, but it could be your secret sauce to unleash team potential. This article dives into how self-managing teams can drive productivity and creativity without traditional hierarchy. If you’re ready to shake things up, this is your roadmap to a leaner, more dynamic workflow.

Remote Work & Organizational Systems

• Remote Work Makes Employees Happier: 4-Year Study Confirms
  Put a smile on your face. This study reveals that remote work boosts employee happiness, and it’s not just a fling. Engagement rises and burnout dips when teams embrace flexibility. You won’t want to ignore this trend as you shape your organizational culture.

• Become an Octopus Organization
  Ready to transform your organization? This article dives into the dynamic structure of octopus organizations where flexibility and interconnectedness reign. You’ll learn how to build resilience and adaptability in your teams to thrive in complex environments.

• A One-Pager Is All You Need
  Cut the clutter and elevate your team’s focus with a killer one-pager. This article reveals how distilling your project goals into a single page can enhance clarity, streamline communication, and drive faster decision-making. You’ll supercharge your team’s effectiveness without the overwhelm.

• The Full Catalogue
  Get ready to feast on a banquet of insights that will nourish your leadership style. This post serves up a comprehensive list of resources that elevate your understanding of organizational dynamics. You’ll transform your team’s performance with actionable strategies that stick.

AI in Engineering Workflows

• Why AI Can’t Do Hiring
  Hiring with AI? Forget it. This article lays out the critical human elements AI just can’t grasp in the recruitment process. You need nuance, judgment, and gut feel to build a killer team that thrives.

• Not Artificial, Not Intelligent
  Are you tired of buzzwords? This book dives deep into the messy truth about AI, distinguishing hype from reality. It provides actionable insights on how to harness technology effectively without falling for empty promises. Get ready to sharpen your engineering strategies and boost productivity.

• What most companies overlook when determining AI readiness
  AI isn’t just a shiny new toy. You need to dig deep, assessing not just technology but culture, skills, and strategy. Get ready to transform your mindset or risk getting left behind in the data dust.

Prioritization, Strategy & Metrics

• Vibe Engineering
  In the fast-paced world of tech, vibe engineering is your secret sauce for building high-performance teams. This article dives into creating an environment where people thrive, making collaboration seamless and focused. You will learn how to harness positive energy to supercharge your team’s productivity.

• Context Switching: The Hidden Productivity Killer
  You think multitasking is the secret sauce to productivity? Think again. Context switching steals focus and zaps energy. Learn how to streamline your workflow and reclaim your time for deeper focus and better results.

• Leadership Unblocked: How to Harness Your Beliefs and Potential
  Are your beliefs blocking your team’s potential? This book dives deep into the psychology of leadership, equipping you with powerful strategies to overcome mental roadblocks and elevate your leadership game. Get ready to unleash your team’s true capabilities and foster an environment where innovation thrives.

Broader Industry & Thought Leadership

• Respect at Work Returns to Record Low
  Attention leaders: workplace respect is hitting rock bottom. This article reveals staggering declines in employee engagement and outlines actionable steps to regain trust and respect. Don’t just serve another bland dish of policies—bring the heat and authenticity back to your culture.

• RDEL 113: What Are the Seven Team Behaviors That Build Belonging?
  Get ready to revolutionize your team dynamics. This article dives into the seven essential behaviors that foster belonging and improve collaboration. Unlock the secret sauce to a thriving work culture and maximize your team’s potential.

• An engineer’s guide to cultivating belonging in tech
  Belonging is not just a buzzword, it’s the secret sauce for team success. This guide dishes out actionable insights on how you can foster an inclusive environment, driving productivity and creativity. If you want to build a team that thrives, you need to read this.

• I Tried to Quit My Job by Faking a Health Crisis
  If you’re feeling burnt out or stuck, this article dives into the wild world of work-life balance struggles. It’s an honest look at the extremes people will reach when their jobs turn toxic. Take a hard look at your own environment and consider what change is truly needed.

If that’s true, that also means we’re headed into an era where you can’t believe everything you see. I studied Broadcasting in undergrad and wrote for the school paper, and it was drilled into me that above all else, you should always verify sources and validate leads before publishing a story. If something sounds too good to be true, it probably is.

It’s easy to take a video for face value and immediately react. There’s a whole side of YouTube dedicated to people reacting to videos. As more AI-generated content is created and anything can be made a reality at the stroke of some keys, it’s going to be extremely easy to bend the truth. Even small things, like public figures having public freakouts, or your co-workers saying something outrageous, could be manufactured with a quick prompt. You are going to have to do the leg work to figure out if it’s reality or not. Snopes.com won’t be able to keep up (is Snopes still a thing?).

Same goes for management (and don’t get me started on B2B sales! /s). You will hear things about your team, their work, what’s happening when you’ve given them autonomy, and you have to determine which version of reality is accurate. Half of management is detective work, following leads, and determining the version of reality you and your team will follow. It’s the same thing for data too. One graph could mean any number of things, so use your critical thinking skills to determine why it’s right or wrong. It’s one of the reasons I love the 1993 classic “How to Lie With Statistics.”

This is also not intended to be doom-and-gloom, but more of a warning to think before you react. I made a mistake early in my career where I assumed I knew the full story, but definitely did not. Learn from my mistakes. And by all means, don’t let me rain on your AI-generated video parade.

Take a moment to gather the facts of the situation, validate the sources, determine the credibility of those sources, and make decisions from there. Redactions and apologies are tough to come back from, so spend a few extra thinking cycles on the believability of what you’ve seen and heard.

Anyway, here’s a video I prompted for Sora 2 of a totally real guy eating totally real onion ring glasses on a park bench. flavors-you-see.io coming soon.

🧭 Engineering Leadership & Management

• Nothing Prepares You for Your First Director Role [Honeycomb]
  Moving into a director role is like switching from sous chef to running the kitchen. This piece nails the messy reality of moving from tactical execution to political influence. Bookmark it for your next promotion talk.

• Leading with Emotional Intelligence in the Age of AI [CIO]
  As automation grows, EQ becomes the most scarce leadership resource. This article makes a solid case for empathy as a competitive edge, not a soft skill.

• Reverse Impostor Syndrome [Wes Kao Newsletter]
  Instead of feeling unqualified, high performers often underestimate how capable they actually are. A sharp mindset shift that helps leaders stop playing small.

• On Good Software Engineers [Can Dost Blog]
  A grounded reflection on what makes great engineers stand out. Hint: it’s not raw speed, it’s ownership, clarity, and generosity.

• Async Programming for Humans [Braintrust]
  Not a coding tutorial, a management philosophy. Async thinking is a survival tool for distributed teams. This piece breaks down how to adopt it without slowing collaboration.

🤖 AI in Engineering Workflows

• Is AI Good Enough to Lay Off Your Engineers [Section AI]
  The question everyone’s whispering. Section AI runs the math on where LLMs actually deliver ROI and where human judgment still dominates. The answer is more nuanced than the headlines.

• The AI Bubble Is About to Burst, But the Next Bubble Is Already Growing [Medium]
  A sharp take on how hype cycles move faster than innovation. The next gold rush might not be AI itself, but the tooling around it.

• AI Podcast Startup Plan Shows the Chaos in Audio Automation [Hollywood Reporter]
  A wild glimpse at AI-generated podcasting. Think cloned voices, messy IP, and an industry still figuring out what “authentic” even means.

• How to Think About AI Progress [Marginal Revolution]
  Tyler Cowen at his best. A clear, skeptical lens on what counts as genuine AI progress versus what’s just packaging.

📊 Prioritization, Strategy & Metrics

• The Wrong Way to Use DORA Metrics [The New Stack]
  DORA metrics aren’t magic. Used poorly, they become performance theater. This post explains how to make them actionable and culturally safe.

• The Purpose of Prototypes [SVPG]
  Marty Cagan reminds product teams that prototypes are for learning, not validation. A tight, essential read for anyone shipping too slowly.

• Determination [Paul Graham]
  Graham revisits grit. Success often depends less on brilliance and more on stubborn progress. An evergreen piece that feels even more relevant in the AI era.

🔮 Broader Industry & Thought Leadership

• The Era of the Business Idiot [Where’s Your Ed At]
  A spicy critique of leaders who confuse buzzwords for strategy. Equal parts rant and insight. You’ll nod, laugh, and maybe wince a little.

• Is Waymo Safe [The Atlantic]
  A balanced investigation into the safety record and perception of autonomous vehicles. The debate around “safe enough” is just beginning.

• How to Think About AI Progress (Archived Conversation with Yann LeCun) [Archive]
  A preserved deep-dive on the philosophical and technical sides of AI development. Less hype, more history.

• The Future of Agentic AI and Automation (Google Share Link)
  A peek behind closed doors at how large enterprises are experimenting with internal AI systems. A little vague, but telling.

GPT-4o had this… warmth. It was witty, creative, and surprisingly personal, like talking to someone who got you. It didn’t just spit out answers; it felt like it listened.

Now? Everything’s so… sterile. Formal. Like I’m interacting with a corporate manual instead of the quirky, imaginative AI I used to love. Stories used to flow with personality, advice felt thoughtful, and even casual chats had charm. Now it’s all polished, clipped, and weirdly impersonal, like every other AI out there.

Hmmm, like talking to PhD-level expert 🤔(no shade intended toward those with PhDs).

The varied responses shine light on what each group wants AI to be. Standard users want their AI assistant to be consistent and reliable with some warmth and personality (like H.E.R.). Tech-focused users want it to be smarter, faster, and more efficient (nearing HAL territory).

Wherever you sit on the line (maybe you don’t even use ChatGPT), it’s interesting to see how a tool so ingrained in the day-to-day can trigger these reactions.

We’re in an age where vibe-coded vaporware is going to get looks from top VCs because of the possibilities. All of the products on ProductHunt have some sort of AI capability. Companies are scrambling to stay relevant the only way they know how, jumping on the hype train and embedding AI into all of their products regardless of whether or not its a good idea.

Call me old-fashioned, but I don’t think I need an AI-powered refrigerator to tell me what’s inside my refrigerator. Instead, I’ll just…open…the door?

On the flip side, as the Head of Engineering for a Conversational AI team, I focus on improving operational efficiency and delivering more value to the company through AI use. It’s a fascinating world out there, one that’s rapidly evolving and it’s tough to know what tools and trends will have staying power.

My advice on how to proceed with the hype is to try it for yourself. Figure out what the repetitive tasks are that you wish you didn’t have to do anymore, and think of a way to offload to AI. What do you wish you could spend more time on? How might AI assist you in getting more time? You could even start with a basic prompt like:

You are an automation expert for casual users. I want to spend more time painting miniatures, but I have X, Y, and Z tasks that take up too much of my day. How can I automate these tasks without a budget? 

If you’re looking for some reading on AI and still forming your opinions on whether it’s good, bad, or both, I’ll aim to have an AI section in this newsletter every week, along with my standard management and engineering leadership links.

🧭 Engineering Leadership & Management

• How Netflix, Stripe, and GitLab Built High-Performing Engineering Teams [Substack]
  Three elite orgs. Three playbooks for building engineering excellence. Talent density, decision-making frameworks, and cultural clarity. Steal shamelessly.

• 20 Powerful Leadership Quotes That Will Transform Your Thinking [Medium]
  Not corporate fluff. These are quotes worth putting in board decks and taping to your fridge.

• The State of Engineering Leadership [Eng Leadership Newsletter]
  A high-level scan of today’s leadership climate. Retention, alignment, and where execs are quietly panicking.

• Top Performer Who Has Lost Faith in You [Reddit]
  When a high performer disengages, your leverage drops. Practical ways to rebuild trust without begging.

• When Team Structure Collides with Role Alignment [Medium]
  Organizational Jenga. Reporting lines and actual responsibilities out of sync. Fix it before velocity crumbles.

🌍 Remote Work & Organizational Systems

• Choosing Where to Spend My Team’s Effort [frederickvanbrabant.com]
  A clear framework for deciding what work truly deserves your team’s energy.

🤖 AI in Engineering Workflows

• Mastering AI at FAANG: A Roadmap from Junior to Senior Engineer [Medium]
  A career progression cheat sheet for AI-native engineers. Skills, tools, and mindset shifts that matter.

• AI Acceptance Rate Is an Easy Measure to Spot Misuse [LinkedIn]
  Laura Tacho introduces a KPI to catch AI misuse early. Keep code quality intact.

• Andrew Ng Calls Vibe Coding an Engineering Apocalypse [Perplexity]
  Ng warns that vague prompts plus AI lead to sloppy, hard-to-maintain code.

• Vibe Coding and the Coming Engineering Apocalypse [WIRED]
  Journalistic view of how AI-generated code could erode engineering discipline.

• Coding Agents Cross a Chasm [Singleton Blog]
  AI coding agents are entering production use. Progress is real but integration is messy.

• Seizing the Agentic AI Advantage [McKinsey]
  A structured guide to deploying AI agents as strategic assets.

📊 Prioritization, Strategy & Metrics

• 2025 Compensation Survey Report [SSUSA]
  Fresh salary benchmarks for engineering, product, and data roles.

• Default Alive or Default Dead [PaulGraham.com]
  The simplest way to measure startup survivability. Ignore it at your peril.

🔮 Broader Industry & Thought Leadership

• Disney and Universal Sue Midjourney Over Copyright Infringement [The Verge]
  A landmark IP case that will influence how generative AI trains on content.

• Can Your Brain Talk to Others While Asleep [Science Focus]
  Early experiments suggest dream-state communication might be possible.

• How to Avoid the Ethical Nightmares of Emerging Technology [HBR]
  A practical framework for responsible innovation.

• The Erosion of Quality in Large Language Models [ScienceDirect]
  Research shows LLM quality declines without human oversight.

I once had a non-technical leader ask me about someone hiding behind “perceived complexity” in a project we were working on. They worried that the project seemed to have stalled and we would miss a significant milestone, putting the broader project at risk. Their interpretation was that the engineers working on a primary workstream were dragging their feet, obfuscating to make it seem like they were working hard without hardly working.

The question inside the question was fair, “this feels behind, but I don’t know enough to help, what can we do?” The way it came out was much more pointed and less empathetic to all aspects of the milestone’s complexity. It was a core system that was being rewritten to facilitate a major migration, all while making sure the company didn’t accidentally stall out in the process.

I’m sure this is not a foreign question for engineering leaders. We’re dealing with stakeholders who don’t understand the underpinnings of the broader systems, and it’s hard to know how granular to explain. Here are a few things I’ve found helpful over the years (at least more helpful than asking them to write it themselves).

1. Show the work. Linear (my favorite ❤️) or Jira are two systems great at showing high-level data and breakdowns of work. I’ve written before about how velocity can be deceiving, so report out with a filtered view or an explanation of shifts. If nothing else, showing your work makes visible the chunks into which your team has broken the larger project. The benefit of charts is that you can see the ebb and flow of interruptive work (additions to scope) and the progression of work because of it.

   

2. Be objective about trade-offs. Something like, “I hear you saying that you are concerned about the completion of this piece of work, if we are able to drop X and Y, we can regain focus on Z.” Removing the emotion and focusing on what’s in the way of potentially completing Z can shift the focus of the stakeholder from defensive to advocate, bulldozing everything that is not Z out of your path.

3. Show diagrams. This is my go-to lately. Pointing at flow charts and architecture diagrams has been much easier than talking theory or writing out large documents. The diagram doesn’t even need to be high fidelity, it can be a generalization to get the point across. Having this tangible artifact can go a long way.

4. Build the trust bridge. The hope is that this is something you’ve worked up to already. In other experiences, I’ve had bosses ask “Hartley, should I be worried about this?” which led to solid, supportive conversation. From there, they trusted I would get the job done, as I had proven many times in the past. If you’re not at that point, have the hard conversation and find out how best to build trust for future situations.

Rarely do engineers drag their feet intentionally. Most are well-meaning and get enjoyment out of finishing complex projects. To assume they are hiding behind perceived complexity is to believe they do not desire to do well in their craft.

In moments of doubt, clarity is your best ally. The more we can demystify the work through visibility, honest trade-off conversations, and simple diagrams, the less room there is for misinterpretation. Stakeholders don’t need every technical detail, but they do need to feel confident that progress is real and purposeful. Our job isn’t just to lead the work, it’s to make it digestible. The hope being that, over time, we all need less TUMS.

Now, onto the links I found interesting this week.

🧭 Remote Work & Leadership That Scales

Remote Teams Need Systems, Not Surveillance
Micromanagement often shows up dressed as “visibility.” This piece argues that what remote teams really need is better systems, not tools that track every keystroke. Fits nicely into the above, no?

Remote Excellence Guide
More on trust! A structured, practical handbook for high-performing remote teams. It’s full of principles and templates you can actually use.

🏛️ Power, Privilege & the Toligarchs

Rise of the Toligarchs – Scott Galloway
The new power players aren’t politicians, they’re tech-native thought leaders. Prof G’s take on the rise of tol-igarchs is sharp, timely, and uncomfortable in all the right ways.

• Watch: The Rise of the Toligarchs
  The written piece is strong, but the video version is classic Galloway: data-backed, unfiltered, and genuinely insightful.

Bond Capital’s TAI Report
Mary Meeker’s latest breakdown on the state of AI, filled with data, perspective, and insight on what’s really next after the hype.

🛠 Engineering Culture & Career Moves

10 Years of Engineering Ladders – Camille Fournier
A decade later, Camille’s framework for IC and management growth still holds up—and this reflection shows why transparency and clarity matter more than ever.

The Engineering Manager Archetypes
Are you the Architect, the Catalyst, or the Fixer? This archetype model helps you better understand your strengths and where you might need backup.

⚙️ Quick Hits

Company Boards Pressuring CEOs to Replace IT with AI
The pressure is real, and boards are asking hard questions about AI-first orgs.

What Nobody Tells Devs About Docs – PostHog
A love letter to documentation that doesn’t suck. If your devs dread writing docs, start here.

100 AI POVs from Experts – Section AI
A goldmine of mini-perspectives from people shaping the future of AI.

9 of Anthropics best guides
All free in Anthropic Academy

Your Privacy Guide to AI Chatbots
Section AI offers practical advice to keep you and your team safe while using chatbots, from toggling off model training to being thoughtful about prompts.

Want more like this each week?
Hit subscribe or reply to let me know what themes you want more of: AI, leadership, systems thinking, team health, you name it.

Subscribe now

It might be a familiar situation or one you’re in right now. Senior leadership says you’re too slow. Engineers say they can’t go faster unless they spend time rewriting. Deadlines are made, band-aids are used, and the cycle continues.

Both groups have the same hopes and desires but end up talking past each other. There’s nothing inherently wrong with either side's position. Still, one group tends not to have enough involvement, depth, or understanding to figure out how to reach across the aisle and reach a common experience.

I saw a post earlier today that noted the “move fast, break things” motto had sunk their startup, with one engineer noting they were leaving because they were tired of “putting bandages on broken bones.”

What an image. We’re all hiking up the same trail with compound fractures, covered in Band-Aids that are doing their best to keep our bones in place.

So, how do you keep forging ahead? As an engineering leader, how do you explain a compound leg fracture to a group that might not understand what a leg should look like?

I’ve not found a fool-proof answer, but I’m going to find one…or fall off the mountain trying.

How have you solved this problem in the past?

Leave a comment

Been a bit, so the backlog of links is large and full of terrors:

📌 Strategy, Priorities, and the Big Picture

• How FAANG Really Prioritizes Work
  A teardown of how top tech companies prioritize without clinging to Agile dogma. If your roadmap feels more like a wish list, this one might recalibrate your approach.

• The Software Architecture Decision Canvas
  Architecture discussions dragging on for hours? Use this canvas to focus debate, clarify trade-offs, and stop decision fatigue before it starts.

• Illich’s Law: The Real Cost of “More”
  A reminder that more hours ≠ more output. Especially relevant if your team is sprinting but barely moving, Illich’s Law is also called “the Law of Diminishing Returns.” This law explains why, and how, to course-correct.

• The CTO’s Ouroboros
  A thoughtful piece on the cyclical nature of tech leadership, and how we often find ourselves solving the same problems with fancier tools (and higher stakes).

• The CTO’s Calculated Absence
  Yes, we’re linking this one again. Because stepping back strategically is still underrated—and this nails the why and how.

🔧 Tools, Techniques, and Ways to Build Smarter

• GreptimeDB and the Future of Observability
  A purpose-built, time-series database designed to meet modern observability needs. If you’ve ever cursed your logging setup, this one’s worth a peek.

• Properly Logging Tech Debt
  Tech debt isn’t just a nuisance, it’s a window into your culture. Documenting it well builds trust, shows accountability, and helps teams think long-term.

• Engineering Metrics That Drive Focus
  LeadDev’s metrics guide remains a banger, ideal for separating signal from noise when performance reviews and planning season hit at the same time.

• Jack Danger’s Pyramid Career Model
  Worth a revisit: grow outward before upward. Cross-disciplinary breadth builds the kind of depth that lasts longer than any title bump.

🤖 AI and the New Developer Toolkit

• Zero Human Code
  AI wrote the code, fixed the bugs, and stumbled all the way through. A brutally honest case study in just how far we are, and how close we’re getting (maybe).

• DX Guide to AI-Assisted Engineering
  A soup-to-nuts framework for embedding AI into your workflows; from planning to production. Less hype, more how.

• Prompt Engineering Whitepaper (Kaggle)
  A surprisingly deep dive from Kaggle on what makes prompts actually work, whether you're coding with GPT-4 or running research-grade inference.

• OpenAI Prompting Guide
  If you’re still guessing at prompts, stop. This guide gives structure to the madness and is an essential read for anyone building with LLMs.

• OpenAI Academy
  Self-serve, well-structured, and designed for builders who want to get good, fast. Still one of the best places to start your AI journey.

• Netflix’s Foundation Models for Recs
  How Netflix is using massive foundation models to supercharge personalization. It’s enterprise-grade, high-stakes LLM work, and it’s live.

• The End of Programming as We Know It
  O’Reilly lays out the future: less “write code,” more “design intent.” The skill shift is coming, time to start practicing. Tim O’Reilly then recently wrote this “AI First Puts Humans First” piece. Interesting combo of articles.

🧠 People, Motivation, and Team Dynamics

• How to Motivate Your Team
  Skip the fluffy platitudes. This is a refreshing, real guide to figuring out what your team actually needs to stay engaged.

• Async Communication for Leadership
  Async isn’t just for ICs. If you want deeper, more focused collaboration, especially with other leads, this is the case for slowing down to go fast.

• Lenny + Cutler on Team Rituals
  Bookmark this one. From calendar audits to reflection prompts, these are the high-signal habits that separate chaotic teams from consistent ones.

• Learning is a Learned Skill
  Still one of the best pieces on intentional growth. Especially useful if you're onboarding a team, coaching a direct, or just hitting a wall.

• The Productivity Phantom
  You feel productive, but are you moving the needle? This piece calls out the illusion, and offers strategies for measuring what really matters.

Subscribe now

First off, there's no such thing as perfect documentation—just like there's no perfect code. The key is producing and maintaining it consistently. Documentation requires a different thought process than coding; it's more creative and explanatory.

AI Summary provided by Audiopen.ai, the only AI tool I pay for (affiliate link)

This brings me to the Diataxis framework. It categorizes documentation into four types: how-to guides (practical steps for tasks), tutorials (learning-based steps), references (quick look-ups for APIs), and explanations (theoretical understanding). This framework helps determine what kind of documentation is needed based on its purpose.

Diataxis helps organize information but doesn’t dictate where it should live—that's up to each organization. It’s like agile processes; each team adapts it to their needs.

So does Diataxis provide insight into organizing documentation?

Not directly; it focuses more on categorizing content rather than structuring it within an organization. Each team must figure out their own system based on their dynamics.

You mentioned implementing a documentation council at work. How does that function?

Our council consists of representatives from each feature team who audit existing documentation and handle requests for new docs or updates. We meet periodically to review what we have and what’s needed, creating tickets for updates or new documents as necessary.

When someone requests documentation, how does that process look?

We kick off audits once every quarter or six months, review existing docs for relevance and accuracy, then create tickets for necessary updates or new documents based on feedback from teams.

In fast-paced environments like Dynamit, how would you implement such practices?

It’s challenging but crucial to allocate time for documentation even in fast-paced settings. Managers need to push for this time allocation while developers should embrace professionalism by thinking about future maintainers of their code.

How do you balance code comments versus external documentation?

Consider who will consume your code: API layers need explicit docs while feature teams might need detailed comments within the code itself. Capture feedback during onboarding to continuously improve your process.

If you don’t have a council yet, where do you start?

Start small by identifying passionate individuals who care about clarity in their work. Give them responsibility over documentation as part of their career growth trajectory—it’s low stakes but high impact.

Thanks for sharing these insights, Michael!

It's not something your end user will see, but it provides juniors and mids with tangible tasks to demonstrate leadership abilities. For others, it's an opportunity to improve things, which is a common goal. Junior engineers, curious about the code and still learning, might notice a lack of documentation. They could spend a day or two diving in, understand it, and present their findings to the team.

I've noticed a trend in organizations heavy on Slack or Teams using video for documentation. Tools like Loom allow for recording changes and explanations. Historically, we preferred written documentation as a contract with everyone. However, long documents can be overwhelming. A five-page document feels like a wall of text; even I struggle with comprehension without multiple reads. TLDRs help in understanding the core quickly.

Videos as documentation are great but come with challenges. Tech talks at our organization contain valuable information, but making them accessible and searchable is tough. Tools like Microsoft Stream offer solutions by uploading videos, generating transcripts using AI, allowing comments, and deep linking to specific sections. This makes videos searchable and collaborative.

AI tools are evolving to assist in documentation. Tools that grok APIs and generate documentation or transcribers like Otter that take meeting notes are helpful. AI tools can retrieve information efficiently but should be used cautiously for generating content.

The industry's direction seems to favor tools like Microsoft Stream becoming more available. Properly cultivated video documentation can be as essential as written docs for quick reference and communication.

As for AI tools in documentation, they can create knowledge bases isolated from the public domain. Integrations with platforms like Confluence make information retrieval easier. However, I caution against relying on AI for generating content; it's better suited for retrieval.

While AI can cover up issues instead of fixing them, we must scrutinize its output rigorously. Use AI as a tool without letting it replace human judgment.

Documentation is an investment for the future and those who will replace you eventually. For new engineers, taking extensive notes while learning can form useful documentation later. It's about professionalism and continuous improvement—start small, iterate, and build a documentation culture.

In summary: dedicate time to documentation, use frameworks like Diataxis for guidance, leverage AI as a tool (not a replacement), and focus on continuous improvement.

For further questions on documentation, I'm available on LinkedIn.

Summary provided by AudioPen Prime, the only AI tool I pay for. Goes from audio thoughts to transcribed summaries in whatever style you’re looking for. Love using this for long drives or walks.

Before we jump in, remember you can always go to askhartley.com to submit your questions anonymously or with your name. I love working through these questions because management is something you learn by doing, often impacting those around you. So thinking through these scenarios helps prepare for when they arise.

Subscribe now

Let's start with balancing coding and leadership as a manager. Imagine you're a front-end lead managing four people while still expected to contribute to projects. You might think a 50-50 split between management and coding will work, but it's not that simple. The context switching between coding and managing is vastly different. Coding problems are direct—either it works or it doesn’t. People problems are nuanced; solutions may take months to reveal their effectiveness.

So don't expect a strict 50-50 split. Priorities shift weekly; some weeks require more focus on individuals, others on code. The urgency also differs—a critical bug needs immediate attention, while a personal issue with a team member requires empathy and understanding.

Next, consider perception and expectations. Your team expects you to stay technical while leadership wants you focused on strategy. As an individual contributor, your job was to write and deliver code. As a manager, you're expected to see further ahead, strategizing across teams and projects.

Balancing these roles is tough, especially if it’s your first time managing. Strategy and people problems will be new territory, taking longer at first—and that’s okay. Here are some strategies that worked for me:

1. Time Blocking: It didn’t work well for me because interruptions are inevitable in management roles. If you try this, be very clear with everyone about your availability during these blocks.

2. Prioritize Value: Focus on smaller tasks that add value without becoming bottlenecks for your team. Let them handle complex issues requiring deep thought.

3. Delegate and Coach: Shift from execution to coaching. Delegate critical tasks but stay involved through PR reviews and architectural decisions without being the sole decision-maker.

4. Set Boundaries: Communicate clearly about when you'll be heads-down coding versus available for team issues.

Remember, as a manager who codes, your role is about multiplying the team’s effectiveness—not just executing tasks yourself.

Now onto our second topic: Sponsorship and recognition in leadership...

Strong sponsorship increases retention, morale, trust, fairness, and encourages diverse leadership growth.

Your success as a leader isn’t just about what you accomplish—it’s about who you elevate along the way.

On sponsorship and recognition, it's about elevating others and strengthening both individuals and the organization. Put them in the spotlight, amplify their voices, and ensure they're heard even if they’re quiet.

Moving on to sponsorship and recognition in leadership: Recognition drives engagement, retention, and career growth because it shows what behaviors are rewarded. Sponsorship helps underrepresented employees advance by putting them in visible positions.

There’s a difference between sponsorship and mentorship—mentorship offers advice; sponsorship actively advocates for someone's career growth by giving them opportunities for visibility.

Here are some practical ways to sponsor as a leader:

1. Public Credit: Acknowledge team members' work in meetings or updates without taking credit yourself.

2. Create Visibility Opportunities: Pull team members into decision-making meetings or let them present topics they’re experts in.

3. Push for Promotions/Raises: Document their impact consistently so it’s easy to advocate for them during promotion cycles.

4. Assign Stretch Projects: Give high-potential employees critical projects to build their credibility.

5. Celebrate Day-to-Day Wins: Regularly highlight both big achievements and small improvements in team communications.

So, how do you balance leadership and coding? Who has sponsored you, or whom have you sponsored in your career? Share your thoughts at askhartley.com or message me on LinkedIn.

That wraps it up for today. Next week, we'll have Michael Yodiv, a colleague of mine, discussing documentation. If you have questions about documentation in current, previous, or future organizations, drop me a note at AskHarley.com. We'll answer them live in a rapid-fire session—it’s going to be fun! That's all for Episode 8 next week. Thanks for listening. Have a great week!

It goes beyond the ineffective meetings, though. There’s something about how we show up in meetings that makes me want to throw hands.

I’m reminded of a story in an HBR case study about an army rowing team with strong rowers but no team cohesion. The team leader, having tried all sorts of team-building activities, finally let the team fight it out, literally. The team fought, and once they’d traded blows, they were stronger and more cohesive, and the snippiness immediately left. They then went on to win several crew trophies, and the rest is history.

In most cases, we can’t fight each other with our fists and get the physical energy out, (though this would make for an interesting case study in organizational hierarchies), but we can spar with our words. Some organizations have code words, like “Level 10,” to help break the ice of saying something that might sound mean or offputting but is intended to challenge directly.

Whatever your method, you must figure out how to get past the hesitation of being nice in order to beat up the ideas being presented. Remember, it’s not you against the individual, it’s all of you against the ideas. After all, you’re hoping to come out with the best path forward.

Kim Scott has a whole section in Radical Candor about “ruinous empathy,” a phrase that I think of regularly, in which, “you care personally about someone, but don’t challenge them.” This is where we get to, in most cases, at work. We build relationships, and we generally get along with our co-workers, but we don’t challenge them directly, especially in meetings. We let ideas drift out with no response, and we don’t punch at them until we’ve got the best version of that idea.

Which fights are you having this week? Are you trading blows or hanging out outside of the ring?

Let me know in the comments below!

🌟 Leadership, Strategy & Decision-Making

Using the Balanced Scorecard as a Strategic Management System
A timeless framework for aligning business strategy with execution. This is a must-read if you’re struggling with prioritization or measuring success.

Dear CTO, It’s Not 2015 Anymore
The role of the CTO has changed dramatically. This article is a wake-up call for leaders who still operate under outdated tech leadership models.

Overwhelmed at Work?
Leadership burnout is real and this article offers practical strategies to manage workload, set boundaries, and focus on high-impact work.

🔐 Security, AI & Innovation

Red Teams: Breaking Things to Build Resilience
A great introduction to red teams and how they can improve security, engineering, and organizational resilience. Every leader should consider this approach.

Securing Generative AI on AWS
As AI adoption grows, so do security risks. AWS’s new course provides a solid foundation for securing AI models in enterprise environments.

The Carbon Footprint of AI Tools
AI isn't just expensive in computing, it’s costly for the planet. A thought-provoking look at sustainability and the environmental impact of AI tools.

Devin, the AI Assistant Revolutionizing CX
AI assistants are reshaping customer experience, this deep dive on Devin explores how AI-driven automation is becoming more sophisticated.

🛠️ Engineering & Organizational Excellence

What Every Non-Technical Manager Needs to Know About Engineering Managers
Engineering leadership can feel like a mystery to non-technical leaders. This article provides a solid foundation for understanding what makes engineering teams tick.

The Deadline Doom Loop
How do you escape the cycle of unrealistic deadlines and constant firefighting? This piece unpacks how leaders can shift from reactive to sustainable planning.

Estimating Complexity
Why are some projects so hard to estimate? A great read on the nature of complexity and how leaders can set better expectations.

Building Barrels, Not Bottlenecks
Scaling isn’t just about hiring—it’s about structuring teams effectively. These four tips will help you avoid growth pitfalls.

The Big Tech Layoffs Playbook
A deep dive into how major tech companies approach layoffs—what’s driving them, and what leaders can learn from the patterns.

Today, we're diving into a topic that's close to my heart: giving yourself grace. This means allowing yourself room to breathe, not being overly critical or pushing yourself too hard. It's something I've struggled with for a long time, and while I'm still working on it, I hope to shed some light on the subject. Maybe you're grappling with this too, and we can work through it together.

Summary provided by AudioPen Prime, the only AI tool I pay for. Goes from audio thoughts to transcribed summaries in whatever style you’re looking for. Love using this for long drives or walks.

Today, we'll explore why we push ourselves so hard, how it affects us, practical strategies for balancing ambition with self-compassion, and the long-term benefits of permitting yourself to rest and recover. If you've ever felt like you're not doing enough, this episode is for you. Even getting this episode out was a struggle for me—I debated whether to push myself or take a break. But I committed to releasing episodes weekly this year, so here we are.

Burnout is an issue we face daily, so let's dive in. Why do we feel this way? Why do we push ourselves too hard? Much of what I'll share comes from my own experience. For instance, I ran a hot sauce company on the side while managing my day job and personal life. It was exhausting and led to burnout.

The culture of overwork is finally starting to fade away, but hustle culture still lingers. Social media often glorifies constant productivity—early mornings, cold plunges, 10-mile runs before breakfast. This lifestyle can make us feel inadequate if we're not doing the same.

This year, I've switched to audiobooks instead of stressing about reading physical books quickly enough. Oddly enough, manga like Berserk keeps my attention better than traditional books.

Why do we push ourselves? Fear of failure and imposter syndrome play a big role. Early in my career at a digital agency, I pushed myself so hard that I got stress-induced shingles twice. The fear of being seen as a failure or unreliable drove me to overwork.

This self-imposed pressure is something I've reflected on for years. We often equate more effort with more success, but sometimes stepping back is the most productive thing we can do.

Think about where you're being hard on yourself and why. Are you pushing too far? In engineering leadership, I promote work-life balance heavily. If someone hasn't taken time off in a while, I encourage them to do so—not because they're doing a bad job but because they need to take care of themselves.

We've created a culture where we're always on, especially in tech. Some colleagues don't even have Slack on their phones—setting boundaries is crucial.

Let's talk strategies for giving yourself grace:

1. Reframe Your Mindset: What does success mean to you? For me, it used to mean climbing the corporate ladder as fast as possible. Titles aren't everything; they don't necessarily equate to impact or satisfaction.

2. Perfectionism: Are you trying to be perfect or good enough? Be okay with 80%. Perfection isn't realistic; aim for progress instead.

3. Set Boundaries: Define clear working hours and stick to them. Use tools like Google Calendar and Slack notifications wisely.

4. Practice Self-Compassion: Talk to yourself like a friend would—replace criticism with kindness and encouragement.

5. Acknowledge Wins: Keep track of your accomplishments, even small victories—they build momentum and positivity.

Lean on your network when you're struggling—having a hype person can make all the difference. And if you're still finding it tough, seeking professional help is okay too.

Understanding your boundaries and relationships is critical as you navigate your career. Reflecting on your progress regularly helps maintain balance and growth.

So think about what makes you happy and gives you joy in life. Give yourself some grace and set boundaries that work for you.

Pushing yourself too hard generally leads to burnout rather than success. Reframe what success means for you—prioritize what matters most.

What's one thing you'll give yourself grace with this week? I'd love to hear your thoughts—reach out at askharley.com or connect with me on LinkedIn.

Thanks for listening! We'll be back next week with episode seven—possibly discussing documentation in engineering organizations with a special guest!

Until next time, take care of yourselves!

Summary from Audiopen.ai Prime (affiliate link for the only AI tool I pay for)

I teased this topic a couple of weeks ago, but today, we’re breaking it down. When setting goals, think in three ways: personal growth, team growth, and company growth. Even as an individual contributor, this approach ensures you're always growing and helping your team and company grow too.

Before we dive in, remember you can always ask questions at askhartly.com or find me on LinkedIn. I also have a weekly newsletter every Monday with helpful links on AI, goal setting, leadership, and more. If you’d like to submit a link or learn more, feel free to reach out.

Alright, let’s get into goal setting. Especially at the beginning of the year, it's critical to get this right. The main framework I use is SMART goals—Specific, Measurable, Achievable, Relevant, and Time-bound.

Specific means your goal is clear. Instead of saying I want to get better at this, say I want to improve my one-on-one skills. Measurable means figuring out how to quantify your progress. Achievable means the goal is realistic within the time frame you set. Relevant relates to your role and career growth. Lastly, Time-bound means setting a clear deadline—whether it’s a week, a quarter, or a year.

So how do you set goals for yourself? Focus on how you want to grow as an individual. If you're an engineer, it might be mastering a new technology or taking on more leadership responsibilities. Avoid checkbox goals like complete a React course. Instead, aim for something actionable like complete the course and deliver a presentation on what I've learned.

Personal goals are helpful because they allow you to track your growth over time. Setting goals gives you clarity on what’s important and helps identify obstacles that might be hindering your progress—be it too many meetings or too much busy work.

Now let’s talk about team goals. Even as an individual contributor, you can set goals that impact your team. For instance, improving a process or reducing meeting times can significantly affect team dynamics and outcomes.

From a software perspective, think about team goals as outcome-oriented. For example, logging more bugs should lead to reduced bug resolution time or fewer overall bugs. Aligning team goals with company objectives ensures everyone is moving in the same direction.

Speaking of company goals, these often trickle down from broader objectives like OKRs (Objectives and Key Results) or KPIs (Key Performance Indicators). These should be specific enough to guide teams but flexible enough to adapt as needed.

Setting company-wide goals requires vision and alignment across all teams. For instance, improving customer satisfaction by 10 points in CSAT could involve various teams working on different aspects like UX improvements or technical debt reduction.

Regular updates and transparency are key in tracking progress towards these goals. Using simple metrics like stoplights—red for off track, yellow for at risk, green for good—helps everyone understand where things stand and what needs attention.

In summary, start with yourself by setting clear personal goals using the SMART framework. Expand to collaborative team goals that align with your organization’s vision. And finally, contribute to company-wide goals that act as your North Star.

What goals are you setting for yourself in 2025? What about for your team or company? Let me know at askhartly.com or find me on LinkedIn. This podcast airs every Wednesday morning on Spotify, iTunes, at hartleyshandbook.com—wherever you find your podcasts.

If you have any other goal-setting frameworks or systems that work for you, I'd love to hear about them. Thanks for listening! Until next time, take care and keep setting those meaningful goals!

Now, nearly 15 years later, finding a job as a Junior Engineer is even more difficult. I have friends who have gone through developer bootcamps, only to find that there isn’t a job on the other side. Even worse, you have companies like Meta saying they will replace mid-level (and I assume junior-level) engineers with AI.

“No take, only throw” is a solid meme that really encapsulates how companies are missing out on the opportunity of junior engineers. We want better talent! But, we don’t want to foster it by hiring juniors.

Meta is doubling down on that statement by reducing its 7k workforce by 5% this year. Companies looking for lower-cost options are aiming toward Latin America, Europe, and Canada. How can newly minted software engineers compete?

We need a mindset shift as an industry. After all, junior engineers become mid-levels, seniors, and so on. Two companies I admired for how they approached creating their own talent were CoverMyMeds and Branch here in Columbus. Both created their own bootcamps where, as a junior engineer, you would come in and learn how to write software at that company. They were willing to take the initial hit of coaching and mentoring junior engineers to drive the results they needed.

The benefit? Engineers that are more loyal, more engaged, and better prepared for the sort of work your company produces. Not to mention, mid-levels need reps at mentoring as well. You need the full engineering spectrum to get the most out of your engineers, and I fear we’re veering far away from that world.

It’s sad that we’ve gotten away from this as a broader industry, and it makes it a bleak world for new engineers to enter. There’s a lot that needs to change across tech for this landscape to improve, but I was thinking about the advice I would give myself 15 years ago in this environment.

Some thoughts…

First, prepare to underbid yourself. Companies are looking at cheaper options like AI or offshore solutions. When I started, I applied for around 40 positions and was repeatedly told that I was too junior. The only offer I got was $20/hr for 10 hours a week. It was not ideal, but it got my foot in the door. You can always renegotiate your contract after you’ve consistently delivered solid work.

Expect challenges and be ready to learn on the job. One of my first projects was a WordPress site that crashed multiple times. Because I was learning on the go, the hours billed were less than the hours worked. Underbidding yourself might not feel great or pay well initially, but it's about building your resume and moving beyond junior status.

Consider platforms like Fiverr or Upwork where you can gain experience, even if it means working for $1 an hour initially. Exposure and experience are invaluable. Are you underselling? Absolutely. Is it sustainable? No. The biggest complaint I heard when I was a junior was that I was too junior. Getting some projects under your belt will help build out your resume and prove you have what it takes to see a project through.

Contribute to open-source projects. These projects often have issues you can tackle, helping you understand workflows and processes while pushing your boundaries. If you’re not sure where to start, “Good First Issues” can point you at projects with low-hanging fruit to get you started.

Personal projects matter too. They show how you think and solve problems. Don't just fork repos; build something from scratch, even if it's simple or niche like a D&D AI agent for random encounters. Personal projects help you break down work into chunks and execute them—skills that are increasingly important as engineers take on more product management roles. More thoughts here: What I Love About the Engineering Graveyard (and Why You Should Mention It When Interviewing)

Lastly, get involved in your local dev community through Slack channels, Discord, startup weekends, or GiveBackHack events. Networking is crucial—find mentors locally or globally who can share their experiences and guidance.

Pound the pavement, talk to folks, and keep pushing forward. Hopefully, this advice will help you navigate these challenging times as a new engineer. In the meantime, if you’re a junior engineer struggling to find a role, feel free to reach out! No, I’m not selling a service, I truly want to do what I can to help folks break into the tech industry.

In my future roles, I will aim to carry this forward, insisting on leaving space in the budget to ensure we have an active junior pipeline. This pipeline is critical to our industry, and it’s our responsibility to keep the next generation engaged.

You can also ask questions at askhartley.com

Now, on with some links I found interesting from this last week (including Episode 4 of Ask Hartley Anything):

🌟 Leadership & Team Dynamics

How Leaders Can Instill Hope in Their Teams
An inspiring guide on how leaders can foster hope during challenging times, building resilience and motivation across their teams.

Finding Joy as a Manager, Even on Bad Days
Practical advice for rediscovering joy in leadership, even when the going gets tough. A great reminder to focus on purpose and small wins.

The Complicated Role of Hope in the Workplace
Research on how hope impacts workplace dynamics—offering valuable insights for leaders looking to balance optimism with realism.

🛠️ Culture & Decision-Making

A Values Engine to Transform Culture
A compelling framework for driving cultural change through clearly articulated and lived values. Essential reading for leaders shaping organizational identity.

How to Make Effective Decisions by Comparing Alternatives
A simple yet powerful method for decision-making that helps avoid analysis paralysis and leads to better outcomes for your teams.

The Case for the Ambidextrous CIO
Why today’s leaders need to balance operational excellence with strategic innovation—and how to do both without dropping the ball.

🤖 Innovation & Hiring Trends

Building Tiny Viral Apps
I love this take on forgetting about the long-term and building silly little apps to learn something. It’s a great look at how simple, focused apps can go viral—and what leaders can learn about product design from their success.

Why No One Wants to Hire Junior Engineers
A candid discussion on the challenges of hiring and mentoring junior engineers, with takeaways for improving hiring processes.

Most Engineering Hiring Processes Are Broken
This piece explores how hiring practices fall short and offers actionable steps to create more inclusive, effective pipelines.

🗞️ Trending Topics

Meta Targets Lowest-Performing Employees in Latest Layoffs
A sobering look at how performance reviews are being weaponized during layoffs. Leaders should reflect on how performance metrics impact morale and trust.

Mammoth Rebirth: Closer in 2025
While not directly related to engineering leadership, the woolly mammoth's return is a testament to bold innovation. It reminds us to dream big and embrace the unknown. It also could mark a weird time in science where we adjust ecosystems by re-introducing extinct animals only to see them go extinct again. Dystopia much?

Have questions? Let me know in the comments!

Summary from Audiopen.ai Prime (affiliate link for the only AI tool I pay for)

Hey everyone, welcome back to Ask Hartley Anything, Episode 4. This is the podcast where I take your questions and share insights from my journey as an engineering leader. Today, we’re diving into mastering decision-making—empowering both your teams and yourself to make faster decisions, along with some mental models to help you do that. We’ll provide frameworks and systems so it’s not as overwhelming.

Before we get into the first question, remember you can go to askhartley.com to submit your questions, anonymously or otherwise. So far, we’ve been able to cover all four episodes with questions from you. I initially started this unsure if folks would actually send anything in, so I'm thrilled you're doing that and appreciate every question.

Today’s topic is helping teams make decisions confidently and using mental models for better, faster decisions. Our question comes from “third place,” possibly referencing a Fantasy football league—I'm not entirely sure. Third place asks:

Hey John, in episode two you briefly mentioned over-democratizing decision making. Could you elaborate more on this topic and how to realign your team so people feel comfortable making decisions? Does a tech lead need to step up as somewhat of a dictator to ensure timely decisions? Is this a superpower bestowed by management or leadership?

Subscribe now

Great question! If you haven’t listened to Episode Two, feel free to go back after this one. Over-democratizing decision-making can be a problem in organizations. It’s when every decision is put out for a vote or discussion, dragging on endlessly. While it’s good to get differing opinions, it shouldn’t hinder timely decision-making.

I’ve seen this happen with RFCs (Requests for Comments) in engineering organizations. You put up a proposal for something like a big architectural change, and it either gets stuck in endless comments or no one responds at all. One way to resolve this is by giving tight timelines: say you have a week for comments, then you’ll address them and make a decision.

A key decision-maker can help break the cycle of indecision—whether that’s your VP of Engineering or a group of directors. Sometimes a simple thumbs-up/thumbs-down vote can work too.

Fear of making the wrong decision often paralyzes teams. It’s crucial to foster a culture where failure is acceptable and reversible decisions are encouraged. For instance, in code, you can revert changes or use feature flags to test new implementations.

I prefer POCs (Proofs of Concept) over RFCs because they allow you to test ideas quickly without getting bogged down in endless debate. A POC shows tangible progress and helps move things forward faster.

Now, who makes the final decision? It depends on the size of the decision. Smaller decisions can be made by tech leads or senior engineers within their teams. Larger system changes might need input from staff engineers or even higher up the chain like VPs or CTOs.

For major strategic shifts like re-platforming, involving top leadership makes sense since it aligns with the company's overall strategy.

To avoid micromanagement and promote autonomy, give teams frameworks for decision-making. Document how decisions should be made within your organization so everyone knows the process.

Curious how decisions are made at your company? Writing it out can reveal how democratized your process really is. But don’t let decisions linger; set deadlines for making them.

Switching gears slightly—if you want resources on better decision-making, Daniel Kahneman's Thinking Fast and Slow is excellent. Remember that all decisions are made with partial information; you'll never have every piece of data.

Let’s talk about some mental models:

1. **Eisenhower Matrix**: Prioritize tasks based on urgency and importance.

2. **Opportunity Cost**: Consider what you're giving up by choosing one option over another.

3. **OODA Loop**: Observe, Orient, Decide, Act—a continuous improvement cycle.

4. **Inversion**: Instead of asking how you can succeed, ask how you could fail and mitigate those risks upfront.

These models help create repeatable frameworks for making faster decisions with confidence.

So we've covered decision-making and some mental models today. If you have more questions, visit askhartly.com or find me on LinkedIn. Thanks for listening! Tune in next week for Episode 5.

Today’s episode is packed. Initially, I planned to cover two topics: measuring the impact of engineering managers and goal setting. But we’ll focus on measuring the impact of engineering managers and introduce an interesting measure called hospitality quotient.

First, a quick plug: You can ask questions for this podcast at askhartley.com or reach out on LinkedIn. Subscribe on Spotify, iTunes, or hartleyshandbook.com.

Note: This text summary was generated from one of the only AI tools I pay for, AudioPen Prime. I leverage it for taking raw audio and turning it into a solid shortened summary.

Our first question today is from Brett, who says he’s a big fan of Adam Grant. If you don’t know Adam Grant, he’s the author of Originals and a professor at Wharton School of the University of Pennsylvania. Brett mentions a podcast where Grant discussed hospitality quotient with a restaurateur and relates it to engineering management. Brett asks for thoughts or metrics on measuring the impact of an engineering manager.

I'm a big fan of Adam Grant. He recently did a podcast with a restaurant owner where the restaurant owner talking about "Hospitality Quotient" and how it's hard to measure. I think of that a lot like Engineering Management. Do you have any thoughts/metrics of measuring the impact of an engineering manager?
Here's the transcript

Subscribe now

Great question! Measuring the impact of engineering managers can be tough. For engineers, output is clear—you can see their work in repositories and pull requests. But for engineering managers, it’s more nebulous.

Let’s start with the hospitality quotient (HQ). You’ve probably heard of EQ (Emotional Quotient). HQ is similar but focuses on making others feel better when you help them. Danny Meyer defines HQ as the degree to which someone feels better about themselves when they make someone else feel better.

Adam Grant relates HQ to affective presence—the consistent set of habits around emotions you elicit in others. Some people have a positive affective presence; others, not so much. This ties back to empathy and emotional intelligence.

But how do you measure these qualities in an interview? Companies have EQ tests that measure how individuals interpret situations, their empathy, and their attitude. In interviews, asking about recent feedback received and given can be enlightening.

Now, let’s pivot to measuring engineering management. It’s easier for engineers with clear outcomes and outputs but tougher for managers since it tends to be more qualitative than quantitative.

Here are five key areas (the Five Ps) for measuring engineering managers:

1. Personal: How do they show up daily? Are they consistent? Do they display empathy? Are they building systems and ideas effectively?

2. Personnel: Team health metrics like engagement scores and retention rates are crucial. Are team members engaged? Is voluntary attrition low?

3. Projects: Look at delivery metrics like velocity—stability over time is key, not just high numbers. Cycle times and DORA metrics also help gauge project execution.

4. Peers: How do they interact within their peer group? Use 360-degree feedback to understand their role in meetings and collaborations.

5. Process: Challenge them to improve one process annually. Are they proactive in suggesting changes? Do they understand organizational processes deeply?

These measures provide a robust understanding of an engineering manager's performance and readiness for the next level.

Think about hospitality quotient again—how do they make you feel in meetings? Do they inspire confidence or dread? If it's difficult interacting with them, consider performance management steps.

Remember, these insights aren't exhaustive but should give you a solid framework for evaluating engineering managers effectively.

Measuring engineering managers, or any managers for that matter, is a complex task. It becomes even more challenging as you move up the hierarchy. For directors, evaluating strategy effectiveness over the year involves larger time chunks, unlike engineering managers where delivery metrics in two-week cycles provide clearer insights. These time frames expand and complicate the assessment.

Over the years, my approach to this has evolved and become easier with experience. It's crucial to use both quantitative and qualitative data to gauge a manager's performance. How are they performing day-to-day? Sprint-to-sprint? Are they effective? When they are, how do they impact other metrics?

I’m always open to learning new methods for measuring managers. If you have techniques that have worked well—or not—please share them. Let's tackle this challenge together. The more we can quantify performance consistently, the easier it becomes to achieve those targets.

That wraps up this episode of Ask Hartley Anything. Thanks for tuning in. We're back on a consistent schedule—it's you and me on this journey every week. If you have questions, visit askhartly.com to submit them anonymously if you prefer. Just include an email for any follow-up questions and to inform you when your question will be featured.

Thanks again for listening. Have a great week. Until next time, insert tagline here (not a typo, I’ve just not thought of a catchy tagline).

I’ve been thinking a lot about the concept of "ghost engineers" lately—those engineering ICs who seem busy but contribute little meaningful work. It’s a fascinating and (mostly) frustrating idea, and I think we’re missing the bigger picture, primarily because engineering output (as flawed as the measure is) is easier to track than elsewhere in the engineering hierarchy.

What about "phantom managers"? These are leaders who look incredibly busy, run countless meetings, and send endless Slack messages but don’t actually drive impact. Unlike ghost engineers, phantom managers can disrupt an entire team’s output by wasting time and energy.

I’ve caught myself slipping into this trap before—weeks where I feel busy but know I didn’t really move the needle. It’s a humbling realization, and it’s forced me to reflect deeply on how I spend my time and what outcomes I’m driving. But how many leaders are doing this kind of self-assessment?

As we approach a new year, maybe it’s time to focus less on engineering metrics and more on evaluating management effectiveness. Are your managers empowering their teams, or are they just creating noise? Are they creating environments where their teams can thrive, or are they stifling innovation and ownership? Are you yourself preventing managers from achieving those outcomes?

Before pointing fingers at "ghost engineers," let’s hold a mirror up to our leadership practices. Are we modeling what effective management looks like, or are we just as guilty of hiding behind busyness?

Anyway, on with the helpful links! As always, if you have questions about engineering leadership or your engineering journey in general, ask me here or at askhartley.com. Next episode will be out on New Year’s Day, but you can check out the latest below:

🤖 AI, Decision-Making & Future Trends

The Future of AI
MIT’s comprehensive exploration of AI's societal impacts is essential for leaders considering how AI will shape their teams and strategies in the coming years.

The AI Trap
Mike Fisher warns of common pitfalls in AI adoption, urging leaders to focus on meaningful value rather than chasing trends. A must-read for balancing innovation with practicality.

🛠️ Developer Experience & Team Dynamics

Measuring Developer Experience Benchmarks
Will Larson shares a framework for evaluating and improving developer experience with real-world benchmarks. Perfect for leaders looking to drive incremental, data-backed improvements.

Communication Structures in a Growing Organization
Jessica Kerr dives into how communication evolves as teams scale, offering actionable insights to prevent silos and foster collaboration in growing organizations.

🌟 Leadership & Decision-Making

Tenets for Faster Decision-Making
A concise guide to making decisions more efficiently without sacrificing quality. Use these principles to speed up execution while maintaining alignment.

Read the Room
Rich Mironov reflects on the importance of emotional intelligence in leadership, especially when navigating high-stakes conversations and organizational shifts.

🔮 Emerging Tech & Long-Term Impact

2024 in Review
A thoughtful retrospective on 2024’s most impactful trends in tech and leadership, with lessons you can apply to prepare for 2025.

Deloitte’s Tech Trends 2024
Stay ahead of the curve with Deloitte’s take on emerging technologies, from generative AI to sustainable innovation strategies.

📚 Big Ideas in Software Engineering

Rewilding Software Engineering
A fascinating perspective on breaking free from rigid processes and rediscovering creativity in software engineering. Great for sparking innovation in your teams.

The Psychology of Remote Work
A research-backed exploration of how remote work impacts team dynamics and individual productivity. Essential for leaders managing distributed teams.

Scaling Excellence
This video offers practical advice on scaling teams and organizations without compromising culture. A great watch for leaders at any stage of growth.

I hope your holidays are restful and enjoyable. Here’s to an excellent 2025.

👉 Have a favorite resource or question? Reply below share your thoughts and insights.

First, I explore how to help team members detach emotionally from their ideas, focusing on fostering a growth mindset, encouraging collaboration, and coaching them to see the bigger picture. Then, I share actionable advice for maintaining and sharpening management skills when stepping back into an individual contributor (IC) role, such as mentoring, leading by influence, and journaling reflections.

Whether you’re managing a team or growing as an IC, this episode is packed with insights to help you level up.

Subscribe now

Links:

• Mindset: The New Psychology of Success - Carol Dweck

• Radical Candor: Fully Revised & Updated Edition: Be a Kick-Ass Boss Without Losing Your Humanity - Kim Scott

• MasterClass

• 9 Books All Engineering Managers Should Read

• 9 More Books All Engineering Managers Should Read

Podcast summary created with Audiopen

Ever had a teammate who takes feedback too personally or wondered how to keep growing as a leader after stepping back into an individual contributor (IC) role? In this episode, I'll share how to help your team detach from their ideas and focus on impact, plus practical tips to sharpen your management skills. Welcome to Episode Two of Ask Hardly Anything, the podcast where I take your questions and offer advice grounded in my experience as an engineering leader. This podcast releases every Wednesday. Feel free to send questions to notes@askhartly.com about your engineering journey.

How have you handled direct reports that take things too personally?

Helping someone detach emotionally from their work is challenging. They’re likely passionate about their ideas and feel beat down when those ideas aren’t adopted. The first step is understanding the root cause. Why are they so attached? Maybe past experiences have made them defensive, or perhaps they tie their self-worth to the success of their ideas.

Sometimes, ideas are extensions of identity or expertise, making critiques feel personal. Early-career engineers often equate idea acceptance with validation, while senior engineers might feel irrelevant if their ideas are rejected. This emotional response can erode team trust and productivity.

In these situations, ask them privately, What happened in there? Understand their perspective without making everyone uncomfortable during the meeting. This helps you grasp whether it’s general frustration or something specific.

Here are six strategies to help:

1. Growth Mindset: Encourage embracing challenges and learning from criticism.

2. Drafts Over Final Products: Present ideas at 60% completion for early feedback.

3. Reframe Disagreements: Position debates as collaborative problem-solving.

4. Focus on Outcomes: Emphasize team goals over individual ownership.

5. One-on-One Coaching: Provide constructive feedback regularly.

6. Clarify Decision-Making: Ensure everyone understands how decisions are made.

At the end of the day, helping reports detach emotionally means shifting their mindset from proving their worth to improving the team's outcomes.

After five years in management, how can I maintain and continue developing my management skills while working as an IC?

Stepping back into an IC role allows you to refine technical skills and observe leadership from a new perspective. Whether you're at the same company or a new one, let go of old management habits and be open to new styles.

First, align with your manager about your goals to stay sharp in both IC and leadership skills. Build influence without authority by gaining trust through excellent IC performance. Mentor others informally, facilitate working groups, and set up office hours for questions.

Look for gaps in skill sets within your team and volunteer for leadership-like projects such as leading meetings or coordinating efforts. Journaling can also help you reflect on past management experiences and apply those lessons constructively.

Remember, building influence without a title involves proving your value through actions and collaboration rather than authority.

For more questions about management or engineering leadership, visit askhartley.com or find me on LinkedIn. Keep asking questions—your journey is important!

Journaling can be a powerful tool. It captures your thoughts and feelings at specific moments, offering insights into how you can adjust over time. Imagine putting yourself in your manager's shoes and documenting that perspective. You might think, Why do I need a journal? It's not a diary. But as you transition into management roles, these reflections become invaluable. When faced with situations your manager handles, you'll have a recorded playbook of your thoughts and strategies.

Seek feedback from peers and leaders about your collaboration and influence. Be specific when asking for feedback. Instead of a vague Do you have any feedback for me? try I've been leading this project. How's it going? Is there anything I can improve? This specificity makes it easier for others to provide constructive feedback.

In conversations with your manager, express your desire to continue developing your skills. They can offer insights into areas where you might need improvement or where you're excelling. Regular check-ins about your management skills can be beneficial.

Invest in learning and development. Many tech organizations offer learning stipends. Join communities of practice like Rand's leadership group or CTocraft to understand how others manage effectively. Reading management books like Radical Candor or taking leadership courses on platforms like Masterclass can also be beneficial.

Set clear goals for your management journey. At the end of the year, reflect on your progress in your journal. Identify obstacles and strategize ways to overcome them.

Advocate for others even if you're not officially in a management role. Sponsor and lift up your colleagues, encouraging them and fostering a team-first mindset. Remember, management isn't just about the title; it's about the impact you make on your team.

I believe you can do this. Entering with the intention to build your skill set will make the journey easier. Set goals and track your progress.

Thanks to Anonymous and Kyle for their questions. You can submit yours at askhartly.com, whether anonymously or not—I'll likely use only first names anyway. These questions help me reflect on my own leadership journey.

Next Wednesday is Christmas, so no new episode then, but I'll be back on New Year's Day with fresh content. Looking forward to more questions from you all.

Until next time, have a great week!

Best part, you can participate! It’s an advice podcast for engineers of all experience levels, tech leaders, and anyone navigating the tech-adjacent world and if you’ve got a question, just submit it here. Or comment at the bottom of this newsletter. New episodes released every Wednesday.

Enough plugs, one thought for the week. It’s December 16, which means we’ve reasonably got ~10 business days left in 2024. Use this time to work on your prioritization skills, leveraging the Eisenhower Matrix to determine what truly needs to wrap up before 2025.

⏱️ Workplace Efficiency & Leadership

Dropbox’s Secret for Saving Time in Meetings
This simple trick from Dropbox has the potential to save your team hours in wasted meeting time. At the end of the day it’s all about leaner collaboration. Dropbox did it before the recent waves, and it proved extremely helpful.

Bosses Say They Want the Truth—Do They Mean It?
Building trust starts with modeling vulnerability and accepting uncomfortable truths. This article challenges leaders to evaluate their openness to honest feedback.

💼 Remote Work & Team Dynamics

Remote Workers and Organizations Drifting Apart
Gallup's research reveals the challenges of keeping remote teams connected. Offers actionable insights to foster engagement and alignment in distributed workplaces.

“Lazy Girl Jobs” Are Just Healthy Jobs
I love this callout, especially as a millennial who had burnout issues in the past. This trend emphasizes the growing demand for balanced, sustainable roles. Leaders should reassess whether they’re fostering environments that encourage meaningful work without burnout.

🛡️ Security Insights

Why Security Still Has a Password Problem
Despite advances in authentication, passwords remain a weak link. Learn how to reduce vulnerabilities and improve your organization’s security posture.

Cross-IDP Impersonation: A New Security Risk
This deep dive into cross-IDP impersonation exposes vulnerabilities in identity providers that could compromise your security strategy. Essential for leaders overseeing authentication systems or IAM policies.

Subscribe now

💡 Strategy & Perspective

The Ultimate Guide to Willingness to Pay
An excellent primer for product leaders on pricing strategy. Engineering leaders can use this to align product development with business goals.

What Are You Getting Paid In?
Aviv Ben-Yosef’s take on non-monetary compensation is a great reminder to evaluate your team’s intrinsic and extrinsic motivators. While almost no one will say no to cash, it’s not always the main motivator.

🛠️ Engineering Culture & Productivity

The Death of the Stubborn Developer
A compelling look at how modern tools and collaborative practices are reshaping the stubborn, isolated developer archetype. A must-read for leaders navigating cultural change in their teams.

Measuring Developer Productivity with the DX Core 4
This research highlights the DX Core 4 framework to measure developer experience and productivity effectively. Use this to align engineering metrics with business outcomes. Always interested in what Laura Tacho and the folks at DX are doing!

How to Ruin an Engineering Organization
A spicy title, but also a brutally honest guide to what not to do when leading an engineering team. Keep this checklist of anti-patterns handy as move your org forward.

👉 Have a favorite resource or question? Reply to this email to share your thoughts and insights.

Featured image: “Winter” Joseph Rubens Powell (artist) British, active 1835/1871

We've recently been surprised with a change in direction to become an ai first company. Can you share some advice on how to manage the team through these changes?

AI is a major buzzword in business today, possibly the decade, or even this century. For many companies, it's more than hype; it's a new way of working. But what happens when this shift feels sudden? Today, I'll share advice on managing team dynamics, keeping morale high, and adapting to new expectations. Welcome to Ask Hartley Anything, the advice podcast for engineers. I'm John Hartley, tackling your toughest career and leadership questions.

Today's episode is timely as we dive into managing teams during big shifts like becoming an AI-first company. If you have questions, send them to askhartley.com or connect with me on LinkedIn. Each week, I'll focus on one core question from you. Today’s is from Anonymous: We've been surprised with a change to become an AI-first company. Can you share advice on managing the team through these changes?

This situation is common now. One day you're solving usual problems; the next, you're supposed to embrace AI like it was always the plan. It's a big ask emotionally and technically.

First, breathe and look at the situation objectively. Why is the company making this shift? Is it driving a business goal for 2025? Is it essential for survival? Understanding the context helps you explain it to your team.

My initial reaction to such pivots is often skepticism: Are we just following others out of fear? The market is saturated with AI applications, so understanding the core reason for this shift is crucial. If you don’t understand it, your team won't either.

Work up the ladder to understand why this decision was made. Is it a revenue driver? A retention play? Becoming a leader in your field? Without understanding the context, you can't manage the team effectively.

Subscribe now

Acknowledge the disruption upfront with your team. Transparency builds trust. Be honest if you don’t have all the answers but share what you're doing to find them.

Frame AI as an opportunity, not a threat. Share specific ways AI can reduce busy work or open new opportunities for innovation. Highlight that AI enhances work rather than replaces people.

Invest in learning and development. Host workshops and encourage experimentation to build confidence in using AI tools.

Set short-term wins with manageable projects that showcase AI's value. This builds momentum and confidence within your team.

Stay human-centered. Remind everyone that AI is just a tool; their expertise and creativity are still vital.

Keep communication open and frequent. Regular retrospectives help gauge team sentiment and address concerns promptly.

The fact that you're asking these questions shows you care about your team's success during this transition. By understanding the business context, staying human-centered, and building short-term wins, you can guide your team through this change effectively.

Remember these phrases: Here's what we know right now, Here's what this means for you, and Here's how we'll tackle it together. These help maintain transparency and collaboration during any change.

I hope this advice helps as you move into 2024 and beyond with confidence in managing your team through an AI-first pivot. Keep asking questions and stay engaged with your team's journey.

And that's it for today's episode of Ask Hartley Anything. If you have more questions, send them along to askhartley.com or connect with me on LinkedIn. Until next time!

It's not productive to dwell on mistakes. Instead, channel that energy into preventing future issues. Consider the benefits this can bring to you and your fellow engineers. Collaborate on solutions to enhance your processes.

As a manager, staying calm during incidents is crucial. Incidents aren't about yelling or showcasing individual prowess. Managers direct the work, they don't do it. By maintaining composure and working with your team, you can figure out how to prevent repeat occurrences. It's valuable for organizations to adopt a blameless approach to incidents. No one should fear reporting them. If people start hiding issues to avoid angering superiors, it leads to more problems in the background.

Build a culture where it's okay to call out problems and fix them together. Take a cue from Toyota's manufacturing lines, where anyone can press a button to signal an issue, and everyone works together to resolve it. This openness is better than covering up mistakes.

As you move up in an organization, discussing outages with executives can be uncomfortable but necessary. Explain what happened, the impact, and the steps being taken to address it. These conversations can be tough, but they're essential for transparency and improvement.

If incidents are frequent, there's a deeper issue that needs addressing. But if they happen occasionally, continue inspecting tools and processes to understand why and how to prevent future occurrences.

Incidents offer a rare glimpse of teamwork in action, similar to sports coaching. You've prepared your team, and now it's time to see how they perform under pressure. If they do well, praise and encourage them; if not, identify areas for improvement.

Don't fear incidents. Fear stifles progress and delays development. Instead, implement monitoring systems that detect issues early and often.

In conclusion, managing AI involves acknowledging disruptions, framing AI as an opportunity, investing in learning, aiming for quick wins, and keeping communication open. By doing these things, your team will understand the changes and participate actively in the transition.

If you have questions or stories to share, reach out at askheartley.com or on LinkedIn. I'll be back next Wednesday with more answers. Until then, thanks for listening and have a great week!

Summary generated by Audiopen.ai

Links:

• https://www.cio.com/article/190888/5-famous-analytics-and-ai-disasters.html

• https://www.reddit.com/r/ExperiencedDevs/comments/1h86g99/how_do_you_not_beat_yourself_up_over_causing_an/