In one of my coaching sessions, a fellow EM mentioned that several engineers on their team — independently, in separate 1:1s — brought up the same thing. They were feeling crushed. Not by the workload itself, but by the volume of open threads they were pulling simultaneously.

Before Claude Code and the other AI tools, they’d have one, maybe two tracks they were actively working on. That’s how software engineering has always operated — you take a problem, you think about it deeply, you ship it, you move on. Now, because the tools make it possible to generate code across multiple contexts at once, they were running three, four, five workstreams simultaneously. And it was breaking their brains.

The overwhelm wasn’t about the hours. It was about the loss of focus and the flood of second-guessing. When you can do more, you start asking: should I be doing more? Are these the right things? What else could I be working on? Every open thread becomes a low-grade anxiety signal — not because the work is hard, but because the optionality itself is paralyzing.

Then then said that it came up in a team retro. One engineer said it in front of everyone: they were experiencing an existential crisis. Real stress. And they specifically named AI tooling as the accelerator — not because the tools were bad, but because the tools made everything feel simultaneously possible and overwhelming.

Interestingly, in every conversation I’m having with EMs and PMs in my network circles back to the same thing — different teams, different companies, loads of excitement accompanied with the same anxiety. The best engineers and hands-on PMs are the most stressed, because they can see just how much AI could do and feel guilty about every hour they spend thinking instead of generating. The newest hires, meanwhile, are shipping AI-generated code they can’t fully explain when asked.

That retro moment is what made me dig into the data. What I found wasn’t reassuring.

The Panic Sandwich

Engineering leaders are caught between two panics. I call it The Panic Sandwich.

The top slice — board and exec panic:

”Why aren’t we moving faster with AI? What’s our adoption rate? Jack Dorsey just cut half his company and the stock surged 24%. Our investors are asking questions. Show me the ROI.”

At Series A–B companies, every board meeting now includes a “what’s your AI strategy?” slide. 81% of IT leaders say the C-suite is now the main driver of AI initiatives — up from 53% just a year earlier — and 51% expect measurable AI ROI within 12 months, despite no consensus on how to measure it (Flexential, 2025 State of AI Infrastructure Report).

The bottom slice — team panic:

”Am I about to be replaced? Should I be using AI more? Is my job safe? I can do five things at once now but I can’t tell if any of them are the right things.”

Your engineers read Hacker News. They see the Bloomberg headlines. They’re doing the math on their own replaceability. And if you’ve hired new ones, they doing it during onboarding.

As an engineering leader, you’re the filling.

You absorb the pressure from above. You absorb the anxiety from below. You translate between two groups that are panicking about the same thing from opposite directions — leadership worried AI isn’t delivering enough, engineers worried it’s delivering them out of a job.

Here’s the thing that makes this particularly dangerous during a scaling push: AI amplifies whatever culture you already have. If your engineers understand the user and the product, AI makes them faster at building the right things. If they don’t — if they’re technically strong but product-blind — AI makes them faster at building the wrong things. More wrong features, faster, with more code to review and more bugs to find.

You can either be a passive panic sponge — absorbing anxiety from both sides until it erodes your judgment — or you can be a clarity driver who turns ambient dread into organizational decisions.

The Numbers That Are Feeding the Panic

The headline data your team is reading:

• Block cut 50% of its workforce on February 26, 2026 (TechCrunch). Gross profit was up 24% YoY. It’s a profitable company deciding it needed fewer people. Stock surged 24%.

• Oracle cut 30,000 employees on March 31 — 18% of its workforce — to free up $8-10 billion for AI data centers (CNBC). Net income was up 95% the previous quarter.

• Dorsey’s prediction — “most companies will do the same within a year” — landed the same day Andrej Karpathy posted that programming has become ”unrecognizable” since December 2025.

But the data that matters most isn’t about layoffs at 150,000-person companies. It’s about what’s happening inside teams that are still growing.

UC Berkeley found developers using AI are working more hours, not fewer (Bloomberg, February 2026). HBR reported that AI augments what employees can do, then delivers “fatigue, burnout, and a growing sense that work is harder to step away from” (HBR/Gartner, February 2026). One engineering leader told TechCrunch: “expectations have tripled, stress has tripled, actual productivity only up maybe 10%” (TechCrunch, February 2026).

And if you’re in the middle of scaling from 20 to 50 engineers, this is the environment your new hires are walking into.

The Velocity Illusion (And Why It’s Lethal During Scaling)

Your senior engineer who used to review four PRs a day is now staring at twelve — and half of them are twice the size they used to be. That’s the velocity illusion in practice.

Faros AI analyzed 10,000+ developers across 1,255 teams (February 2026). Teams with high AI adoption merge 98% more PRs. Leadership sees that and thinks the investment is paying off. But the full picture:

• PR review time increased 91%

• Bugs per developer rose 9%

• Duplicated code increased 8x

• Refactoring activity dropped ~60% (GitClear, cited in the Faros AI Productivity Paradox report)

Despite individual output spikes, they observed no significant correlation between AI adoption and improvements at the company level. The delivery pipeline isn’t moving faster. It’s clogging. The bottleneck didn’t disappear — it moved from writing code to reviewing code. Nobody updated the scoreboard.

The 2025 DORA Report — nearly 5,000 respondents, 100+ qualitative interviews, the most rigorous annual study in engineering productivity — now says it plainly: ”AI does not automatically improve software delivery performance.” It amplifies existing conditions. Teams with mature platform engineering, small-batch workflows, and strong engineering hygiene pull further ahead. Teams that are fragmented or lacking product discipline accelerate their decline. AI is a multiplier, not a corrective — and most scaling orgs don’t have the foundations in place to multiply something good.

The quality data is getting worse, not better. METR found that roughly half of test-passing AI-authored pull requests would be rejected by the repository’s own maintainers — agents optimize for green CI, not for code quality, architectural fit, or readability. Your pipeline says “all checks pass.” Your codebase says otherwise. The Cortex 2026 Benchmark Report fills in the rest: incidents per pull request up 23.5%, change failure rates up ~30% for teams that adopted AI without upgrading their quality practices. And CircleCI’s 2026 State of Software Delivery — 28 million workflows across 22,000 organizations — shows main branch success rates at a five-year low of 70.8%. AI throughput is outrunning validation capacity across the industry.

Waydev captured the punchline: AI drove a 59% surge in engineering throughput — but releases are not keeping pace. More code. Same number of releases. The work is going somewhere, but it’s not reaching users.

Meanwhile, 90% of CEOs report AI has had no measurable impact on productivity (NBER/Fortune, February 2026). Only 1 in 50 AI investments delivers transformational value (Gartner/HBR, February 2026). But 96% of executives expect AI to increase productivity (AskFlux, 2025). That gap between expectation and measurement is where the panic lives.

Now layer on Anthropic’s study from January 2026 — a randomized controlled trial with software developers: those using AI scored 17% lower on comprehension tests, roughly two letter grades worse than those who coded by hand. The biggest gap was in debugging — exactly the skill you need most when a growing portion of your codebase is AI-generated.

Think about what this means at 40 engineers. You just brought on 15 new people in two quarters. They’re using AI tools from day one, shipping code faster than any cohort you’ve onboarded before. But if they’re fully delegating without understanding the output, you’re building a team that’s fast but increasingly unable to validate what it ships.

At 15 engineers, your seniors could absorb this in review. At 40, they’re buried.

From Panic Sponge to Clarity Driver: The Playbook

To be clear: AI does deliver real value. On my team it’s accelerated everything from boilerplate and test generation to higher-leverage work — prototyping POCs, answering support tickets, digging into implicit product decisions buried in the codebase, feature flag cleanups, etc.

The problem isn’t AI. It’s adopting AI without the organizational infrastructure to channel it well. Every tactic below assumes you’re keeping AI and using it aggressively — just with guardrails.

1. Protect Product Sense First

This is the most important tactic: AI can generate code, but it can’t generate product judgment.1

An engineer who doesn’t understand why users need a feature will produce technically correct but product-wrong code — and AI will help them produce it three times faster. More wrong code, faster, all passing CI. If the culture your team had at 15 engineers — deep product understanding, engineers who could explain *why* they were building something — is eroding at 40, AI will accelerate that erosion.

Build product understanding into your AI practices:

• Require PR descriptions to articulate the user problem, not just the technical change. “Adds pagination to the API” tells you nothing. “Users processing more than 500 transactions per month hit timeout errors — this adds cursor-based pagination to keep response times under 2 seconds” tells you the engineer understands what they’re building and why

• For newer engineers: use the “Generation-Then-Comprehension” pattern from the Anthropic study — generate with AI, then understand the output and its product implications before moving on. Those who did this retained 86% comprehension. Those who fully delegated retained 39%. If they can’t explain how the code connects to a user need, they’re not ready to ship it

• Run product walkthroughs alongside code reviews. When reviewing an AI-generated feature, check whether the code solves the right problem, not only its correctness. This is the review that AI can’t do for you.

The engineers who’ll be most valuable in two years are the ones who generate the right code — because they understand the product deeply enough to direct AI toward the work that actually matters.

2. Name the Elephant — Then Bound It

Stop waiting for your team to bring up the anxiety. They might not — not because they aren’t worried, but because they don’t know if it’s safe to be worried at work. Name it explicitly.

In 1:1s, ask directly:

• ”How is the AI tooling actually affecting your day-to-day? Not the productivity stats — your experience.”

• ”I know the industry headlines are out there. What questions do they raise for you about our team?”

• ”Are you finding it harder to focus with more things in flight?”

Then bound it.

Help your team separate what’s actually changing on this team from what’s happening in the news cycle. “Oracle cut 30,000 people” is a headline about a 160,000-person company betting $156 billion on data centers. “We just hired four engineers and our scope is expanding” is your team’s reality. Those are two different stories. Your job is to make sure your people are living in the right one.

The patterns across your 1:1s will tell you where the anxiety is concentrated — and whether it’s about AI specifically or about a broader lack of clarity on what the team is building and why. Often it’s the latter, and AI is just the accelerator.

3. Coach for Leverage, Not Volume

This one came directly from my team’s experience. AI tooling didn’t just speed up their work — it fragmented it. When you can generate code across five contexts simultaneously, you end up context-switching across five work streams. And the instinct becomes: I can do more things, so I should do more things.

That instinct is wrong. It’s always been.

An engineer’s leverage isn’t in solving a huge volume of problems. It’s in solving a specific, well-chosen problem that affects a large volume of users or revenue or other business outcomes. AI didn’t change that equation, it made the temptation to scatter harder to resist.

Your job as a leader is to coach engineers back toward leverage. Help them ask: “Of the five things I could start right now, which one matters most to the user? Which one moves the metric we actually care about?” Then go deep on that one thing. AI makes the execution faster — great. Use the time saved to understand the problem better, not for AI-powered snacking.

This seems counterintuitive when leadership is pushing for throughput. But an engineer deeply focused on one high-leverage problem will ship more real impact than an engineer scattered across five threads of AI-generated drafts that all need review and none of which were the most important thing to build.

Frame it this way to leadership: “We’re optimizing for impact per engineer, not tasks per engineer.”

4. Re-frame Measurement Upward

Your board is probably tracking the wrong metrics. Here’s what that conversation sounds like — and how to redirect it.

What your board says: ”We’re investing in AI tools across engineering. What’s the ROI? How many PRs are AI-assisted? What’s our adoption rate?”

What you say back: ”Adoption is high — our engineers use AI daily. But let me show you the full picture. We’re merging 98% more PRs. That sounds great. But review time is up 91%, and our DORA metrics — the ones that actually measure delivery performance — are flat. PR count measures activity, not outcomes. What I want to show you instead is product throughput: features that solve user problems, shipped to production, validated with data. That’s the number that matters for product-market fit.”

This re-framing works because you’re not pushing back on AI — you’re pushing back on bad measurement of AI. That positions you as the person thinking clearly about what actually drives the business. Anchor on Gartner’s finding that only 1 in 50 AI investments delivers transformational value. Results is the name of the game, not adoption.

5. Define AI Delegation Zones

The Anthropic study showed that how people use AI matters far more than whether they use it. Remove ambiguity by giving your team explicit zones:

🟢 Green zone — high delegation, low risk: Boilerplate code, test scaffolding, documentation drafts, simple refactors or cleanups. AI accelerates these and verification cost is low.

🟡 Yellow zone — AI-assisted, human-verified: Feature implementation, API integrations, data transformations. AI builds, humans review carefully. Every AI-generated change here gets the same scrutiny as any other PR. Even though this zone is “yellow”, it’s where the majority of your team’s PRs fall in.

🔴 Red zone — human-led, AI follows: Security-critical code, architecture decisions, complex business logic, anything touching money or user data. Humans lead. AI can suggest, but a human must understand and own every line.

Across all zones, one thing remains true: the human is accountable for each line of code, whether AI wrote it or not.

The zones do double duty. They give engineers clarity on where AI belongs — reducing the “should I be doing more?” anxiety. And they protect your product quality by concentrating human review where it matters most. At a scaling company, these zones also become part of your onboarding — new engineers know the expectations from week one.

6. Budget for The Verification Tax

AI-generated code isn’t free. It arrives fast but carries a verification cost that nobody budgets for. This is the operational reality behind the velocity illusion.

Make it explicit in sprint planning:

• Add ”AI review” as a line item in capacity planning, not an afterthought

• Track your review-to-generation ratio as a health metric. If generation is outpacing review, you’re accumulating unverified code — which is just tech debt with a different name

• As a rough model: if AI cuts generation time by 60%, add 30% to your review estimates per story point. The net is still faster — but the review budget is now visible, not hidden

During rapid scaling, this matters even more. Every new engineer adds to your generation capacity. Your review capacity doesn’t scale at the same rate. If you don’t budget for the verification tax, you’ll hit a point where you’re shipping code faster than anyone can validate it — and the bugs will find your users before your reviewers do.

The Clarity Your Organization Actually Needs

After that team retro, we worked on a set of specific decisions. We capped WIP at two tracks. We started requiring product context in PR descriptions. We made the review queue visible as a team metric, not an invisible tax on seniors. We named the anxiety out loud in a team meeting and separated what was actually changing from what was headlines.

None of it was revolutionary. All of it was clarity.

You can’t control the Bloomberg headlines. You can’t promise layoffs will never happen. You can’t predict how AI will reshape engineering roles.

But you can control the clarity of the environment you build — where AI belongs, where human judgment is non-negotiable, how you budget for the real cost of AI-assisted development, and whether your engineering practices build product understanding or let AI bypass it.

The productivity panic is real. The pressure from above is real. Your team’s anxiety is real. But the engineering leader who converts panic into clarity — who takes the ambient dread and turns it into organizational decisions, specific practices, and honest conversations — that person isn’t a panic sponge. That person is the reason the team holds together during the hardest scaling phase of the company’s life.

The next time an engineer tells you in a retro that AI tooling is giving them an existential crisis, you’ll have an answer. Not a reassuring platitude — a specific set of organizational decisions that convert their anxiety into something they can actually work with.

