Andrew Wegner | Ponderings of an Andy - Leadership

Management Debt: When Leadership Patterns Rot

2026-04-30T13:15:00-05:00

Introduction¶

Engineering leaders talk about technical debt frequently. We track it, we visualize it, we plan around it, we explain it to executives. There's a related kind of debt that gets a fraction of that attention and, in my experience, does at least as much damage to engineering organizations. I've come to think of it as management debt - the engineering-leadership flavor of what recent research calls organizational debt: the accumulation of outdated structures, policies, and processes that quietly hinder how a company operates.

By management debt I mean the gap between how leadership is supposed to operate and how it actually operates. Decision rights that have quietly migrated to whoever speaks up first. Skip-levels that became calendar holds nobody runs. Quarterly planning sessions that turned into backwards-looking status reviews. Performance feedback that gets saved up for the yearly review cycle because nobody had the harder conversation in when a problem occurred.

None of that looks like failure in the moment. It looks like a function nobody changed for three years. It still works, technically. Every change to it just costs more than it should.

How management debt accumulates¶

Most of the management debt I've seen didn't enter the organization through a bad decision. It entered through a deferred one. It entered through a "best at the time" decision that was never revisited.

A skip-level got cancelled because a customer escalation came up. The next month it got cancelled again for similar reasons. After that it quietly fell off the calendar, "until things calm down." But, things never calm down. Six months later the engineering manager is making decisions that the director should be involved in, and the director doesn't know those decisions are being made.

The same pattern shows up in design reviews. A team starts skipping the architecture review for "small" changes. Over time, the definition of "small" expands. A year later, the team is shipping huge changes without review and finding integration issues in production that the review process was specifically designed to catch.

Each of these is defensible at the time. They look like sensible prioritization and efficiency, not debt. The problem is the same as with technical debt. The small concessions accumulate into a system that's worse than the one you designed, and at no single point did anyone make the call to make it worse.

The four patterns I see most¶

I've come to recognize four common patterns. Each has its own diagnostic and its own fix.

Decision rights drift¶

The clearest sign is that you can ask three people who's responsible for a particular call (production deploys, architectural decisions, prioritization of a bug over a feature) and get three different answers. The RACI chart says one thing. Practice has drifted somewhere else, usually because the formal owner delegated informally years ago and the delegation never got written down.

The fix is uncomfortable. List the decisions that matter. Write down who actually owns each one today, not who's supposed to. Then write down who should own it. Where those two lists disagree, you've got a decision to make and to communicate.

I've done this exercise on every leadership team. Every time, it surfaces things the leadership team didn't realize had drifted. Fast-scaling teams are particularly prone to this. Decision rights set when the team was eight people rarely survive contact with thirty.

Ritual decay¶

Skip-levels, design reviews, retrospectives, planning sessions. These are leadership rituals that exist for a reason, and they decay along a predictable path. First the rhythm slips ("let's skip this week"). Then the agenda hollows out ("we don't really have anything to discuss, let's just do round-robin status"). Then the meeting becomes a calendar hold that nobody prepares for and nobody gets value from.

The fix is to either kill the ritual or restore it to its original purpose. If you kill it, write down what it was supposed to do and confirm you're getting that signal another way. Keeping the calendar hold but letting it stay hollow is the worst of both worlds. People look at it, decide leadership doesn't take its own rituals seriously, and stop preparing for the ones that still matter.

Feedback latency¶

Healthy organizations give feedback close to whatever prompted it. Gallup's research is blunt about this: employees who get weekly feedback are far more likely to be engaged than those who only hear from their manager at year-end, and only 14% of employees say their performance review actually inspired them to improve. Organizations carrying management debt batch feedback into year-end performance reviews, where it lands as a list of surprises about events from eight months ago that nobody can do anything about.

This one is the hardest to fix because the people involved have to do something they've been avoiding for a year. The structural piece is making sure feedback has a low-friction venue. Consistent 1:1s, written notes, performance check-ins quarterly rather than annually. The behavioral piece is the one that actually matters: the leader has to commit to delivering feedback soon after whatever prompted it, and their own manager has to check that it's happening.

In my experience, this is where management debt does the most damage to retention. An engineer who hears "you should have been doing X differently for the past year" in a performance review either loses trust in their manager or starts interviewing. Often both. I've seen the same avoidance dynamic show up in unlimited-PTO programs - a perk turns into a liability when the management work behind it never happens.

Meeting metabolism¶

The slowest variant to spot is the gradual expansion of recurring meetings until calendar load makes deep work impossible for the leadership team itself. I like to call this "Calendar Tetris", and symptoms include frequent, overlapping meetings, often of a recurring variety. Each meeting was added for a defensible reason. The aggregate is that an engineering manager spends 32 hours a week in meetings and wonders why nothing strategic is getting done. On globally distributed teams the math gets worse, since synchronous slots compress into a few overlapping hours and "let's just add a recurring sync" becomes the default response to any coordination problem.

The fix is blunt. Cancel everything recurring for two weeks. Re-add only the meetings that someone actively missed. The recurring meetings nobody noticed missing weren't serving the purpose they were created for. They were calendar inertia, and they were eating the leadership team's capacity. Shopify did exactly this at scale in early 2023, deleting roughly 12,000 recurring meetings in a single calendar purge with a two-week cooling-off period before anything could be re-added. Their reported outcome was a 33% drop in time spent in meetings and a 25% increase in completed projects.

I've done this, and it's always refreshing when recurring meetings don't come back. Those weren't as needed as once believed.

How to find your own management debt¶

The diagnostic question I run on myself, and on every leadership team I've inherited, is this: What rituals are we running today that we wouldn't design from scratch if we were starting tomorrow? If the answer is "none," you're either not looking hard enough or you've genuinely just done a refactor.

Another version: where in our leadership operating model are we relying on heroics or institutional memory instead of process? The answers are the line items in your management debt portfolio.

A more concrete version I use with my staff: which decisions in the last quarter took longer than they should have, and why? The "why" almost always points to a piece of management debt. A missing decision right, a stale ritual, a communication channel that nobody runs anymore or that needs the help of management to clean up.

Why this matters more than technical debt¶

Technical debt slows code velocity. Management debt slows everything.

These are decisions that aren't being made on time, feedback that isn't landing, and rituals that aren't producing signal. They show up as engineers who feel like they're working harder for less output, leaders who feel like they're spending the whole day in meetings without making progress, and a strategic plan that everyone agrees with and nobody actually executes.

Engineering leaders are usually fluent in technical debt management. We track it, we explain its cost, we plan its repayment. We need the same discipline for the management practices themselves. Make it visible, talk about it explicitly, refactor it deliberately instead of waiting until the organization is genuinely broken.

Conclusion¶

Across the leadership roles I've held, the leaders I've seen succeed long-term aren't the ones with the most polished initial operating model. They're the ones who are willing to look at how they're actually leading, six or twelve months in, and fix what's drifted.

Management debt is real. It accumulates the same way technical debt does. It costs at least as much, and it doesn't show up in any dashboard you already track. The next time you catch yourself thinking "we should really restart that ritual" or "we should really write down who owns that decision," that's not a nice-to-have on a backlog. That's overdue maintenance, and the longer you defer it the more expensive it gets.

I Proved AI Could Beat Our Technical Interviews. Then I Had to Fix Them.

2026-03-25T15:00:00-05:00

The interview process I used to run¶

For years, I used timed online assessments as part of my hiring process. At PacketFabric, when we needed to scale the engineering team rapidly during our Series B, I helped evaluate several assessment platforms to find one that balanced candidate experience with the quality of signal we received as hiring managers. We landed on Woven, and it worked. The assessments helped us move quickly through a high volume of candidates and gave us comparable data points across applicants.

I had doubts, though. I've been opposed to LeetCode style interviews forever. Woven wasn't LeetCode as it provided amazing feedback to the candidate on what did and did not work. I liked the company so much that I joined Woven for a while. But even with the best assessment platform I'd found, I saw cracks. The candidates who passed the assessments and joined the team didn't always succeed in the ways I expected. Some produced clean code under time pressure but struggled to collaborate with the team. Others passed technical screens convincingly but couldn't translate that skill into shipping features in a real codebase with real constraints. The assessment told me they could solve a problem in isolation. It told me very little about whether they could do the actual job.

Then ChatGPT arrived, and my doubts became certainties.

In late 2022 and early 2023, I ran ChatGPT through technical assessments on LeetCode, TestGorilla, CodeSignal, Codility, HackerRank, and CoderByte. It passed most of them. Not marginally; it produced solutions that would have advanced through our pipeline. That wasn't a theoretical concern anymore. If a freely available tool could pass our technical assessment, we weren't evaluating engineering skill. We were evaluating test-taking ability, and we now had a machine that was better at test-taking than many humans.

That was 2022 and 2023. We are now several AI model generations beyond that early ChatGPT. Tools like Claude Code, Codex, Cursor, and GitHub Copilot are used by millions of developers daily. These aren't novelty chatbots any longer. They're integrated development environments that write, debug, and refactor production code. The gap between what AI could do when I ran those tests and what it can do today is enormous. Any assessment that was vulnerable to early ChatGPT is trivially solvable now.

I had to rebuild how I hire.

What timed assessments and take-homes actually measure¶

Timed assessments reward speed and pattern recognition under artificial pressure. That correlates poorly with the actual work. Nobody ships production code in 45 minutes with a countdown timer and no access to documentation. The skills that make someone fast on a Codility problem like memorized algorithms, familiarity with specific puzzle patterns, comfort performing under observation, are not the same skills that make someone effective on a team building real products.

Take-home projects have the opposite problem. Without time constraints or observation, there's no way to verify who actually did the work, how long it took, or what tools they used. Even before AI, take-homes had issues: they disproportionately disadvantage candidates with families or other time commitments, and they're difficult to evaluate consistently across candidates.

Both formats share a deeper flaw though. They optimize for a narrow technical signal while telling you almost nothing about how a person thinks, communicates, or works with others. I've seen candidates pass assessments convincingly and then struggle on the job because they couldn't explain their decisions to a colleague, couldn't adapt when requirements changed, or couldn't take ownership of a system beyond the specific code they wrote. The assessment didn't predict any of that. It just told me they could solve a contrived problem under contrived conditions.

I want to be fair to these tools, though. They feel rigorous and objective on the surface. That's why they're popular. The scores are comparable, the process is standardized, and it feels like you're making data-driven decisions. But the data is measuring the wrong thing.

What I look for instead¶