If you’re scaling an engineering team through the AI productivity panic and want practical frameworks for maintaining product culture while growing fast, [subscribe to Stratechgist](https://stratechgist.com). I write about building product-minded engineering teams at scale — lessons from the trenches. You can also find me on LinkedIn where I share shorter takes on what’s actually working in engineering leadership right now.

If your team is growing past 20 engineers and you’re seeing velocity drop despite AI adoption, drop a reply or a DM and let’s exchange notes. I can help you out.

For years, your PM was the person who wrote tickets. They decided what, you figured out how. Then you crossed over — became an EM — and suddenly the PM isn’t handing you tickets anymore. They’re sitting across the table expecting you to co-own the outcome.

Nobody warned you about this shift, and your PM is wondering why the new engineering leader keeps waiting for instructions instead of showing up with opinions.

Here’s the playbook for making this relationship actually work.

The Shift Nobody Explains

As an IC, your PM relationship was simple: they decided what to build, you built it. Maybe you grumbled about it over lunch, but ultimately you could just put your headphones on and code.

That’s gone now. Your PM expects you to have opinions about the roadmap, push back on bad bets, and bring the engineering perspective to the table unprompted. And right now? You’re probably still nodding along in meetings and then venting to your tech lead about how the priorities make no sense.

How I learned this the hard way

I’ve been on both sides of this dysfunction. When I first became an EM, I transitioned in October — right before the annual planning cycle kicked off in November. My PM did the whole exercise: put the spreadsheet together, lined up priorities, presented the roadmap. And I was very much not in the driver’s seat. I wasn’t even in the passenger seat. I was in the goddamn trunk of the car.

I asked questions — “Why is this valuable?” “What’s the expected impact?” — but I didn’t pitch in. I didn’t bring my own perspective. The insight I was missing: I owned the team, which meant I owned what the team delivers, which meant the roadmap was my accountability (too.) It was supposed to be a partnership, and I was treating it like a briefing.

The wake-up call came from my own team. I brought the roadmap to them, and someone asked, “What’s the bandwidth allocation for technical improvements? We’ve got debt, performance work, new patterns we could adopt — where does that fit?” I didn’t have an answer.

So I went back to my PM: “Hey, I think we need to add some technical work.” He said, “Great, what do you want to add?” I had no idea. I went back to my team. Then back to the PM. I was a ping-pong ball bouncing between the two of them, trying to put the footprint of an engineering leader on the roadmap without knowing what that footprint should look like.

It was frustrating for everyone — especially my PM, who just wanted me to show up with a point of view.

What I learned to do from there: build a technical roadmap on the side, maintained over time with my tech lead. We’d nurture ideas, scope them when planning came around, and explain the product value behind each technical investment. Once you can articulate why a technical improvement matters for users and system stability, it’s very hard for a PM to push back. But that muscle took time to build — and it only started building after that humbling first planning cycle.

The Co-Pilot Model

I call this The Co-Pilot Model because that’s what your PM relationship should be: two people in the cockpit, both responsible for landing the plane, but with different instruments in front of them.

Your PM is watching the market, users, and business metrics. You’re watching architecture, team capacity, and technical debt. Neither view is complete alone — I’ve seen the crash, and it looks like a team shipping features nobody uses while the PM panics because engineering “isn’t moving fast enough.”

Three principles:

1. Shared context, separate expertise. You each bring a unique lens, but you both need to understand why the other’s decisions matter.

2. Complementary challenge. Your PM pushes for speed and scope; you push for quality and sustainability. Neither of you should “win” — the user should win.

3. Joint accountability. When a feature flops, you don’t get to say “well, the PM wrote the spec.” You own outcomes together.

The three conversations below are how you start building this.

The Three Conversations That Matter

The difference between a functional and dysfunctional PM relationship comes down to three recurring conversations. Most teams have none of them.

Conversation 1: The Why Sync

Frequency: Every 2-4 weeks, 30 minutes

Purpose: Align on the why behind the work, not the what. This is the conversation most teams skip entirely. You talk about what and when, but never why this thing matters more than the other twelve things you could be doing.

In a Why Sync, you ask your PM:

• “What’s changed in the market or with our users since we last talked?”

• “Which bet on the roadmap are you most uncertain about?”

• “If we could only ship one thing this quarter, what would it be and why?”

And your PM should be asking you:

• “What technical risk are you most worried about right now?”

• “Is there anything on the roadmap that’s significantly harder than I think it is?”

• “What technical investment would give us the most product value?”

The point is to make sure you’re both operating from the same understanding of reality, instead of renegotiating the roadmap every two weeks. When context is shared, a hundred small daily decisions get easier.

What happens without a Why Sync

I learned this the expensive way. Early in my EM tenure, one of my engineers and I got fired up about simplifying the integration patterns for an API our team owned. We brainstormed the design, did the engineering spec, ran through product design — weeks of preparation. We had high conviction this was the right thing to build. Our PM was theoretically aligned too, but stretched thin on other priorities, so we ran ahead.

Then we took it to the product review forum. One of the senior product leads looked at our plan and asked a question that stopped us cold: “You’re optimizing this integration flow — which is great — but you have double-digit users on this API. Why are you spending time optimizing instead of recruiting users to actually build on it?”

They were right. We’d been solving an engineering problem without the product context. The priority wasn’t a better integration experience — it was adoption. I’d failed to engage my PM deeply enough, and they hadn’t had the bandwidth to catch it. Engineering ran ahead of product, and when product caught up, they were baffled.

We had to put the project on pause. My engineer was disappointed — understandably. We pivoted to growth experiments to drive adoption instead.

Two years later, we actually did build the optimized integration experience, and it worked beautifully. The difference: thousands of users benefiting from it instead of dozens. A month of wasted preparation taught me that every project kickoff needs real alignment between me and my PM — not just theoretical agreement, but both of us actively confirming *this is the right thing to build right now*.

Making it work

As a new engineering leader, you probably don’t have a strong intuition for product strategy yet. That’s fine — nobody expects you to. But you do need to understand the strategic context well enough to make good tradeoff decisions without escalating every call to your PM. The Why Sync builds that muscle.

Your team will come to you with prioritization questions you can’t answer without product context — “Should I fix this bug or finish the feature?” is a product question disguised as an engineering one. Without the Why Sync, you’ll either escalate every call to your PM (eroding their confidence in you) or guess wrong and own the fallout.

Here’s the Slack message I send: ”Hey [name] — I want to make sure I have enough product context to make good tradeoff calls without pinging you on every decision. Could we grab 30 minutes every couple of weeks to sync on the ‘why’ behind the roadmap?”

Conversation 2: The Tradeoff Table

Frequency: When scoping any meaningful piece of work

Purpose: Make scope/quality/timeline tradeoffs explicit and shared

Here’s how most scoping conversations go: PM writes a spec. Engineering says eight weeks. PM says four. Everyone argues, escalates, and ships something mediocre.

The Tradeoff Table is a reframe. Instead of arguing about whether something is “possible,” you lay out options:

Now you’re not fighting about estimates — you’re choosing between options together. Either way, the decision is transparent.

The key move: Never show up with a single estimate. Always bring options. This is how you stop being an order-taker.

The sentence that reframes the conversation: ”I want to make sure we’re choosing the same tradeoff on purpose, not landing on one by accident. Here are three ways we could scope this — what feels right given what you’re hearing from users?”

Conversation 3: The Retro Loop

Frequency: After every significant ship (not a process ceremony — a real conversation)

Purpose: Learn together from what actually happened

Not your team’s sprint retrospective — a private conversation between you and your PM about what you shipped and what you both learned. Questions to cover:

• “Did users actually use this the way we expected?”

• “What surprised us — technically or from a product perspective?”

• “Where did our assumptions break down?”

• “What would we do differently if we were starting over?”

Over time, these conversations build shared pattern recognition — a joint sense for “what works here” that’s worth more than any process. They also create psychological safety: you’re both admitting what you got wrong, which makes it easier to challenge each other next time.

Here’s how I propose it: ”Hey [name] — now that [feature] has been live for a couple of weeks, I’d love to grab 20 minutes to compare notes. Did it land the way we expected? What surprised us?”

When Your PM Is the Problem

Everything above assumes a willing PM. But sometimes the relationship still isn’t working. Before you escalate, answer one honest question: is your PM actually blocking progress, or are you not stepping up?

The mirror test

Before pointing fingers, check yourself:

• Have you actually tried the conversations above — or just thought about trying them?

• Are you bringing options and opinions to the table, or still waiting for instructions?

• Have you told your PM directly what you need from them, in specific terms?

• Does your PM know you’re frustrated — because you’ve told them directly?

If you can honestly answer yes to all four, the problem might genuinely be on the other side. If not, start there first.

Giving hard feedback to your PM

When your PM is underperforming or checked out, you owe them directness before anything else.

The script: ”Hey [name], I want to talk about how we’re working together. I’ve noticed [specific behavior], and the impact on the team is [specific consequence]. I want us to figure this out together, because the current pattern isn’t sustainable.”

Three rules:

1. Be specific, not general. “You’re not engaged enough” is useless. “The last three specs arrived the day before sprint planning” is actionable.

2. Name the impact, not the intent. You don’t know why they’re checked out. You do know the team is making decisions without product context.

3. Do it in private, and do it early. The longer you wait, the more likely it leaks sideways.

When to escalate

If direct feedback hasn’t changed anything, involve your manager. Escalate when:

• You’ve had the direct conversation at least twice and the behavior hasn’t changed

• Your team’s delivery or morale is measurably suffering

• The PM is making commitments to stakeholders without engineering input

• Trust has eroded to the point where you can’t give feedback effectively

When you do, lead with facts: *”I’ve raised X with [PM name] twice. Here’s what I asked for, here’s the impact on the team. I need your help figuring out the next step.”*

Five Anti-Patterns That Will Tank the Relationship

Knowing what to do is half the battle. Here’s what to stop doing.

1. The Ticket Machine. You treat your PM as a requirements factory — they write specs, you build them, nobody talks about whether the specs make sense. Before building anything, ask “What problem are we solving, and how will we know we solved it?”

2. The Back-Channel Complainer. You disagree with your PM’s priorities but vent to your team instead of saying it to their face. Your PM finds out eventually — they always do — and now they don’t trust you. Disagree directly, in private, with data: ”I see this differently — can we grab ten minutes before we commit?”

3. The Scope Creep Enabler. Your PM keeps adding “just one more thing” and you absorb it silently because you want to be a team player. Use The Tradeoff Table every time: ”We can absolutely add that. Here’s what it costs. What should we cut to make room?”

4. The Technical Gatekeeper. You use complexity as a weapon — “that’s not possible” when you mean “that’s hard.” PMs can smell this from a mile away. Be honest about effort, explain why something is hard, and bring a simpler alternative that gets 70% of the value.

5. The Absent Partner. You skip product reviews, don’t read specs until sprint planning, and can’t name your team’s top three metrics. Block 30 minutes a week to read what your PM is writing — you don’t need to become a product expert, just informed enough to ask good questions.

I’ve lived #2 firsthand. After a reorg, I started working with a PM whose work ethic didn’t match my team’s intensity. I tried to steer them — more rigor, less ad-hoc — but the feedback didn’t stick, and I wasn’t experienced enough to make it land. So the frustration leaked. My “venting” to my manager turned into ammunition that went up the chain. Senior leadership delivered harsh feedback, and eventually the PM left the organization.

The worst part wasn’t that he left. It was that my inability to be direct destroyed the collaboration long before anyone intervened. Avoiding hard conversations to keep the peace is a recipe for a worse explosion later.

Start With One Conversation

If this all feels like a lot, start with one thing: schedule a Why Sync with your PM this week. Thirty minutes. No agenda beyond “let’s make sure we’re seeing the same picture.”

You’ll be surprised how much changes when you simply show up with curiosity about their world. Most PMs have never had an engineering partner ask “what are you most uncertain about?” Try it. Watch what happens.

How you’ll know it’s working

This takes time — your PM relationship probably won’t feel like a real partnership next week, and that’s fine. But if you commit to these conversations, here’s what the progression looks like:

• Month 1: Your PM stops being surprised by timeline pushback. Scoping conversations get shorter because you’re both working from the same context.

• Month 3: You can answer your team’s prioritization questions without escalating to your PM. You have enough product context to make the call yourself — and your PM trusts you to make it.

• Month 6: Your PM proactively asks your opinion before making commitments to stakeholders. You’re not just informed — you’re consulted. That’s the co-pilot dynamic working.

If you’re three months in and still getting blindsided by roadmap changes, the conversations aren’t going deep enough.

Your PM relationship is the first real test of whether you’ve made the transition from builder to leader. As an IC, you could be great in isolation. That’s over now. Your impact lives or dies in the space between you and the people you share ownership with — and your PM is the first one across the table.

Get this right and everything else gets easier. Get it wrong and no amount of engineering excellence will save you.

If you found this useful, subscribe to Stratechgist for more practical leadership playbooks. You can also find me on LinkedIn — I post about engineering leadership, career growth, and the messy reality of crossing from IC to leader.

A major user who’d been with us for years decided to finally integrate with our newly-shipped API. Up until this point they’d been using a competitor’s solution that worked fine, but we had this big partnership announcement planned. Marketing was excited. Their account executive was excited. Then they ran their load tests.

Compared to our competitors, our API was a snail. It returned 2-second response times. Their previous solution averaged 200 milliseconds.

Suddenly I find myself on a Zoom call with my manager, an account executive, and a solutions architect – they tell me about this very unhappy customer who’s questioning whether they should abandon this whole launch. All eyes on me: “When can you fix this?”

Here’s the thing about user escalations: your first instinct is usually wrong. You want to stop the world, gather your team, and start firefighting. Don’t. That creates chaos when you need clarity.

After going through a few such escalations, I’ve developed what I call the SHIELD framework. It’s how you protect both your user relationship and your team’s sanity.

S - Seek Context First

Before you touch your team, understand what happened. I made this mistake early in my career - ran straight to my engineers with “EVERYTHING IS ON FIRE” energy. Created panic, killed productivity, and I still didn’t understand the real problem.

Talk to your internal stakeholders first. In my API case, I spent an hour with my manager understanding the problem from his perspective. Then, I talked to the solutions architect involved. Turns out they were comparing our API to a competitor’s API that is not as feature-rich as our API. Still, it was their prerogative to be unhappy.

Then I talked to their Account Manager: “How did we get here? What commitments were made?” She showed me emails from six months ago where we’d promised “enterprise-grade performance” without defining what that meant.

Next, talk to the user directly. Don’t delegate this, it’ll be in poor taste. Get on a call with their technical team. In my case, I spoke with a senior engineer and his product manager. He walked me through their load testing results, showed me their current integration, explained their go-live timeline.

“Look,” he said, “we don’t need your API to be the fastest. We just need it to be predictable and under 500ms at p50. But right now it’s inconsistent - sometimes 200ms, sometimes 5 seconds. Your p50 is over 800ms.”

That context was gold. The problem wasn’t just speed - it was also consistency.

Write everything down. I created a shared doc with:

• Timeline of events leading to escalation

• Technical requirements from user

• Business commitments made by sales/marketing

• Current performance metrics vs. expectations

• Key contacts and their concerns

Escalations get messy fast. Escalations also move at breakneck speed. You need this paper trail. Especially when things get heated. And they will.

H - Hold Your Team Steady

Don’t pull engineers off current work until you understand the scope. Your team doesn’t need the stress of an emergency until you know it’s actually an emergency.

I learned this the hard way. Previous escalation, I immediately grabbed three senior engineers: “Drop everything, we need to fix the user dashboard.” Turns out the “critical” issue affected 12 users and had a simple workaround. I’d derailed at least a month’s worth of roadmap work for something that could wait.

Once you do need them, be surgical. For my API issue, I needed two people: our Staff Engineer who’d built the original system, and a Senior Engineer who specialized in performance optimization. No need to pull in other people where these two would suffice.

Create a communication blackout. I told them: “You two disappear. Turn off Slack notifications. I’ll handle all external pressure. Check in with me once daily at 4PM, otherwise you’re in a bunker.”

Why? Because the moment leadership knows who’s working on the problem, they’ll ping those engineers directly. “Quick question about timeline...” turns into a 30-minute interruption that kills deep work. And the last thing we need is to have these people interrupted. On the contrary, they should be focused on the solution space, not on a Confluence space.

Protect their focus ruthlessly. When our VP of Engineering asked to “just hop on a quick call with the engineers to understand the technical approach,” I said no. “I’ll get you the information you need. They’re heads-down fixing this.”

I - Identify Solutions at Three Horizons

Work with the user to define what success looks like across different timeframes. Don’t just ask “what do you want?” - they might say “make it faster” when what they really need is predictability. When talking to users I always try to remember that quote from (probably?) Henry Ford that goes “If I asked people what they wanted they would’ve said faster horses.” Users don’t know what exactly they want, but hearing them talk about what they want is a good signal. Use it.

Short-term (days to weeks): Immediate pain relief while you work on the real fix.

For my API problem, short-term was implementing request throttling on their account and setting up dedicated sharded infrastructure for their load testing and productionizing. We deployed this in 2 days. Performance improved from 2+ seconds to 600ms - not great, but consistent and close to their 300ms threshold. Not great, yet not terrible.

Also, my PM and I negotiated with Finance to waive their transaction fees for the month. Sometimes the short-term fix is business, not technical.

Medium-term (1-3 months): Architectural improvements that address root causes.

We implemented proper caching, database query optimization, and connection pooling. Added monitoring so we could see performance patterns in real-time. This got us consistent 500ms response times.

Long-term (3-12 months): Complete rewrites or major platform shifts.

We rebuilt the API with a different architecture - using a more modern tech stack, with concurrent primitives supported by the language. The new system could handle 10x the load with consistent latency and half the costs. But this took 8 months and wasn’t ready when the user needed it.

Be explicit about trade-offs. I told the customer: “We can get you stable performance in a week, good performance in two months, and great performance in eight. What matters most for your go-live?”

They chose stable performance with a plan for good performance. Made the decision easy.

E - Establish Communication Rhythms

The biggest mistake I see engineers make: irregular, ad-hoc updates that create anxiety instead of confidence. Then they get polled for updates from different stakeholders which interrupts their focus and flow.

Internally: Daily standups with the core team only. 10am sharp, 15 minutes max. Format:

• What did you learn yesterday?

• What are you tackling today?

• What’s blocking you?

• Any changes to the estimated timeline?

Then I packaged updates for broader stakeholders without overwhelming engineers. Every evening, I sent a Slack message to our leadership channel:

API Escalation - Day 3 Update:

• ✅ Implemented throttling fix, deployed to staging

• 🔄 Load testing scheduled for tomorrow morning

• ⏰ Customer demo Friday 2pm

• 🚫 No blockers currently

• 🔜Next update: Tomorrow 6pm

Externally: Match frequency to uncertainty level. No timeline yet? Daily written updates. Clear path to resolution? Weekly calls work.

For my API customer, I sent daily Slack updates for the first week (we shared a common channel):

“Hi [PM name],

Quick update on the API performance work:

Yesterday: Deployed throttling improvements to production Today: Running load tests on your staging environment Tomorrow: Planning to show you results and discuss next steps

Performance is already more consistent (see attached graphs), but we’re not at target numbers yet.

Any questions or concerns, ping me directly.”

Notice what I included: concrete actions, data, next steps, and my direct contact. No fluff, no false promises.

L - Lead from the Trenches

If your engineers are working late, you’re online with them. Handle the bureaucracy, project management, and organizational politics. Let them focus on building.

Take the admin work. While my engineers optimized database queries, I:

• Scheduled all meetings with stakeholders

• Updated Jira tickets and project tracking

• Coordinated with infrastructure team for new servers

• Handled communication with Finance about fee waivers

• Prepared demo materials for customer presentation

Remove organizational friction. When my engineer needed help from the Reliability team, I didn’t say “reach out to them.” I pinged their manager, explained the situation, and got someone assigned within an hour.

When we needed to deploy on a Friday after midnight, I got approval from the on-call engineer explaining the situation and aligning with them instead of making my engineer fight that battle.

Be available, but not overbearing. I didn’t hover over their shoulders. But when they Slacked me at 9pm saying “this query optimization isn’t working,” I hopped on a call immediately.

Sometimes you can help technically. Sometimes you just need to be a sounding board. Always you need to show you’re in it with them.

D - Document and Defend

After resolution, run a retro focused on process, not blame. What broke down? How do we prevent this?

My post-mortem revealed three systemic issues:

1. Sales promised “enterprise performance” without engineering input - We now require technical review for any performance claims

2. No load testing in our standard customer onboarding - We built a load testing checklist for large integrations

3. Performance monitoring was reactive, not proactive - We implemented alerts before customers notice problems

Create new operating procedures. I wrote a “Customer Escalation Playbook” that became our standard. Shared it in our engineering all-hands, posted it in our team wiki, and sent it to other engineering managers.

Claim the victory. I presented our resolution and new processes to the executive team. Not to brag, but to show we’d learned from the experience and built systems to prevent future escalations.

The customer renewed their contract and became a reference account. More importantly, we haven’t had a similar escalation since.

The Meta-Lesson

Most escalations come down to communication and process failures. The technical stuff is the symptom. Your job is to handle everything else so your engineers can do their best work - the meetings, the status updates, the political cover, the late-night Slack from the VP.

Your impact as a leader comes from coordination and protection, not solutioning.

Want more frameworks like this? Subscribe to my newsletter where I share battle-tested approaches to engineering leadership challenges every week.

Let’s connect on this topic: I post daily insights about managing up, scaling teams, and handling the messy reality of engineering leadership on LinkedIn. Would love to hear your escalation war stories.

🎁 BONUS: 4 Templates + 1 Reference Card

Paid Subscribers get:

• SHIELD Quick Reference Card - One-page framework summary with all six phases (Seek, Hold, Identify, Establish, Lead, Document) in a scannable table format. Pin to desk or team wiki.

• Escalation Context Template - Fill this out BEFORE touching your engineers. Covers timeline, technical requirements, business commitments, key contacts, and initial assessment. Forces you to understand scope before creating panic.

• Communication Templates Pack - Four copy-paste templates: daily standup format, internal Slack update, external customer update, and engineer briefing script.

• Three Horizons Solution Planner - Structured worksheet for planning short/medium/long-term fixes. Includes the customer trade-off discussion script from the article.

• Post-Escalation Retrospective Template - Retro structure focused on systemic issues, preventive action items, and distribution plan. Process, not blame, as always.

Get them below:

Read more

They’d been with us for two years. Solid performer. Never asked for a professional development budget before. The conference was well-regarded in the industry, not some vendor junket.

But we had a policy: conference attendance was capped at one per person per year. Budget constraints. Fair distribution of opportunities. The usual reasons.

This would be their second conference of the year. The first one had been in Q1—a mandatory vendor training that the team needed someone to attend. This new conference was the one they actually wanted to go to for their own development.

I looked at the policy. Saw they’d already been to one conference. Told them we couldn’t make it work. He understood. The conversation ended there.

Then I found out our sibling organization – same division, same budget constraints – regularly sent people to multiple conferences per year. They counted mandatory vendor trainings separately from conferences for professional development. Same policy our organization supposedly had to follow strictly.

This meant the engineer in question had an option: miss the conference and the learning opportunity, or transfer to the sibling org where they could go to the conference, but would have to leave the team they’d built a 2-year relationships with.

The engineer spent three weeks getting mixed messages while this played out. Finance said maybe. Their skip-level said probably. I said the policy was clear. The sibling org said they’d approve it if he would join their organization.

Frustrating for everyone involved.

What I Got Wrong

I treated the policy like it was absolute. But worse, I didn’t push back on the fact that it was being applied unevenly.

Policies exist for good reasons. When we approve conference attendance, we need to manage budget and ensure fair distribution of opportunities across the team. The one-per-person cap makes sense for that.

But our sibling organization was interpreting it differently. They didn’t count mandatory vendor trainings or required certifications against the cap. Only elective professional development conferences counted. For an outsider this seems like a petty problem that we’re being pedantic about. But in a organization with multiple-hundreds of people you want policies to be standardized and applied evenly.

This request wasn’t a random one, that would break the budget. This was a proven engineer who’d used their one “real” conference slot on a mandatory training, asking to attend an actual professional development conference.

The policy’s intent (fair distribution of development opportunities) wasn’t being violated. And the uneven application meant we were forcing good people to choose between professional growth and staying with their team.

I should have asked: why are we counting mandatory trainings against the conference cap when our sibling org doesn’t? Does this case deserve an exception? Instead, I saw the rule and stopped thinking. Not great.

How My Manager Handled It

My skip-level didn’t argue the policy was wrong. She acknowledged why it existed and that it generally made sense.

But she pushed on the inconsistency. Why was our sibling org interpreting “one conference per year” to exclude mandatory trainings, but we weren’t?

She built the case for why this situation was different:

• This was a conference in the engineer’s core area of expertise

• The first “conference” was mandatory vendor training, not elective professional development

• The engineer had never actually used professional development budget for their own growth

• The sibling org was explicitly not counting mandatory trainings against the cap

• The policy’s intent was fair distribution of development opportunities

• This interpretation wouldn’t violate that intent. In fact, it would actually serve it better

She showed leadership that we were applying the policy unevenly across the organization. Either the sibling org shouldn’t be making that distinction, or we should interpret the policy the same way.

She gave them a framework for making an exception without undermining the policy itself, that would lead to applying it consistently with how other parts of the org were already operating.

That’s what I should have done from the start.

When Policies Need Exceptions

Good policies create consistency. They prevent chaos. They encode organizational learning so we don’t have to re-litigate the same decisions repeatedly.

But policies are general rules designed for typical situations. Not every situation is typical.

I’ve seen this pattern repeat across different contexts:

• A hiring timeline works for most roles but loses you a stellar candidate in a competitive market. The policy says three rounds over four weeks. The candidate has another offer in two.

• A code review policy makes sense generally but blocks a critical security patch. The policy says two reviewers and 24-hour review window. The vulnerability is being actively exploited.

• A promotion cycle is reasonable for most situations but fails to account for someone who took on a leadership role mid-cycle and crushed it. The policy says reviews happen twice a year. This person deserves recognition now.

The policy isn’t wrong in these cases. But rigid application without judgment creates bad outcomes.

The Framework I Use Now

When I hit a policy that’s creating a problem, I don’t assume it needs to change. I ask four questions:

First: Why does this policy exist?

Not just the stated reason. The actual problem it was designed to solve. Often you’ll find the policy made perfect sense when it was created, and still makes sense for most cases.

Second: Is the policy being applied consistently?

Are other teams, orgs, or divisions getting exceptions you’re not? If so, why? Inconsistent application often signals that the context has changed or that someone else has already solved the problems the policy was meant to prevent.

Third: Is this situation different?

Not “is it inconvenient” or “would I prefer a different outcome.” Actually different. Does the reasoning behind the policy apply here? Is the risk profile the same?

Fourth: What would an exception look like?

Can you grant an exception without setting a bad precedent? Can you document why this case is unique in a way that doesn’t open the floodgates?

If the answers are “the policy is sound,” “it’s being applied unevenly” or “this case is genuinely different,” and “we can make an exception without undermining the rule,” then you build your case.

Building the Case for an Exception

Document why this situation differs from the norm. Be specific.

Don’t say “this conference is really good” or “this person really deserves it.” That’s true for lots of situations that don’t warrant exceptions.

Say: “This conference is directly relevant to the engineer’s core responsibilities. The policy exists to ensure fair distribution of professional development opportunities. The first conference was mandatory vendor training required for the team. Our sibling org doesn’t count mandatory trainings against the cap. The policy’s intent isn’t being violated—they haven’t actually used their professional development allocation yet.”

Or: “Our sibling organization explicitly separates mandatory trainings from elective professional development in how they count conferences. If they can make that distinction, we should be able to as well. Either we need to apply the policy consistently, or we need to document why our org has different constraints.”

Show what makes the risk profile different. Point out inconsistent application. Give leadership a clear framework for granting the exception without setting a bad precedent.

Make it easy for them to say yes.

What I Should Have Done

I should have gone to my manager and laid out the situation. Here’s the policy. Here’s why it exists. Here’s how our sibling org interprets it. Here’s why this case is different. Here’s what an exception would look like. Can we make this work?

Instead, I saw the policy and stopped thinking. I didn’t push back on how we were interpreting it differently than other parts of the org. I didn’t advocate for consistency.

That’s on me.

The engineer eventually got to go to the conference. They spent three weeks uncertainty about it, leaving a bad aftertaste in their mouth. All that just to access standard professional development.

That uncertainty was unnecessary. I could have advocated for them from the start.

The Broader Lesson

Policies provide structure. They’re necessary. Most of the time, you should follow them.

But leadership means knowing when the structure needs to bend. When the specific context is different enough that the general rule doesn’t apply. Or when the policy is being applied inconsistently across the organization.

Inconsistent application is often the clearest signal that something’s wrong. If one team can do something and another can’t, there’s either a good reason for the difference or the policy isn’t being managed properly.

As a leader, you need to push back on that inconsistency. Not because you want to undermine the policy, but because uneven application creates confusion and forces people into unnecessary choices.

You can’t do this for every inconvenient policy. If you’re constantly pushing for exceptions, you’re probably the problem.

But when the situation genuinely differs from what the policy was designed to handle, or when you discover the policy is already being applied differently elsewhere, you owe it to your team to make the case.

I didn’t do that when it mattered. I won’t make that mistake again.

If you’re navigating the transition from IC to tech lead or engineering manager, I write about these leadership challenges every week. Subscribe at Stratechgist.com or connect with me on LinkedIn.

He'd been building an integration for six months. The integration connected our product with another platform built by the same company – different teams, but same organization.

Our head of sales had been asking about the integration. He wanted to understand what we were building so he could stay ahead of the curve with prospects. Smart guy – he knew that understanding our technical capabilities would help him sell better.

I arranged a walkthrough with him so we could all learn about the integration. I figured my engineer, having worked on this for months, would walk us through how the host product worked and how our integration fit in.

What happened next was one of the most awkward demos I've ever sat through.

The head of sales started asking basic questions about the host product's core features. How do the main primitives interact? What are the canonical use cases? Think of it like asking someone building an Amazon marketplace integration to explain how sellers, listings, and carts work together.

My engineer couldn't answer. At all.

Here was someone I'd been managing for months on this project, and he understood less about the host product than our head of sales and I did. We came expecting expertise. Instead, we got surface-level explanations and uncomfortable silences.

The code worked fine. But this was a product engineering failure.

You Can't Be a Product Engineer Without Understanding the Product

Here's what most engineers miss: when you're hired as a product engineer, it's pure business.

Someone made a case for your headcount. A GM or business lead told finance: "We need this person to build these features that solve these customer problems." Your entire role exists because there are customer problems that need solving.

If you don't vibe with that reality, you're setting yourself up to fail.

You can fake caring about customers during interviews. You can nod along in product reviews. But when it comes to actual work, you either have empathy for user problems or you don't.

Product engineering isn't about writing elegant code in isolation. It's about solving customer problems through product features. If that doesn't interest you, there are other engineering paths. Infrastructure, platform, backend systems engineering. All valuable, all needed.

But product engineering? That's reserved for people who want to understand what users actually need.

My Own Product Blindness Nearly Tanked a Project

Early in my career, I learned this lesson the hard way.

I was consulting for a major internet service provider. We built an internal tool for their sales team – a deal builder where salespeople could configure enterprise internet packages. Different connection speeds, service levels, pricing tiers. Incredibly complex business logic.

My senior teammates told me it was a fascinating, complicated project. I nodded along, pretending I understood.

For four months, I contributed almost nothing meaningful. Not because I couldn't code. Because I had no clue what problem we were solving.

The domain was intricate. Abbreviations everywhere. Technical terms I'd never heard. I was building features without understanding why they mattered.

Eventually, my boss moved me to another project. He called it an "opportunity." I now realize he was protecting both the client relationship and my confidence.

The project succeeded without me. My teammates thrived because they took time to understand the business.

I failed because I never asked the product manager to spend three hours explaining what the sales team actually did.

How to Actually Learn Your Product

The solution is simpler than most engineers think: use the damn product.

Start with scenarios. Don't just click around randomly. Pick a persona and a problem, then solve it using your product.

Example: "I'm a finance controller at a big bank who needs a weekly expense report for airfare costs in the past seven days."

Now use your financial software to solve that problem. Follow the same path a real user would take. Read documentation. Watch tutorials. Click through the interface.

Take notes on friction points. Notice where you get confused. That's where your users struggle too.

Leverage Your Teammates

If you work with other functions, use them.

Talk to your product manager. Ask them: "What problems are we solving? Can you show me how users actually interact with this?"

Don't have a PM? Find a senior engineer. Ask the same questions.

Want a radical idea? Join a user call. Listen to how customers talk about your product. Get feedback directly from people who pay for it.

Talk to designers. They usually understand user problems deeply. They think about workflows and pain points constantly.

Talk to salespeople. They know exactly what the product does well and where it falls short. They've heard every user complaint and feature request.

Make Time to Learn

Spend 20% of your first few weeks learning the product you're building.

No reasonable manager will stop you from this. It's like expecting a mechanic to fix a car they've never seen before.

If you work somewhere that discourages product learning, you're in the wrong environment.

The Bottom Line

Product engineering success requires product understanding. You can't make good technical decisions without knowing what users need.

That integration my engineer built? It might work technically. But does it solve the right problem? Does it create the experience users actually want?

Without product knowledge, he can't answer those questions. And neither can you.

If you're serious about product engineering, get serious about your product. Use it. Understand it. Talk to people who depend on it.

Your career depends on it.

Want more practical advice on engineering leadership and career growth? I write about these topics every week, sharing battle-tested frameworks and real engineering war stories. Subscribe at stratechgist.com or connect with me on LinkedIn for more insights on building your technical career.

It wasn’t technical knowledge, or writing great code or being the most eloquent presenters. They had something else – a skill that multiplied everything they touched.

While everyone else focused on their assigned work, these engineers noticed the gaps. The undocumented deployment process that confused every new hire. The missing integration between two critical systems. The feedback loop that no one owned but everyone needed.

More importantly, they didn't wait for permission to fix these gaps. They just did it.

The Pattern I Couldn't Unsee

Once I recognized this pattern, I saw it everywhere.

When our API response times started creeping up, one engineer noticed we had no visibility into which component made the endpoints slow. No one asked him to build a performance dashboard. He just did it in an afternoon. That dashboard prevented three potential regressions (or eve incidents) just in the following month.

When another team kept missing deadlines, a different engineer realized the real problem: dependencies weren't tracked anywhere. She created a simple dependency mapping tool. Nothing fancy – just a spreadsheet with some automation. Suddenly, everyone could see the bottlenecks.

Neither task was in their job description. Both became critical to our success. And they didn’t have to pull heroics to do this.

They had an understanding of a fundamental truth of complex systems: the most important work often lives in the spaces between defined responsibilities.

Why Most Engineers Miss This

We're trained to execute within boundaries. Your ticket says build feature X, so you build feature X. Your role is backend engineer, so you write backend code. Your team owns service Y, so you maintain service Y. And this model works, you can get very far in your career using this approach.

But systems don't fail at the center of well-defined domains. They fail at the edges, at the handoffs, in the coordination between teams.

The senior engineer who gets promoted to staff isn't just technically stronger. They've learned to spot these boundary problems before they explode. They've developed an instinct for organizational debt – the accumulated friction from all the small gaps no one owns.

More crucially, they've learned when to fill a gap themselves versus when to build a system that prevents the gap from forming.

The Three Levels of Gap-Finding

I've watched engineers evolve through three distinct stages of this skill.

Level 1: Reactive gap-filling. You stumble across problems and fix them. The deployment breaks, so you update the docs. A new hire struggles, so you pair with them. You're helpful but tactical.

Level 2: Proactive gap-hunting. You actively scan for issues. Before starting a project, you map dependencies. During planning, you ask "what could go wrong?" You prevent fires instead of fighting them.

Level 3: Systematic gap prevention. You build systems that surface and eliminate gaps automatically. You create processes that make gaps visible before they become problems. You teach others to spot gaps themselves.

The leap from Level 2 to Level 3 is where good engineers become great leaders.

Making It Practical

Start by asking better questions in every meeting:

• "Who owns the handoff between these two teams?"

• "What happens if this person is unavailable?"

• "Where would a new engineer get confused?"

• "What are we assuming but not verifying?"

Document what you find. Not in some elaborate gap-tracking system – just a simple list. Review it weekly. You'll start seeing patterns.

Pick the gaps that block multiple people or processes. These have the highest leverage. Fix them, but more importantly, create visibility so they can't re-form.

The magic happens when you teach your team this skill. Run a "gap review" in your retrospectives. Ask everyone to name one thing that fell through the cracks. Make gap-finding a celebrated behavior, not extra work.

The Compound Effect

Engineers who master gap-finding accelerate everything around them.

Projects ship faster because hidden dependencies get surfaced early. Teams collaborate better because interface problems get addressed. New hires ramp up quicker because knowledge gaps get documented.

But the real power is in what doesn't happen. The migrations that don't fail. The deadlines that don't slip. The engineers who don't burn out from preventable friction.

Your manager notices when things just work. When projects mysteriously avoid the typical pitfalls. When your team seems to dodge bullets that hit everyone else.

That's not luck. That's systematic gap-finding.

The Meta-Skill That Matters

Technical skills become obsolete. Frameworks change. Languages evolve. But complex systems will always have gaps.

The engineer who can see these gaps – who can build bridges before anyone realizes there's a chasm – will always be invaluable.

This skill transferred when I moved from engineer to manager. It'll transfer if I switch companies or industries. It's the skill behind every other skill, the multiplier that makes everything else more effective.

Start looking for gaps tomorrow. Not because someone asked you to, but because that's what leaders do. They see what's missing and make it whole.

If you're working on developing this meta-skill and want more frameworks for engineering leadership, I share practical insights every week. Subscribe to my newsletter or connect with me on LinkedIn where I write about the critical skills that actually drive engineering careers forward – the ones they don't teach in bootcamps or CS programs.

Congratulations! You're now the proud owner of a product roadmap that makes as much sense as AWS pricing, a team of engineers who have developed Stockholm syndrome for Prometheus, and exactly zero product management support.

Welcome to hell. Population: you.

Here's how to survive without losing your sanity, your team, or your job.

Step 1: Accept That You're Now a Part-Time PM (Sorry)

Let's get one thing straight: you're not becoming a product manager. You're becoming someone who does PM work badly while also trying to do your actual job. It's like being asked to perform surgery while also doing the hospital's IT support. Now, if you’re one of those lucky bastards that you were able to manage an engineering team without having a clue about your product - tough luck.

Time to get a grip.

Start using your own product religiously. I know, I know, you probably think you understand it already. You don’t. Engineers using their own product is like doctors taking their own medicine: theoretically sound, practically terrifying. We like testing happy paths, not what our users will actually experience.

To have a chance at any redemption, block an hour daily to actually use the thing your team builds. Poking around like you're debugging won’t do you much, put in the effort to create real scenarios with actual jobs to be done that you’ll take for a test drive. For example, if you're building payroll software, pretend you're Sharon from HR who needs to explain to the CEO why the engineering team's salary budget exploded again. Walk through every painful step she would take. Feel her pain. Become Sharon.

But not Karen. Never become Karen.

While you’re using the product keep a "why does this suck" log. Document every moment you want to throw your laptop out the window. Think of this as market research disguised as self-torture. Your frustrations are probably shared by actual users, except they can't fix the code.

Make this a habit, not a one-time thing. Schedule two hours weekly for this masochism, set it as a recurring event on your calendar. Use some LLM-backed tool to generate user scenarios if your imagination fails you (it will).

Step 2: Build a Roadmap (Or At Least Something Resembling One)

A Google Sheet roadmap is infinitely better than no roadmap. And yes, I said Google Sheet, because we both know you're not going to learn how to use Jira roadmaps properly even though you’ve been using the tool for a decade. Honestly, who really knows how to use it, anyway?

You should know what your product’s/department’s strategy is. If you don’t I - brush up, right now. To avoid letting your people down, whatever roadmap that you build must map to strategy. Take whatever passes for your company's product strategy (if it exists and isn't just "grow revenue 300%") and connect each project idea to it. If you can't draw that line with a crayon, don't build it.