My core philosophy has stayed the same across companies even though the specific steps change based on the team, the roles, and the company's needs. The philosophy is this: I want to understand how someone thinks, how they communicate, and whether they take genuine ownership of their work. The specific technology matters, but it matters less than those three things.

How I evaluate depends on the level of the role.

Mid-level and senior engineers¶

For experienced candidates, I focus on past project deep-dives. I ask the candidate to describe something they built - not a rehearsed elevator pitch, but a real system they worked on. Then I poke at it.

The questions I ask depend on what the candidate brings up, and I rotate through several lines of inquiry based on what I'm hearing. If someone describes a system they architected, I'll ask about the tradeoffs they made and why. If they describe a project that clearly had rough patches, I'll ask what went wrong and dig into how they handled it. This isn't because "tell me about a failure" is a novel question, but because the follow-up conversation reveals depth. The most telling question, though, is usually some form of "what would you do differently if you built this again?" Candidates who were deeply involved in a project have learned something from it. They have opinions about what they'd change. Candidates who are exaggerating their involvement tend to stumble here because they haven't actually wrestled with the consequences of the original decisions.

About half of the candidates I interview can genuinely defend their decisions in this format. The other half can describe what they built but can't articulate why they made the choices they did, or what they learned from the experience. That's the signal. I'm not looking for perfect decisions. I'm looking for evidence that they understand systems deeply enough to reason about them, not just implement them.

For more senior and architecturally-focused roles, I lean harder on design tradeoff discussions. For mid-level engineers, I focus more on the "what went wrong" and "what would you change" angles, which are more accessible and still reveal a lot.

Junior engineers¶

Past project deep-dives work less well for junior candidates. They don't have enough experience to defend decisions they haven't had the opportunity to make yet. Asking a recent graduate to explain the architectural tradeoffs of their senior capstone project isn't a fair evaluation.

Instead, I use a small live coding exercise. Something that can be written in 5-10 lines of code, with multiple valid approaches. For example, a problem that can be solved iteratively and recursively. I ask them to write it one way and we talk through it for a minute or two. Then I ask them to write it the other way. I don't tell them in advance that I'll ask for the alternative approach. I want to see what they do naturally when the problem shifts.

The code itself is almost secondary. What I'm evaluating is the conversation. Can they reason about the difference between the two approaches? Can they articulate why one might be preferable in a given context? Do they get flustered when asked to think differently, or do they engage with the challenge? A junior engineer who writes imperfect code but can reason clearly about alternatives and ask good questions is far more promising than one who produces a clean solution but can't explain their thinking.

Leads and directors¶

For leadership roles, I shift to scenario and system design conversations. Less about code, more about organizational and architectural judgment. How would you structure a team to build a particular kind of system? How would you evaluate and prioritize a backlog of technical debt? How do you handle a situation where product and engineering disagree on timeline or scope? The signal here is similar to the engineering deep-dives. I'm listening for whether a candidate can reason through ambiguity, make a decision with incomplete information, and explain their thinking clearly. A strong candidate will ask clarifying questions, acknowledge tradeoffs, and arrive at a defensible position. A weak candidate will give a textbook answer that doesn't account for the messy reality of the scenario.

Technical product managers¶

I also interview Technical Product Managers (TPM), and the approach shares the same philosophy as the engineering deep-dives. I'll present a feature or problem that has already been solved so that I have detailed knowledge of what has worked. I ask them to walk through how they'd approach it. I'm watching how they think through the problem, what questions they ask, what tradeoffs they identify, and how they communicate their reasoning. Then during the conversation, I poke at their decisions the same way I would if I were working through the problem with a TPM on my team. Can they explain why they prioritized one approach over another? Can they articulate the user impact? Can they adjust their thinking when I introduce a constraint they hadn't considered? This fits directly into the communication signal I look for across every role which is the ability to reason through a problem, defend your position, and adapt when new information arrives.

The soft skills that predict long-term success¶

Technical skill gets someone through the interview. Soft skills determine whether they succeed on the team. I assess these through a combination of specific questions, observing behavior throughout the interview, and paying close attention to how candidates describe the systems and processes they've worked in.

Three signals have been the strongest predictors across my career:

Ownership without ego. I want someone who takes responsibility for the system, not just the lines of code they wrote. But ownership can become toxic when it turns into "this is my baby and it's always right and the user is wrong." The best engineers own the outcome for the user, not just the implementation. When something breaks, they don't deflect. But they also don't get defensive when someone suggests a different approach or when a user reports that the system isn't working the way they intended. You can often hear the difference in how candidates describe past work: do they talk about what "I built" in isolation, or do they talk about how the system served its users and how the team improved it over time?

Communication. Can they explain a technical decision to someone who isn't an engineer? Can they disagree with a colleague constructively? The interview itself is a communication exercise and I'm paying attention to how clearly they explain their past projects, how they handle follow-up questions, and whether they can adjust their level of detail based on the conversation. An engineer who can only communicate with other engineers who share their context will hit a ceiling quickly, regardless of their technical ability.

Curiosity and willingness to learn. The technology stack will change. The industry is already changing and AI has introduced so much disruption in such a short time that it is vital candidates are willing to learn and adapt. I've worked across many industries in my career, and the engineers who thrived through transitions were the ones who were genuinely energized by learning something new rather than threatened by it. In interviews, I listen for whether candidates describe their learning in terms of genuine interest or obligation. "I had to learn Kubernetes for the role" sounds very different from "I got interested in how our deployment pipeline could be more reliable, which led me to Kubernetes."

Designing interviews that AI can't shortcut¶

The ChatGPT experiment wasn't just a blog series - it fundamentally changed how I approach hiring. My current process is designed so that AI assistance is either irrelevant or immediately visible.

You can't have ChatGPT defend your past project decisions in a live conversation. When I ask a candidate what they'd do differently about a system they built two years ago, there's no prompt that generates an authentic answer. The deep-dive format is inherently AI-resistant because it's evaluating lived experience, not producible knowledge.

For the junior coding exercises, the code portion could theoretically be AI-assisted. But the follow-up conversation, "now write it the other way, and explain why you'd choose one approach over the other", reveals immediately whether the candidate understands what they wrote. I've caught candidates who clearly used AI for their solution and then could not explain their own code when I asked follow-up questions. The conversation is the evaluation, not the code.

My position on AI use in interviews is nuanced. I don't ban AI tools, but I do expect candidates to disclose if they're using them. If a candidate uses AI and tells me about it, we can have a productive conversation about how they used it and what their own contribution was. If we've asked, and they haven't disclosed, that's a failure of integrity that outweighs technical competence. When you're hiring someone to join a team, trust matters as much as skill.

This isn't a hypothetical concern. I've encountered candidates who were clearly using AI during interviews and couldn't explain their own answers. I'm not alone. CNBC reported in 2025 that tools like Interview Coder and Cluely now use invisible screen overlays that are undetectable by standard screen sharing, and hiring managers describe the telltale pattern of a pause, an "Hmm," and then a suspiciously perfect answer. An analysis of over 19,000 interviews by Fabric found that cheating adoption more than doubled from 15% to 35% between June and December 2025, with technical roles showing a 48% cheating rate.

I've also encountered the broader trend of candidates working at multiple companies simultaneously. This is a real and growing problem in remote engineering. A ResumeBuilder.com survey found that 37% of remote workers hold two full-time jobs, with AI tools making it increasingly feasible to juggle multiple roles within a standard workweek. Both of these trends make it even more critical that your interview process evaluates the actual human sitting across from you, not just the output they produce.

What I haven't solved yet¶

No hiring process is perfect, and I don't want to pretend mine is. There are areas I'm still actively working to improve.

Evaluating candidates from very different technology stacks remains a challenge. When someone's entire career has been in a language or ecosystem that's different from what we use, the past project deep-dive still works for assessing how they think, but it's harder to gauge how quickly they'll become productive in a new environment. I haven't found a clean solution for this that doesn't fall back on the kind of generalized assessments I've moved away from.

Scaling the process is another challenge. Deep-dive conversations take time and they're significantly more time-intensive per candidate than a timed assessment that can be administered asynchronously. When you're hiring for many roles simultaneously, the time cost is real. I've mitigated this by involving more of the team in interviews, but that creates its own overhead.

And the overall hiring pipeline is still slower than I'd like. The industry-wide process of sourcing, screening, interviewing, and closing candidates has friction at every stage. Improving my interview process doesn't fix the weeks lost to scheduling coordination, offer negotiations, and notice periods.

What actually matters¶

I've been hiring engineers across industries for nearly two decades and for companies ranging from pre-seed startups to Fortune 500 corporations. I've been wrong about candidates in both directions; people I was confident about who didn't work out, and people I had reservations about who became some of the strongest members of the team.

What I've learned is that the interview process should evaluate what actually matters on the job: Can this person reason about complex systems? Can they communicate clearly and work constructively with others? Do they take ownership of outcomes, not just code? Are they honest about what they know and what they don't?

No timed assessment answers those questions. A conversation does.

The Remote Engineering Leadership Playbook: Why Distance Doesn't Diminish Performance

2025-08-22T09:00:00-05:00

Remote Engineering Works When Done Right¶

When the U.S. Bureau of Labor Statistics released its comprehensive analysis of remote work productivity in 2024, something stood out. A one percentage-point increase in the percentage of remote workers is associated with a 0.08 percentage-point increase in total factor productivity. This covered over 60 industries from 2019-2023 (pre and post pandemic).

Rephrasing that slightly, as the number of remote workers increase at a company, the total productivity increases at the company.

For engineering leaders, this validates what many of us have seen firsthand. Remote engineering teams can outperform their co-located counterparts when proper processes exist. The difference between success and struggle lies in having the right systems in place.

After scaling multiple engineering teams, I've learned that distance becomes a liability only when we lack intentional systems. The companies thriving with remote engineering teams have built deliberate frameworks for collaboration across timezones, asynchronous communication, and meaningful ways of measuring the team's results.

Remote Engineering Success¶

Cross-Timezone Collaboration That Actually Works¶

The biggest mistake I see engineering leaders make is treating timezone differences as a scheduling problem when they should approach it as a workflow design challenge. With 80% of software engineers working at least partially remote by the end of 2025, timezone optimization becomes a core competency for leaders.

The Follow-the-Sun Development Model

Instead of forcing everyone into the same working hours, successful teams design workflows around natural handoffs. The key is documentation driven handoffs. Each transition requires clear context about what was accomplished, explicit next steps and acceptance criteria, identification of blockers and dependencies, and quality gates that prevent broken work from moving forward.

Strategic Overlap Windows

While asynchronous work drives the majority of productivity, you still need dedicated synchronous time for problem-solving and relationship building. I've found that scheduling dedicated overlapping windows a couple times per week provides face-to-face interaction without constraining individual productivity. Teams need at least one session that focuses on technical discussions and a second that builds team culture. Be intentional about these meetings though. To many and you fall into the trap of making this a scheduling problem. To few, and your team starts siloing itself.

Remote teams need fewer but more intentional synchronous touchpoints instead of trying to replicate in-office meeting cadences.

Asynchronous Communication as a Strategic Advantage¶

GitLab's engineering team scaled from 100 to 280 engineers in 1.5 years while remaining fully remote in in the early 2020s. They deliberately avoided making their primary productivity metric, Merge Request Rate, an individual metric because they wanted to encourage collaborative behavior rather than siloed competition.

The takeaway from this, to me, is that successful remote teams optimize for collective intelligence rather than individual heroics.

Documentation-First Decision Making

Every architectural decision, technical specification, and process change should be documented before it's discussed. Writing forces precision in thinking while enabling asynchronous input from team members across timezones. This approach creates institutional memory that survives role changes and allows ideas to be evaluated on merit rather than presentation skills.

Structured Communication Protocols

Remote teams need explicit protocols for different types of information. Urgent blockers require immediate Slack notifications with clear context. Technical discussions benefit from a structured request for comments process. Status updates should follow standardized formats that enable quick scanning. Relationship building happens through dedicated informal channels and virtual chats.

The goal is more effective communication that respects individual deep work time while enabling collective progress, instead of simply increasing communication volume.

Meaningful Metrics That Drive Performance¶

Most remote engineering initiatives fail because they measure activity instead of impact. The DORA metrics provide a research-backed framework for measuring what actually matters.

Deployment Frequency measures how often your team ships code to production. Lead Time for Changes tracks the time from commit to deployment. Mean Time to Recovery shows how quickly you recover from production issues. Change Failure Rate calculates the percentage of deployments that cause problems.

These metrics work particularly well for remote teams because they focus on outcomes rather than presence. A team that deploys multiple times per day with low failure rates is performing well, regardless of whether they're working from an office or their kitchen table.

Team-Level Indicators That Matter

Beyond DORA metrics, successful remote engineering teams track cross-team collaboration frequency to prevent silos, knowledge sharing effectiveness measured by new team member productivity timelines, sprint predictability showing whether teams can reliably estimate and deliver, and technical debt management indicating whether the team builds for today or tomorrow.

The key is making these metrics visible and actionable. GitLab makes their engineering productivity metrics publicly available, creating accountability and continuous improvement.

Culture at Scale¶

Technology and processes enable remote work, but culture makes it sustainable. The most successful distributed engineering teams I've worked with share common cultural characteristics.

Ownership Over Oversight

Remote work amplifies individual accountability. When you can't rely on hallway conversations and office presence, team members must take genuine ownership of their commitments. This requires hiring for self-direction and creating systems that support autonomous decision-making.

Mentorship Through Documentation

Traditional mentorship happens as junior developers overhear senior conversations and absorb knowledge informally. Remote teams must be intentional about knowledge transfer through code reviews, architectural decision records, and documented retrospectives.

Celebration and Recognition

Remote teams need to work harder at celebrating wins and recognizing contributions. Without spontaneous high-fives and impromptu team lunches, recognition becomes a deliberate practice that requires system and consistency.

The Competitive Advantage of Getting This Right¶

The Bureau of Labor Statistics data reveals an something else too. A 1 percentage-point increase in the percentage of remote workers is associated with a 0.4 percentage-point decrease in growth in unit office building costs. This extends beyond productivity to sustainable economics, and makes me raise an eyebrow at the number of return of office mandates we have been seeing.

Companies that master remote engineering practices can access talent from anywhere rather than just expensive tech hubs, reduce operational overhead without sacrificing performance, build more resilient teams that aren't dependent on physical proximity, and create competitive advantages through superior asynchronous collaboration.

The question has shifted from whether remote engineering teams can work to whether your organization will develop the processes and culture to unlock this advantage. Many companies continue treating remote work as a necessary accommodation rather than recognizing it as a strategic opportunity.

Remote engineering success requires intentional design rather than hoping things work out naturally. For leaders willing to invest in the right frameworks, the returns in productivity, talent access, and competitive positioning are substantial and measurable.

Junior Engineer Crisis: How AI Code Generation is Reshaping Engineering Teams

2025-08-18T09:00:00-05:00

The Data That Changes Everything¶

The software development industry is experiencing a shift that's happening faster than most organizations realize. Three statistics captured my attention this year, and collectively, they paint a picture of an industry in transition:

AI now generates 41% of all code, with 256 billion lines written in 2024 alone, according to Stability AI CEO Emad Mostaque.
Software engineer job listings are down 35% from five years ago, according to The Pragmatic Engineer's analysis
AI tools make experienced, open source, software engineers 19% slower, not faster, based on a randomized controlled trial by METR Research

That last statistic flies in the face of all stories we're seeing at this point in 2025. Through my time scaling engineering teams, I've learned to pay attention when data contradicts conventional wisdom. If AI is making experienced engineers slower, what does that mean for how we think about productivity, learning, and career development in software engineering?

The implications extend far beyond individual productivity. They touch the core of how engineering teams function, how knowledge transfers between generations of software engineers, and ultimately, how we build the technical leaders of tomorrow.

The Productivity Paradox¶

The conventional narrative around AI in software development has focused on speed and efficiency. AI improves employee productivity by up to 66% across various roles, according to recent studies. Yet when it comes to experienced software engineers, the opposite appears to be true.

The METR Research study revealed that when experienced engineers used AI tools, they took longer to complete tasks compared to working without AI assistance. This finding challenges the central assumption driving AI adoption in engineering teams.

Why does this happen?¶

In my experience, software development isn't just about code generation. It's about problem-solving, architecture decisions, and understanding complex system interactions. When software engineers rely on AI to generate code, they often spend additional time not doing these. Instead they are reviewing and understanding what the AI spit out to ensure it aligns with system requirements. Then they spend time debugging the code due to missed requirements, edge cases, or lack of context provided to the coding assistant.

This productivity paradox reveals something crucial. The value of software development isn't in typing speed. It's in thinking speed.

Reality Check¶

Meanwhile, almost all companies are investing in AI, but just 1% believe they are at maturity, according to McKinsey's 2025 workplace analysis. This suggests that even organizations themselves are struggling to effectively integrate AI tools into their development processes.

The disconnect between AI's promise and its current reality in software development creates a unique opportunity for engineering leaders who understand how to navigate this transition thoughtfully.

The Mentorship Gap¶

Traditional software engineering career progression has followed a predictable pattern:

Junior Engineer -> Mid-level Engineer -> Senior Engineer -> Technical Lead

This progression relied heavily on mentorship, code reviews, and the gradual transfer of knowledge from experienced engineers to new team members. AI is disrupting this learning pipeline in ways we're just beginning to understand.

The Traditional Knowledge Transfer Model¶

Historically, junior engineers learned through writing code that was reviewed by senior engineers. They also participated in pair programming and code reviews that taught best practices and patterns, and working on increasingly complex tasks. Crucially, they also debugged their own mistakes and learned from failure. Generative AI deprives the youngest team members of this skill because they are debugging code that was generated for them rather than by them. They don't have the depth of knowledge over this code snippet. They haven't spent hours working to solve a problem in this one line of code. The failure of the code is not their own, it's the AI's.

Each of these steps built not just coding skills, but engineering judgment to teach them the ability to make good technical decisions under uncertainty.

The AI-Disrupted Model¶

Now, increasingly, the model is that the AI generates code based on natural language specifications. Then a senior, not junior, engineer reviews the output. As the debugging loop starts, the focus is on the AI prompt engineering instead of the code. Code reviews become a validation of the AI and aren't teaching moments any longer. Junior engineers solve less problems and babysit the AI instead.

This shift significantly changes the nature of mentorship on engineering teams.

The Hidden Cost¶

When senior engineers spend their time reviewing AI-generated code instead of mentoring junior engineers, we lose the critical element of human knowledge transfer.

A senior engineer reviewing a junior's code can ask questions like: - "Why did you choose this approach?" - "What other options did you consider?" - "How would this handle increased load?" - "What happens if this service is unavailable?"

These questions build engineering judgment. But when reviewing AI-generated code, the questions become: - "Did the AI choose the right pattern?" - "Does this handle our edge cases?" - "Is this consistent with our architecture?"

The learning opportunity shifts from building problem-solving skills to validating AI decisions.

What We're Really Losing¶

The impact of AI on junior engineering roles goes beyond individual career paths. We're potentially losing institutional knowledge, problem-solving capabilities, and the human intuition that comes from learning to code through struggle and iteration.

Problem Decomposition Skills¶

One of the most valuable skills a software engineer develops is the ability to break complex problems into smaller, manageable pieces. This skill typically develops through experience. This is through encountering problems that are too big to solve all at once and learning to approach them systematically.

When AI handles this decomposition automatically, junior engineers don't develop this critical thinking muscle. They become skilled at describing problems to AI rather than solving them independently.

Debugging Intuition¶

Experienced engineers often talk about having a "gut feeling" about where bugs might be hiding or what might cause a system to fail under load. This intuition develops through years of debugging their own mistakes and understanding how systems fail in practice.

AI-generated code fails differently than human-written code. It might be syntactically correct but miss business logic edge cases. It might follow patterns perfectly but make assumptions about data that don't hold in production. Learning to debug AI code is a different skill from learning to debug human reasoning errors.

Architectural Thinking¶

Understanding why certain architectural patterns exist, when to apply them, and how they impact system behavior requires experience with the consequences of different choices. This understanding traditionally developed through making mistakes, seeing systems break, and learning from the aftermath.

When AI makes many of these architectural decisions automatically, junior engineers may learn to recognize good patterns without understanding why they're good or when they might be inappropriate.

The Compound Effect¶

Perhaps most concerning is the compound effect of these changes. If junior engineers don't develop problem-solving skills, debugging intuition, and architectural thinking, who becomes our next generation of senior engineers?

Software engineers are finding it harder to get jobs in 2025 due to changing hiring standards, according to analysis from the software engineering community. The bar for what constitutes "junior engineer" skills is rising, but the pathways to develop those skills are being disrupted by AI.

The Strategic Response¶

The organizations that thrive in this transition won't be the ones that embrace or reject AI wholesale. They'll be the ones that thoughtfully integrate AI while preserving the human elements that create strong engineering teams.

Understanding the Market Reality¶

Despite these challenges, employment opportunities for software engineers are still expected to grow by 20%, according to recent market analysis. This suggests that demand for engineering talent remains strong, but the nature of that talent is evolving.

McKinsey's analysis indicates that AI has the potential to fundamentally transform software development processes, but successful transformation requires deliberate strategy, not just tool adoption. This point bears repeating because it's vital for leaders to understand.

Attention

Successful transformation requires deliberate strategy, not just tool adoption

Bringing Copilot, Cursor, Claude Code or other AI coding assistants to your team does not guarantee success. It is a step in being successful in the AI transformation. It is not the step.

Three Strategic Approaches¶

Based on my experience scaling engineering teams and observing successful AI integration, three strategic approaches are emerging.

The first approach is redefining what it means to be a "Junior Engineer." Instead of eliminating junior positions, successful organizations are redefining what junior software engineers need to be good at. Traditionally, a junior engineer would be able to write syntactically correct code, follow team development patterns, understand the language and framework used by the team to a degree, and be able to implement requirements that are well defined.

However, a new AI-era junior engineer needs different skills. They need to be able to analyze and decompose a problem, showing system thinking and architecture understanding. This enables them to collaborate with AI coding assistants to generate solutions that actually solve the problem. Critically, they can perform a review of this output.

The most effective teams I've observed use AI as a teaching tool rather than a replacement for learning. Junior software engineers work with both AI tools and senior engineers, using AI to handle boilerplate while focusing human mentorship on architectural decisions and problem-solving approaches. This keeps several of the mentorship gaps minimal and builds a foundation that today's junior engineers can build on as they grow in their careers.

I've also heard of teams implementing regular "AI-free" coding sessions for engineers to ensure they can solve problems without the assistance of the AI tooling to build their early troubleshooting and debugging muscles. This type of thing also has been extended to code reviews, where an engineers must be able to explain why the AI tool took certain approaches and if their are alternatives that might have been better.

Personally, these approaches feel somewhat academic. A junior engineer is still a professional not a student in school. I think there could be good training around these ideas, but I don't think it should feel like we are taking away a tool. Instead, teach how to use it correctly while filling in the knowledge gaps.

In my experience, successful teams are making knowledge transfer deliberate through recording architectural decisions that were made and what alternatives were considered. Through troubleshooting sessions, problem solving sessions, and "pair support" to dive into complex system problems.

Mentoring from anyone to anyone is important too. Everyone on the team has something to contribute and teach. Whether it's complex system architecture that a senior engineer shares with a more junior team member or having a junior engineer lead a session on how they solved a problem. All of this is important for the whole team.

Redefining Junior Engineer Value¶

The key insight is that AI doesn't eliminate the need for junior developers. It changes what makes junior software engineers valuable, though.

Code Generation to Code Curation¶

In an AI-first world, junior software engineers become code curators rather than code generators. They will evaluate AI generated solutions for correctness, efficiency and maintainability. They'll identify edge cases the AI misses. They'll take AI generated code and ensure it works within their area of responsibility.

New Core Competencies¶

The most successful junior software engineers I've worked with in AI-enabled teams demonstrate the ability to think about entire systems, assess code quality, break down problems clearly, and strive to learn and adapt to new tools which allows them to build a method of debugging code they didn't write themselves.

Looking Forward¶

The software engineering industry is experiencing a shift, but it's not the first time. We've navigated the transition from assembly language to high-level languages, from procedural to object-oriented programming, from desktop to web to mobile development. Each transition created new opportunities for those who adapted thoughtfully.

The current AI transition is no different, but it requires us to think carefully about what we're optimizing for. If we optimize purely for short-term code generation speed, we risk creating a future where we have powerful AI tools but fewer humans who understand how to use them effectively.

The Organizations That Will Win¶

The organizations that thrive in this transition will be those that preserve human judgment while leveraging AI capabilities. Organizations that invest in developing people while adopting new tools and capabilities will have a key success factor. These are the organizations that create space for engineers to learn and build engineering thinking into their processes. Most importantly, teams that maintain their cultural values while adapting processes will find engagement instead of resistance.

The Individual Path Forward¶

For individual engineers, especially those early in their careers, the path forward involves:

Embracing AI as a tool while building problem-solving skills that transcend any specific technology.
Focusing on system thinking and architectural understanding that AI currently cannot replicate.
Developing communication skills that allow you to work effectively with both AI tools and human teams.
Building debugging and quality assessment capabilities that work regardless of who or what generated the code.
Maintaining curiosity about how things work, not just how to make them work.

Conclusion¶

The junior engineer crisis isn't really about AI replacing entry-level engineers. It's about ensuring that as we integrate powerful new tools into our development processes, we don't lose the human elements that create strong engineering teams and effective technical leaders.

I argue that every significant technology shift creates winners and losers. The winners are those who adapt early and thoughtfully, who understand both the capabilities and limitations of new tools, and who invest in building the human skills that remain uniquely valuable.

The current moment represents a unique opportunity for engineering leaders to shape how AI integration happens in their organizations. The choices we make now about hiring, training, mentorship, and team structure will determine whether AI makes our engineering teams stronger or simply faster.

AI is already reshaping our industry. The question is whether we'll guide it in directions that build stronger teams and better engineers, or whether we'll optimize for short-term productivity at the expense of long-term capability.

The junior software engineers we hire and train today will become the senior engineers leading teams in 2030. How we prepare them for that role, in partnership with AI rather than in replacement by it, may be one of the most important strategic decisions we make as engineering leaders.

Please join the conversation over on LinkedIn. I've split this article across three posts over there and would love to hear your feedback

Leading Distributed Teams: Lessons from Managing Global Engineering Teams

2025-04-15T01:00:00-05:00

Introduction¶

Leading engineering teams across multiple time zones has been a defining part of my career. I have taken courses on how to manage a remote team, how to implement TeamOps (both offered by GitLab) and I've managed teams spanning half of the global time zones, with team members located across every continent except Antarctica. This global distribution brings tremendous advantages in terms of talent access and round-the-clock development capability, but it also presents unique leadership challenges that require intentional strategies.

As software development continues to embrace remote work - kind of, it has started falling out of favor since the end of the pandemic - the ability to effectively lead and scale distributed engineering teams has evolved from a nice-to-have skill to a critical competency for senior leaders. The lessons I've learned managing global teams have shaped my leadership approach and provided insights that apply across both to engineering and to the broader organization.

Building Foundations for Distributed Success¶

The foundation of any successful distributed team begins with intentional communication. Tools like Slack, Zoom (with recording capabilities), Atlassian suite (Jira/Confluence), GitHub/GitLab, and collaborative document platforms like Google Workspace aren't just conveniences. They are the essential connective tissue of distributed teams.

However, having the right tools is only the beginning. More important is establishing clear principles for how these tools should be used. In my experience, the most successful distributed teams operate with a strong bias toward asynchronous communication. This means documenting decisions thoroughly, creating detailed specifications in advance of implementation, and ensuring appropriate synchronous discussions are recorded and summarized for team members in different time zones. Things like team meetings, troubleshooting sessions, and deep dives should be recorded and shared so that others can consume this information too.

Documentation is the backbone of effective collaboration. Unlike co-located teams that can rely on impromptu conversations or whiteboard sessions to clarify questions, distributed teams need comprehensive documentation that stands on its own. This includes architectural decisions, specification documents, onboarding guides, and even meeting notes.

A study by GitLab in 2021 (during the height of the pandemic) found that less than half of respondants felt their company was sharing company goals, creating and documenting processes and standards or promoting visibility across teams well. Intentional communication is important in all work places, but even more so when everyone is located in geographically different areas of the world.

I've found that building a "document-first" culture pays enormous dividends. When team members know that the first question in response to "How do I...?" will be "Did you check the documentation?", they naturally begin to contribute to and rely on that shared knowledge base. This reduces repeat questions, accelerates onboarding, and creates a more equitable information environment across time zones.

Decision-Making Frameworks Across Time Zones¶

One of the most challenging aspects of leading distributed teams is balancing the need for inclusive decision-making with the necessity to move projects forward. Over time, I've developed a time-gated decision framework that respects input from all regions while preventing decision paralysis.

For non-emergency decisions, I post proposals to our shared channels with clear timelines for feedback. For example: "I'll be creating Jira stories based on this architectural approach starting next Monday unless concerns are raised." This provides a minimum of one business day (often more) for team members across all regions to review and comment, while also creating a clear decision point that prevents endless deliberation.

For decisions requiring input from specific individuals, I'll explicitly mention them in the initial message. This creates accountability while also signaling to others who the key stakeholders are for that particular domain.

Not all decisions can wait, of course. Production outages or customer-impacting bugs demand synchronous communication and rapid response. In these cases, available team members need to be empowered to make decisions with the information at hand, with the understanding that these decisions will be reviewed and possibly refined once more of the team is available.

The balancing act of knowing when to wait for comprehensive input versus when to move forward with available information is one of the most nuanced skills in distributed leadership. In my experience, being explicit about which type of decision is being made helps team members adjust their expectations appropriately.

Technical Infrastructure for Global Development¶

The technical infrastructure supporting distributed development deserves particular attention. Continuous Integration/Continuous Deployment (CI/CD) pipelines, which are beneficial for any engineering organization, become absolutely essential for distributed teams. Automated testing, code quality checks, and deployment processes create consistency across time zones and reduce the risk of human error. This isn't limited to just a "time zone" thing though. It creates consistency across the team. Everyone's code, from the newest member of the team to the most veteran member, has their code commits go through the exact same process.

Code review practices need careful consideration in distributed environments. When reviewers might be asleep during a developer's working hours, teams need clear expectations about review timeframes. I emphasize that while we strive for quick reviews, team members should be prepared to either continue with different work or pivot to another task if a review is delayed. As the team grows and more individuals are working similar hours these delays will reduce, but initially, it is a concern that the team members have delibrately work on so that someone isn't always delayed.

Deployment strategies must also account for global distribution. Whether your team deploys each commit directly to production or follows a more scheduled release cadence, the key is establishing clear, documented processes that anyone on the team can follow regardless of location. When setting up these processes, consider who needs to be available during deployments, how deployment failures will be handled across the team, and whether certain deployment windows should be avoided due to regional holidays or weekend coverage.

In my experience, the most successful approach is establishing deployment processes that don't require real-time coordination between team members in different time zones. This might mean investing more heavily in automated testing, feature flags, and rollback capabilities, but the resulting independence pays dividends in team efficiency and satisfaction.

A Support Model¶

One of the natural advantages of a globally distributed team is the ability to provide around-the-clock coverage without requiring anyone to work unusual hours. We've implemented a rotation support model, where team members handle support duties during their local working hours. This creates continuous coverage while respecting everyone's work-life balance. Depending on the product, this could mean that the team only provides support during business hours or it could mean that the support follows the sun. In either case, the type of support provided must be clearly communicated to both the team and to end users.

This doesn't mean team members are never contacted outside working hours. True emergencies sometimes require waking someone with specialized knowledge. However, two important principles guide these situations:

First, if someone is contacted outside working hours to address an issue, they receive compensatory time off. This creates accountability in the escalation process. People think twice before waking a colleague unless truly necessary.

Second, and perhaps more importantly, each off-hours escalation triggers a review of our documentation and training. If someone needed to be woken for a particular issue, that indicates a gap in our knowledge distribution that needs to be addressed. This transforms what could be a negative experience into an opportunity for team improvement.

Over time, this approach creates robust documentation and broader knowledge distribution across the team, reducing the frequency of off-hours disruptions and building resilience into the organization. This is important, because documentation takes time. It's rarely a one shot deal.

Evaluations in Distributed Teams¶

Evaluating performance fairly across distributed teams requires deliberate attention to measurable outcomes rather than observable behaviors. I focus primarily on deliverables. Are teams hitting their targets and delivering on time and on budget? Are we meeting the KPIs we've established for deployments, code reviews, specifications, feature delivery, and performance improvements?

For managers specifically, I evaluate whether they're maintaining regular one-on-one meetings with all team members, regardless of location, and whether they're developing clear career succession and training plans for each report. These expectations apply uniformly across the organization, creating consistency in how leadership effectiveness is measured.

To ensure that geographical distance doesn't create invisible barriers to advancement, I maintain skip-level one-on-ones with team members across all regions. This gives everyone direct access to higher-level leadership and provides me with unfiltered insights into how to team is operating and individual contributions that might otherwise be obscured by distance.

I've found that managers who excel in distributed environments share certain qualities: they communicate proactively, document thoroughly, avoid making assumptions about team members' contexts, and create equitable opportunities for visibility and recognition regardless of location. These behaviors become key elements in leadership development and promotion criteria.

Developing Talent Globally¶

Hiring for distributed teams requires evaluating candidates not just for technical skills but for their ability to thrive in a remote, asynchronous environment. Beyond the job-specific requirements, I look for clear written and verbal communication skills, as team members will interact with colleagues, leaders, and customers from diverse linguistic and cultural backgrounds. Comfort with asynchronous work patterns and self-direction is essential, as are strong documentation habits that support knowledge sharing. Cultural adaptability and awareness round out the key attributes that predict success in distributed environments.

Once hired, ensuring equitable career development opportunities across regions becomes essential. During review cycles, we systematically discuss everyone's performance and growth trajectory. I expect managers to speak knowledgeably about each team member's contributions and aspirations, regardless of where they're located.

The skip-level one-on-ones mentioned earlier serve a dual purpose here. First, they help identify talent that might otherwise be overlooked due to geographical distance from headquarters or senior leadership. These conversations also build relationships that help me understand individual motivations and career goals across the organization.

One particularly effective practice has been creating cross-regional project teams that give team members exposure to colleagues and challenges outside their immediate locale. This broadens perspectives while creating mentorship and leadership opportunities that might not arise within more regionally confined teams.

Conclusion¶

As I've moved through increasingly senior leadership roles, the principles of effective team management have become even more important to my leadership approach. The future of engineering leadership demands comfort with distributed teams. Demands. Leading a team, whether it's fully remote or hybrid, is a skill that leaders need if they want to have access to talent.

The most successful technical leaders in this environment will be those who design systems and processes that work asynchronously by default, create cultures where documentation and knowledge sharing are valued and rewarded, and balance inclusive decision-making with the need to move forward. They will build technical infrastructure that supports distributed development, implement support models that leverage global distribution, ensure performance evaluation focuses on outcomes rather than presence, and develop hiring practices that identify talent suited for distributed work.

These capabilities represent the future of engineering leadership at the highest levels. For aspiring technical leaders, developing comfort and competence in distributed team management isn't just a nice-to-have—it's increasingly essential preparation for senior technical leadership roles.

Technical Debt Management: A Strategic Approach

2025-04-08T09:00:00-05:00

Introduction¶

The term "technical debt" has become a catch-all phrase, it's used to describe anything from poorly written code to outdated systems. But at its core, technical debt represents the very real trade-off of choosing immediate delivery over long-term maintainability. For companies caught between aggressive timelines and the need for sustainable systems, managing this debt becomes more than just a technical challenge. It's a strategic imperative.

Understanding Technical Debt¶

Technical debt manifests differently at various companies. Large organizations struggle with legacy systems built decades ago, while smaller companies struggle with systems built hastily last quarter that are already creaking under unexpected scale or scope expansion.

The primary sources of technical debt during rapid scaling often emerge from several common scenarios. I've witnessed early architectural decisions made with limited information create significant challenges. When we built our first API at a one startup, we made assumptions about how users would utilize the API and the portal built on top of it that proved incorrect. We made assumptions about our own product line that didn't hold true as we scaled. As our user base grew, as our product line grew, as our internal structure grew, we found that we'd built ourselves into a cage that wasn't easy to build our way out of. Acquisition integration introduces another layer of complexity, as we often need to integrate systems built with different architectural assumptions and technical standards.

Feature pressure also plays a huge role. When racing to meet competitive threats or capitalize on market opportunities, corners get cut. These aren't necessarily bad decisions at the time, but they accumulate over time. Team rotation creates knowledge gaps. As teams and companies scale, original architects and developers move into management, other roles, or to other companies taking vital context with them if proper knowledge transfer isn't prioritized.

The "move fast and break things" ethos that drives early success can quickly become a liability if technical debt isn't managed proactively. In these environments, yesterday's clever hack becomes today's bottleneck, and today's workaround becomes tomorrow's single point of failure.

The Real Cost of Technical Debt¶

Technical debt is often discussed in abstract terms, making it difficult for non-technical stakeholders to appreciate its impact. To make these costs tangible, I find it helpful to categorize them into different areas of impact.

Unmanaged technical debt progressively slows development. What once took days begins taking weeks as developers navigate around increasingly brittle code. Systems built around technical debt typically require more hands-on management. For example, in one role, we found support was seeing the same pattern of problems over and over again, despite engineering effort to solve the problem. Engineers were spending so much time maintaining these systems that new development slowed to a crawl.

Which leads to what I think is the most damaging aspect of unmanaged technical debit. Stiffled innovation. When engineers spend their creative energy working around limitations rather than solving new problems, competitive advantage erodes. This cost is hardest to quantify but most devastating long-term. Technical debt becomes most visible when it impacts customers. Whether this manifests through outages, performance issues, or security vulnerabilities, it impacts customers in some way. By then, the solution is typically more expensive and disruptive than if addressed proactively.

When to Address vs. When to Defer¶

Not all technical debt requires immediate attention. The key is distinguishing between strategic debt that enables necessary velocity and toxic debt that creates compounding problems. Here's how I approach these decisions:

The Upgrade Case Study¶

As I mentioned above, at one company, we faced a critical decision about our API infrastructure. We had built an initial API quickly as a skeleton for the product, but it wasn't designed for the scale and feature set we now needed. As the team grew rapidly, we had to decide whether to focus exclusively on building a new production ready API, or gradually migrate from old to new while continuing feature development on both.

After analysis, we estimated that implementing new product features in the old API would actually take longer than building a robust new API and implementing the new features there first. The tipping point came when our team estimated that one specific new product line would take less time to deliver by building the skeleton of a new API, setting it up properly, and implementing the new feature than it would to build the feature into the current API.

The clean-cut approach allowed new team members to focus entirely on the new API, infrastructure, and features. They came up to speed quickly by building a product they knew from the ground up. We ported the old API functionality to achieve parity, added new features as an incentive for customers to migrate, and then deprecated and ultimately shut down V1.

This counterintuitive approach, where addressing technical debt actually accelerated delivery, is exactly the kind of strategic analysis companies need.

Why Early Is Cheaper¶

A fundamental principle of technical debt management is that the cost to update almost always increases with time. In my experience, moving one version forward is generally easier than moving two, which is easier than moving three. Waiting until something reaches end-of-life means you're multiple versions behind, increasing the likelihood that functionality you rely on has been deprecated or removed.

The same principle applies across development. Finding problems in development is cheaper than finding them in QA, which is cheaper than finding them in production. Security follows this curve most dramatically. Addressing vulnerabilities during development is vastly cheaper than responding to a public security breach.

When discussing technical debt with business stakeholders, this compounding cost curve is the most persuasive argument for proactive management.

Making Technical Debt Visible¶

Creating organizational awareness around technical debt is essential for managing it effectively. The approaches I've found most effective include visualization tools that make the abstract concrete.

One simple but powerful approach that worked for us was a "stoplight" system for technical debt. We identified all libraries, frameworks, and language versions in use and tracked their end-of-life dates. These became our "red light" dates - points at which we must update or risk being on unsupported versions. This system helped build a clear priority list and highlighted whether manual maintenance was feasible or automation was needed. Managing 5 dependencies manually is reasonable; managing 500 is not.

Automation as Visibility¶

Tools like Dependabot provide ongoing visibility into dependency status. When automated systems continuously generate pull requests for outdated dependencies, the entire organization develops awareness of technical health. These systems make the invisible nature of tech debt visible and turn theoretical discussions about debt into actionable items. It also does it gradually, so it just becomes part of system maintenance, instead of giant maintenance cycles that slow development.

When discussing technical debt with non-technical executives, I focus on two key aspects. First is why we need to address it. These reasons vary depending on the scenario and team, but could be something like us being on an unsupported version, or we that spend significant hours weekly working around issues fixed in newer versions.

The second aspect is considering the consequences of deferring. If we remain on an unsupported version, the vendor won't help when problems arise or at least not cheaply. There might be active exploits in the wild for the version of a library we are using.

I also include impact analysis on existing priorities. If properly planned, technical debt work fits into existing timelines with minimal disruption. When that's not possible, I clearly explain the trade-offs and impacts of both addressing and deferring the debt.

Cultural Elements of Technical Debt Management¶

Technical debt management isn't only a technical practice. It's a cultural one too. The most successful approaches I've seen embed debt management into everyday work rather than treating it as an occasional "debt sprint."

A culture of automating away low-level technical debt proved crucial in my experience. Implementing tools like Dependabot, OWASP scans, and accessibility checks reduced the time engineers spent worrying about these issues because they were handled behind the scenes. This automation-first approach served multiple purposes. It baked prevention into the development process, encouraged engineers to think about security, accessibility, and dependencies early, demonstrated organizational commitment to technical excellence, and created a positive ripple effect as other teams adopted similar practices.

When one team successfully automated technical debt management, others naturally followed suit. This created a culture of continuous improvement rather than periodic cleanup.

One particularly effective practice I found was assigning new engineers small technical debt tasks as their first projects. This might be a library update, minor bug fix, or addressing a potential security flaw. New engineers made immediate, valuable contributions while building confidence in a new system by completing manageable tasks. The team addressed technical debt items that might otherwise struggle for prioritization, documentation got updated based on fresh perspectives, and new team members learned team processes in a low-pressure context.

By introducing technical debt management during onboarding, we established it as a normal part of engineering work instead of an occassional activity.

The Continuous Approach¶

Rather than scheduling occasional "technical debt sprints" that disrupt normal work, I've found greater success in making debt reduction a continuous process.

Traditional technical debt sprints create several problems. They interrupt feature development momentum, treat technical excellence as exceptional rather than normal, and encourage deferring small fixes that could be handled immediately to "some other time".

Instead, I've found treating technical debt like regular household maintenance works better. By making small, continuous improvements, you prevent the need for major renovations in most cases.

With automated tools handling routine updates, engineering teams can focus on substantive technical debt such as infrastructure improvements, major framework upgrades, outdated UI refreshes, and performance bottlenecks. These larger initiatives deserve careful planning and dedicated time, but they should still be approached as part of normal development cycles rather than exceptional activities.

The most efficient technical debt management strategy I've witnessed is preventing unnecessary debt in the first place. During high-growth periods, implementing automated checks early in the development process caught potential issues before they became embedded in our systems. Clear standards for code quality, security, and architecture provided guidance without imposing unnecessary constraints. The key was establishing these standards as enablers rather than barriers. They helped developers make good decisions quickly rather than slowing them down with bureaucracy. It also eliminates back and forth during code review - "This line is 120 character", "This function call should have parameters on new lines". Bake that into your linter that every developer must use and those discussions will never need to occur again.

Some technical investments I've seen pay dividends by preventing debt accumulation. Comprehensive test suites caught regressions early. CI/CD pipelines enforced quality standards. Architecture decision records preserved context. Service boundaries limited the spread of technical compromises. These investments created an environment where quality was the path of least resistance rather than an additional burden.

Conclusion¶

In my experience in multiple leadership roles, when managed effectively, technical debt becomes not just a necessary evil but a strategic tool. By making conscious decisions about when to take on debt and when to pay it down, companies can maintain the velocity needed for market success while building sustainable technical foundations.

I've found that making debt visible through automation, metrics, and clear communication ensures technical debt is part of strategic conversations. Embedding debt management in culture builds technical excellence into everyday practices rather than occasional initiatives. Focusing on prevention by investing in tools and practices makes it easier to do things right than to create new debt. Being strategic about remediation means addressing debt that limits key business initiatives while deferring debt that doesn't impact current priorities. Measuring the impact by tracking before-and-after metrics demonstrates the value of technical debt reduction.

As engineering leaders, our role isn't to eliminate all technical debt. That would be neither possible nor desirable. Instead, our job is to manage technical debt as thoughtfully as we would manage financial debt. The goal is to take it on deliberately when the terms make sense, monitoring its impact, and paying it down strategically to maximize long-term value.

Scaling Engineering Teams: From 5 to 50+ Without Losing Your Culture

2025-04-01T10:00:00-05:00

After nearly two decades in software development leadership and multiple VP-level roles, I've learned that scaling engineering teams is about much more than just adding headcount. It's about creating sustainable growth that preserves the core elements of your culture while evolving systems to support a larger organization.

The Challenges of Rapid Growth¶

When scaling engineering teams, I faced two consistent challenges that required thoughtful solutions:

Challenge 1: Accelerated Hiring While Maintaining Quality¶

Hiring quickly while finding candidates with the right skillsets is one of the most difficult aspects of scaling. The pressure to fill seats can easily lead to compromising on talent quality or cultural fit. I've found that being crystal clear about technical requirements while remaining flexible about where a candidate's talents can best serve the organization helps thread this needle.

During interviews, I focus on diving deep into candidates' past projects rather than relying solely on technical assessments. If an engineer discusses a project and emphasizes backend architecture and database design while only briefly touching on UI elements, this reveals their true areas of expertise. I always follow up by asking whether they want to continue developing in those areas or expand into new ones. Both answers are valuable—they help me understand not just what the candidate can do today, but how they might grow tomorrow.

Soft skills are incredibly important. An engineer that takes ownership of the system, is willing to try an unknown, likes mentoring (and being mentored), and can communicate with others in a professional and empathic manner can bring much more than their technical skills to a growing team. Obviously you need that technical skill, but an engineer isn't a machine. They should be able to do more than sling code, rebuild a server, or make a system diagram. I am hiring someone for their whole set of skills.

Challenge 2: Knowledge Transfer at Scale¶

In small teams, knowledge naturally diffuses through daily interactions. As teams grow, this organic process breaks down, creating knowledge silos and redundant work. Each wave of engineers we onboarded faced steeper learning curves without proper documentation and orientation. Our solution was to make each cohort of new hires part of the knowledge-building process. Every wave of engineers contributed to our knowledge bases, improving the experience for the next group. We implemented, essentially, an onboarding buddy system that paired new engineers with each other to build relationships, while also connecting them with experienced team members who could fill in knowledge gaps.

The other benefit of these types of improvements, is that is supports asynchronous communication and remote work. Remote work and hybrid work have grown in popularity, especially since 2020. Building knowledge transfers through tooling that doesn't expect the entire team to be in a single location provides so much context to others. Someone can catch up in a Slack channel later, or read a Confluence article tomorrow.

Culture Preservation Techniques That Work¶

Maintaining culture during growth requires intentionality. Here are strategies I've found effective:

Immediate Integration into Meaningful Work: New team members were immediately included in team ceremonies and assigned meaningful tasks—not just busywork. This sent a clear message: you're a valued contributor from day one. By giving new engineers real problems to solve immediately, they quickly identified with the team's mission and felt ownership of their work.
Public Knowledge Sharing: We instituted a rule that all support work must occur in public channels. This transparency accomplished several things. New engineers could observe troubleshooting in real-time allowing everyone to learn from each issue that arose. Team members could spot when someone was solving a previously addressed problem which helped find patterns of recurring issues. These became visible, highlighting systemic problems that needed permanent fixes.
Visual Documentation: A picture truly is worth a thousand words on day one. System architecture diagrams, workflow charts, and even team organization maps help new engineers orient themselves quickly. We continually updated these visual aids as our systems and teams evolved.

Evolution of Team Structure and Communication¶

Adaptive Team Structures¶

There's no one-size-fits-all approach to team structure during scaling phases. I've built dedicated backend, frontend, and QA teams, and I've also created cross-functional pods. The right approach depends on your product, business needs, and the existing strengths of your team. What matters most is acknowledging that your structure must evolve as you grow. The flat organization that worked at 5 engineers simply won't function at 50. Being transparent about these necessary changes helps the team understand why restructuring happens.

Communication Cascade¶

As teams grow, communication needs to flow through multiple channels. While I always strive to stay hands-on and close to the work, the reality of executive leadership means I can't directly communicate with everyone daily. Building a strong communication cascade through direct managers becomes essential.

I maintain regular one-on-one meetings with my direct reports and hold skip-level meetings on a consistent cadence. I also encourage my direct reports to do the same with their teams. This creates multiple pathways for information to flow up and down the organization. Crucially, engineers need to see their feedback traveling up the chain and resulting in actual changes. When team members witness their input driving decisions, they remain engaged in the communication process and feel valued for their insights.

Measuring Success Beyond Headcount¶

Adding engineers is easy—ensuring they contribute effectively is the real challenge. Here are metrics I've found valuable for measuring successful scaling:

Time to first meaningful commit: How quickly can a new engineer contribute value?
Feature deployment velocity: Is delivery speed maintaining or improving as the team grows?
New product launch timelines: Are we bringing innovations to market faster?
Support queue metrics: Are new engineers getting involved in support while maintaining quality and response times?

These indicators help identify whether your growing team is becoming more capable or just more numerous.

The Lesson I'd Apply to Future Scaling Efforts¶

If I were scaling a team again tomorrow, I'd place even greater emphasis on breaking down business expectations into clearly defined incremental goals. Saying "we're adding X engineers to deliver Y major initiative" creates unrealistic timelines and pressure. New engineers need time to contribute meaningfully to large tasks. By defining a granular priority list with visible intermediate steps, both new and existing engineers can march toward tangible milestones rather than an intimidating "big thing" with unclear pathways to completion.

Cross-Team Integration from Day One¶

Finally, I've learned the critical importance of ensuring engineering teams aren't isolated from other departments. As engineers onboard and learn, they should continuously interact with product, sales, customer success, and other functions. This cross-functional exposure provides vital context about why certain features are requested or designed in specific ways. Engineers who understand the business rationale make better technical decisions and can anticipate future needs. For example, understanding upcoming business requirements helps engineers build flexibility into systems where it will actually be needed, rather than adding unnecessary complexity. Building with the right level of flexibility now is infinitely easier than redesigning systems later.

Conclusion¶

Scaling engineering teams successfully requires balancing technical excellence, cultural preservation, and business alignment. By implementing thoughtful onboarding processes, maintaining transparent communication, measuring meaningful metrics, and keeping engineers connected to the broader business context, you can grow your team without losing what made it special in the first place. The journey from 5 to 50+ engineers is challenging, but with intentional leadership, it can result in not just a larger team, but a more capable, cohesive and impactful organization.

Failure of Management - Unlimited PTO

2023-08-14T15:00:00-05:00

The pitch¶

Unlimited PTO - more vacation time! - is a great recruiting pitch. Who wouldn't want to take more time off through out the year? Recruiters like unlimited PTO because it reduces benefit package negotiations over vacation time. Theorectically, it should help fight employee burn out too because employees can take time off to recharge any time.

From an employer perspective it also has benefits. A defined vacation package requires employers to payout unused time if an employee leaves the company. The Wall Street Journal, in March 2015, reported that this cost employers of less than 500 workers approximately $1,900 per employee. For employers of over 500 workers, this jumped to over $2,600 per employee. Unlimited PTO isn't accrued, so the company doesn't owe this payout if the employee leaves.

The downsides¶

"Unlimited" doesn't truely mean "unlimited". An employee isn't going to get 6 months of vacation approved by management. A survey conducted by Namely in 2022 showed that employees that were offered unlimited PTO took as many or fewer days of vacation time compared to peers at companies with a defined number of PTO days. On average, this survey showed that US employees are taking about 12 days a year off.

Another downside, is management failure to implement unlimited PTO fairly. I recently read a story of a worker that had been denied a two week vacation this summer that they requested in May to take place in August. Other than a day off for an illness earlier in the year, they hadn't taken time off in 2023. However, a team mate had just come back from a two week vacation and had taken another two week vacation over the winter.

This company is exposing themselves to a potential leave discrimination claim. According to what I've been told, it sounds like one employee is allowed to take a leave but others are not.

One of the jobs of a manager of teams is to prevent to many overlapping vacations. With an unlimited policy, how do you justify allowing one person time off and not another? Worse, how do you justify a month of time off for one employee and only one day for another?

The flip side of this is how a manager determines when abuse occurs. Is a month of PTO in a year abuse? Two months? Two weeks? Where is that line and once defined how do you continue to present this as "unlimited"?

Alternatives¶

I've worked at companies that have "unlimited PTO", a set number of days of PTO and "minimium number of days of PTO". Personally, I prefer the last two. Unlimited PTO - as an employee - very quickly becomes a game of determining how much is to much, and stressing out about having time off denied over a vague policy.

A set number of days is nice because you know exactly how much time to take. Management, in my experience, has been way less picky about time off in these environments because once you hit that number of days, you are done taking time off. The trade off here is that unused time either has to be rolled over to the following year (company policy may prevent this) or extended vacations start cropping up at the end of the year. As an employee, I had several month long end of the year vacations, which worked out nicely for me. From a project planning perspective though, this means that those time periods mean that work slows to a crawl. Company culture has to allow for this and fortunately, it did in my case.

The last option is, essentially setting a minimium and maximium number of days to take off. This isn't quiet "unlimited", but in my experience was labeled that with an asterisk. The important part though is that the company required you to take a minimium amount of time off and it had to be in blocks of time, not one off days. This encourages downtime and better work/life balance.

My thoughts on unlimited PTO¶

I left a company with a well defined PTO policy that granted more time with more seniority. I left this company to join one with unlimited PTO. At the time I thought that I'd be using more time off and enjoying the benefits of this unlimited PTO policy. Unfortunately, like many others, I didn't do that. Instead I took fewer days than my defined policy had allowed and even lost some company holidays that the previous employeer had that the new one did not. In short, I worked more. It took a long time and a lot of push back within the company to get people to take the time they needed to recharge. Sadly, by the time I left that role, it was still uncommon for people to take extended vacations.

Unlimited PTO is as much a benefit as it is a company culture thing. During interviews, applicants should be asking questions about how much time their potential coworkers are taking off. Are these truly times off or are they expected to be able to take a phone call? These answers will help them determining if "unlimited PTO" is a benefit the company offers or recruiting buzzwords put in place to lure in new employees and it's actually a scam.

What should a software engineering interview look like?

2023-07-06T15:00:00-05:00

Some context¶

I spent nearly five years at PacketFabric. In my role as Vice President of Software Engineering at the company, I rebuilt the hiring pipeline for the software engineering organization. As the company closed it's Series B round of funding we needed to bring on world class talent quickly. I moved on to Woven Teams for a short stint as Director of Engineering where I not only built a tool used by thousands of engineers to get a new job, I hired for members of my team as well. In my current role at FleetOps, I've been working to ensure this previous experience is utilized to build a candidate focused hiring process.

I wrote about my hunt for a new role in the summer of 2022. This covered my experiences with various application tracking systems (ATS), which application systems require you to duplicate work and what job search rejection looks like. In the end I got a job at FleetOps as Director of Engineering.

Let's go through what I think an ideal candidate experience should be. Reality means that all of this isn't possible in all environments, but I strive to ensure as much of this is in place in areas and companies I have a say in. A good candidate experience provides a good feeling about the company and in any environment - candidate favoring or employer favoring - a happy candidate and new hire will be more effective joining a new company.

Job Description¶

Candidates are applying to a role at your company and should know what that role does. Regardless of whether the candidate is a referral from an executive or someone who is applying from a job board, the job description sets initial expectations for the role. Many engineers can smell marketing hype in a job description. Things like "ninja coder", very vague descriptions or numerous requirements. These are all negatives. A job description should be tailored to the role. It can also be reflective of the company's culture without being off putting.

Job descriptions should include salary ranges. In my experience, the listings with ranges get more applicants. Additionally, it's becoming a legal requirement in many localities, especially in the United States. This should be a legitimate range. If the range is a hundred thousand dollar spread or higher, the believability is pretty low. It signals that the company either doesn't know what they want for this role, that they vastly under pay some of their team, vastly over pay some of their team or a combination of all of these.

Finally, the job description should spell out the application process and expected and realistic timelines.

Application¶

The next step describes a software engineering hiring process. It requires up front work on the part of the company to ensure it goes smoothly. The application should be relatively simple. I'm a fan of not weeding out candidates at this stage and immediately sending them to a technical scenario. This only works if the process can be automated because a job can get hundreds or thousands of applicants. This should be made clear in the application and process description that the next step is a technical scenario.

Technical Assessment¶

A technical assessment should be real work. Do not do leetcode or code quizzes. If you use either of these, expect them to be easily answered by utilizing ChatGPT. Build a rubric so that every person being evaluated is judged the same way. You should be able to automate some of this to build in responses that can easily weed out the candidates that are completely inexperienced.

Scenarios should reflect the type of work they will perform on the job. Build the prompt to fit around a recent problem your team solved. Create a problem that is unique to your industry. Utilize the experiences of your existing team to create these scenarios. When building the rubric, do not build it so that the only possible solution is the one that your team came up with. There are many possible solutions to a problem. Ensure you get those to truly see the experiences and expertise your candidates have to offer.

Build scenarios that have experience levels built in. A junior engineer is going to think about a problem in a different way than a staff engineer. The rubric should be reflective of that.

The technical assessment should be short and timed. At Woven, I told the companies I worked with the entire assessment (usually 2-4 scenarios) should not last longer than two hours. Candidates are unwilling to take assessments that long. Additionally, untimed scenarios favor candidates that do not have other commitments - perhaps another job, family, or hobbies to name a few. Keep candidates on a level field as much as possible.

Honorium¶

When I've looked for specialized skillsets or executive roles, I've extended the time frame of scenarios and attached an honorarium. This will compensate the candidate for the longer time taken on the application. Unfortunately, free labor is common in the technology industry interview process. This is to show the company isn't seeking free labor on a problem. It may need to be explained to candidates due to the experiences they have had with other interview processes.

Remote work¶

I am a huge fan of remote work. With the proper company structure, I can hire from a global candidate pool. It's important that the team is able to support their new coworkers regardless of their location in the world. I've seen teams and companies expand their developer ranks by slowly expanding the timezones they hire from instead of immediately jumping to global. The trade off here is that you are missing candidates that would be good for you team immediately and in turn you are slowly training your team to operate on a broader set of timezones and be more asyncronous.

How the team expands requires careful consideration of team dynamics and executive support. It should also be a discussion the hiring manager is prepared to have with candidates. "Remote" does not always mean someone sitting a handful of timezones away. For some it may mean that they like to travel and could be in the same timezone as you this month and over the winter they are half a world away. How will you, as a team and as a manager, respond to this type of situation.

Onboarding¶

Once you've made a decision to hire someone, the hiring manager should remain in contact with the candidate. Don't just hand things over to Human Resources and assume everything is perfect. Changing jobs and starting a new job is a big deal. Talk with the candidate on next steps. Ensure they are getting the right equipment to perform their job. Start setting up the first tasks they will be doing when they join the team.

Day one is going to consist of HR work. There is paperwork to fill out, there are things to sign, there are policies to go over, and insurance to sign up for (in the US at least). Everyone with a job has done this stuff. Build this time into their first days on the job. Day one also consists of getting the new employee access to systems and introductions.

Work with the employee and provide a checklist of things they should be doing and who they should be working with to complete these first items. They don't know who in HR to work with because they are new. They don't know their team lead because they are new. The hiring manager should make these introductions easy.

Set up expectations for the first week or two, the first month and first three months. They will need to learn the environment, get access to the ticketing system and code repositories, and start making their first commits to the code base. But, that's not a day one thing. They will need to learn how system A talks to system B. Again, this is not a day one thing. A new user is going to get a firehose of information. Make it somewhat easier for them by not expecting them to be an expert by the end of week two.

Intangables¶

A hiring process has a lot of intangables that can make your candidates feel better or worse about your company. A few examples are:

How many interviews does the candidate have to go through? To many quickly burns out a candidate and makes the entire process feel like a waste of time. To few, or only technical interviews, doesn't give the candidate a sense of the company and the team.
Can the interviewers answer a candidate's questions? Candidates are interviewing you too. Does your interview team have the ability to answer a candidate's questions about the company, role expectations, day to day work, job perks, and more? Is the interview committee excited about a new teammate or are they stressed out/uninterested.
Does the candidate receive updates on their application through out the process? Feedback is important and ghosting a candidate will quickly turn an excited candidate to one that doesn't want to join the team.
Communication with rejected candidates is important too. Coming back to ghosting a candidate and applicant tracking systems, these can be set up to send candidates emails based on what's happening with their application. If they are rejected, have the system send them a message. Please, PLEASE, don't use a default template for this though. There is a person receiving this email. They deserve more than "we're not moving forward at this time." If the hiring manager has talked to a candidate then this email should be more than the basic template sent to candidates rejected earlier in the process. A rejected candidate may reapply to a future role. How you inform them that you aren't hiring them right now determines if that candidate considers reapplying in the future.
How is the company perceived to the outside world? A candidate wants to join your team, which means their name will be linked with your company for friends and family at least. Future jobs will associate your company with their name. The candidate may ask about this perception - recent news articles, CEO announcements, blog posts - and the interview team should be able to answer these types of questions.

Conclusion¶

Interviewing is different at each company, but candidates don't know what the process looks like at each until they are into the process. The earlier this process is communicated to them, the smoother the candidate's experience will be. This requires that the company and hiring manager have spent time building the job description, technical assessments, and interview cycles ahead of time. Organization is important.

Communication is more important. The candidate is applying to join your team. How you communicate with them is their first indication on how they will be communicated with as an employee.

My thoughts on what remote work will look like in the coming decade

2023-05-23T15:30:00-05:00

Preface¶

This post is a bit different than some of my others. It's a direct response to an article. Over the past 9 months, as the technology industry contracts, we've seen return to office orders from countless companies. Combined with the, roughly, 300k layoffs between August 1, 2022 and May 23, 2023 (I was laid off in that time frame too), we've seen a lot of articles about how many companies are recalling people to the office.

I think this is short sighted. Remote work, when done properly, is the way of the future and forcing everyone back into an office is not going to work as expected. One of the bright spots from the COVID-19 pandemic was that society learned many jobs can be done from home.

The article¶

The article I'm responding to is Changing my mind on remote, moving the team back to San Francisco by Flo Crivello. This isn't designed to pick on this author specifically, it's just the latest in a long line of these types of posts.

I encourage readers to take a look at the article. It is well written. I, however, disagree with almost all of it.

Let's get started, shall we?

Counter point¶

I have a lot of problems with this article. The short version is that it sounds like this company implemented remote work poorly, possibly during covid (I'm not sure how long they've been around). I think remote work is the best, especially for companies that does not need a local presence.

The article raises four coordination cost bullet points:

It’s harder to get a hold of each other, as we’re not online at the same time. “I’ll talk about it when I see him tomorrow” — these delays compound in a huge way.

So most interactions are async, leading to lower bandwidth, more context switching, and more things falling through the cracks.

Even sync chats aren’t as good. People can’t interrupt each other or have sidebars, and there are bugs with video, audio, screenshare, etc… These frictions compound too.

This causes us to be less aligned. We’re only a few engineers right now, and yet people feel out of the loop on who’s building what.

The first three of these are the result of poor company policy and team expectations for how remote work will function. Remote work is still "work". It isn't "spend time by the pool with a laptop". It isn't "pick up groceries, mow the lawn, volunteer at the classroom parent, and maybe hop on a phone call". It is work. The team and company need to set that expectation. However, remote does offer the flexibility to do different things during the day. The company needs to be accepting of time zones, and time shifts. Embrace the employees that are productive outside of a 9-5 working day, especially if your workforce is scattered across time zones.

If the company is fully remote, they should build in the async communication as part of their communication plan. Good communication requires repetition. Asynchronous communication leads to that perfectly. Send a message in slack, send an email, mention it in Slack in another context, bring it up on an all hands call. Versus, only mentioning it once in a meeting.

Items falling through the cracks isn't a remote or async communication problem. It's a team problem. It's a leadership problem. It's a training problem. Don't blame remote work for this failure. Empower your team to make decisions that don't require constant input from others. This is one of the core points that GitLab's TeamOps has. Give your teams agency to make decisions without permission, review or approval. Do this, and those cracks get a lot smaller - regardless of where the employees work.

Synchronous chats having communication problems aren't great, but the reasons for failure that are listed by the author don't sound like a sync chat problem. "Interrupting", "having sidebars" - There are other avenues to communicate - zoom chat and slack are two examples. The bigger problem, in my opinion, is the requirement to always have video communication on in a company. This leads to fatigue due to communication patterns that don't exist in face to face communication (close eye contact, seeing your self, reduced mobility, and higher cognitive load). I argue that a well structured async communication plan and team will do better without constant sync communication. Sure, seeing people in person is helpful sometimes, but it's not required for all interactions.

The alignment problem is a leadership failure. I've worked remotely for the better part of a decade. I worked in an office for over a decade. Teams don't get misaligned because of remote work. They get misaligned because of leadership failures. Failure to communicate at all, or only slivers of data, will misalign a team faster than a network outage or Zoom failure will. Way faster. A poor company culture will ruin alignment in a way that a "My web cam isn't working today" could only dream of accomplishing.

Colocation is more fun too. You get to have lunch with your team, grab beers on Friday nights, play video games at the end of the day in the office, etc

sigh

This author does not care about a work life balance either for themselves or their employees. There are employees that absolutely love doing these things, building those relationships, and that's great. There are others that want to get home and spend time unwinding, being with family, hanging out with friends and none of that can be done if the boss is expecting you to go to the bar with them on a Friday night or stay at the office to play video games. Team building is important, but the way it's described here is not the way to build a team long term.

This matters not only because fun is fun, and building community is super important, but also because it helps build trust, which improves our work

My personal bias is going to show here, but my trust in team mates grows more through professional pursuits. How a team accomplishes a task or how a team responds to failure ( especially how they respond to failure) is going to build that trust a lot more than going to a bar on a Friday. Going to a bar will build a personal friendship, but that is different than a professional level of trust.

[A]sk yourself which of the following competitors you’d be most afraid of:

The bunch of hackers coding on a couch in an apartment

The team that’s fully colocated

The team that’s hybrid

The team that’s fully remote, split across timezones

The last one, absolutely. In this environment, I as a manager, can hire the best person for the job regardless of where they sit in the world. It doesn't matter if we could car pool to an office or if you are 18 hours ahead of me. This is the massive advantage of a fully remote workforce and is commonly brushed under the rug in these types of articles. A team that is aligned and has the best people in the world or industry working for them is going to crush a team of that is colocated and is limited by who lives in commuting distance or is willing to relocate to commuting distance of the office.

Lastly, this quote

A quick look for software engineers finds that SF has about 40 times more than Miami: (and my hunch is that they’re better ones too)

Wow. Every engineer here should be offended by this. I've hired over 100 engineers in my career. I think I have a pretty good idea of how it works, how these engineers perform, and how they behave. Purely from an economic stand point, hiring from the Bay Area is expensive. "But your engineers don't live in the Bay Area, Andy, you just said you hire globally." True...now, tell that engineer in Miami or London or Ankara or Sao Paulo or anywhere else why they are making at least $100k less a year than their coworker doing the exact same thing and see how quickly engineering morale crumbles. Or, are you one of the minority of companies that pay the same regardless of location? If not, you should be.

The best engineers I've worked with, except one, have been located well outside of the Bay Area. An engineer in Miami can do the exact same work that an engineer in San Fransisco can at the same quality.

Remote works can and is incredibly successful for many companies. It does require deliberate, intentional, company decisions to make it work though. I shared the TeamOps information above (and completed TeamOps certification earlier this year). GitLab, one of the largest successful all remote companies in the world, has intentionally built their remote policies around this. Without putting in the time or effort to ensure remote is successful, teams will (and are) defaulting back to in office. I think we are going to be seeing just how unsuccessful that strategy is in the next decade. One of the few benefits of Covid was that it showed many engineers around the world just how much they are missing out on with daily commutes, 10-12 hour days in the office, lack of family time which is why there has been such push back. Those that have successfully adapted (or built from the ground up) the company culture to handle remote work will have a huge advantage as this period of contraction eases in the future.

10 Soft Skills to Look For in Senior Software Developers

2022-06-26T09:00:00-05:00

Before we begin...¶

This post is republished from Woven's blog.

I was recently asked about what I thought the top soft skills - those hard to define traits - a senior engineer should possess to be successful. Below are my thoughts.

The list¶

Excellent communication¶

No one lives in a vacuum. While portions of an engineer’s role may involve working alone, a senior engineer does not work in isolation. They interact with teammates, other teams, managers, end-users, and more.

Experienced developers have top-notch communication skills. They’re able to communicate effectively with individuals and teams to accomplish a common goal. Building relationships with these areas improves interactions in the future.

Ownership mentality¶

A senior software developer sees the dirty underbelly of the system. They embrace it. They work to clean it up.

Your ideal candidate is taking ownership, tackling one task at a time to make the system slightly better. Not every change has to be big, flashy, and headline-grabbing; a change to improve stability is rarely commented on, but users notice if the system is unstable.

Additionally, helping a customer through an issue doesn’t always have to fall to “Level 1 Support”. A senior engineer can and should spend time on support — learn the pain points users are having and use that knowledge to improve the system.

They’re not too big for the small things.

Ethics¶

Software engineers know that what they’re building will not only be used by them; it will impact others in some way, shape, or form. They consider that impact. They consider the unintentional impact, too.

It can be easy to fall into the trap of thinking, “It’s just a system. Someone else is making the decision.” However, even the most simple systems have a ripple effect. Look for this type of critical thinking and awareness in your candidates and employees.

Willingness to fail¶

Not everyone has amazing new ideas. And not all ideas are going to be successful. (If they were, we’d all have several more commas in our bank accounts.)

Failure is an option and an opportunity to learn something new. Senior engineers chase ideas, explore hypotheses, and do unique things. If they fail, they learn something from it. They’re open to admitting mistakes and take constructive feedback easily.

They use this knowledge to help their team learn something, too.

Openness to discussion¶

Are your senior engineers willing to have their ideas challenged? They should be.

Discussion around how something works now versus how it can work in the future helps everyone improve and helps the system get better over time. This should not be an antagonistic discussion but instead reflect the different options other developers can bring forward.

Commonly, these discussions result in a broader perspective and even better ideas.

Mentorship¶

A senior engineer has a position of trust on the team. They should use this position to guide more junior team members, inviting them to larger discussions and helping them grow professionally. Patience is key as junior devs ask questions and turn those questions into learning opportunities.

Zoom calls don’t have to be scheduled and they don’t have to be an hour long. If a senior engineer hops on a call when they’re troubleshooting and invites team members to join, observe, and ask questions, they’re the right person for the role.

Time management¶

Deadlines are a part of life. A software engineer with good time management skills helps set those deadlines through effective communication with the team.

They also know how to make decisions on prioritization; if (and when) they miss a deadline, it shouldn’t be a surprise to management. Software engineering leaders are time conscious and make sure everyone is aware of timelines and processes.

Empathy¶

This one’s a hot topic.

Employees aren’t machines. They have feelings, ups and downs, and life events outside of their job.

Emotional intelligence is important — especially in a remote work environment — to building a great professional relationship. Experienced engineers take time to get to know their coworkers and their customers as people, not just as a means to an end.

Leadership¶

A person doesn’t need to have “Engineering Manager” in their title to be a leader. Leaders can take many different forms, and the most important part is being able to inspire those around them. This could be by driving technical discussions, being a great mentor, or simply having an idea and knowing how to get buy-in and execute on it.

Leaders make things happen, and they don’t wait for permission.

Creativity¶

In the fast-paced tech world, engineers must be able to take a step back, see the big picture, and think outside the box. They can’t be afraid to try new things or challenge the status quo.

Often it’s unorthodox approaches that lead to breakthroughs and a final product that’s worthy of users’ time and attention.

Final thoughts¶

Software development is a team sport. The best players are the ones who make those around them better.

To be truly successful, your senior engineers should have a mix of both hard skills (like coding) and soft skills (like problem-solving). These are the people who will take your company to the next level.