Once you have that laundry list of projects, find 3-5 people who won't lie to you and run your roadmap past them. Identify your most product-minded engineers. These are the ones who ask "but why would users want this?" instead of just "how do we build this?" Treasure them. They're rarer than software without LLM integration.

Also, talk to your manager (if they're competent), peer EMs who've survived similar disasters, that one UX designer who actually talks to users, or PMs from other teams who owe you favors. Their feedback will transform your roadmap from "obviously written by an engineer" to "surprisingly coherent for something written by an engineer."

Step 3: Figure Out Who's Doing the PM Grunt Work

Here's the uncomfortable truth: some projects need actual product work such as user research, design coordination, market analysis. You know, the stuff PMs do when they're not in meetings about meetings. And realistically, someone will have to do that work.

But it’d be a mistake to just dump it on a random engineer, especially if that’s not something that they want to do. So, find engineers willing to stretch beyond code. Your project leads need to understand they're signing up for more than implementing features. They'll be writing briefs, talking to users, and yes, attending design reviews. Make this explicit before they volunteer, unless you enjoy having your team quit.

Don’t reinvent the wheel, steal templates shamelessly. Don't come up with new product briefs from scratch like some kind of masochist. Find templates online, steal them from other teams, or beg that PM friend at another company. Fill in the blanks and move on. Remember: the engineering group are not PMs; you’re doing the absolute necessary work to ship something to users, not to be proud of that one product brief.

Lastly, accept that you're now a coordinator. You'll be sourcing designers, begging for their time, and negotiating with their managers. It's like being a talent agent, except everyone hates agents and the talent can quit anytime.

Step 4: Turn Your Engineers Into Mini-PMs (Good Luck)

The secret sauce is distributing the product pain across multiple people instead of concentrating it in one person (you). The truth is that the intensity with which the lack of PM will be felt on each workstream is inversely proportional to the seniority of the leader of each workstream. That’s why each workstream will need someone to bring the clarity on the problem that the workstream is solving

That’s why it’s good to partner your staff engineers with project leads for the heavy thinking work. Staff engineers are good at understanding how new features interact with existing systems, which is exactly what product managers pretend to do but with more buzzwords.

Putting the load of PM-ing projects on a single set of people can lead to overall unhappiness and kill the vibe. Rotate the responsibility. Don't burn out your best product-minded engineers by making them permanent PM substitutes. Spread the suffering evenly.

Lastly, grow your engineers to become product-minded. Trace the line between their wonderfully-architected code and the productivity of Sharon from HR, and why, as improbable as it sounds, someone pays for it. This takes time, patience, and probably alcohol. Not everyone will be good at it. That's fine, not everyone needs to be.

Step 5: Manage Expectations (Or People Will Eat You Alive)

Your team is shipping without a PM. The quality bar should stay high, but the context matters. If you don't set expectations, others will set them for you, and trust me, theirs will be unreasonable.

Do not apologize, but lead with a disclaimer. In every product review, design critique, and stakeholder meeting, mention upfront that engineers wrote the brief. This provides essential context rather than making excuses.

And when jerks come with their “feedback”, shield your team from them. When feedback turns from "here's how to improve this" to "this is terrible” it’s time for a reality check. Your engineers are already doing extra work to the best of their abilities, they don't need to feel bad about it.

Over-communicate, especially when things are going south. Use every channel available: Slack updates, email lists, 1:1s, team meetings, bathroom stall graffiti. Risk being annoying rather than leaving people in the dark.

Step 6: Build Systems or Perish

The longer you're without a PM, the more you need actual systems instead of heroics.

Document the shared PM responsibilities. Create clear role definitions for product work on each project. Write it down. Make it visible. When things go wrong (they will), at least you'll know who to blame. (That was a joke!)

Presenting and discussing with stakeholders is a valuable career skill for any engineer - so give them the opportunity to learn it. Establish regular reviews where your engineers present project status and create forums for decision making. This builds their product skills and creates accountability. Just don’t throw them to the lions - be there to support and take feedback on the chin for all of you.

Never stop using your product. The friction logging can't stop because it's your connection to reality in a job that's increasingly about managing other people's work.

The Things That You Won’t be Able to Solve

Your team can absolutely keep shipping useful features without a PM. You'll excel at improving existing workflows and solving known user problems. It’s the bread and butter of engineering execution. And it’s great, that stuff actually matters.

You'll suck at net-new product discovery, complex go-to-market coordination, and anything requiring deep user research. That's fine. Focus on what engineering teams do well: solving problems that are clearly defined.

Most importantly, your engineers will develop product skills they never would have learned otherwise. Some will discover they love it. Others will gain newfound appreciation for what PMs actually do.

The Uncomfortable Truth

Losing your PM isn't a disaster, but it's a stress test that will either make your team stronger or reveal exactly how dependent you were on someone else to think about users.

The system you build to survive without a PM will make you resilient when you eventually get one back. Your engineers will understand users better, your roadmap will be grounded in reality, and your team will be more self-sufficient.

Just don't tell your executives how well you're managing without a PM. They might decide you don't need one after all.

Want more unvarnished truth about engineering leadership? Subscribe to my newsletter for weekly reality checks that your bootcamp didn't prepare you for.

Let's connect: I share observations about the absurdity of tech leadership on LinkedIn. Follow along for more uncomfortable truths.

Here's an uncomfortable truth: sometimes you need to do a half-assed job. Contrary to popular belief, half-assing something should not indicate that you're lazy or incompetent. I see half-assing as a tool. And like any tool, it's about knowing when and how to use it.

The Two-Step Rule for Strategic Shortcuts

When you deliberately choose the quick-and-dirty path, you must do exactly two things:

Document the 'why' - Capture your reasoning, constraints, and trade-offs. Write down why you chose the expedient solution over the perfect one. Include what you would have done with more time and resources. Heck, even add the ‘ideal’ approach - what if you had unlimited time and resources? What would you do differently?

Socialize the 'why' - Share this context with your team. Make sure people understand this was a conscious choice, not an oversight. Your future self will thank you when someone asks why you built it ‘this way’ instead of the ‘best way’.

That's it. Two simple post-actions that transform a potentially career-limiting shortcut into a conscious engineering decision that speaks about your ability to make pragmatic engineering choices in an imperfect world full of constraints and hindrances.

Real-World Examples That Work

In my decade+ experience I can recall many occasions where I, or my colleagues, have made such decisions. Here are a few:

• Email Monitoring for System Health. In my early days when it wasn’t that easy to just plug in some observability library (e.g. Datadog), building monitoring was a big lift and we didn’t have the time to engineer a proper solution. So, we built a nascent monitoring system: via email. Email isn't the best tool for monitoring – OK, it’s horrible! – but it got the job done while we focussed on building core features. On advice of an experienced colleague, we documented our plans to evolve this into proper tooling later. That allowed others, who joined the project later, to consider us not that crazy.

• Shallow Performance Investigation. Due to customer complaints, a colleague had just two days to investigate performance issues. Due to external factors, setting up comprehensive profiling was not viable, so instead she focused on some obvious bottlenecks (i.e. database N+1 queries, lack of indices, data (de)serialization). She found three quick wins that improved the response time by ~30%. This way we showed our customer that we are able to act with urgency, which made them happy and bought us time to invest in proper performance optimizations. Later, when other colleagues jumped on, there was no FUD on the unorthodox way of approaching the performance analysis – they understood the constraints that the original engineer worked within and yet delivered measurable customer impact.

• Hardcoded Configuration Values. We hardcoded API endpoints and feature flags directly in the code instead of building a configuration management system. For a very early-stage system this eliminated unnecessary complexity. It was key that we documented which values should become configurable as the system matures, so future colleagues (or ourselves) did not have to lose their minds to figure this out by themselves. .

The Documentation Template That Saves You

When you take a shortcut, use this format to capture context:

Decision: [Brief description of what you built]
Constraint: [Time/resource limitation that drove the decision]
Trade-off: [What you sacrificed for speed]
Evolution Path: [How this could be improved with more resources]
Threshold: [What would trigger an upgrade to the proper solution]
Date: [When this decision was made]

An example:

Decision: Implemented email-based error alerts
Constraint: Two-day deadline to ship monitoring before launch
Trade-off: No real-time alerts, manual email checking required
Evolution Path: Move to Slack/PagerDuty integration with proper alert routing
Threshold: When we have >10 errors/day or need 24/7 response
Date: March 15, 2024

The Socialization Playbook

Documentation is not enough – it must be socialized.

Immediate Team Communication need not be fancy. Just share your decision in the next standup or team sync. Use this script: "I implemented [solution] for [problem]. I chose the quick path because [constraint]. Here's how we could improve it later: [evolution path]."

Slack/Team Chat Updates can take the same format, just post in your team channel: "Shipped the monitoring solution using email alerts. Quick context: [constraint] led me to choose this over [ideal solution]. Planning to upgrade when [threshold]. Questions welcome!"

In the codebase you can add comments directly in the code. I would suggest adding them near the top of the file so it’s easy for others to gain the context when opening the file:

# STRATEGIC_SHORTCUT: Using hardcoded values for v1 launch

# Context: 3-day deadline, 5 total config values

# Evolution: Move to config service when we have >20 values

# Decision date: 2024-03-15

API_ENDPOINT = "https://api.example.com"

Another very solid alternative is to actually use the Git history of the project. A good approach that I like to point people to is The Linux Kernel’s guideilnes on how to submit patches, which includes a guide on how to use Git commit messages to share context on the changes. It’s a perfect and extremely cheap way to keep the context of how the code evolves, without needing any supporting documentation or software.

ADR (Architecture Decision Record)

For bigger shortcuts, write a brief ADR:

ADR-042: Email-based monitoring for MVP

Status: Active

Context

Need monitoring for launch in 2 days. Full observability stack would take 2 weeks.

Decision

Implement email alerts for critical errors. Check inbox twice daily.

Consequences

• Pros: Unblocks launch, catches critical issues

• Cons: No real-time response, manual process

• Evolution: Migrate to proper alerting when team grows to 5+ engineers

When NOT to Half-Ass

Strategic shortcuts aren't appropriate everywhere. Avoid them for:

• Security implementations - Never cut corners on authentication, authorization, or data protection. Security debt compounds dangerously. Security issues have a wide blast radius – when it explodes it can be fatal to the business.

• Data integrity systems - Database schemas, backup procedures, and data validation logic need careful design. Recovery from data corruption is always more expensive than prevention.

• Public APIs - External interfaces become contracts. Half-assed API design creates permanent technical debt that affects every consumer. I always like saying “APIs are forever, once it’s out in the wild you can’t bring it back home”.

• Critical path dependencies - If other teams depend on your component, invest in proper implementation. Your shortcuts become their blockers.

The Communication That Makes It Work

When you ship the quick solution, be explicit about your trade-offs. Tell your team: "I had two days to solve this monitoring problem, so I built an email-based solution. Here's how we could improve it with more time, and here's why the current approach is sufficient for now."

This transparency prevents future confusion and demonstrates thoughtful decision-making under pressure. It shows you understand the difference between optimal solutions and practical ones.

Create a shared document or wiki page tracking these decisions. Include the threshold conditions that would trigger upgrades. This becomes a living roadmap of technical improvements tied to business metrics.

Remember: your future self is part of your team too. Document decisions so you can remember your reasoning six months later when the constraints have changed and the quick solution needs evolution.

Making Shortcuts Strategic

The difference between strategic half-assing and poor engineering is intentionality. Strategic shortcuts advance your goals within real constraints. Poor engineering ignores constraints and creates unnecessary technical debt.

Before taking a shortcut, ask: "What would I build with unlimited time?" Then ask: "What's the minimum that solves the current problem?" The gap between these answers is your strategic shortcut.

Strategic half-assing isn't about lowering standards. It's about being honest about trade-offs and communicating context so your team can make informed decisions about when to improve, iterate, or leave things as they are.

Engineering leadership means making tough calls about resource allocation and technical trade-offs. I share frameworks for navigating these decisions every week—practical approaches that work in real engineering environments, not theoretical perfection.

Subscribe at stratechgist.com for weekly insights on technical leadership, or connect with me on LinkedIn to discuss the frameworks that help engineering teams move fast without breaking everything.

When a product finally hits product-market fit, especially with viral growth, it’s exhilarating. What’s there not to love? User base growing, traffic growing, features growing, popularity soaring.

Fantastic. But there’s also the wonderful problem of scaling that pops up. This is precisely when technical foundations are tested most severely. Remember Vine? Despite its rapid user growth and innovative short-form video concept, Vine ultimately could not meet the demands and competitive pressure from its parent company, Twitter, effectively leading to its shutdown in 2017. It’s a stark example of how even popular platforms can falter when they can't overcome technical or strategic hurdles.

Inability to scale is a core business risk. Scalability failures aren't just inconvenient; they cost money, destroy user trust, halt innovation, and can cripple a business at its most critical phase. You’ve probably seen websites go down when they get “hugged by death”. You wouldn’t want that to happen to the company you’re leading/advising/investing into. Right?

Most founders and engineering leaders that I have met claim their system "scales infinitely." Outsiders can't verify this. I take a rigorous, skeptical approach to assessing scalability – not just asking “can it scale?”, but how, at what cost, and how robust.

Below, I outline the key areas I examine when assessing scalability, beyond surface-level checks. It will help you understand if the underlying tech is a foundation for growth or a ticking time bomb. I aim to get you a no-nonsense look at evaluating infrastructure, databases, and application architecture, focusing on tangible indicators of future scalability and the risks of ignoring them.

Quick Red Flags

I’ve identified a few common warning signs that you should look out for:

• No automated testing. It’s a problem, as manual testing is error-prone and tends to be slow. Manual testing should complement automated testing, not be the only available testing. Also, performance or load testing is important. "It works on my machine" or "it handles 100 users" isn't enough.

• Manual scaling – if responding to surge in traffic requires human intervention, it’s a problem. Humans are slow and error-prone under pressure. You want something like elastic scaling, where the infrastructure scales up (i.e. new servers are automatically provisioned) as the traffic surges. And when the traffic subdues, the extra infrastructure is decommissioned.

• Single points of failure (SPOF) are critical, both on the system side and on the team side. Any component where failure brings down the whole system has to be eliminated. The same is relevant for the engineering team – knowledge should be shared, documented and maintained. The exit of a single important person (even a founder) must not be a seismic event.

• Ignoring past incidents signals low-learning engineering culture. Dismissing production issues as “one-offs” invites larger, catastrophic failures down the line. A solid operational culture requires looking at the systems in place (both technological and human) and their flaws, rather than just the symptoms.

• High operational burden or toil is the bane of engineering teams. When the team is constantly firefighting instead of building features, the system is fragile under load. It requires systematic investment. Building new features in this case is useless - no one can use features of an app that goes down every day.

• Absence of a plan for growth signals that there’s no thought given to how the system will grow. Surge in popularity can bring 3 to 5 orders of more load or data, and the human-technological systems have to be prepared for such an event.

• Inexperienced team is the last sign – if the team hasn’t successfully scaled similar architectures before, it’s unlikely they’ll do it now. The leadership has to bring someone experienced right away to close the knowledge gap and bring others up.

Conversation starters to dig out these hidden issues:

1. Show me your last three incident postmortems.

2. What happens when your database goes down?

3. How do you deploy code during peak traffic?

4. What's your plan for 100x user growth?

5. Who's your most experienced engineer with scaled knowledge?

At face value these issues are manageable. But usually they have an underlying problem, which if not solved will trigger the cascading failures that killed Vine: turning a growth opportunity into a business-ending crisis.

How I think about Scalability in Practical Terms

Scalability isn't just "add more servers." Scalability is the system's ability to handle increasing load. It’s basically the opposite of “hug of death” - it’s the ability to survive the hug. But survival at any cost isn’t the goal. An expensive, barely-hanging-on system is still better than failure, but not by much. The goal is to have a healthy business with systems that scale efficiently, reliably, and cost-effectively.

Systems that require significant architectural changes or performance degradation are not scalable; they’re a liability.

To understand load, I think about it in three dimensions:

• User volume: this is not just total registered users, but concurrent users and different user behavior patterns (heavy v.s. light users).

• Data volume: growth of the database, stored files, logs, events. As the business acquires more users and more product usage, it’s key to think about the performance implications of data growth.

• Transaction/throughput load: number of API calls or requests per second, orders processed per minute, data points ingested per hour.

Where I Dig Deeper: The Foundations

In my assessment, I start with the principles and assumptions under which the system was built. For example, a popular blog is engineered for heavy read-load – new content is occasionally published, but the same content is served million of times per day. Also, I assess the traffic patterns too, because the traffic volatility assumption is baked into the foundations.

Cloud v.s. On-prem

In general, systems can run in two infrastructure types: in the cloud or managed/on-premise infrastructure. Both have their pros and cons. While the elastic features of cloud providers are amazing, they also come at a significant premium.

The alternative is on-premise or hybrid infrastructure. This means that the team owns the hardware that it runs its systems on. This could mean literal server racks in a basement or equipment hosted in a third-party data center. On-prem infra requires significant in-house expertise, capital expenditure, and manual processes to scale. I assess the team’s track record: with cloud providers you pay for that reliability, but the reliability of on-prem infra requires expertise. That expertise is essential, yet I have found that it varies wildly between companies.

Load balancing

Load balancing is essential to scaling, because it’s the method of distributing network traffic across a pool of servers. It’s the lowest hanging fruit for scaling, so I have found it as a good indicator about the team’s readiness.

As the product adoption scales, more resources (e.g. servers) will be added to handle the new traffic. Load balancers make sure all traffic is equally spread through the available infrastructure.

Additionally, traffic distribution removes single points of failure, effectively mitigating the “hug of death” I mentioned before.

Shipping Code Safely

Observability is a combo of monitoring, logging, alerting and telemetry. Observability allows the engineering team to detect the incoming traffic/load. With meaningful metrics (e.g. request rates, error rates, latency, resource utilization), the engineering team can preempt scaling issues. Lack of observability is a major scaling liability.

Shipping code under load is extremely important to scaling. The deployment process must be orthogonal to infrastructure scaling. In other words, engineers must be able to deploy new code even when the systems are under load.

The code must be tested, so deployments can be automated, i.e. via Continuous Integration (CI) and Delivery (CD) pipelines. Manual deployments under stress lead to mistakes (and downtime), so it’s best practice to remove humans from the process.

Operational posture is essential for scale. As the team adapts the infrastructure for scale it leads to infrastructure sprawl. More servers, more services, more fit-for-purpose applications. The team must have the right observability, alerting and muscle memory to efficiently handle regressions. Up-to-date runbooks are essential to operating systems under pressure.

Lastly, the infra cost model. As the infrastructure scales, the team must have a grip on how the costs scale. Linearly? Sub-linearly? Exponentially? Online you can find plenty of horror stories about runaway cloud infra costs bankrupting companies.

The Database: Where Most Scaleups Break

In my work with different scaleups I’ve noticed a pattern: the database was a bottleneck. Databases are the workhorse of many early-stage companies, so with traffic surges it’s the first piece to show cracks. A good database design will prolong the slowdown, but a suboptimal design will cripple the system the moment growth starts. This is where the 'money down the drain' scenario becomes real - I've watched marketing spend get completely wasted when databases couldn't handle the incoming traffic.

The Right Database For the Problem?

Choosing the right database is tricky. Plenty of options to choose from, from the typical relational databases, to document databases (i.e. NoSQL), to specialized time series or search-optimized databases. Yet, the scaling ability of an early-stage product is a function of the database(s) design and the underlying technology.

Each database type has its own scaling challenges and trade-offs. The key is matching the technology to your data patterns and growth trajectory. When I see a mismatch - like trying to scale a social network using a relational database instead of a graph database - it's a red flag.

Choosing the right database type is crucial to the scaling success of the product, especially in those early stages. Here, I trust my gut. When I see a mismatched database choice I dig in to uncover the red flag, if any.

Schema Design & Scaling Strategies

Schema design and indexing are important scaling topics. The way the schema and the indices are set up to support the heaviest queries will affect the scaling. For example, efficient indexes help with fast retrieval of data on large datasets (e.g. think about using the index of a book versus scanning page by page to find something in a book).

Battle-tested database scaling strategies that you should look for:

• Read replicas, i.e. multiple replicas for reading from and one main replica to write to, with proper read-after-write consistency patterns. It eliminates the read bottleneck, as it spreads the load from applications reading data. It’s a tried-and-tested scaling strategy – one scaleup I worked at served 10 million monthly active users just with this strategy.

• Sharding and partitioning are common scaling strategies, which involve splitting the database tables/collections based on a sharding key(s). It’s a tad more complicated pattern, as it requires good thinking before choosing a sharding key.

• Caching is popular, but I’ve found that in practice people do it poorly. Lots of frameworks/tooling make caching easy, but teams’ cache invalidation strategies are suboptimal. I have seen a team being forced to allocate four engineers to clean up a caching mess for 6 months. All due to bad caching decisions made years ago. In one team I worked at, we had to completely rethink caching which led to a few months of caching configuration rewrite.

There are other aspects to databases I consider, such as data lifecycle (e.g. archival or data purging), or concurrency and isolation. But those are a bit more advanced topics and tend to be relevant for more mature startups.

Application Architecture: The Code's Resilience

With infrastructure assessed, I examine the application architecture.

In my experience, finding the application’s architecture as a bottleneck is tricky. A suboptimal architecture allows for lots of scale. Yet, the wrong architecture will severely damage the app’s ability to scale. Therefore engineering teams always find it difficult to pinpoint the scaling issues on the architecture, as they’re more difficult to measure (e.g. when compared to other components).

Commonly, there are two types of architecture: monolithic and service-oriented. As a high-level observer of the field, you don’t need to get into the weeds of the different subtype of architectures, just knowing these two is sufficient.

Monolithic architectures can become a scaling bottleneck if components can't be scaled independently. It can suffer from shared resources or tight coupling between modules. Not all modules scale the same way, i.e. with an app going viral the landing and registration pages will take a massive hit compared to the in-app messaging system. The monolith’s inability to scale out modules separately can be a headache for the engineering team.

On the other hand, services offer independent scaling, but introduce complexity. Lots of it. Some examples are service-to-service communication, data consistency, distributed tracing, and more. A team that is investing into services needs an overarching vision and principles in place, otherwise they end up in Uber’s 1300+ microservices land.

Team Readiness for Scale

The most elegant architecture won't scale reliably if the team isn't capable of building, deploying, and operating the system under pressure. Scaling isn't just code; it's people, processes and discipline.

Startups tend to employ younger folks, but I don’t care about age. I care about the experience. I avoid the ageism trap: age doesn’t guarantee experience or expertise. I identify whether the core engineering leadership and senior technical staff have experienced individuals who have worked on scaled systems. The "scar tissue" from past scale-ups teaches them the non-obvious pitfalls and operational rigor that less-experienced folks lack.

Digging into the engineering leadership further: the top engineering person (e.g. CTO). Their credibility must be good. Sure, everyone’s done missteps, but as long as they haven’t done a Wirecard-shaped drama – acceptable! More important: can they articulate specific bottlenecks? Do they know their database connection pool limits, memory ceilings, and network throughput constraints? Understanding where the scaling bottlenecks are allows them to balance short-term needs with long-term scalability.

The best team maturity indicator is the incident and operational posture review processes. Issues will pop-up when scaling up, so how the team responds to and learns from those issues is critical. Signs of a mature team look like an organized incident remediation process, where roles amongst folks are clearly delineated. I look for leaders managing comms and coordination, while engineering is focused on mitigating the incident. Chaotic firefighting and finger-pointing is a sign of an immature team. What happens after the issue is mitigated is important: is there a blame game, or is the team writing blameless postmortems as a learning medium.

A team that learns from failure is better equipped for the future.

The Verdict

Taking all that we’ve covered so far, when I need to form a judgement I bucket my findings into three categories:

1. Built for scale, meaning, the system I’ve audited has scale as one of its guiding principles and can scale well with a surge of popularity/traffic.

2. Scalable with some effort. This means that the system is generally sound, but I’ve identified bottlenecks or areas where significant effort is required so the system scales well. Usually these are database replicas, elastic scaling (if in the cloud), improved monitoring and alerting. Fixing these requires a clear roadmap and a group of individuals/team to work on it. Typically, most of the systems I’ve worked with are in this bucket.

3. Fragile, will likely crumble. The system has fundamental flaws that cannot be easily fixed to scale without significant rework. This system will struggle or fail under significant traffic/popularity surge. If the system is in this shape, assuming I can, I strongly suggest to leadership to invest resources in this area. Otherwise, any money spent on marketing to bring people to the product will go down the drain once users start trickling in.

At all costs, I avoid the trap of "Complete Rewrite". As an outsider, it’s difficult to make such a damning call. Sure, there are times a complete rewrite is necessary. But they’re also very costly and risky. I assess if targeted refactoring and incremental improvements can suffice, or if the foundation is truly rotten. If I can’t assess that, then I steer clear from suggesting rewrites as they can backfire.

Liked this article? Make sure to ❤️ click the like button.
Got thoughts or feedback? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to 🔁 share this post.

Want more? Here is how I can further help you

• Need technical due diligence or advising? Drop me a message on LinkedIn or at the email below.

• Get one of my ebooks here.

• Sign up for 1:1 mentorship, resume feedback, career strategy or an AMA session here.

Get in touch

You can find me on LinkedIn or BlueSky.

If you wish to make a request on particular topic you would like to read, you can send me an email to blog at ieftimov dot com.

The sales team promised: “if we had reporting, this big user would sign a 5 year contract”. I prioritized the reporting functionality, we shipped it, user signed, a success all around. Months later, the user discovered a bug – reports were wrongly aggregated if they straddled more than one calendar year. I didn’t want to prioritize the bugfix because it was a rare use case, and this was the only report of it. “Just tell them to combine multiple annual reports in Excel,” I told their account manager.

She agreed. We both moved on, at the chagrin of the user who signed this 5 year contract.

Software development constantly generates imperfections. Not everything can or should be fixed. No one has unlimited resources, if you’re a team leader you know this firsthand. It’s difficult to prioritize a bug that affects a handful of users over new features that will drive more adoption.

After a few years of prioritizing features, you get a laundry list of bugs that at some point you will have to take care of. As a leader, you’ll have to decide when. If you don't, the alternative is wasted effort on low-impact fixes, critical issues festering, and team morale drained from neverending backlogs.

Every team needs a conscious, strategic approach to managing bugs. You need a framework. Let me tell you about mine: the three Fs. It stands for “Fix, Flag or Forget”. Yes, forget, as in leave it broken.

The Framework: Fix, Flag, Forget

The “three Fs frameworks” categorizes any issue/bug in one of these three buckets:

1. Fix It (now or soon). It means I prioritize the bug for resolution in the near term (hotfix, current/next sprint). This implies the value of fixing outweighs the cost.

2. Flag It (for future consideration). Bugs that end up in this bucket must be acknowledged and documented. This category gives me the room to defer the decision to fix, while slotting it in a tracker. Tracking bugs requires a system (or at least a tool) for tracking and a cadence to revisit the tracker. It’s critical that the team must not treat this tracker as a dumping ground for all sorts of bugs and issues.

3. Forget it (or in other words, consciously decide not to fix): I make an explicit, documented decision that the cost/risk of fixing outweighs the benefit for the foreseeable future. I consider “forgetting” a bug as an active choice, and not neglect.

Let’s dig further into the factors that I look into when making the decision in accordance with the framework.

Key Decision Factors

Impact

First things first: impact! Impact is communicated as ‘severity’, a proxy for “How bad is it when it happens?”. The severity of an issue is a wide spectrum. I’ve seen issues ranging from minor user annoyances to system crashes and data loss.

Each bug has an associated business cost. It comes in two flavors: quantifiable and qualitative. In my experience the quantifiable is easier to dig out as it comes as one (or a combination) of the following:

• Lost revenue

• Support costs

• Compliance failure

• Reputational damage

• Productivity loss

The qualitative is the user's pain. My own proxy for it is “how much of the user’s day have we ruined” by them running into the issue. The qualitative cost manifests as frustration, confusion, yelling at support agents, and difficulty with working around the bug itself.

I consider these factors essential when assessing the impact of any bug or regression, as they will allow me to better prioritize the fix.

Effort & Cost

Every fix has an associated effort, which affects the cost. The cost to fix exceptional issues with high severity – e.g. showstoppers – is irrelevant. In all other cases the cost is essential to prioritising a fix.

I find engineering cost estimates most useful, when they are expressed in time (i.e. hours, days) or story points (if the team’s process is Scrum-y). As a leader of a team I take understanding the effort to fix a bug very seriously. We all have limited time on our hands and we have to be careful how we deploy it, so having a good understanding of the effort is essential to prioritize well.

The cost of the fix has correlation with the complexity of the issue at hand. A simple tweak (e.g. copy change) can take minutes to fix, while a structural problem that requires a major refactor can take months. The complexity of a fix is also related to the knowledge required to implement the fix – some fixes are small only to the engineers with specialized knowledge. Picking the person with the right expertise to execute (or oversee) the fix can influence the cost of the bugfix.

Another factor that complicates a fix, and increases its cost, are dependencies. Issues can span multiple systems, services or products. For example, a bug that caused by a timestamp field without timezone support requires a fix in the service backend, a change of the column type in the respective database table, a proto schema change, and bumping the protobuf schema versions on downstream services to adopt the new field, and rolling out all of those services one by one.

To complicate things further, this long chain of changes and dependencies can get blocked. It doesn’t have to be a huge blocker - even a service deployment lock due to an unrelated incident can postpone the bugfix hitting production by hours, days or even weeks.

Finally, I lke to consider the blast radius. Major fixes like refactors are risky. Without excellent test coverage they can introduce new, worse problems, destabilizing the system. I prefer fixes with surgical precision – small, targeted, low-risk changes, easy to test and revert – instead of open-heart surgeries. Precise fixes are low risk.

Strategic Alignment

When it comes to fixing bugs, as engineers we don’t always think about how strategically aligned these fixes are to the current or future goals. More interestingly: does not fixing them block our goals? If a bug is of low impact and it’s not strategically aligned with the product’s direction, then it’s difficult to justify prioritizing it.

Also, the issue might distract the team from higher-priority strategic initiatives. If the team doesn’t have the bandwidth then maybe the bug should not be prioritized now (or ever?).

Sometimes even though there’s no strategic alignment, there might be technical alignment. Some bugs are related to technical debt. In such cases, the bug should be used as additional fuel on the fire to prioritize fixing it, as it’ll be a double whammy – you’re not only fixing a bug, but you’re also paying down debt. I have witnessed bugs that popped up in legacy parts of the system and it’s always neat to use said bugs as an excuse to migrate (part of) the system to newer foundations. As an engineering leader, it’s easier to justify a migration when it’s related to a regression.

Future Implications

Bugs can regress the system over time or over a different dimension (e.g. traffic, load). In the past I’ve launched a new API with a memory leak. In the first days the leak’s memory impact was negligible. But after a couple of days it was completely depleting the server’s memory. We observed that as the traffic grew, also the leakage got bigger, so we not only had to reboot the server every day, but also to sty vigilant for days with elevated traffic. Eventually, we found the leak and fixed it.

The example shows how an issue can creep up and get worse over time or with the increase of use. If we didn’t have good monitoring in place the memory would leak out and the operating system’s OOM killer would reap the server process, leading to downtime.

Issues such as the memory leak also have a delayed cost. The more complex a codebase becomes the more difficult it will be to root cause the leak. That’s why it’s better to work on such issues sooner rather than later.

Worse case scenario would be if such issues become a blocker for new feature development. In other words, neglected issues halting innovation. A nightmare.

Deep Dive: When to ‘Fix It’

As software engineers we all build the intuition when an issue has to be fixed now v.s. later (or never). As an aspiring engineering leader I’ve been thinking about codifying this: a set of practical criteria when to characterize an issue as a must fix now.

Here’s my loose categorization:

1. Critical production bugs. These are issues that “brick” the system. Showstoppers. They block some core functionality, might bring the system down, lead to data loss or data corruption.

2. Security vulnerabilities. In my opinion, any vulnerability must be fixed with high urgency as it is good engineering hygiene. I might be biased as I’ve worked in fintech, where vulnerabilities lead to big liabilities. Contingent on your domain, your tolerance to security vulnerabilities might be higher.

3. Compliance/legal mandates. Smaller compliance mandates, like amending terms of service, can bring liability to the organization hence it’s good to prioritize them now instead of later. Larger issues, like failing audits or violating regulations result in incidents, which beget a broader and better defined process than just a bug fix.

4. Directly blocking high-priority projects. Bugs that block or hinder projects are easy to prioritize, as the bug’s impact is directly felt by the project and the people involved. Often the blocked team itself will gladly fix the bug to unblock themselves.

5. Significant, measurable business impact. I like to quickly prioritize bugs that create measurable business impact. Some examples include high support ticket volume, direct revenue loss or severe reputation risk for the company. For example, I have worked on products that have gotten criticism on Hackernews’ front page. You want to jump on fixing that thing right away.

6. Rapidly escalating issues. Problems that clearly get worse on their own should be prioritized to the ‘Fix it’ category. An example is the memory leak issue I brought up earlier. This class of problems is especially tricky – if left unchecked they can morph into one of the other categories above.

Any of the above should end up in the ‘Fix it’ category. But just prioritizing them is not enough. Teams must build a muscle to react to this class of bugs; for example:

• Teams have a week-long rotation where an engineer takes one-off work (e.g. user queries, bugs). This engineer can just jump on the issue once it’s been prioritized as ‘Fix it’.

• If no rotation exists, I look for volunteers. Seniority, domain knowledge (where the bug is) and availability are important factors. I don’t want to dump work on someone who already has a full plate. In cases where there is only one subject matter expert, I pair the expert with another engineer to share knowledge.

• The type of issues that provide some grace period (e.g. compliance/legal mandates), can be tackled in dedicated bug-fix sprints in combination with other less-urgent bugs.

The bottom line is that any engineering team must have the mechanisms to tackle important bugs rapidly, with as little interruption as possible. The leader(s) of the team must protect the team during that ordeal and communicate outwards (i.e. stakeholders and leadership) about any side-effects to ongoing projects.

Deep Dive: When (and How) to Flag It

Flagging is great. It allows you to acknowledge a bug yet defer its fixing. But it can be a trap. Flagging can turn the backlog into a graveyard where tickets go to die. To avoid the graveyard situation flagging must be an active bug management process, not a knee jerk reaction.

Here’s my categorization for flagging:

1. Low-to-medium impact bugs. These can be annoying to users, but must have workarounds. They must not affect a large % of the user base. If they do affect many users, then they must be cosmetic of nature.

2. Known tech debt. Not currently blocking, but identified as needing attention eventually. Requires specific designs and planning phase as the solution is often open-ended.

3. Feature enhancements disguised as bugs. Oftentimes users expect a feature to work in a particular way, which they flag as a bug. In fact, the slightly different behavior is essentially a small feature request.

4. Issues requiring significant effort/planning. Issues that are too complex to be fixed immediately. These can be issues that span multiple systems or product features, which requires research, design and alignment across multiple teams or functions.

5. Issues dependent on future work/refactors. Sometimes it’s just not possible to fix a particular issue without first completing another work item.

As I mentioned before, flagging is tricky. To be effective you need a tight process and to be a bit dogmatic in following it. If you end up skimping on hygiene your backlog will soon overflow with bugs that you don’t even remember why they’re there in the first place.

Here’s what effective flagging requires:

1. Clearly documented issues. The foundation on which every issue/bug stands on is reproducible steps. If the fixer is not able to reproduce it, the ticket is worthless. The impact assessment must be present (using the factors above!). It’d be nice if the author considered potential solutions, but not required as the solution space is ownership of the team. The estimate (even rough) should be filled in by the engineering team. Links between related tickets should be established, and duplicates (if any) must be closed.

2. Meaningful prioritization. Labeling in my opinion is the lowest hanging fruit to ticket segmentation. You need nothing fancy, just fix-it-later as a label is enough. I’ve seen teams use dedicated backlog sections for these tickets (e.g., "Tech Debt Backlog"), which works also OK.

3. Regular review cadence. Flagging is not enough, the flagged tickets need to be groomed. I like to set dedicated time (i.e. a reminder on my calendar) to review flagged items. Questions I consider: Has the impact or the cost changed? Does it align with upcoming goals? Then, I force a decision: Fix now, Leave Broken, or Keep Flagged (with justification).

4. Set an owner. I like to assign owners or area stewards responsible for championing important flagged items. For example, if I have performance issues lingering on the backlog, I dedicate someone passionate about performance to be the performance champion of the team. They will monitor and escalate the tickets, when relevant.

The bottom line is that any engineering team must have the mechanisms to flag issues with consistency. Allocate specific time for reviewing flagged items. Resist pressure to fix everything immediately if it doesn't meet the "Fix It" criteria.

Deep Dive: When to “Forget it”

Sometimes, the best decision is to do nothing. As a lead, what I always make sure to highlight is that deciding not to fix something is not neglect but a strategic non-action. This requires courage and clear communication, to your users, your stakeholders and your leadership.

When to leave things broken:

1. When the impact is negligible. Extremely rare edge cases, or bugs that affect zero or near-zero active users, or that are purely cosmetic in a non-critical area.

2. Astronomical cost or risk to fix. When the fix requires rewriting half the system, or involves significant downtime risk, or uses niche skills no longer available. The ROI is deeply negative.

3. Deprecated feature/system. The issue exists in a component that will be phased out soon. Basically, a wasted effort.

4. Strategic pivot. The business direction has changed, making the affected area irrelevant.

5. User adaptation. Users (or you) have established workarounds they are comfortable with.

As a leader, to decide to leave something in a broken state is not just closing the Jira ticket as “Won’t do”. The decision requires auxiliary artifacts so people (including your future self) can refer back to them whenever needed.

Here’s what I suggest:

1. Explicit documentation. Record why the decision was made, the assessed impact, and the date of the decision. This prevents re-litigation unless circumstances change. My team has a decision log (literally an append-only document) where we write down these decisions and put our signature in support of the decision.

2. Monitoring, if needed. If you anticipate that there's a risk the issues could get worse over time, it’s best to monitor the frequency and the impact. It’s best to have an automation that would create a ticket or a ping via chat (e.g. Slack) so the team can take action. Consider alerts, but be very conservative with pages.

3. Clear communication. As a leader, you have to inform relevant stakeholders or users about the decision and your reasoning. And be ready to defend the team’s decision while being receptive to feedback.

Common Pitfalls to Avoid

As with any framework, there are some pitfalls that it’s easy to get into if you do not apply critical thinking to your use of the framework. Some examples:

1. The ticket graveyard. Flagging issues without a thorough review process, which results in your team’s backlog turning into ticket backlog that no one ever cleans up.

2. Fixing trivial things. Wasting time on low-impact issues due to noise or the temptation for an "easy fix". This is like snacking: you’re taking in calories that don’t really feed you well.

3. Ignoring hidden costs. Underestimating the long-term impact of tech debt or annoying bugs on developer velocity and morale.

4. Analysis paralysis. Spending more time debating regarding the bug and its fix, than what it would actually take to fix it.

5. Poor communication. Making decisions in a vacuum and surprising stakeholders, users or leaders.

A Visual Heuristic to Making the Call

A simple visual that should help you, as a leader, make the right call:

It’s useful to remember that it’s not just about making the call as the leader. Such decisions should not be made unilaterally. Great leaders facilitate a discussion between the different functions impacted by the issue, and drive to a win-win conclusion.

No decision made is forever. Especially when it comes to flagged items - you must build mechanisms in your team to revisit flagged and "left broken" decisions periodically. Time moves on, users’ need changes, the business evolves so what was true a year ago might not be true anymore. Your decisions require iteration, too.

Liked this article? Make sure to ❤️ click the like button.
Got thoughts or feedback? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to 🔁 share this post.

Want more? Here is how I can further help you

• Need technical due diligence or advising? Drop me a message on LinkedIn.

• Get one of my ebooks here.

• Sign up for 1:1 mentorship, resume feedback, career strategy or an AMA session here.

🎁 3 Templates to Immediately Put This Framework In Action

Read more

Intro

Our head of engineering set the date. Users were interested, and the opportunity seemed perfect. Yet, our codebase was not ready for it. The architecture was simply not ripe for the extension we wanted to build. But we had to go fast. We all knew we would incur debt.

We’ve all been at the crossroads of speed and technical debt. The pressure to ship features and maintain code health (or, keeping tech debt at bay) is universal, especially during critical launches. It's not if you’ll incur it, but how you navigate it. It’s always difficult to strike the right balance, even if you’ve walked the tightrope between meeting aggressive deadlines and not tipping over the system, many times like myself.

This is not a theory. It's a breakdown of the practical framework and tactics used in a specific, high-stakes situation to make conscious trade-offs and survive the launch (and its aftermath). No magic, just deliberate choices.

The Perfect Storm

The product I worked on was an enterprise loyalty points calculation API. Originally, the same functionality was included in another, broader loyalty program management API. But while going to market we learned that our users didn’t really want a whole product (API) to manage loyalty programs programmatically. They all already had in-house or purchased software that did this for them. Yet, multiple potential users were interested in the points calculation API, as it was one of the features that was difficult to build well.

Upon sunsetting the broader API, we were left with a choice: do we leave the opportunity to go waste, or do we act on the signal from our users?

Myself and my product manager were adamant: this was our opportunity to show the world our smart points calculation algorithms. The signal from the market was solid, we need to use the momentum. Despite initial skepticism, the overall team showed support for the idea.

We kicked off a small development team: three engineers and the product manager, supported by the engineering manager. One senior engineer with decades of experience and a very strong understanding of the domain. The other two were a newly hired senior and a junior engineer. Still, both were technically excellent. The PM was the best in his group, hands down.

The deadline? It was January and we had 3 months to launch the product in private beta. We had users who committed to adopting the new API by Q2, as their business was seasonal and they wanted to use the new loyalty points calculation API when the new season starts – sort of a clean cut off. Doable, but aggressive.

Our existing monolithic codebase, while reasonably organized, wasn't designed for this public API. So, here’s what we were looking at: building a new API, on foundations that never previously supported a public API, with architecture that had to be pried open just enough so the new API would fit, while keeping all other calculations and other functionality operational and working without regressions, while serving over 20,000 users every day. Fixing the debt or reworking the architecture was simply not an option on the proposed timeline - we barely had time to get the basics out by the deadline, architecture work would take many more months.

We decided to bite the bullet, all to not let the prospective users down.

Conscious Choices, Not Accidental Outcomes

Now that we knew that we’ll have to cut some corners, I wanted to put down some principles / framework around it. After going through similar experiences in the past, I’ve found the following four principles that are key to hitting ambitious milestones when you consciously know you will incur debt.

Principle 1: Radical Transparency & Shared Understanding

As a leader, it’s easy to convince yourself that “it won’t be too bad” if you incur some debt. Especially if you’re in a position of authority, your engineers might not even be willing to push back on you. And you’ll think to yourself “if they don’t say anything, it’s probably fine”. While at the same time, they might be fuming about a manager who seems oblivious to the consequences of incurring debt.

That’s why it's key to be radically transparent and open to receive feedback. During the initial phases we had discussions about the debt, the risks, the deadline, and the plan. No sugar-coating. We knew we had to take some shortcuts, and we had to make it abundantly clear to ourselves why they had to be taken.

Practically, I’ve found as an engineering group it’s good to have alternatives. For example, we thought that cracking open a particular class and shoving the API parameters to it was one option. It was viable, but the debt that we’d incur there was astronomical. We challenged ourselves to look elsewhere. Was there perhaps a higher layer in the call stack that could take the API parameters, massage them to appear as if they're just an internal struct, and then pass it down the calculation bit?

Externally looking, we were under a lot of pressure to deliver by our stakeholders. Large users were waiting to use the new API, which would open new revenue streams for our product. This made our business partners willing to move mountains for us. But with that, the pressure was climbing. In high-stakes situations, as leaders it’s on us to be brutally honest about the risks associated with the speed and the debt. I went to our stakeholders and explained that the tradeoff we’re making is that if we choose to not pay the debt, we risk the possibility of severe UX issues down the line (e.g. instability, incidents), effectively losing user trust.

Once senior leadership understood the risks and accepted that this debt must be paid, we were able to proceed with execution.

Principle 2: Ruthless Prioritization via Risk Assessment

All debt is not created equal. Some of it is easy to take on, other not so much. To be able to understand the debt better I like using a simple matrix:

On the X axis, we have an impact on launch success or stability. This reflects whether the debt in question will be a direct threat to the launch functionality or stability. On the Y axis, we have the effort to quickly address the debt. In other words, can the debt in question be fixed/mitigated with reasonable speed.

The way we used this matrix is:

• When the debt is high impact and low/medium effort – we have to fix it, it’s non-negotiable.

• When the debt is high impact and high effort – we have to mitigate / contain it now. We asked ourselves, how can we isolate it? Would adding monitoring do the trick? Feature flag the related area carefully? Delay fixing fully until post-launch, but actively manage the risk.

• When the debt is medium impact and low effort – fix it if the time allows. Basically, a potential stretch goal,or assign if someone is having some downtime or if a new person is ramping up on the project.

• When the debt has low Impact and is of effort size – we’d log it and defer it for later. We explicitly added such debt to a post-launch backlog that we didn’t touch until much later.

Principle 3: Define a Specific, User-Centric "Good Enough"

Perfection is the enemy of meeting an aggressive timeline. So, we thought of what good enough means for us. The nature of the new API did not suggest that it required substantial performance or reliability profile - it was a loyalty points calculation API after all. But that doesn’t mean that we didn’t care about reliability at all. Loyalty points are currency of its own, so users do feel strongly about having their points correctly calculated and have them appear quickly enough on their profiles so they can immediately use them.

“Good enough” should not be arbitrary. It must be rooted in your users’ needs. In our case it meant:

• Loyalty points calculation must take less than 1 second at the p99. In other words, we wanted 99% of the requests to be fulfilled at 1 second maximum. We identified that 1 second is enough of a sweet spot for private beta by talking with a single user. n=1 is certainly not representable of all users, but it was enough to get us started.

• We were peaceful with an availability of 99% - it meant that for private beta we would tolerate ~14m of downtime daily. This was acceptable because we would have few beta users, who have a good relationship with us and would be understanding to any service degradations during beta.

• The core calculation path had to be functional, any auxiliary functionality or polish could be safely ignored for the private beta phase.

• Test coverage had to be good. This was essential because it’d allow us to continue safely expanding the API once we’d hit the private beta milestone. If we would ignore tests then it’d be almost certain we’d introduce regressions when we’d expand the functionality of the API.

• The API documentation had to be sufficient for any new user to be able to onboard themselves, but it’d be accessible only for beta users. The docs availability being limited meant we could ship unpolished docs.

• No support for internal tooling, simply emitting log lines for some debugging of beta usage.

Principle 4: Isolate Problems, Don't Chase Perfection

During crunch phases, it’s important to focus on reaching the milestone. Driveby refactoring or fixes must be punted for later. If a particular service or a module is problematic, fixing it would be an anti-pattern. In such cases it’s best to isolate it. This can be a module or a service or any other dependency on the code that you’re writing. In such events, we focussed on putting a facade around the problematic module.

I remember a particular class which tried to just do too much and it was difficult to split up into multiple classes. What we decided to do is to write a wrapper around it, that would encapsulate the complexity of the difficult class which would result in the new API path to be reasonably clean. The idea being once we can clean up the complex class we can just completely drop the “mediator layer” between the API method and the complex class.

We had layers of problematic code that we had to keep the urge to refactor at bay. This was easier said than done, as all of us had the urge to clean up stuff a bit. To make this easier for the group, I proposed a rule: refactoring will be strictly limited to work that directly unblocks items on the critical path, or demonstrably reduces immediate launch risk. Otherwise, it’s slated as a follow-up.

Tactics on the Ground: Making it Happen

Now that we covered the different principles and the context, let’s see how we operationalized the tech debt management in practice.

The IOU List

To manage debt that we incurred, we virtually had an IOU list of tickets. The whole point was to have a list of debt that we have deferred to later, once we reach the private beta phase. These lists have to be visible for everyone, that are agreed on by everyone in the team (that includes your product counterpart as well). As leaders, it’s on us to make this visible and make it top of mind as we go. Adding a new item to the list should be publicly acknowledged, so all stakeholders are aware of the tradeoffs we (the engineering team) are making.

Each ticket should include:

• What it is

• Why it was deferred (link to risk assessment)

• Potential impact

• The explicit commitment to address it post-launch (maybe even rough sizing/timeline)

This isn't just a backlog; it's a documented agreement.

In addition to that, we had dedicated "debt triage" meetings. These were short, frequent meetings (maybe 2-3 times/week initially, daily closer to launch) with tech leads, senior engineers, and potentially the PM.

Surgical refactoring

In line with principle 4, we avoided unnecessary refactoring while in crunch. But, on a few occasions we had to perform targeted refactoring, or as I like to call them “surgical strikes". One such example was refactoring the inputs to the loyalty points calculation class, where the main logic was encapsulated. Because of layers of debt in there, the parameters coming from the API had to be transformed into the parameters that were accepted by the calculation method. While we had an engineer write out the logic, in the changeset it was evident that the parameters parsing and morphing was very involved. Not only that they had to patch in some messy logic, they also had to add hundreds of lines of tests, which very clearly told us (yelled at us?) that the class was doing just too much.

Together, while looking at the changeset, we decided that we had to break the fourth principle and do very targeted refactoring. We tasked the engineer who wrote the changeset, accompanied by another engineer, to draft up a quick design on how the refactoring would look. It wasn’t just about writing the code, it was also about rolling it out before the other changes go out. Refactoring such as this one could not be shipped together with the new functionality. To have a targeted refactoring we also wanted to have a controlled rollout - that way, if the refactoring introduced any regressions it would be very easy to catch and fix.

Eventually, the targeted refactoring worked out and we were able to have a simpler abstraction and encapsulation of the API parameters parsing, morphing and passing down the call stack into the internals of the calculations.

Operational Readiness

When leaving some debt in, one thing I’ve learned is: instrument everything. Things that can go good, but especially things that can go bad. We had dashboards on top of that instrumentation, that allowed us to observe the system as it works. It’s crucial to have alerts for any anomalies, and pages if things really go south. It’s essential to be alerted when things start falling over completely. By having these dashboards and alerts, you will have the confidence to defer some fixes.

But monitoring and alerting is not enough of a precaution. It’s essential to have tight controls on the rollout of the changes. That’s why we used feature flags everywhere. They’re not just for new features, they can be leveraged also for new codepaths, or new branches of code path execution that you’re not feeling great about. Using feature flags allowed us, on multiple occasions, to disable problematic sections or fall back to older (stable) logic where necessary without having to push new changes to production.

Testing

Before making changes to existing code, one thing we did was solidify the existing tests. In our case we had test coverage data for the particular modules that we would be changing, so we knew which parts are lacking code coverage. If you ever find yourself in a similar situation where you need to be strategic about the tech debt that you incur, use some analysis tool to surface test coverage. It’ll be eye opening, trust me.

Once we knew which parts were under-tested, we started with beefing up the test coverage in those part of the codebase. Once we were at a healthy level – no, we didn’t strive for an arbitrary 100% – we began our changes. These are three areas where we were quite pedantic about having good tests:

• New critical path functionality.

• Areas where debt was deferred (especially high-impact).

• Key integration points

But, even when being pedantic we also had to remain pragmatic. We agreed that accepting reduced coverage is OK as long as it’s temporary. If we had to accept reduced coverage, we agreed that we would spend a bit extra time on manual/exploratory testing focused on those areas. Plus, we would flag the lack of tests by adding a ticket to the IOU list.

Changing code, carefully

When making changes in brittle modules, it’s essential to maintain rigor. Especially in critical/risky hotspots. Abundance of caution is essential – what we did in such cases is have a primary and secondary reviewer for the changeset. The primary would do the review as normal, while the secondary would try to find any quirky spots or secondary effects that are not immediately obvious. Changesets that were authored via pair-programming, required only a single reviewer.

But all changesets do not require the same scrutiny. We noticed that quite quickly. So we went with a nuanced approach - if a change has a lower risk profile, then a quick review from one person is sufficient. The key here is not to be dogmatic (“two reviewers must review!”) but rather to be pragmatic and leverage extra pairs of eyes selectively.

Lastly, in changesets where debt was ignored (or, worse, introduced) reviewers had to explicitly call out the debt, usually via a comment: “Peaceful with the debt here, logged IOU #123 as follow-up”. That way all debt is accounted for and it’s consciously agreed upon between the author and the reviewer(s).

Navigating the Crunch: The Final Weeks/Days

In the last few weeks until the deadline it’s typical for engineering teams to cut more corners than originally planned. The extra corner-cutting stems from a combination of time pressure and engineers being torn by other responsibilities (advising in reviews, coordinating, meeting XFN partners, etc). In these phases, as an engineering leader, it’s paramount to keep the team focussed on the prioritized tasks. At any last minute attempt of scope creep or a meeting that popped up on their calendars, I jumped in to defend the engineering team’s focus.

By looking at your team’s focus and how they expend their energy, you also support their morale. It’s important to acknowledge the pressure, take things off their plate, especially if it’s of lower priority. I remember the engineers being pulled into interviews which were a distraction from the crunch. In such cases, I chatted with the recruitment manager, explained the situation and agreed with them to take the engineering group off interview rotation for 3 weeks.

In cases of issues or blockers, it’s important to have a swift escalation playbook. What we did is for non-strategic blockers (e.g. blockers on code level) I trusted the engineering group to self-unblock. If there were bigger problems, I gave the team the permission to spin up an near-instantaneous meeting and pull in me (the EM) and the PM of the team at will. Luckily, we had none such instances.

Finally, as leaders we have to stay away from the negativity and the pressure. To do that, I really like celebrating milestones, even though they might not be the big thing that we’re pushing for. For example, I started communicating outwards our progress every time we had a little win. The little wins are not the finish line by any means, but they boost people’s morale. People like seeing their work being celebrated, regardless of its size. And in crunch time, keeping the morale at a solid level is essential.

The Aftermath: Reckoning and Recovery

After hitting the private beta milestone it was time for a celebration and taking stock of the next steps. Our first user started using the API, and they had no notes. A resounding success!

Once we were done yelling from the rooftops about the successful private beta, it was time to start scheming what’s next. First, a quick retrospective: what worked, what didn’t? We held a blameless post-mortem focused on how the debt vs. delivery balance was managed.

Then, it was time to roll up the sleeves. The engineers put lots of trust in my promise that they will get the time and space to fix the debt after we hit the beta timeline. The chickens have come to roost.

I allocated the next three weeks to start tackling the high-priority items from the IOU list. Three weeks wasn’t much, so I gave the option to extend the cleanup period if necessary. Collectively we decided that three weeks is a good start. To me, demonstrating that the commitment to address the debt was real was of highest priority. It’s how you build trust with your people. I also publicized the progress on debt reduction as the team was making progress in the form of status updates.

Another thing we thought about is: how can we avoid accumulating this type of high-risk debt again? As I shared above, we learned a few lessons about continuous tech debt management that we try to carry forward to this day. (See the “Tactics on the Ground” section for a refresher) And of course, pacing. If you strive to be an engineering leader, you have to continuously look for the balance between development pace and quality. In my experience the pace grows linearly with the technical debt. Be intentional with it.

Liked this article? Make sure to ❤️ click the like button.

Got thoughts or feedback? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to 🔁 share this post.

Want more? Here is how I can further help you

• Get one of my books here.

• Sign up for 1:1 mentorship, resume feedback, career strategy or an AMA session here.

Get in touch

You can find me on LinkedIn or X.

If you wish to make a request on particular topic you would like to read, you can send me an email to blog at ieftimov dot com.

Zero interest rates are gone. It's a budget-constrained environment. That's not to say that budgets were not important before, but when money was cheap to borrow, it was easy to spend. For software engineering teams, this new environment means that now, even more than before, we need a tunnel vision to create value for customers. The craft of engineering is essential, but we need to invest our time and energy carefully. We've entered a time of effective engineering.

As a new engineering manager, I've faced this reality: How can I be effective with my team's time and energy? To arrive at the answer, let's first examine how projects usually begin.

🛫 The usual project start

An idea springs up in the form of a (pseudo) product brief. The team's leads—usually the engineering manager with the product manager and/or tech lead—review it and decide to fund it. It's cross-checked with the other cross-functional partners—it looks good. The EM elects an engineering lead for the project, and together with the PM, they are off to the races.

After some exploration and solution shaping, it's time for a review. They explain the feature shape, its UX, and the execution plan. They say it'll take two months to ship. The PM and the engineering lead are confident in the solution. The technology can support it, stakeholders are aligned, and it's all a go. It just needs a green light from the EM, and it's game on. Do you give the green light?

As an EM, I support my team's ideas. But before I do that, I like to challenge the team to think about shipping value faster. My favorite way is to try to bring the future closer to today.

🎚️ Toying with The Triple Constraint

The CAP theorem (stands for Consistency, Availability, Partition-tolerance) is a popular theorem that deals with tradeoffs in distributed computing systems. The equivalent in project management is the Triple Constraint. This principle posits that in any project, three primary constraints—**scope, time, and cost**—are interrelated. Similarly, as with the CAP theorem, any change to one factor affects the others.

As an engineering manager, I find it interesting to play with these factors. Questions like: how much could we decrease the 'Scope' (e.g., drop features), and what would be the 'Time' or 'Cost' benefits? Or, can we dial up the 'Cost' – e.g., by adding more people to the project – and how much would the 'Time' decrease assuming the 'Scope' remains the same? You get the idea.

The question boils to: in the project's context, what are reasonable tradeoffs? I've been thinking about these 'sliders' lately - how can I crank-up and down the intensity of each of them to bring the desired value faster to our users and have confidence that we're building the right thing for our users.

It's easier said than done. In real life, it's almost impossible to play with these factors like Winamp's equalizer without making your team hate you. Moving resources or timelines of one project also affects the other projects in the organization. While there is no easy way to figure this out, I have found a set of questions that can bring you closer to the truth. It's not a time machine, but it works.

🔧 Solving the Right Problem

We developers get excited to solve problems. Sometimes, we become so enamored by a great solution that we forget the problem in the first place. But how do we know if the problem is worth solving? How do we know if our users truly experience this problem? Or are we just looking for an exciting way to scratch our engineering itch?

Another way to look at this is: if your company had a runway for one last-ditch effort to turn the company around, would this be it? That's too big of a question to ask anyone. Yet the gravity of the question does not invalidate the mental exercise. If you could solve one last problem, how do you know this is the one that will turn everything around? Have you talked to the users? If so, what did they say?

This is the first set of questions to ponder and ask if the problem at hand is the real problem. The questions might appear basic, but in complex systems and products, this is quite hard to deduce. The interplay of complex features can have obvious side effects that can send you down a wild goose chase of building features that no one wants.

So, ask. Because what made sense yesterday doesn't mean it's still sensible today.

🧱 Is this the right solution shape?

OK, we are sure the problem is the one we want to solve. What about the solution shape? What are we basing our solution shape on? Is it user feedback? Maybe we're doing something similar to what competitors are doing. If so, do we truly have the same user demographics? Are we sure that what they want is what they need or expect?

There's no alternative to building for users. But there's a problem with users: they think they know what they need but only know what they want. Remember Henry Ford's 'faster horse' saying: "If I had asked my customers what they wanted, they would've said a faster horse". In other words, never ignore user feedback but discern between what they _want_ and what they _need_.

Taking this a step further, instead of asking them to tell you what they want, how about you think about what they need, build a prototype, and show it to them? For example, instead of creating the actual API, you can show a document outlining the API endpoint(s), the request and response shapes, and the integration with these new APIs. Or take some Figma prototypes and guide the users via a Zoom call (or even a recording) through the UX of the new feature you're building.

Such a nimble approach derisks your investment in the solution's shape by getting user guidance. This not only ensures you're building something your users would use, but it also gives your users the feeling that they're shaping the product together with your product engineering team. And if it doesn't resonate with the users, you've saved hundreds (if not thousands) of hours building the solution.

⏱️ Bring value to users faster

Now, say you've derisked the solution shape, and you're sure users will use what you build. Coding time? Not so fast—we need to think about the execution model. The fact that we have an actual solution shape is great, but we still have to get to it. And I always prefer to find the shortest way to user value, not what feels natural (or best) from an engineering perspective.

The other day, I read a post by Adriaan Mol, the founder of Mollie about shipping software:

Speed isn’t the enemy of quality; it’s the catalyst for it. Shipping fast means you can take more risks, make mistakes, and learn faster. The quicker you get real feedback, the quicker you can refine and improve. Perfection is a moving target, and the only way to hit it is through continuous iteration. Fast shipping fuels better quality over time.

I don't think about speed as a way to shrink the estimations of my engineering team; instead, I think about how to give users value sooner rather than later. So, I try to force my mind to things that don't scale. For example, the most absurd question "Can we do this manually for a few select users?". If we can, let's onboard a handful of beta users, write some automation script that would sort of do the job of the real solution, and see how they like it.

Would they pay for it? Is it meeting their expectations in the context of a beta? What other improvements would they like to see in the future? By doing something (semi) manually, we wet our users' beaks and show them a glimpse of the cool future that's coming.

What if they hate our beta? They might think it's a problem that needs solving, but now, after trying the beta, they realize they're fine without it. If so, we just saved ourselves months of actual development time. Just fold the project and move on to do something else more useful for the users.

They loved it? We double down on the feature and ship the real thing.

Despite our gut feeling, some features might not be as valuable as we thought they were. Thinking about providing value to our users, even in a half-assed way, gives us the ability to prioritize what our beta users truly find valuable.

🖖 That’s all folks

As always, I'm eager to hear from you, my readers! If you've read this far, you're awesome - drop me a message, I want to meet you!

Feel free to connect with me on LinkedIn or Twitter and send me a message. I respond to everyone, without exceptions.

As a new engineering manager, there's one maxim I've read in all writing on management 101: do not miss or skip 1-on-1s with your reports. This maxim appears in different forms, but the message is always the same. Some say, "Miss them at your peril". Others call them the "highest-leverage meeting of your week".

Steven G. Rogelberg frames 1:1 well in his HBR article Make the Most of Your One-on-One Meetings:

The best managers recognize that 1:1s are not an add-on to their role—they are foundational to it. Those who fully embrace these meetings as the place where leadership happens can make their teams' day-to-day output better and more efficient, build trust and psychological safety, and improve employees' experiences, motivation, and engagement.

With Nvidia's rise in popularity, all of us have paid much attention to the CEO's practices. Notably, Jensen Huang has 60 direct reports and doesn't do 1:1s. He believes that at _that_ level, he should give feedback publicly. He considers it "a gift for everyone to learn from everyone's mistakes". That sounds great, but let's face it: You and I are not Jensen. Nor does your company have Nvidia's culture. I don't work there, but I'm sure he's an outlier, even within his company.

High-level leaders leverage vision and influence to lead. And what's a better way to articulate the vision, get feedback from reports, and align on the messaging than via a 1:1 with the people who will spread that same vision through the ranks?!

Experienced managers fall into this trap. They believe they're the outliers. They prioritise other meetings over their 1:1s, effectively prioritising process over people. They think that attending that one review meeting is time better spent than talking with their own reports. They believe that one escalation—usually just a wild goose chase—can't be delegated. They make up this excuse that "a new crisis requires their attention." So, they decide to skip. 

All to their peril.

In continuation, we'll cover a list of non-obvious side-effects and downsides of engineering leaders skipping 1:1s with their reports, specifically:

• ⭐️ Reputational Damage

• 🛡️ Hit on Trust and Credibility

• 🤝 Weakened Team Morale and Engagement

• ⚖️ Compromised Decision-Making

• 🛟 Missed Signals for Help

• 🧨 Poor Crisis Management

By doing that, I'll scare the managers among you enough to stop missing your 1:1s. If your manager has been skipping your 1:1s, send them this article.

⭐️ Reputational Damage

In the fast-paced industry that we work in, we want leaders to lead with a steady hand amid all the chaos. Engineers expect their managers to be a source of calm, stability, and consistency. This consistency in behavior and decision-making fosters a sense of trust and security in the team. It allows the team to focus and put the noise aside.

Missing one-on-ones has the opposite effect. It's erratic behavior. It does not send a message of consistency, stability, and trust. On the contrary, it paints the manager as disinterested, distracted, and disorganized. 

Over time, missing 1:1s tarnishes the manager's reputation with their reports. The manager appears disengaged. He gets labeled as "MIA". The label propagates throughout the organization, and the reputation slowly evaporates.

🛡️ Hit on Trust and Credibility

Upstream of reputation are trust and credibility. Regular one-on-ones are fundamental to maintaining mutual trust. In 1:1s, managers get the opportunity to talk about what truly matters to their engineers and what is truly going on in their lives. It's about opening up and being vulnerable. Vulnerability builds trust. It sends the message that we all make mistakes, and it's important to learn from mistakes.

By skipping 1:1s, the manager signals that they do not value the report's time or concerns. They do not want to be frank with their reports and do not want to spend time debugging issues or insecurities. Over time, such behavior erodes the engineer's trust in their engineering manager. The engineer closes down and is not transparent with their manager, which eventually kills the relationship.

🤝 Weakened Team Morale and Engagement

As a manager, you are the face of the company to your team. In the capacity of an agent of the company, your reports interface with you, not your boss, HR, or anyone else. You. In their eyes, you are the company. 

So, if you want them to feel appreciated by their employer, it's on you to make them. No one else can or will. The manager must explain the engineer's value to the organization. 

Managers who miss their 1:1s don't take the time to show appreciation. As a result, their team starts to feel undervalued and disconnected. Disappointed reports will result in poor performance and the employees unwilling to go above and beyond.

⚖️ Compromised Decision Making

Managers rely on nuanced information to make decisions. A simple project staffing decision involves lots of steps and decisions. Here's a shallow demo of what usually goes in my head in terms of staffing projects:

• Who is available to be the primary engineer on the project? Who else can help?

• What is the rough complexity of the project? Is it difficult to implement?

• Is there a good match between the available engineers and the project complexity?

• What sort of work does the project entail? Does it require lots of stakeholder management?

• Do the available engineers have the relevant skills?

• Is the potential primary engineer a match from a career growth perspective? Would they like to work on this project?

• If the first choice for a primary engineer does not take the project, are there alternatives on the team?

And so on. You get the point - there's so much nuance and context that each manager must consider when making any decision. Look at the list above: it requires off-the-cuff knowledge about the status of ongoing projects, the career goals of each engineer, available skills, project complexity, a rough feel for the work involved, etc.

Regarding knowledge of your team and their ambitions, you can only pick up these signals in open-ended conversations as a manager. Regular one-on-ones are perfect for exploring these topics. Managers who miss 1:1s end up making decisions based on incorrect, incomplete, or outdated data. In fast-paced environments, making decisions based on flawed data can harm the team's impact and the manager's career.

🛟 Missed Signals for Help

One-on-one meetings are the right environment to discuss personal challenges, such as health issues, family responsibilities, mental health struggles, burnout, big workload, etc. They often provide a private and safe space for individuals to share these concerns. In these nuanced situations, the manager must be present to pick up on the signals and act on them. At the very least, ask: How can I help?

By missing these regular check-ins, managers are unable to pick up the signals. They're unaware of their team members' struggles, which widens the drift between the situation on the ground and the manager's perception of it. This leads to compromised decision-making, unrealistic expectations from the team, and, eventually, attrition.

🧨 Poor Crisis Management

Conflicts are a byproduct of group work. They should be expected, especially with driven and passionate individuals. However, conflicts pose a risk for the team—they can quickly turn the environment sour. When they go unnoticed or unresolved for a longer time, they can easily escalate into larger issues.

Through regular check-ins, managers gauge the state of projects and team dynamics. Without talking to the team, the manager can't recognize the early signs of a crisis. Even worse, once the crisis unfolds, they cannot comprehend its full scope, which hinders their crisis management and remediation.

Crisis management requires quick action. However, a manager who doesn't communicate regularly with their team will not learn about a crisis until it has escalated. As a result, their response will be delayed, which will exacerbate the situation. On top of that, their communication will be off as they won't have the required information to de-escalate the situation.

That will further deepen the crisis and create confusion within the ranks.

🖖 That’s all folks

As always, I'm eager to hear from you, my readers! If you've read this far, you're awesome - drop me a message, I want to meet you!

Feel free to connect with me on LinkedIn or Twitter and send me a message. I respond to everyone, without exceptions.

An engineer's career maturity

When starting my first job, my only goal was to become productive, 'grow up', and be financially independent of my parents. Looking back on that journey to becoming a productive engineer, I can identify different phases. Over my decade in the industry, I've had to go through these phases repeatedly. I'd wager that the journey starts as a 'Novice' and "ends" as a 'Visionary'. Visually:

As a new engineer in my first job, I was a novice. A couple of years later, I thought of myself as 'senior' (or proficient). Still, now I know I was merely becoming intermediate. It took me another few years to feel (and truly become) proficient, but that proficiency was mainly limited to the context of my first job. Getting to the 'Expert' level probably takes another 7 to 10 years. And that was assuming I would stay on the same job for that time. The alternative is to have a mentor(s) and get the opportunities to learn and grow in other companies. Which I luckily did.

At my second job, I was indeed 'Proficient'. But even though I felt good about my abilities, I couldn't start at the 'Proficient' level in my next job, especially because it was only my 3rd job. I "degraded" to 'Intermediate', but once I onboarded and got a solid grasp of the business, I climbed back up to 'Proficient' within a year or so.

Even though we can take all our knowledge, dotfiles, and notes to the next job, moving jobs is never easy. Gaining expertise takes time. It requires context, knowledge, connections, and user insight. Getting to the 'Expert/Leader' level is even more difficult. It often requires execution through others, which requires a very different set of skills that most software engineers only start grappling with after a ~decade in their careers.

Proficiency

To be a proficient contributor, every engineer needs a good balance of the relevant skills. I would summarize the necessary skills in the following buckets, in no particular order:

• Ability to navigate the organization. Understanding of ownership, the decision-making centers, where the experts congregate, how to reach them, etc.

• Relationships. Engineers must have good relationships with their team, other engineers, PM and EM, cross-functional partners, etc. Simply put, they should be on good terms with everyone they're working with.

• A user-first mindset. The ability to empathize with and think like the user and articulate the user's friction with the product.

• Product strategy. Understand how the product differentiates from competitors. Look for gaps and shortcomings. Look for opportunities. Where will the product be in 2-5-10 years?

• Solid command and understanding of the tech. This spans beyond the tech stack or the programming language. It's understanding of the company's software development lifecycle, how to deploy, source code versioning, data warehouse, observability tooling, etc.

• Autonomy, accountability, and dependability. The ability to shape features, articulate user needs, plan projects, lead people, execute, deliver quality, and keep the bar high—all that without needing someone to look over their shoulder.

All of these are difficult to acquire. After joining a new company, engineers need months, if not years, to begin building for their users. Learning to navigate the organization requires someone to fly the engineer's flag. Building a relationship cannot be rushed—it takes time, effort, empathy, and respect. By using the product, an engineer can adopt their users' mindset. But they also need to talk to their users by reading feedback or participating in user calls.

You get the picture - becoming proficient is difficult. It requires consistently working hard over an extended period. That's why highly proficient engineers are worth their weight in gold. These are context-heavy skills that, once fully materialized, make the engineer an unstoppable value-creation machine. They must be given the room to acquire the skills and use them to become deep product and technical experts, leading and growing other engineers around them.

Reorgs debilitate engineers

Managers think that reorganizations are a good way to refresh the organization. Reorgs realign teams against new business priorities. Or, they're an easy way to handle people dynamics (e.g., new leaders being convinced they know best). Wrong. Well-designed organizations age like fine wine. They don't need a reorg to get refreshed. They get refreshed due to their success by adding new people to their bloodstream and further growing their success.

If an engineer needs at least a year to fire on all cylinders to become a true domain expert, reorgs stifle that growth. They interrupt continuity. Changing teams is stressful for people. It forces the engineer to change their environment. Even in cases where there are no team changes, but teams only absorb new domains, significant stress is still incurred. And don't even get me started on the fatigue reorgs create.

To engineers, reorgs are horrible. They make engineers lose time and energy in handing over ownership of services or processes. Some reorgs kill projects or efforts that the team(s) was previously working on. In the waste that reorgs cause, ownership of some components or services is often dropped or forgotten about. Expertise is lost. When some projects get defunded, engineers get frustrated, disappointed, and leave.

To some extent, it's easier to trade off organizational dysfunction for a stable environment where product teams can create value for the customer and the company.

Loss of Institutional Knowledge

When engineers are shuffled around, institutional knowledge is lost. Documentation might be missing or stale. Engineers develop deep understanding and intuition that is difficult (impossible?) to document. Examples include their systems' behavior, product quirks, workarounds, long-running user friction, and historical decisions. Or why that one feature that you think makes sense to exist doesn't.

Like losing personal things when moving houses, context is lost when moving people in an organization. Engineers don't lose it on purpose. They focus on what's in front of them: the new domain or technology required to succeed in their team. New knowledge replaces old.

However, this old context and knowledge are crucial for efficient problem-solving and innovation. The context within which a product was built is messy. It's a skein of thousands of decisions over the years. The ones that survived the test of time can be seen in the code. But the things that didn't survive the wrath of the user and the lessons they brought - will be lost.

This context is a long-running thread running through the product's fabric. Reorgs are the scissors.

Erosion of Trust and Loss of Talent

Every time organizational lines are redrawn, one thought pops into everyone's mind: am I gonna have a job after this is over? When engineers feel that their job security is threatened or that their contributions are undervalued, it leads to a decline in trust, morale, and engagement, thus making it harder for leaders to motivate their teams. Innovation happens in gelled teams based on trust and respect. If a reorg damages this trust, it will take a long time to rebuild the connections, the grit, the confidence, and the productivity of the teams.

The most significant downside of reorgs is the potential loss of key talent. Engineers who feel unsettled by the changes or disagree with the organization's new direction may choose to leave. The primary effect of people leaving is the loss of valuable skills and knowledge. However, there are secondary effects, such as the domino effect—when key individuals leave, others become demotivated and choose to go. The remaining who decide to stay will certainly not feel the psychological safety they once could contribute to.

Dilution of Expertise

Another side effect of reorgs is the dilution of specialized skills and knowledge. While the reorg attempts to diversify skills or align with new strategic directions, engineers find themselves in roles or projects that do not fully utilize their strengths or areas of expertise. Some engineers get reassigned to different parts of the organization where their skills are not critical. Such misalignment again leads to frustration, as the engineers cannot fully use their skills and knowledge.

A new team configuration integrates members from different backgrounds or experience levels. This, too, can dilute the core expertise of the group. Newer members require time to ramp up, slowing the progress of projects that rely on deep technical knowledge. This is not to say that mentorship is bad; it's, in fact, great, but leaders must consider whether the time is right and whether the team can support it.

Niche areas of expertise might not be considered critical in the new organizational lines. Engineers with niche skill sets might be overlooked and feel undervalued. Lack of recognition impacts the motivation of the experts in these areas. If these experts leave, the organization will be vulnerable in these specific, potentially critical aspects of its operations.

Increased cognitive load

When an engineer works in a familiar environment, the cognitive load coming from the environment is minimal. Coming to work remotely or in the office feels like being in the groove. The people are familiar. The problem area is known. Relationships with stakeholders are established. The team is gelled. All that's left is to execute.

When the organizational line changes, the environment increases the cognitive load. Engineers in the organization must adjust to their new roles; with every team member added or removed from the team, the team dynamic changes. It's like a barely new team. In reorgs, ownership lines change occasionally. When a team takes ownership of a new service that uses a different technology, additional friction, and cognitive load is thrown on the engineers.

All of these ways of adding additional mental effort detract engineers from executing at their highest capacity. When mental bandwidth is spent on fitting into the new environment, there's less mental bandwidth for engineering work. Engineers are not able to apply their best skills to the problem, which slows down the team's rate of innovation and the individual's personal development.

Cultural realignment

The increased mental load is felt the most when a newly restructured team needs to gel. Newcomers to the team need to learn the ways of the veterans—all the idiosyncrasies, the standups, the planning sessions, how they do retros, how they disagree, what's allowed to say or not, and when it's generally accepted to call meetings or to call it a day.

Yet, the veterans will observe the dilution of established norms and practices. The team flourished on these norms for [TIME], yet now they have these newcomers that they need to onboard and show them the ropes. It's a predicament. These cultural shifts affect how knowledge is shared in the team, how the decisions are made, and even how risks are taken.

This all leads to a less cohesive work environment, in which the manager and the team must completely realign.

And that’s it for this issue! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

Let me tell you about Hannah. Hannah was a tech lead I worked with. Excellent engineer. A hard-working individual with a high sense of ownership. She was always tasked with complicated, cross-functional projects because she excelled at them.

As any tech lead, Hannah pulled a lot of weight. Her TODO list was always long: stakeholder management, leading technical architecture, day-to-day execution, managing the project team, work planning, and so on. While leading a big project, Hannah got stressed from the overwhelming responsibilities of running it. It happens to the best, too.

The pressure on the tech lead is high when a project gets messy. Complications take many forms, such as :

• Stakeholders being challenging to manage

• Shifting timelines and pressure (escalations) from leadership

• Scope creep or constraints changing

• Quality issues: complicated code, delivery problems, customer escalations

• Managing team dynamics: conflicts, bridging communication and collaboration styles, motivation issues, straddling timezones

So, as Hannah's manager, I wanted to understand how to support, de-stress, and empower her. She was one of my best engineers, and I was ready to pay any cost to release the pressure that had built up. In continuation, I'll share some lessons I learned while helping out Hannah.

We will cover:

• First step of getting help: admitting they need it

• Calming down the nerves through new perspectives

• Debugging the stress

• Allocating more resources

• Taking over responsibilities

• Split-brain mode

• Rebuilding confidence

Admitting they need help

Hannah showed signs of stress but couldn't admit that the project had issues. It wasn't her fault; other factors complicated the project. Yet, she took it on herself, doubting her engineering leadership skills.

Like Hannah, individuals with a high sense of ownership are great tech leads. But they also find it difficult to admit that they need help. People who take pride in their work think asking for help is a sign of weakness or incompetence (hint: it's not!).

Before I offered help, I wanted to get Hannah's explicit request for help. Stepping in to help without being asked can be perceived as an intervention. Instead of lowering the stress levels, an intervention would further stress Hannah, undermining her confidence and trust. It's always best to approach things with curiosity and patience in such situations. Steer the technical lead to the revelation that they need help through questions. Once they internalize that they do need help - jump in!

Some conversation starters:

• “In the latest [PROJECT] update, you flagged we're having difficulties with [TOPIC]. Are there other challenges you're working against?”

• “What aspects of [PROJECT] are going as planned, and where are we facing unexpected challenges?”

• “How are you feeling about your workload with [PROJECT]? Is it manageable within your current schedule and responsibilities?”

• “On a personal level, how are you finding [PROJECT]? Are there aspects that you're particularly enjoying or finding more stressful?”

• “If you could change one thing about [PROJECT] or how we're approaching it, what would it be?”

Calm down the nerves

It isn't easy to appreciate all the team has accomplished when the project is still not over the finish line. Despite Hannah's outstanding leadership, she struggled to see the forest for the trees. Her team was in deep execution mode. Different individuals needed help, so she was often in the trenches with them - as she should. But it was challenging to keep an eye on the whole battlefield from the trenches. Trying to do too much added to the stress.

Once I received her request for help, I knew it was time to act. Hannah needed help managing her workload and energy, but we needed to work on getting her in a more relaxed state before we could get there. We reflected on the team's accomplishments. Together, we looked back at all the great achievements the team had so far. "See how far we've come, don't you think?" was my question.

Also, what worked was to provide Hannah with the external perception of the rest of the organization on her work. In other words, I explained how her peers and their bosses perceive the work that she is doing with her team. It was evident that people were impressed with her skills and that there was nothing to stress about.

Conversation angles to give perspective through:

• When you look back at the past [period], what milestones stand out as our key achievements?

• Can we discuss some significant hurdles the team has successfully overcome? How do you think these challenges have shaped our team?

• From your perspective, what achievement are you most proud of regarding the project team's work, and why?

• Given what we've achieved, what opportunities or new directions do you see opening up for the project team?

Debugging the stress

But it wasn't easy to get rid of the stress. Sure, the new perspectives helped Hannah de-stress a bit. But the stress was still here, still looming, waiting to strike.

In such cases, it's best to dig to the source. What is the problem? What _truly_ spikes her cortisol? Is it the project deadline? Is it the work that's still to get started? Is it the quality of the work? Was she afraid of causing incidents? The blast radius of the code changes? As an EM, you've got to let the questions flow in these situations. I did it, even at the risk of annoying Hannah. I just had to figure out what were the stressors.

In our case, the cause of the stress was the impending deadlines. There was still too much work, yet the time was flying by. Simply put, Hannah thought we wouldn't get to the finish line on time. And that was great - now we had something to work on. If you're in a similar situation, you must keep prodding to find the root stressors.

Once we uncovered the root, we could discuss mitigations. Would adding more people help? Can we de-scope something from the initial launch to ease the pressure? We could ship the remaining scope as fast-follows. Can we remove interruptions on the team? If yes, what are these interruptions?

Resisting to add more resources people

Projects can sometimes be de-risked by adding more people to the problem. It's the oldest trick in the management book. Allocating more people is a mitigation strategy for projects with low cross-functional dependencies or low-to-medium technical complexity. However, adding more people doesn't always work. It can be a trap.

Hannah's project was cross-functionally complex. Delivering on the project needed lots of coordination. There were dependencies. The involved teams were spread between many time zones. Different cultural backgrounds made communication challenging. Hannah grappled with coordination, which pulled her away from what she enjoyed doing - solving difficult technical problems.

Adding more people in complex cross-functional situations won't do the trick. Such projects usually get stuck within the dependencies, i.e., team A is waiting on work to be done by team B. Adding more people to Hannah's team was not the right move. She would need to spend even more time coordinating both within the team and externally.

We both agreed that she needs not more people but more help with coordination.

Take over responsibilities

When a tech lead struggles with organizational complications, it's worth investigating everything they need to do to keep the project moving. In Hannah's case, there were dependencies to track, coordinate with other teams involved in the project, code, help other contributors, make progress updates to management, etc. It was evident Hannah had too much on her plate.

In these such situations, engineering managers have to detect the needless shit. Then, become an umbrella for your tech lead—even a hazmat suit. Do whatever you can to make their life easier. There are administrative tasks, stakeholder management, meeting running, cross-functional team communication, and much more to take over. As an EM, you should think through the prism of servant leadership: provide support, remove obstacles, and stay away from the critical path.

In Hannah's case, I began by attending daily sync meetings, following written communications, and taking over tracking dependencies. In meetings, whenever Hannah or her team didn't receive a crisp update or commitment from another team, I would play the "dumb manager" card and say, "Just for my understanding: we're expecting the new [COMPONENT] to be ready by [DATE]—are you folks saying that it will be ready by that date? Or are we delayed?"

When dependencies were not panning out or the team got mixed messages, I'd go to the technical project manager and start flagging issues immediately. Engineers are conservative about raising flags, but as a manager, I find it necessary—as long as the engineers are not disrupted by the ruckus.

Taking over responsibilities from Hannah allowed her to remain close to the technology, the code, and the architecture.

Split-brain mode

With less experienced tech leads, one easy way for the tech lead to load-shed responsibilities is to hand over the project logistics to the engineering manager. In this 'split-brain' mode, the tech lead gets more mental bandwidth to remain in the details, while the manager can cover the cross-functional processes and alignment needed with the project.

Some examples of the cross-functional coordination aspects:

• Collaborate with PM on how the new product will interoperate with existing products

• Bring in non-obvious stakeholders to the table

• Get buy-in on the change of plans or new timelines from leadership

On the project logistics side, they can:

• Consider whether the project has the right expertise. Would it benefit from more people or people with newly acquired skills?

• Identify potential risks to the project, including technical, resource, and timeline risks.

• Audit team processes and find opportunities for streamlining or optimization

• Prioritization and scope. For example, if there's too much at stake for the initial launch, identify things to de-scope and fast-follow.

Rebuild their confidence

Hannah did a great job as a tech lead, yet she doubted her abilities. All of that was because she struggled with the project due to too much necessary coordination. Individuals who take pride in their work struggle in such situations, as they doubt their abilities. Understandable.

The engineering manager must rebuild the tech lead's confidence in such situations. So, choose the next project wisely after the team completes the complicated project. It must be complex enough to be engaging, but you must be sure it will be a home run for them. Having a project they succeed at will reassure them that the issues on the previous project were transient and do not speak about their abilities overall.

And once they hit that home run on the next project use the opportunity to reinforce the idea that their skills are up to par. Say, "You did a great job here and nailed the project. You see, the struggles you had before had nothing to do with your competence or abilities".

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

Jim Whitehurst, CEO of open-source software maker Red Hat, has said, "I found that being very open about the things I did not know had the opposite effect than I would have thought. It helped me build credibility." Asking for help is effective because it taps into the natural human impulse to cooperate with others.

What Jim is getting at here is that, as a leader, not knowing something is not a problem. It can even be transforming. It isn't good to pretend that you know something when you truly do not.

So, how do you show your ignorance in different forums as a (budding) engineering leader? I've put this writeup together with practical examples, covering:

• Openly admitting mistakes and knowledge gaps

• Asking for help in public

• Sharing your struggles

• Reacting well to feedback

• Sharing learnings

• Transparently sharing uncertainties or insecurities, and

• Borrowing Authority

Let's dive in.

Admit mistakes openly

Born in Eastern Europe, I grew up with the idea that elders or leaders must always be right—no questions asked. In that culture age, experience, or status allowed one never to be questioned about their choices or knowledge. If you haven't, watch the BBC's Chernobyl mini-series—you'll get the idea very quickly.

The top-down culture doesn't translate in the tech world. The all-knowing leader persona might work for a bit, but in the long term, it breeds insecurity in the people on the team and creates a toxic environment. Not being afraid to admit and embrace mistakes is the better way to lead. Benjamin Laker, in his article on the MIT Sloan Management Review website, argues that "responding without blame creates an environment of learning and growth in which employees recognize that mistakes are part of the process and that their efforts are appreciated — a blameless culture".

So how can we, as engineering leaders, admit our mistakes and show engineers that it's OK to make mistakes and learn from them? Share instances where you made errors in judgment or decision-making and how you learned from those experiences.

In team meetings, actively encourage discussions about setbacks or challenges faced during projects. Lead by example:

1. Share a personal story where a misjudgment on your part led to a project delay, then

2. Explain how acknowledging your mistake allowed the team to pivot and find a solution and finally

3. Reinforce the lessons that openness allowed for fast recovery.

At some point, we all ended up choosing a technology that did not fit the project requirements. If this has happened to you, share the decision-making process, the signs you missed, and the technical shortcomings later discovered. Sharing this will signal your team that it's OK to make mistakes when they are acknowledged and serve as lessons.

The bottom line is that leaders should lead by example, share their mistakes openly, and build an environment of psychological safety in which mistakes are valuable lessons and not anomalies.

Publicly ask for help

It's impossible to know everything. So, another way of being vulnerable as a leader is to ask for help transparently. Asking for help signals to the team that not knowing is OK and encourages the team members to lean on each other. So, how can you, as a leader, practically do this?

Begin by making seeking help a non-event—in other words, normalizing it. For example, during team meetings, openly discuss areas where a project needs specific expertise that you do not have. Say something like, "[Person] asked me about our team's vision of evolving our service within the broader architecture. I realized this is an area where I have limited knowledge. Who can help out here?"

While broadcasting requests for help is good, another way is to call for help from individuals on the team directly. For example, if you're grappling with a new technology stack crucial for your project, ask a proficient team member for a brief tutorial or resources. You might say, "I've noticed your extensive experience with Rust. I'm trying to get up to speed on our upcoming project. I want to understand the technology we will use to support the team. Could we schedule some time for you to walk me through the basics and best practices?"

As a bonus point, always acknowledge the expertise of others publicly. For example, if someone helped you understand the basics of Rust, record the session and praise them publicly. Say something like: "Jane gave me a tour of Rust, which I found extremely useful. We recorded the session—watch the recording HERE. Thank you, Jane, for the wonderful tour of Rust!"

Share your struggles

Managers face challenges, just like any other individual. Curve balls, escalations, complications, projects going sideways—the apparent drama never seems to stop. Good managers shield their teams from needless information or drama to keep their teams focused on the projects. But still, as a manager, it's good to show vulnerability and share some of the struggles you're experiencing.

In team meetings, you can incorporate stories from lessons you've learned the hard way. Team meetings are an opportunity to talk about past projects where you had difficulties or failures. Discuss the context, your reaction, and the outcome. For example, if you once led a project over budget due to poor planning, share how you took responsibility, what measures you implemented to mitigate the situation, and how it changed your approach to budgeting and planning in future projects.

You can also share your struggles in one-on-one meetings. Share a personal story of a time when you faced a significant challenge, such as when you struggled to meet expectations. Explain your feelings, your actions to address the situation, and what you learned from the experience. Sharing your struggles will build a deeper, more trusting relationship with your team members.

React well to feedback

Another way to show vulnerability as a leader is feedback. You must welcome it, take it well, and act upon it. Begin by regularly asking for feedback. Ask for feedback during one-on-one meetings with team members. Don't ask for general feedback - be explicit. Ask about your particular skill or how well you do something. For example, say, "I'm working on improving my leadership skills. Could you provide specific examples of what I've been doing well and areas where I could improve?"

Once you get the feedback, be appreciative. Thank the person for their input. For instance, if a team member suggests a better approach to managing project timelines, respond with, "Thank you for sharing your thoughts. Your input is invaluable to me, and I'll look into how we can incorporate this approach moving forward."

Then, take the feedback and do something about it. For example, if you've made changes based on feedback, check back with the person or team who provided it to see if they've noticed the improvements. If not, you may have more work to do. Say something like, "A few weeks ago, you mentioned that my emails were unclear, and I've been trying to make them more concise. Have you found them easier to understand?"

Lastly, share improvements in public! During team meetings, share how specific feedback has led to personal or process improvements. It could involve discussing how feedback about your communication style led you to seek out a coach or a course to improve your skills, showing that you take feedback seriously and are committed to personal development.

Admit ignorance

You might not like vulnerability, but admitting you don't know something is the best way to show integrity. Saying "I don't know" is liberating. It signals the team that not knowing is OK. It also encourages learning. Use any "I don't know" as an opportunity to brainstorm, research, and learn together.

First, be transparent about your knowledge gaps during discussions. For example, if a particular product behavior comes up that you're not familiar with, openly admit it. Say something like, "I'm not as familiar with the details of that part of the product. Could someone quickly bring me up to speed so I can participate in the discussion?" Such behavior creates a team culture where it's safe to admit gaps in knowledge and is an expected part of growing.

Next, ask insightful questions. For example, when someone brings up a concept or strategy you don't know about, ask detailed and thoughtful questions. "Can you explain how that would work in our current environment? What are the potential challenges we should anticipate?" Asking questions demonstrates that you value the information and are engaged in learning, even if the topic is new.

After admitting your knowledge gap, take time to research the topic. At the next opportunity, share what you've learned and thank those who provided insights or resources. "Thanks to your recommendations, I explored the X product further. Here are some ideas from it that we can apply to our project…".

Share learnings

Talk about recent things you've learned. Emphasize that learning is an ongoing process for everyone, regardless of their position.

Learning must be part of regular team meetings. For example, introduce a short "Lessons Learned" segment where you share something new you've learned. It can be a recent discovery or challenge you've overcome. It doesn't need to be fancy: a simple new coding shortcut you found can be enough.

For a broader influence, write about what you have learned. Lots of companies have internal blogs or newsletters that you can leverage. For instance, after attending a workshop or conference, write a summary of key takeaways and how they might apply to your team's work. Publicly sharing lessons documents your learning journey and provides a resource for others.

Always model a growth mindset. When facing setbacks, share the lessons constructively learned with your team. For instance, do a retro if a project didn't meet its objectives. Analyze what happened, gain new insights, and leverage the team to decide how these lessons will influence future projects. Then, broadcast the insights and decisions widely.

Transparently share uncertainties

Similar to knowledge gaps, trying to under-communicate uncertainties is a bad idea. It's OK to say, "I don't know how we will do that," or "I haven't thought of that before". For example, when facing a significant decision with multiple unknowns, openly discuss the options, the knowns and unknowns, and your reasoning. Say, "We're at a crossroads between technology A and B. Here are the potential benefits and risks as I see them. I'm leaning towards A because of X, but I'm concerned about Y. What are your thoughts?"

Also, involve your team in risk assessment. When dealing with incomplete information, involve your team. Use a (virtual) whiteboard to list potential risks, their impact, and mitigation strategies. Say, "Given the unknowns about this market, let's do a pre-mortem and decide how we might mitigate the risks."

Lastly, regularly schedule Q&A sessions with your team to address uncertainties and concerns. Underscore that _all_ questions are OK to be asked. This provides a safe space for open dialogue and lets you share your thoughts about risks, decisions, and strategies. As a bonus, allow the team to ask questions beforehand to ensure you address all concerns anonymously.

Borrow authority

You don't have to do everything around projects, especially when you're not the right person. Instead, delegate responsibilities to your team. Delegation signals that you value their expertise and judgment, just like they value your leadership. Assign a team member the responsibility of making critical decisions for a project component. For instance, you could say, "I trust your judgment on the architecture for this module. Let's review your decision framework, and you can take the lead on finalizing it."

But delegating is not enough—people need to feel empowered. In project or client meetings, explicitly designate a team member as the expert on a specific topic. Prepare them beforehand and make it clear to others that this person has the authority in that area. For example, "Alex will lead our discussion on the integration design, as he's spearheaded that effort."

For a longer-term delegation, give a team member full ownership over a project or a (sub)domain. They should own the topic, including the authority to make decisions and manage resources. Ensure they have access to you for guidance, but make it clear to the team and stakeholders that this person is the go-to authority in this area.

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

Delivering performance feedback is no small feat. The engineering manager's energy has to be right, they have to shape the conversation in the right way, the content has to be on point, the list goes on. Getting it wrong can have wide-ranging effects. It will surely create FUD with your engineers. But it can demotivate or ostracise some of them, too. The stakes are high, so you have to get it right.

Below, I share practical tactics that you can use on the next performance review you conduct. More specifically, we'll cover:

• 🏋️ Preparation

• 🗓️ Scheduling and pre-reads

• 🖖 The vibe

• ❗️ Important things first

• 🥇 Accomplishments and strengths

• 📈 Areas for improvement

• 💰 Compensation

• 🗺️ Talk about the future

• 🤝 Agree on action items

Without further ado, let's dive in.

🏋️ Preparation

Annual performance reviews is a critical process that directly impacts your team's morale, future performance, and career trajectory. In other words, it's a high-leverage meeting and you really want to get it right. Especially if the news you're about to share with your engineer are not great. To navigate this delicate task, here are several tactics to prepare for the review:

• Crank up the empathy and honesty. Put yourself in the shoes of your reports - this moment is the culmination of a whole year of hard work. Ambitious folks want to know how they did, how much more money they will earn, and any other bonuses. So, be grounded, emphatic, transparent. Be ready to spend many hours with your team mates on this - it's very important.

• Avoid surprises. The official annual performance designation should continue the feedback the individual has been receiving over the year. Conversely, if someone has been underperforming over the whole year, the annual review should not be their first time hearing and getting feedback. If someone's getting promoted this cycle, you want to add a talking point about the bar getting raised. They will have to meet the higher standards of their new title, so tell them that explicitly.

• Prepare for awkward questions. Performance designations are summarized to a rank on a scale, such as a number from 1 to 5. Some companies use the equivalent, but in words - e.g. “does not meet expectations”, “meets expectations”, “exceeds”, etc. You will get awkward questions for the ones you think they did well. Also, some folks will get a different performance designation than last year’s. The ones that receive a lower designation this year might see it as a downgrade, so be prepared to handle such remarks.

• Have the data on hand. To you, performance review results are old news by now. But it's all news to your team, and you will get questions you wouldn't expect otherwise. For example, an engineer who worked very hard in the past year might think they deserve a score of 5, but all they got was a "lousy" 4. Come prepared to dig into the reasons for their scores, including examples of how the person could achieve a higher score. You should not be defensive but have data and examples ready to go deeper.

• Prior art on newcomers. When possible, chat with a new report's previous manager about how they took their performance and salary conversations the last time. Some folks like to be detailed, so you better be well-prepared. You don't want to lose credibility with someone new on the team, especially during your first performance review together.

• Check the math on the compensation sheets. Take the time to go through the numbers for each of your engineers before the actual reviews happen. The reason is simple: you don't want any mistakes during the compensation discussion; mistakes erode the individual's trust in you (as their manager) and the company overall. You and HR must fix any compensation errors before the reviews.

🗓️ Scheduling and pre-reads

When it's time for yearly job reviews, how and when you share information can make a drastic difference. A lot of the important details can be shared even before the review meeting begins. You want to give your engineers the time to ruminate on some of the outcomes before they come to the meetings. That gives them the opportunity to think slow.

Some ideas on this:

• Send the review material the day before. You want to give folks time to sleep on it before they discuss it with you. This practice allows them to read it at leisure and then come to the review meeting ready to discuss what it says.

• Ensure all correct details are in. When they read that email the day before the review, everything must be there. They should have all the details in that package to avoid making any wrong assumptions. And when emailing the performance and compensation outcomes, triple-check that you're sending the correct documents to the right person. Sending the compensation details of one engineer to another would be horrible. Try to prevent this from happening at all costs.

• Send a refresher. As part of that email, send links to pre-reads on how the company does annual performance reviews so the process is fresh in their mind when they come to the review meeting.

🖖 The vibe

Starting a meeting with the right atmosphere is crucial to keep the conversation on track and productive. Setting a positive vibe isn't hard—it just takes a bit of planning and the right approach. It also helps to set the to keep the egos at bay and have a transparent conversation.

Here are some practical tips:

• Set the right tone. When kicking off the meeting, you reinforce the idea that it's a review. It's a look back, it's appreciation and, hopefully, celebration. It's not a criticism fest.

• Explicitly spell out the meeting format. When kicking off the review, you want to eliminate any doubt about the content of the conversation. Also, the order is essential. So, reiterate what you are going to be talking about and in what order:

  • Achievements

  • Opportunities for Growth

  • Goals for the upcoming year

  • Compensation changes

• Make it a two-way conversation. Encourage them to bring any questions or topics you want to discuss. Also, make frequent pauses. Frequent pauses allow oxygen to enter the conversation and allow the engineer to ask questions or make remarks.

• Slow down. Remember that even though they've had the review and gotten to read it, you should still take the time to review each section, starting with the strengths and accomplishments.

❗️ Important things first

As an engineer, I've always hated when managers took forever to get to the point. Now, as a manager, I suggest getting to the important bits right out of the gate, and quickly:

• No feedback sandwich. Don't do that B.S. Keep it grounded and honest: here's where I think you shined, what you didn't do well, and the actions we'll take to make you even more impactful.

• Do not bury the lede. Tell them their performance designation. Tell them the areas where they are a top performer. Tell them if they did (not) get that up-level. Tell them all the essential bits up front. They should know everything from the pre-reads you sent, but you want to be rock solid here.

• Ask them if any of that surprised them. If they are surprised, especially negatively - that isn't good. Ask them to enumerate what surprised them, jot that down, and tell them you'll get back to them as soon as you finish the main part of the review. You're hoping that the review will take care of many (or all) surprises. But be transparent - tell them that.

🥇 Accomplishments and strengths

In my experience software engineers tend to not like praise. Regardless, if there's one time of the year they should get it - it's now. So do it. Spend time on this and make them feel appreciated. It'll go a long way.

• Don’t skip over the positives. Many software engineers are uncomfortable being praised at length, so they'll be dying to jump straight into the areas for improvement. Don't. Skipping the strengths and achievements and not congratulating them for their success undermines the value of the review and fails to reinforce and encourage their talents.

• Spend plenty of time on achievements. You want to celebrate achievements, talk about what’s going well, and give plenty of praise for good work.

• Praise them for their strengths. You'll use these strengths to determine when you want to promote these people, and it is important to write them down and reflect on them.

• Be specific: "Your leadership in [specific project] led to a 30% increase in product efficiency. Your ability [concrete skill] ensured we met our launch deadline two weeks early."

📈 Areas for improvement

Bringing up areas for improvement is about helping people improve, not just pointing out what's wrong. Approach this part of the conversation in a positive and supportive manner. Try to avoid stress when delivering feedback - it's about making the engineer excited for their growth opportunities, not dread them:

• Use the 19 words sentence, as told by Adam Grant. It goes like this "I’ll give you these remarks because I have very high expectations and I am confident you can reach them." You don't have to learn it by heart - make it your own! This angle sets the right tone for the feedback you're about to deliver. With this, you tell the individual that your feedback is not about criticism but growth. You want to support them to reach their true potential.

• Go slow. Do not dump everything at once on the person. Open up the areas piecemeal. Refrain from using language that implies they're not doing anything right, but rather, talk about growth. For example, "There are opportunities to grow and increase your impact on our team. One area we can focus on is [specific area for improvement]."

• Be concrete, do not generalize. Give specific examples of behaviors or outcomes that illustrate the need for improvement. Generalizations are confusing or demoralizing, so avoid them. For example, "During the [specific project], you did [specific behavior] which led to [specific consequence]. Addressing this will help out the team's collaboration."

• Link to impact. Explain the impact of these areas on the team, project(s), or organization. Tying it to impact helps the individual understand the broader effects of their performance. For example, "Improving in this area will help us achieve [specific goal] more efficiently and make the team gel better. Both are crucial for the latter part of the year, where we'll simultaneously work on two challenging projects."

• Explicitly identify the promotion gap. If the individual was up for promotion but didn't get it, it's paramount to identify the gaps. Your feedback must indicate one or two skills they must work on to qualify for that promotion. Informing them of the gaps is the bare minimum - talk about what kind of support they'd need, too. For example, "In your view, what is the best way for me to support you to close the gap on [specific skill]?".

• Keep in mind: it's a two-way conversation. After presenting the area for improvement, pause. Give the colleague time to digest what you just said. Encourage them to share their perspective. Pausing (and asking) for their input invites them to collaborate with you on the approach to address your feedback.

💰 Compensation

Discussing compensation is a pivotal moment in the review. It can significantly influence the remainder of the conversation, but also their long-term motivation. It's critical to be crisp and direct here. Some ideas on how to do that:

• Start on the same page by reiterating your company's total compensation package setup. Reiterating it allows both of you to get into the compensation mindset and establish the vocabulary before you get into the actual numbers. If you need a refresher, companies usually have the following compensation structure: base salary, equity, bonus, and additional performance-based equity.

• Do not beat around the bush. Once you've set the proper context, jump in the numbers immediately. Start with a summary: "Given your contributions this year, including leading the [specific project] to success, you'll receive a 5% salary increase, 22.5K bonus, and 100K equity refresh. This reflects our appreciation for your hard work and the value you bring to our team." Once that's out of the way, go to the details: start with the salary and bonus (if any). Then, move into equity, if any.

• Talk specifics. When discussing salary bumps, spell out the math for them. For example, "You get a 5% raise to your base. Starting next month, instead of your old salary of 100K, your new annual base salary will be 105K." When you go into the bonus, explain the bonus structure. For example, "Per your contract, your bonus is 15%. Based on your performance designation, you're rewarded with 150% of your bonus. In other words, your bonus is your base salary 0.15 1.5 = 22.5K". When discussing equity, continue with the same approach: dive into the numbers.

• Make sure the math checks out. The last thing you want to happen is to miscalculate or incorrectly explain any compensation outcomes. Take your time; don't rush it. If the math doesn't work, either try to debug on the spot with the individual or say that you'll ping HR to get help, and you will follow up with the individual ASAP.

🗺️ Talk about the future

Now that you're through the compensation, it's time to talk about the future. Be excited - the future holds great things for your team!

• Explore their motivations. Pick 2-3 career goals and dive deep into them. What is their motivation for having those goals? For example, machine learning has gotten very popular lately. So, your report might have a goal to "deploy a machine learning model". If your team does not have an upcoming project where the individual could do that - you need to discuss it. Perhaps the company can invest in training for this person. Or maybe there's a better-suited team where they could do that?

• Dig into the disconnect. If the career goals and the areas for improvement are grossly misaligned - talk about it. Explain the rationale for your feedback (again) and how that ties to the expectations for the engineer's level in the company. Put the feedback in an urgent context, too. For example, if someone's performance is at risk (e.g., close to getting a PIP), you must explain that they should prioritize meeting their role's expectations before other goals.

• Identify practical work to grow through. Think about the areas for improvement and the individual's personal goals. What projects, domain areas, or expertise could they work on? For example, if an area of improvement is stakeholder management and the engineer wants to work on a project involving microservices, then figure out how they can lead a crucial role in an infra-level project. Such a project will allow them to manage internal stakeholders (i.e., lower risk) and be happy to expand their knowledge.

• Set clear & achievable goals. Work together to set goals. Make each goal SMART - specific, measurable, achievable, relevant, and time-bound. For example, say "Let's set a goal to improve your [specific skill or behavior]. A way to achieve this could be through [specific action or resource], aiming for [specific outcome] by [specific timeline]. What do you think?"

• Write a Personalized Development Plan (PDP). PDP is a practical guide that will help the engineer grow towards their career goals by aligning the goal-related activities with the company's objectives. For instance, if the engineer aims to specialize in machine learning, their PDP could list actions like completing an advanced machine learning course with a curriculum relevant to an upcoming ML project in the company. That way, the engineer will achieve their career goal, and the company will achieve its objective.

• Put support structures. To achieve said goals, the two of you need to decide what support they need to achieve their goals. They can get support from the company, such as mentorship or training. You can support them as their manager, be a sounding board and a coach. You could do something extracurricular for them - for example, introduce the individual to a senior leader so that they can ask any burning questions or get more insights into the company's strategy. Get creative!

🤝 Agree on action items

To close off, you need to agree on the action items, owners of the actions and cadence at which you will review these items to keep track of their progress:

• Summarize. Conclude the review by summarizing the key points you two discussed. Call out any action items you agreed on. Summarize the development plan, if any. Ensure both of you are clear on the next steps. Bonus: share the written summary via email after the call.

• Establish recurring progress reviews. Follow-ups are key to tracking progress, so set a timeline for follow-ups and immediately put it in your calendars. For example, I prefer a separate, monthly check-in similar to a regular 1:1, but it focuses strictly on the progress the individual is making through their goals and improvements. Here, you can also review and tweak their PDP, marking down the milestones they've achieved.

🎁 Performance Review Conversation Starters Tool

Exclusive for readers of Captain Codebook - I built a small tool that allows you to tailor a set of conversation starters, based on the outcomes of the report you’re reviewing.

Based on the choices you make, the tool will return a “Main conversation” part, which will include a solid layout for the performance review conversation. Also, driven by the choices you make in the form, the tool will return additional conversation starters for potentially awkward scenarios.

Test it out and leave me feedback in the comments!

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

Software development is a team sport, so once in a while, engineers will have to flock to a meeting room and discuss. Projects require constant collaboration among team members, including developers, designers, product managers, and stakeholders. Many cool things can happen in meetings: discussion, alignment, ideation, learning, bonding. Meetings are a fact of our "work lives". It's how organizations work. They're a tool to focus many brains on a topic and get the best outcome for the given topic. 

Efficiently leading meetings ensures clear communication, aligned objectives, and effective collaboration. Leading effective meetings is an essential skill that most engineers completely gloss over or discard as useless. And yet, if you are (or aspire to be) a senior engineer, you must know how to get a chaotic meeting back on its rails and push it forward gracefully. That's especially true if you're the leader in the pack. recently wrote, "driving meetings is a critical skill for growing to Senior."

If the issue at hand involves complex problem-solving and brainstorming or requires immediate clarification and interactive feedback - call a meeting! Meetings are a high-bandwidth medium that enables real-time discussion and immediate questions and answers, and they can be course-corrected in real-time. However, suppose the information contains a lot of detail (e.g., technical design). In that case, a medium that would allow engineers to digest the information over time is better (e.g., an RFC).

An expensive exercise

In the famous article "Maker's Schedule, Manager's Schedule," Paul Graham said, "When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in." Engineers perceive meetings as a waste of time. Meetings interrupt their flow and drain energy. Yet, the average engineer spends roughly 11 hours per week in meetings. That's more than a whole day's worth every week.

Meetings are expensive. Shopify's recent exercise to reduce meetings found that the average cost of a 30-minute meeting with three employees can be from $700 to $1,600. Are all meetings worth this cost? Hell no. That's why at the start of 2023, Shopify canceled 12,000 calendar series and events and reinstated 'no meeting Wednesdays.' The average time per person spent in meetings decreased by 14% in the first five months of the year relative to the same five months of the previous year.

The ROI of a Meeting

An example: an hour-long operational review with a team of 6 plus their manager, using Shopify's math, costs the company ~$3500. My question to you is: Is the operational review worth it? Abso-friggin-lutely. Operational reviews, where the team reviews their dashboards and looks into how their systems perform, are high ROI meetings. Any potential system issue uncovered in these reviews can prevent massive problems down the line, so they're worth the engineering team's time. Suppose that the same proverbial team has an operational review every two weeks. In that case, they'd annually spend $91,000 (26 weeks x $3500) on operational reviews. Yet, said reviews can prevent a multimillion-dollar incident down the line. Even if the reviews prevent one big incident every five years - money well spent.

Not all meetings are equal. Nor do they cost the same. As an engineer, sometimes it's worth it to pay the price of the meeting. An hour-long brainstorming session in front of a whiteboard can be the most impactful hour of an engineer's time in a month (or even a quarter). For example, if said brainstorming results in setting the right technical strategy, it can be a game changer for their team or entire organization. Meeting with the right people can unlock a whole avenue for an engineer's learning, leadership opportunities, and career growth.

There are more examples of high-ROI meetings. One-on-ones with your manager. Incident retrospectives. Interviewing. Onboarding newcomers. The list goes on. We need a more nuanced perspective on meetings. We shouldn't flat-out reject them. We must make peace with it - that's how most companies work. They're "a necessary evil", as said. We must be very intentional with our time and invest it only in meetings whose outcomes and results we can influence. If the group can achieve the same result without input, then our time is better spent elsewhere.

How do you lead an effective meeting as a software engineer?

Before even calling a meeting, we need to figure out the purpose of the meeting and its objectives. What do we aim to achieve with the meeting? For example, are we trying to get to a decision? Alignment? Brainstorm? The purpose has to be clear, as it'll set the meeting's direction (and the destination). Talk with allies beforehand if you're unsure what the proper format is. For example, say, "I think we should approach the meeting as a brainstorm; what do you think?" and calibrate.

Once the purpose is clear, set objectives; these are a few goals or outcomes you want the group to achieve. Make them practical. For example, do not say, "discuss the viability of microservice architecture," but rather "decide on go/no-go for the microservice architecture prototype." "Discuss" is what you do in a meeting anyway. The objective is not to discuss - it's to get an outcome you want out of that discussion.

Using the purpose and the objective, you can create the agenda. In it, list the topics to be discussed, including a brief description and the goal for each. Once you're happy with the list, assign a realistic amount of time to each agenda item. Lastly, share the agenda with the participants well before the meeting. Sharing the agenda allows the participants to prepare for the discussion. Add the agenda to the calendar invite, i.e., to the description field, so it's easy to find.

When creating the invite, choose the right participants. How? Think about the people with lots of context, knowledge, or stake in the topic. Invite only those whose input is necessary to arrive at the best decision. Engineers' managers might be interested in the subject as well. Still, sharing the notes with them after the meeting might be enough. But, if the meeting is between multiple teams and you can see that the topic might be contentious, having the teams' managers on the call might be a good idea. They can act as unblockers should the need arise.

During the actual meeting, stay punctual and focused. Join the call on time, and announce that you'll give everyone 2 minutes to join. Then, start the meeting once those two mibs are gone. You have to respect everyone's time.

Keep conversations aligned with the agenda and objectives. Redirect off-topic discussions as needed. Don't ignore off-topic or tangents - jot them down and tell the group you'll revisit those points separately. Be respectful: you should appreciate the tangent, but the facilitator's goal is to respect everyone's time and keep the discussion on track. 

Should any disagreements arise, seek to understand the different perspectives. Once you have the different sides of the argument, summarize them for the rest of the group and ask for an acknowledgment. Say something like, "OK folks, to summarize: on one side, I hear [summary of first argument]; on the other side, I hear [summary of second argument]. Is this correct?". Once you get a solid understanding of the two sides, then it's good to ask the group for ideas on tradeoffs to make to bridge the disagreement. Keep repeating this and work towards a consensus. 

If the group can't progress on a particular disagreement, it's time to decide: is the disagreement a blocker? Or could the meeting continue without alignment on that specific topic? If blocking, then as the facilitator, you must respectfully ask the group's decision-makers (i.e., the manager) to step in. Once the manager decides, the group must (disagree but) commit to the decision. If the manager(s) cannot decide on the spot or the argument is getting heated, it's best to move to the next agenda item. Use something like, "OK, I don't think we can arrive at a decision now. I will restart the conversation via Slack and schedule a follow-up conversation on the topic once we regroup. Any objections?". 

We're all different. Some of us are self-confident and like to speak out. Others come from cultural backgrounds where speaking up is frowned upon if not asked. Some people are loud, but others perceive loudness as confidence and knowledge, which might be incorrect. That's all to say that it's on the facilitator to ensure all voices on the call are heard and all opinions get attention and be valued. As the facilitator, you must create a safe space where team members feel comfortable sharing their ideas and concerns. Say, "Hey [name], what do you think about that?". Or "Hey [name], you've been a bit quiet. Anything you'd like to add?".

Once the group goes through all agenda items - hopefully on time - it's best to review the decisions and rationale behind them. Then, read all the action items and call out their owner and deadline. Before everyone hops off the call or leaves the meeting room, it's best to ensure everyone leaves with the same understanding of the meeting's outcomes. So, read out the decisions, jot them down in the notes document, and read out the action items. Before you wrap up, ask, "Have I misrepresented or skipped anything?". If all you get is silence - you're golden. Time to stretch your legs!

An excellent way to wrap up a meeting facilitation is to share a meeting summary with the attendees. In the summary doc or email, you should include the decisions and action items with all participants, relevant stakeholders, and deadlines (if any). Make sure each action item has an owner and is prioritized accordingly. Or communicate the action item with the owner's manager to ensure the team will adequately prioritize it.

Leveraging your manager before and during meetings

There are qualities that managers have that you can leverage. Managers usually have clout because, well, they're managers. Managers have a network in the company. They have experience and have been in a bunch of meetings - both great and terrible. They know what a well-run meeting looks like. So, lean on your manager when preparing to lead a meeting.

What can you ask of your manager? So. Many. Things.

For starters, if you feel insecure about leading a meeting, you can talk to your manager. Your success is your manager's #1 priority, so they will figure out ways to debug your insecurity and help out with your confidence. Confidence can significantly impact your performance and how good of a job you'll do at facilitating the meeting. Ask them to work with you on the meeting prep. They can review your write-ups, the meeting agenda, and objectives and provide you with feedback. 

Your manager can kick off the meeting. They can clarify your role as the discussion leader to everyone in the meeting. Communicating your role in the call will set the stage for you to take charge and others to respect your leadership in the session.

In cross-functional meetings, like product reviews or technical discussions, your manager can review the proposal document and provide helpful feedback. You can also leverage your manager for "backchanneling" – they can talk with other leaders and feel out if your proposal will get pushback from the other team(s). Use them to get that feedback. Then, eliminate any contentious points before the meeting so the meeting is (hopefully) smooth sailing.

If you have an inkling that an upcoming meeting might be contentious, explicitly inform your manager. You can have a prep session together and form an attack plan. Your manager can help with keeping the meeting vibes in check. They can keep your back if you run into headwinds (e.g., strong feedback) or if attendees go on tangents and you find it challenging to keep them focussed. Your manager can be a co-host of the meeting and take an active role. Or be a liaison who can bridge the gap between attendees by translating technical jargon or clarifying project goals and constraints.

After the meeting, you can ask your manager for constructive feedback on what went well and areas for improvement. Tell them to highlight specific instances where you excelled, and query them for actionable advice for future meetings. If you have to learn - ask them for resources or training opportunities in areas like public speaking, project management, or leadership.

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

The naïve optimist and the cynic

According to recent polls, around 90% of companies will introduce a return-to-office policy by the end of '24'. The in-office 5-day work week is gone for good. Still, companies are betting on a "couple of days in the office" policy.

The cynic in me wonders how a return-to-office (RTO) policy is justified in the age of Nvidia - a fully remote company - being now worth as much as the entire Chinese stock market. Still, the naïve optimist in me believes that there are still some benefits from a hybrid working model, where employees go 2 to 3 days per week in the office and work from home the remaining days.

To be clear, an experienced software engineer can do their best work from their home office. No question. The same applies to the office. Yet, early-career engineers or newcomers to a company can benefit from being around more experienced and well-established engineers in the office. That's where the office outmatches the home office, I would wager.

I decided to document some practical tips and tactics that I've picked up on how to navigate a back-to-the-office situation. Who knows, you or your team might end up in a similar situation soon. Here's what I will be talking about:

• How to make the RTO policy your own

• Why and how the team should own the implementation

• How to define guiding principles, with examples

• How to set in-office days and core working hours

• Localizing core hours and thinking about "satellite" offices

• How to recognize and appreciate folks who follow the new policy

• How to continue to strengthen the bond virtually

Let's dive in!

Make it your own

Going back to the office is a deal-breaker for some of us. And that's fine. After all, it's a job, and people can choose their employer freely. For the rest of us who will remain around and give this whole RTO thing a shot, I think there's a new mindset here that we need to adopt. RTO is happening, whether we like it or not. But, instead of letting RTO "happen to us", we ought to make it work best for our teams.

By the looks of it, most companies will go to a hybrid mode - in one work week, the employee will be present a couple of days in the office, and the rest of the days, they'd work from home. The good news are right there: when there's flexibility, there's room to make the policy implementation work for my team. Instead of against us.

So, I've learned that we shouldn't just implement policies as they come. Engineering manager should make a sensible decision on how to apply the policy to their team. It's about putting the new policy's true spirit into practice. While we can't influence our companies on whether a hybrid model is the right thing, we can influence how we implement the policy within the guidelines of the policy.

So, the question is: how do we, through creative ways, make this change of policy work for the team and ourselves?

Team owns the policy implementation

Assuming that there's flexibility in the in-office days, the team should be involved hands-on in defining the team's implementation of the new policy. While the policy defines the minimum number of days in the office, it's on the team to define how this will play out - and to commit to it once the plan is in place.

So, I believe that the team must own the implementation. If it came from "above," it would create even more resentment regarding the policy change. The team must voice feedback to shape the hybrid work policy implementation, clarifying that the team's input has influenced the final implementation of the policy. After all, the implementation of the policy is what affects the team every working day.

Establish guiding principles

Companies usually want to encourage collaboration between folks earlier in their careers and those at later stages. They also want newcomers to interact with people who embody the company's values and are well-established and performing. In other words, they are "cultural ambassadors." The idea is that newcomers will absorb the company culture faster by working in proximity to these ambassadors.

Following this logic, I believe managers with their teams should establish guidelines around building a more robust network in the company and allow for in-person collaboration time. The point here is that with the guiding principles, we have a tool through which the team can better prioritize their time in the office. So, what is a guiding principle in this context of RTO policy implementation at the team level?

Few examples:

1. Prefer collaboration over meetings. The team will not schedule meetings during the in-office days - they can do the same from home via Zoom. Instead, they will encourage pair programming, brainstorming, and whiteboarding in the office.

2. Strengthening bonds. The team will reserve free time during in-office days for social activities in the office (or at the water cooler!)

3. Encourage community participation. During in-office days, the team should allocate time to attend tech talks, lunch and learns, fireside chats, Q&As, etc.

4. Test and evaluate. The team will establish checkpoints (e.g., once per quarter) during which the team will huddle and decide if the current RTO policy implementation is working.

These are just examples, but they're a solid foundation. As always, take them and make them your own.

Define in-office days

For the team to become closer and establish stronger ties, it's best to define a set of in-office days. By in-office days, I mean the team commits to a set of days to show up in the office. Simple to define, difficult to commit to. But you know what they say: a team that defines their office days together - stays together.

The policy can be enforced anywhere between one to four in-office days per week, depending on the company. Some companies use percentages, e.g., in-office participation at least 40% of the time. Then, the team needs to define two days of the week to be present in the office. The pedantic among us might argue that 40% can mean spending half a day in the office 4 days a week - which would be correct. But impractical, I'd bet. So, I prefer to avoid these overly flexible interpretations.

Defining the in-office days should be a collective decision - no one should be left behind. The implementation of the in-office policy will be uniformly applied, so everyone should have their say. That doesn't mean that it'll fit everyone's personal schedule. Fitting the in-office schedule to everyone's life is difficult, especially if the team is large. The difficulty of aligning on in-office days is proportional to the number of personal schedules that must be considered. Still, it's a worthwhile exercise.

If aligning on days proves difficult, the team can implement a rotation for in-office days. For example, if the requirement is to have 3 in-office days in the week, then every month, the team can go to the office on Monday, Thursday, and Friday, and every second month on Tuesday, Wednesday, and Thursday. That way, everyone on the team is ~evenly inconvenienced.

Define core hours

During the pandemic, everyone's schedule changed. We saw life and work get intertwined. Which was a challenge. The workaholics lost their lives, and the rest lost their motivation. Some of us moved away from the big cities we used to live in. Some of us even got used to the suburban life. Fast-forward to today - these same folks now will struggle to commute to the office.

Some folks became parents during the pandemic (like myself!). Some of us now have toddlers in daycare. Kids must be dropped off at the daycare or school and picked up at the correct times. Toddlers are also germ magnets - they get sick and pass their germs on to their parents. Taking care of a sick toddler while sick is.... something. And let's not fool ourselves: working next to a sick child who needs your care and attention is not possible. Full stop.

All that goes to show that we need flexibility in the work hours: every one should get the time to do their work, but those hours are not necessarily the same hours of the day for everyone. We must recognize that each team member may have different preferences and obligations outside of work. They should be able to propose their work hours, considering the requirement for core hours and the need for overlap with teammates for collaboration.

Leading with empathy and defining core hours for the team works best, and they set an even playing field for everyone. Core hours are a timeframe within a working day when the team must be online and available (e.g., on Slack) and actively working on their tasks. In the context of the hybrid model, it's best to define hours when everyone has to be in the office, too. During that time, folks will know that their teammates will be around for a coffee, pair programming, lunch, etc.

Having some flexibility for people who live far from the office is an extra step to make their lives easier and, ultimately, happier with their jobs. Such flexibility can make their lives easier, as commuting can be frustrating during rush hour. For example, I've seen folks using such flexibility to avoid traffic: they can split their days, e.g., work 2 hours in the morning at home, then commute to the office outside of the rush hour, spend the majority of core hours in the office, and then go home earlier (or later) to avoid the evening traffic.

Localize core hours and core days

If your team is distributed, there's further flexibility the team can unlock: all colocated team members can self-assign in-office days, with core in-office hours. Obviously, they have to overlap with the core hours of the team, but whether they're to work from home or from the office, it's best to be arranged by the affected individuals. The manager should be a facilitator for these conversations, not an active participant. It's up to the colocated folks to work this out together, so they are also bought into it.

"Satellite" offices and individuals

Suppose you're part of a company with smaller (a.k.a. satellite) offices worldwide. In that case, developing a policy regarding people who should return to those smaller offices is good. Frequently, such offices gravitate around sales and adjacent teams. As an engineer, there isn't too much of a point in commuting to and back from the office if other engineers aren't present on-site.

I am not suggesting hanging out with sales folks in the office is not good. In fact, I encourage it. But there are other (better!) reasons why an engineer should commute multiple times per week to the office. As managers, it's best to tap into these offices' local communities. Frequently, these offices have site leads who know the community and the office well, so with them, we can figure out the best way for our engineers to leverage the office and its community.

To assure equal and fair treatment to all "satellite" engineers, defining an org-wide policy is best. An example policy can be as simple as engineers are encouraged to observe the new RTO policy to work X% of the time in the office only if an engineering community is present on-site.

The threshold of engineering presence can be defined based on the company size. For some companies, having 3 engineers on-site is enough; for others, it might mean 300.

Show gratitude & recognition

Even though it's a policy and a job, I believe that team members who respect the back-to-office policy set an example for others and, as such, should get some recognition for it. Recognition is critical during the transition period when the team moves from a work-from-home / remote setup to a hybrid. To reinforce the good behavior it's useful to figure out how to extend the gratitude beyond a simple "thank you" at the next one-on-one.

I've got a few ideas.

First, public recognition. Acknowledge teammates' efforts to comply with the new policies during team meetings or through org-wide communications. Public recognition boosts the individual's morale and sets a positive example. But beware: some folks don't like the public praise. If that's the case, write them a personalized thank you note. It will make the individual feel appreciated for their efforts to adhere to new policies without shining the spotlight on them.

Another way is through reward programs. One can implement a rewards program where employees can earn a symbolic award for following the new back-to-office policy. I wouldn't go as far to suggest handing out "Amazon gift cards", as they might be perceived as a monetary reward. A better alternative can be some unique company swag. Every manager should use their knowledge of the individuals on the team and find a suitable award while still keeping it symbolic in monetary value.

An extension of the award idea is to put these individuals in the spotlight by making them team ambassadors. They can become culture champions who can take the lead in organizing and promoting in-office activities. Tread carefully: organizing team activities might not be enjoyable for everyone and might put pressure on them. I wouldn't want to put more pressure as a reward for following a new company policy.

Connecting beyond the office

It's also vital to continue extending the bond and camaraderie over the wire. In distributed teams, some folks won't work frequently with other distributed teammates. Even if they do go back to the office every week. In fact, they might rarely see each other on-site.

They need to spend time together virtually to strengthen the team's bond beyond the in-office connections. It's good to plan regular team-building activities and social events online, such as monthly virtual coffee breaks, virtual lunch (and pick up the tab!), and other water cooler chats over Zoom. These are virtual spaces for casual chats and non-work-related conversations. These can be a Zoom call or a dedicated chat channels where team members can share personal news, hobbies, or exciting finds.

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija

Managers or employers want to be sure that when they hire someone, it'll all work out just fine. Great managers or employers won't optimize costs on candidates (e.g., trying to save a few bucks) - they will prioritize hiring the right personality and skills.

As someone trying to break into the industry, I would ask myself: before I apply to jobs, what steps can I take to derisk my potential employment? In other words, how can I make it so apparent that I will be a good fit for the manager/company that they won't even feel like they're making a bet?

My answer: proof of work. As a newcomer to the industry, the most efficient way to derisk my work application is to show evidence of competency. But it's also the most challenging way.

In continuation, I will talk about how to build a proof of competency. While I am sure there are other ways to approach breaking into the industry, I am confident this is the best way, even though it's demanding. If you have a different approach - tell me about it in the comments; I would love to learn.

My assumed profile

To frame my write-up well, let's create a persona. It'll be helpful to have one, as it will frame my advice better. 

In no particular order:

• I am not a fresh grad out of college. Let's assume I am in my early thirties (as I am at the time of writing this).

• I worked in an unrelated field for a few years before switching careers. I've never worked in any tech company before.

• I have invested a few months to learn fundamental web technologies. For example, I completed a boot camp.

• My goal is to enter the tech industry as soon as possible. I want to earn a salary, but I am okay with delaying that – an unpaid internship is also acceptable for a short bit.

Without further ado, embracing this persona, here’s how I would break into tech. 

Step 1: Flexible mindset

Limiting myself to only the area I started my learning in would be a mistake. In other words, spending time on a front-end boot camp doesn't mean I should avoid learning about other areas. A limited mindset gives me a striking similarity to the sunk cost fallacy - just because I invested time and money in one area doesn't mean I shouldn't be flexible and expand my horizons.

A short personal story: I found front-end work interesting early in my career and had ambitions to be a front-end engineer. But, as luck would have it, I had more opportunities to work on backend. So, I took them. At the start, I was afraid I lacked the skills to be a backend developer; e.g., I was never good at solving algorithmic challenges. Over time, despite being somewhat frightened of the prospect, I ended up as a backend engineer. I learned to love and appreciate the field. And to suppress my impostor syndrome.

Back to our hypothetical scenario: I don't get to choose as someone trying to break into the industry. If I'm serious about entering the industry, I'll take any opportunity. You name it, whether that's front-end, backend, support engineer, or infrastructure engineer.

I call this "engineering my luck". The more flexible I am, the more opportunities I will get, so I will have a bigger chance of finding a job or an internship faster than not.

Step 2: Know the job market

After agreeing that any job/internship is better than none, I would change my focus to learn the job market. By "learn," I mean figuring out what jobs are hot or not, what roles are in demand, what profiles, schools, boot camps, etc. Practically speaking, I hop on LinkedIn, look for local and remote jobs, and jot down my observations in a notebook.

I don't browse for jobs to apply to them. My goal is to get data about what's in demand. If front-end is not in demand, or people want to avoid juniors, I must broaden my search. Or get creative by considering ways to fit my expertise within another adjacent role.

For example, with the knowledge gained from my front-end boot camp, I could think about adjacent roles: design or full stack development. Suppose the market does show demand for full-stack developers. In that case, I will start thinking about expanding my knowledge. In other words, I would (potentially!) embark on the journey of learning full stack, building on top of the knowledge I already have.

The bottom line is that I follow the market. If the market is leaning towards full-stack engineers, I build a plan to bridge the gap between where I am and what an employer expects of entry-level full-stack engineers.

After identifying one or two adjacent and in-demand roles, I think long and hard about what path to choose. Once I decide, I will be ready to start closing the knowledge gap. Note that this doesn't stop me from applying to front-end roles - it just adds another supplemental role that I can eventually apply for.

Step 3: Identify the gaps

Let's build on the example from step 2: my LinkedIn research shows that full-stack developers are in demand.

I ask myself: What minimum skills do I need to be seriously considered for an entry-level full-stack position? Finding the answer can be nerve-wracking. But there's a trick to it: I will ask someone who is already a full-stack engineer what skills I lack. I don't assume or jump to conclusions. Ask the people who do the job—the professionals.

It's mind-blowing how people think it's wrong or rude to ask. It's not. I have feared rejection in the past, but I know I've got only something to gain. The worst case is I get no reply, or I get ghosted. And usually, there's a good reason for it. After a decade in the industry, I have yet to find someone who genuinely wouldn't want to help newcomers—especially the hardworking and humble ones.

Do you want to try this for yourself? Just ensure you're logged in on LinkedIn and click on this link. Once you see some folks with the "Full stack" title on their profile - message them. That's it, there's no magic to it. If you're searching for experts in different roles, update the search keyword for a more suitable one.

When reaching out to folks, I take my time when composing the message. I want to save their time, so I go straight to the point: share my goal to become a full-stack developer, explain my skills so far, and ask for advice on what to learn next. I would also ask if they have resources (books, websites, courses, etc.) that they have experience with that I should get. Getting vetted resources is very useful - it'll provide me with a free quality check (so I don't get stuck in useless content). Also, it will help me with step 4.

Next: X (ex-Twitter). Same exercise. Make sure you're logged in on your browser and click here. Look at the people that show up in the search results. I'd do a quick up-to-30-second scan for each of them and see if they engage with others. If so - ping them and ask them the same questions as you did on Linkedin.

I do not doubt that after reaching out to 100 people across Linkedin and Twitter/X, I will get a dozen replies. As a result, I will identify a set of skills or technologies that I need to learn to bridge the gap and become a serious full-stack candidate. Plus, I'll have some links to courses or names of books that I can work on next.

Step 4: Close the gaps

After identifying my knowledge gaps, it's time to close them. In simple terms, it's time to learn the skills I lack. Given that I've already been through a boot camp, I know there's no better way to learn than rolling up my sleeves and getting my hands dirty. So, it's time to dive into the courses and the books I got in step 3.

I wouldn't use the shotgun approach. Trying everything is rarely good. Instead, I would find the most adjacent new skill to the one I already have. For example, I wouldn't learn React if I only knew DOM manipulations using JavaScript. First, I would learn to understand the building blocks: APIs, asynchronous requests (fetch), and JSON. I will move to higher-order abstractions once I know how data flows from an API to the browser (and back).

Given my goal to learn full-stack, I would also look for adjacent technologies. For example, I would learn a well-established technology like Node.js - it's JavaScript on the server side and a mature technology. In some communities online, Node might be perceived as "uncool" or "outdated", but that's just noise. As a newcomer, getting productive as fast as possible is essential. 

When building an API - I would begin with a straightforward JSON API instead of using the more advanced GraphQL or self-describing REST APIs. It's enough to be able to return JSON from my APIs. I can learn the other aspects and ways of building JSON APIs later. All that matters is that I can do damage as soon as possible.

Same with data storage: instead of using a database right out of the gate, I'd start with learning how to use a document storage platform (e.g., Firebase or Supabase). Once I can create simple CRUD applications using Firebase, I can explore how to use an actual RDBMS. My approach would be similar there - use one of the most popular choices, like MySQL or Postgres. Some online communities might state that MySQL has limitations, but that's irrelevant at my level. My goal is to become productive as fast as possible to build applications and my portfolio.

Some folks say that object-relational mappers (ORMs) are lousy practice. I would ignore this advice, too. ORMs are great for being productive fast and learning to store, read, and modify data in a database. Yes, one should absolutely know the lower-level language powering the database (e.g., SQL), but I can learn those later.

Step 5: Proof of work

Assuming I spend the time to bridge the gaps and learn the basics of the skills I lack, I need to show the world my skills. Building in public is the highest leverage I can do: I build something in public to show the world my skills, and by building, I further develop my skills.

I would build multiple apps that would showcase my knowledge. Starting simple is critical. I'd begin with building a personal website. It would be backed by a database with a landing page, an 'About me' page, and a blog archive. Then, something more advanced: a tiny clone of a favorite website. Again, simplicity is vital. If I tried to clone Reddit as a whole, I'd quickly get overwhelmed and fail. So, selecting a few core features and starting with them is crucial. Once I feel more confident in my abilities, I will go for the other, more niche features.

If I need inspiration, I would look at some indie products over at Indie Hackers and build clones. Cloning is not plagiarizing. Plagiarism can be illegal, but cloning is not. Especially when done for educational purposes. Not sure how a particular feature is built? Ping the maker via the Indie Hackers website (or Linkedin or Twitter) and ask them. Just give them context that you're trying to learn, not steal their customers.

Another idea is to look for public datasets or public APIs. Use the data to build a website around it. For example, here's a repository with a bunch that is free to use: GitHub - public-apis/public-apis: A collective list of free APIs. Use the free data and build an application around it.

Very important: proof of work is no proof if it can't be seen in others. So, any apps I would build must be online and accessible. I would deploy my app and tell the world about it. I'd put the code up on GitHub. Write a solid README. Do good commit messages and make them tidy. If I am unsure what a well-organized repo looks like, I will look at popular open-source projects on GitHub. The GitHub Explore feature is handy to discover new and popular repositories.

Remember the folks I spoke with on Linkedin and Twitter? I would send them the link to my new app, including the Github repository, thanking them for their input and celebrating the achievement of launching an app. I would also politely solicit their feedback. One never knows - they might check the code and give me tips or a review.

If I manage to build a few apps accessible online, with open-sourced code on Github that is well documented, I have my proof of work. My competency is online, free to be seen by any potential employer.

Step 6: Find my people

It's good to have a support network in difficult times. In my case, I would lean on my friends and family for support and a shoulder to cry on. But also, it's good to find my community. Find the people who are having struggles similar to mine.

Having a network of folks who have embarked on a journey like mine benefits my ego. I will know I am not the only one struggling. It will be a good reminder that many thousands like myself are out there, day in and day out, trying to break into the tech industry.

Nowadays, there are plenty of communities online. I would look for Discords where folks hang out. Here are some examples I've found in the wild - you can just click on the links to join the community:

• DEV's Dungenon - ±10K members at the time of writing

• Devcord - ±35K members at the time of writing

• Code Support - ±33K members

• The Coding Den - ±155K members!

Reddit is another way to take part in a community. Some useful Subreddits for newcomers:

• /r/FreeCodeCamp - subreddit to learn to code for free

• /r/ProgrammingBuddies

• /r/LearnProgramming

• /r/cscareerquestions - subreddit for questions regarding careers in Computer Science

• /r/webdev - subreddit for web developers

• /r/learn$LANGUAGE - there are many "learn" subreddits, such as /r/learnajvascript or /r/learnpython

Beware: joining these communities is not enough - I must engage. Engaging can mean more than just helping others. Helping others can feel daunting for newcomers - it's common for folks to self-censor due to feeling insecure about their knowledge or experience. In the beginning, I would engage by asking questions whenever I got stuck while building apps, but only for questions that Google, Perplexity, or ChatGPT could not give me a straight answer for. (Asking questions that are easy to find online is poor etiquette and a sign of laziness.)

In general, I would keep my vibes in check. Positive energy and a collaborative spirit go a long way. If I employ a helpful attitude in these communities, I know that in no time, I will have a small network of like-minded people going through a similar journey like myself whom I can connect and lean on in my career.

Step 7: Find my mentor

Until now, I've been working on learning the skills / closing the gap, and building a support network around me. An essential component of the support network is to find a mentor. As you can tell, there's a theme here already: people. Learning technical skills is no joke. Yet learning how to connect with people and nurture relationships is as difficult. Finding a mentor can also be nerve-wracking. But it doesn't have to be.

The mentor's profile

Before looking for a mentor, I need to decide on my mentor's profile. It's common to want to be mentored by an experienced person working at a fancy company, but it's unnecessary. It can be an impediment. Folks working at the fancy, MANGA(-like) companies are often unavailable as their jobs are demanding. More prominent companies attract more experienced folks, so these folks might also have families. Their free time is generally limited, and they might want to prioritize it differently.

But I know I don't need that experienced mentor. I would instead identify someone with just enough experience. Someone just a few steps ahead of me - someone five years ahead of me.

To maximize my chance of getting a 'yes', I want to also look for engineers that engage with their community. Look for people who write blogs, have a bunch of points on Stack Overflow, Reddit karma, or people who talk at/organize meetups. I look for folks who engage with their community beyond their day-to-day work. By targeting them, I'll have a better chance of finding a mentor, as these people already like to engage with and empower others.

Finding The One

I would start with LinkedIn. Like before, when I looked for advice to close the skill gaps. I would look for engineers with a more significant following who often publish posts or comment on people's posts. Recently, LinkedIn started a crowd-sourced platform for writing articles called "Collaborative Articles". By contributing to these collaborative articles, authors can get the "Community Top Voice" status - an award for their contributions. Folks having this badge can be a good candidate for a mentor. Message them!

Alternatively, if someone rejected me, I would pitch them to boost my message to their followers. These "Community Top Voices" typically amass a following as part of their special status. I would write a short and punchy post on Linkedin about my background, my journey, and that I am looking for a mentor. Then, I would ask the person to re-share my post with their network, significantly increasing the likelihood of finding a fitting mentor.

Next, I would use websites like The Mentoring Club, where people volunteer as mentors. Interested mentees can review mentor profiles, including work experience, expertise, passions, etc. Mentees can schedule a call with a mentor - they send a request, and, assuming the mentor accepts, they're well on the way to having a first session with a mentor.

Next, local meetups. I would use Meetup.com to see what's happening around me and attend some meetups. Once there, I would approach other folks and create relationships. I would refrain from jumping directly into asking people to be my mentors. I would get to know people, ask them to share their stories with me, and ask how I can help them. That's it. Once we've established a meaningful relationship, I might ask them to mentor me.

Keep in mind that mentorship must be a win-win situation. While the mentee might get more out of the relationship, mentors should still get something. If mentors don't get anything out of the mentorship, they won't be incentivized to do it. As a mentee, I would bring my best self whenever I meet my potential mentor.

Meeting mentors

To have a practical mentorship session, I have a clear goal in mind: I want to break into the industry. That's all that I am going to be talking about with my mentor. Nothing else. Having focus in my conversations shows them that I have my eyes on the prize. A personal connection with my mentor is valuable. But after getting to know them, I would spend every ounce of my mentor's energy and every second of their time focusing on the problem.

Showing focus and commitment is simple. I like to be on time. I come prepared with questions and topics to go over. I do my homework (if any). To listen attentively, I leave my phone out of sight. Or out of the room. I jot down notes. I do everything in my power to maximize my learning and my retention.

I would try my best to never run out of topics to discuss. I would build a topic bank from which I can always pull ideas. If you need inspiration for your mentorship sessions, here are a few ideas to start with:

• Feedback on my current project(s)

  • "I've been working on $PROJECT_NAME. Could you review my code and suggest areas for improvement?"

  • "What design patterns would be most effective for this project?"

  • "Here's a challenge I faced during this project. How would you have approached it?"

• Asking for guidance on my learning path

  • "What key technologies should I focus on learning next, based on my current skill set?"

  • "Can you recommend any courses or resources that helped you when you were at my stage?"

  • "What skills will be most valuable in the industry over the next few years?"

• Asking for general career advice

  • "Which career paths in coding do you see as most promising for someone with my background?"

  • "What skills are currently in high demand in the coding industry?"

  • "How can I align my learning path to meet the industry needs?"

Step 8: Interviewing

Next up: learning how to interview. Yes, "interviewing" is a skill of its own. If you don't believe me, ask any engineer who has switched jobs or works at a more prominent company. Or hop on YouTube and see how many tutorials on solving LeetCode questions there are. (Hint: countless!)

I wouldn't invest in LeetCode-like exercises for interviewing sake. Such coding challenges are more common in huge companies. But instead, I would learn all the unwritten rules and customs of interviewing in the industry. For example, how to structure my CV, answer interview questions, prepare for interviews, and so on.

Make my CV tight.

I've seen folks over-index on being prepared on the technical aspects but have yet to land an interview. Yes, solving a bunch of coding questions or experimenting with the language's standard library is very useful. Yet, I've witnessed these same folks, who are technically sound, send their CVs to job openings to no avail. They laminate that the market is terrible or that juniors are not in demand.

But I think that's wrong - no company will pass on a great junior candidate. At the very least, the recruiter will send a note back. Not receiving any feedback when sending my CV says nothing about the market. But it says about my CV. Picture this: I send my CV, and the recruiter receives it. They download the CV from the email. They open the CV. And the clock starts ticking. My CV has 30 seconds at most to convince the reader that I should get a chance at an interview with them. After those 30 seconds - it's decision time. If my CV does a good job - I'll get the interview. If not - I won't. It's as simple as that.

What happens behind the scenes eludes newcomers. They think it's their skills or their experience. Nope. It's the CV itself. Having a great CV is like wearing a tailored suit; both are customized to fit perfectly, making an excellent first impression and highlighting I am the best fit for the open role.

Practicing

Some of the free or open-source communities and websites for practicing software engineering interviews include:

1. Leetcode: Offers over 1050 software engineer interview questions and solutions and is one of the most well-known platforms for practicing coding skills.

2. HackerRank: Provides code challenges and interview preparation for developers and offers a substantial library of challenges for free.

3. Coderbyte: Offers full-stack coding challenges, interview preparation courses, and mock interviews, with over 500 challenges, articles, and videos across different domains.

4. Interviewing.io: A platform where software engineers can participate in mock and actual technical interviews, watch a library of video interviews, and take mock interviews with engineering hiring managers.

5. Pramp: Allows users to practice coding interviews through peer-to-peer mock interviews, helping them prepare for actual technical interviews for hiring companies.

These platforms offer a variety of resources, including coding challenges, mock interviews, and actual technical interview practice, to help software engineers prepare for interviews and improve their skills. I would lean into these, spending time to hone my interviewing skills with my mentor, where I would talk more about the "soft" sides of interviewing.

Sourcing jobs on Linkedin

I would look for jobs in companies where people are already working in the same positions I am learning about. For example, I wouldn't apply for a company job ad for a "full stack engineer" if there were no other full-stack engineers. In such a situation, it might mean that the company has no experience growing full-stack engineers. 

Also, I wouldn't use only the LinkedIn Jobs functionality. While it's excellent, this functionality is not tailored to juniors. I would use the search functionality and look for posts from recruiters mentioning junior or entry-level positions.

Next, I wouldn't apply directly via Linkedin. Once I see a job ad on Linkedin, I would contact the recruiter or the hiring manager of the company that posted the ad. Even better, I'd contact a potential colleague there. I would explain my situation, give them the context, show my proof of work, and ask for a referral. I'll likely get the referral with the right vibe and the evidence of work.

The same approach works for other social networks. The right approach is connecting with the people behind these companies and avoiding the paved path.

Step 9: Document my journey

I would start to document my journey. I would write about my experiences, challenges, and successes. Writing is a powerful tool. It's not just about keeping a record; it's about reflecting on what I'm learning. This process helps solidify my new skills. I think of it as talking to a friend about my day. I would start with a blog or a journal. I would write about what I learned today, a problem I solved, or a new idea that I got. This doesn't have to be a daily task. Even a weekly update is a great start.

When writing, I imagine explaining my day to someone who doesn't know much about the topic. This helps me break down complex ideas into simpler parts. It's a skill that will not only make my writing better but also improve my ability to communicate. Deconstructing and explaining technical topics to non-technical folks is an essential skill.

I wouldn't worry about making everything perfect. The goal is to share my journey, not write a textbook. I would share my successes, but especially my mistakes. Mistakes are valuable because they often teach the most important lessons. Over time, you'll see how far you've come, and others will.

I wouldn't write on other platforms, like Medium. I would do it on a personal blog, where I can own my content. Writing connects me with others who are learning and have been in the field for a while. It'll build me a network, get feedback from others, and learn from them.

Remember, everyone started somewhere, and many will appreciate the honesty and effort in my writing. It is critical to keep it consistent, genuine, and reflective of my personal journey. This way, my blog or newsletter becomes more than just a diary - it becomes a tool for learning, networking, and personal growth.

Step 10: Learn to unblock yourself

Being resourceful when working is crucial. There will be many times when I won't have someone to unblock me, so learning to struggle through the problem and finding a solution by myself is very important. Luckily, the tools nowadays are much better than what they used to be a decade ago. There are two types of tools to master: search engines and AI-powered chat-like tools.

Looking things up online, a.k.a. Googling

When I am stuck on a coding problem and turn to online search for help, the key is to be as specific as I can in my search. I would start by describing my issue with precise terms. For instance, I mention 'Python' along with the specific error message if I am dealing with a Python error. The more details I provide, the better my chances are of finding a relevant solution. It's also a good idea to include any specific tools, languages, or technologies I use. Yet, too many keywords can create diminishing returns, so it's important not to overdo it.

Another clever tactic is to combine different keywords in a way that targets my problem accurately. I'd think about pairing general concepts with specific issues. For instance, searching 'Python for loop syntax error' is more effective than a broad search like 'loop problem'. If standard terms lead me astray, I try adding version numbers or using technical jargon related to the issue. 

I use the minus sign (-) for unrelated results to exclude terms from my search. This helps filter out the noise and zoom in on the information that matters. Continuously tweaking the search terms and experimenting with different combinations is the way.

ML-Powered tooling

AI tools like ChatGPT and Perplexity.ai are the secret weapon for getting up to speed. These tools are fantastic for breaking down complex tech jargon into simple, understandable language. For example, to understand a tricky programming concept, I can pop a question to these apps, and they'll explain it in a way that makes sense. They're like having a patient mentor at one's fingertips, ready to clarify things without judgment.

These tools also come in handy when I'm stuck on coding problems. While they won't fix bugs for me, they're great at suggesting what could be going wrong and how to approach fixing it. They're also super helpful for quick answers to straightforward questions, like how to use a specific function in my code. This saves me time sifting through search results or documentation. Integrating these AI tools into the learning process can be a game-changer for beginners in tech, making the journey into tech smoother and more enjoyable.

Lastly, it's important to remember that while these tools are powerful, their knowledge is based on the information available up to a certain point. They might not have the latest data or be aware of recent developments. Also, unquestioningly trusting ChatGPT or similar tools is a mistake. It's essential to verify their results and supplement their suggestions with self-research.

And that’s it for this week! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

Subscribe now

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija