I didn’t see it until Tuesday. By then, two other leads had independently done the most mature leadership work I’d seen from any of them all quarter. None of them had needed me. The only thing that connected those three moments was that I wasn’t there.
I’ve been sitting with that for two weeks now, and I think it changes how I understand my job.
The day off wasn’t strategic. I just needed a break. Declined every meeting, closed Slack, went fully dark. I’d been telling myself for months that my teams could run without me. I was about to find out whether I believed it.
The lead who sent the 5:29am email had, three weeks earlier, been on the edge of quitting. He’d vented to me at six one morning about a team that wouldn’t listen, frustrations and exhaustion in equal measure. The work I’d been doing with him for months was very obviously developmental: how to have hard conversations, how to escalate without burning bridges, how to write things down rather than carry them in his head.
On the Monday I wasn’t there, he crossed a line I’d been waiting months to see him cross. Not management (knowing what’s broken). Leadership (saying it out loud and committing publicly to fix it).
Meanwhile, on a completely different team, one of my engineers, not even a lead, posted a customer discovery write-up that did the kind of work I’d usually expect from a principal. He’d structured the customer feedback by priority, mapped requirements to retention risk, and proposed an early-versus-later scope split. He did this while handling a family emergency. No direction from me. No prompt. No template. He just saw work that needed doing and did it at a level nobody had asked for.
A few days later, a third lead, the one who manages QA across one of my teams, sent a formal email to her reports. She opened with: “I want to be direct: I’m responsible for part of this.” A team lead, in writing, publicly naming her own contribution to the problems before asking her team to change. Not “we need to do better.” Not “I’ve noticed some patterns.” She said “I’m responsible” first.
Three leads. Three teams. Three independent moments of leadership maturity. Same week. The only thing they had in common was that I wasn’t in the room.
Something was going on.
When I’m in the room (or in the Slack channel, or on the calendar), my leads know there’s a backstop. If the conversation goes sideways, I’ll help. If the decision is wrong, I’ll course-correct. The safety is real, and I spent months building it.
But safety has a side effect. When the backstop is always there, people lean on it. Not consciously. Not lazily. Just naturally, the same way you drive differently when the road has guardrails.
My absence removed the guardrails. And instead of driving off the cliff, my leads drove more carefully — the consequences were suddenly theirs. The most mature leadership email of one lead’s career was sent at 5:29am on a day he knew I wouldn’t see it until later. The QA lead’s accountability email was CC’d to me but not written for me. The engineer’s product write-up was posted in a channel I wasn’t monitoring.
My presence gives safety. My absence gives permission.
If the story ended there, it would be too clean. A neat parable about letting go. The kind of thing that fits on a LinkedIn post.
The same week, the same team whose lead sent that powerful 5:29am email was dealing with an attendance crisis. People not showing up to the office. A team that can run its technical governance without its director still can’t self-organise on basic attendance norms. Autonomy without reliability is one dimension of maturity, not maturity itself.
And on another team, an intern said something in a retro that stopped the room. “I look at us and I don’t feel like we’re a team. Everyone works on different things. People feel like strangers.”
That took real courage. The team that hasn’t passed the absence test yet produced the most honest self-assessment of all three. Sometimes the team that names its own failure is further along than the team that doesn’t notice.
I’ve been coaching my leads for months on the same principle: constraints, not methods. Define the end state, shut up about the path. But I’d been applying it inconsistently. I defined the end state for the work. I was still showing up to manage the path for the people.
Every weekly 1:1 where I coached a lead through a difficult conversation was also a weekly signal that they needed coaching to have difficult conversations. Every time I modelled the right response to a tricky stakeholder was a demonstration that the right response needed modelling.
The method that finally worked was not coaching harder. It was disappearing for a Monday.
What follows is the LinkedIn-shaped part I gestured at earlier. Three concrete changes. Forgive me; they’re the part I actually have evidence for.
One: I’ve started declining meetings I used to attend “just in case.” In the last three weeks I’ve declined eleven of them. Nine were genuinely fine without me. Two surfaced gaps I now know about, things I’d been quietly papering over by being in the room. Both are now on a list to actually fix, instead of permanently absorbed by my calendar.
Two: I’ve stretched the gap between 1:1s with my most senior lead from weekly to fortnightly. The accountability bar went up, not down. We agreed in advance what would be different at the next session. Two cycles in, the conversation has more in it. Less status update, more genuine reflection. The space between sessions is where the independent decisions happen.
Three: I’m watching what happens during my absences more carefully than what happens during my presence. The signals that matter aren’t in the meetings I attend. They’re in the Slack messages sent at 5:29am when nobody’s watching.
I’ve been managing people for years. My stated goal this quarter is to help my teams stand on their own feet. Every post I’ve written this year circles back to some version of: let go, step back, trust the system.
And yet. Every instinct I have still says be there. Be available. Be the backstop. The gap between knowing you should step back and actually doing it turns out to be approximately the width of a Monday.
I’m not going to pretend I’ve cracked this. I still jump into Slack threads I should ignore. I still schedule coaching sessions for people who are past the point of needing them. I still have an involuntary physical reaction when I see a team decision I would have made differently.
But that Monday keeps replaying. Three leads, three independent acts of leadership courage, and the only common thread was my absence.
Your presence gives safety. Your absence gives permission. The answer, I suspect, is more permission than you’re comfortable with.
]]>I sat there listening to them reconstruct the story and felt something I’m still processing: pride, yes, but also a strange kind of vertigo. My team had used a principle I’d been teaching them for months, applied it under real pressure, and I hadn’t been in the room.
It started about a month earlier, in a meeting about engineering standards.
We’d been handed a comprehensive document. Seven sections. Dozens of pages. Coding conventions, architecture principles, review processes, deployment practices. It was meant to be the thing that unified our engineering teams across multiple products.
I read it and my first reaction was: this is a textbook pretending to be a standard.
The content wasn’t wrong. Most of it was thoughtful. The problem was that nobody could tell me which parts were actual requirements and which parts were one person’s preferred way of working. A junior engineer reading this document would have no idea what was mandatory and what was aspirational. (A senior engineer, honestly, wouldn’t finish it.)
I told the group: “If this is a hundred, we need something at twenty.”
What followed was a conversation about how to define standards that people would actually follow. The position I kept coming back to was almost embarrassingly simple: define the end state, shut up about the path.
Tell teams what must be true. Maybe ten things. Non-negotiable, short enough that everyone reads them, strict enough that nobody escapes them. Not “good test coverage.” Something like: every production change has a rollback path. Every service has a named on-call owner. Every bug fix references the bug. Things you can hold up against an artifact and check, yes or no.
Don’t tell them how to get there. The maturity tiers, the migration plans, the per-team baseline assessments, the enforcement timelines: in this context they were substituting for trust. If you have to design a compliance system to make people follow your standard, the problem is probably not the people.
The litmus test I keep coming back to is what a stranger would extract from the artifact. Take a document, a process, a decision. Imagine a senior engineer arriving in three months who wasn’t in any of the conversations. What do they get from the written thing? If the answer is “nothing clean,” you’ve defined the path, not the end state.
A few weeks after the standards meeting, a different team was handed the PHP8 ultimatum I opened this post with.
Today or Monday. Take it or leave it. The kind of pressure that, six months earlier, would have arrived in my inbox as an escalation before lunch. This time it didn’t. The team’s most experienced engineer chose Monday on the call to buy thinking time, then brought it back to the team. They mapped the actual work, identified the risk windows, drafted a counter-proposal, and went back with it as a group. They didn’t argue against the upgrade. They argued against the date. They won.
I learned about it in a retro a week later. Not because they wanted credit. Because someone was reflecting on what they’d done well.
Define the end state (we’ll upgrade PHP, we’re not refusing). Let the team figure out the path (here’s the date, here’s why, here’s the plan).
The way they did it was not how I would have done it. Mine would have been more political. Mine would have been more diplomatic. Mine would have been worse, actually. They went straighter at the problem because they didn’t have the political muscle memory I do. The fact that their way wasn’t my way is the feature, not the bug.
Here’s what nobody tells you about “define the end state and let teams move freely”: you have to actually let them move freely.
That sounds obvious. It isn’t.
When the team came back from that PHP8 conversation with their counter-proposal, my first instinct (which I’m not proud of, but I’m being honest) was to wonder whether they’d pushed back the right way. Whether the tone was correct. Whether the timing was optimal.
And then I caught myself. The whole point of defining the end state is that you release control over the method. You don’t get to specify the destination and then backseat-drive the journey. If the team arrived at the right outcome, using their judgment, in their own way, you don’t get to have an opinion about the choreography.
This is where the principle stops being an intellectual exercise and becomes a test of character. Do you actually trust the people you manage? Not in the abstract “I believe in my team” way. In the concrete “they handled it without me and I don’t get to second-guess how” way.
I’ve been managing engineers for years. I’m still working on this.
The same week one team was pushing back on external pressure with confidence and autonomy, a different team, the one with the newest leadership, was still figuring out the basics. In a retro, an intern said something that stopped the room: “I look at us and I don’t feel like we’re a team. Everyone works on different things. People feel like strangers.”
That took guts to say. And it was true. This was a team where the end state had been defined (ship integrations, hit OKRs, build capability) but the path hadn’t been walked yet. You can’t tell a team to move freely when they haven’t figured out how to move together.
“Define the end state” assumes a baseline. People know each other well enough to collaborate, trust each other enough to disagree, and have enough shared context to make independent decisions that don’t contradict each other. For one of my teams, that baseline was rock solid. For another, it was still being built.
The temptation, when the philosophy doesn’t work immediately, is to add process. Build tiers. Create checklists. Impose timelines. The same reflexes I’d rejected in that hundred-page document, suddenly attractive again now that the discomfort is mine.
But the answer isn’t more process. It’s patience. The intern who named the identity gap did something more valuable than any migration plan: he made the problem visible. Now the team can work on it. In their own way. At their own pace.
Define the end state. Even when the end state is “become a team.”
“I look at us and I don’t feel like we’re a team.”
I keep coming back to that sentence. Not because it’s elegant. Because it’s the one moment all week where the path got named honestly, and the only person who could have named it was the one standing on it.
That’s the end state, actually. Not pushing back on ultimatums. Not winning the timeline. The end state is a team that tells you the truth about itself, before you get to.
I’m still learning to shut up about the path long enough to hear it.
]]>It wasn’t delivered as a dramatic reveal. More like an afterthought. Wedged between complaints about team attendance and frustration about back-end code quality. “I was so close to calling you Saturday morning to say I’m done.” Then they kept talking about something else.
This was a Monday. At 9:23 AM that same Monday, before we’d even spoken, they’d already sent a firm, clear attendance policy email to their entire team. No escalation. No draft review from me. No permission slip. They’d identified the problem, set expectations, and pressed send.
The person closest to walking out the door was the same person showing the most ownership I’d seen from them all quarter.
The people closest to quitting are rarely the disengaged ones. They’re the ones who care too deeply about work that feels impossible.
My lead wasn’t frustrated because the job was hard. They were frustrated because they’d tried everything they could think of (coaching, direct conversation, leading by example) and the team still wasn’t listening. “They don’t listen when I talk to them,” they told me. “So they’ll have to learn to read.”
The Monday email wasn’t rage. It was the culmination of months of being ignored and deciding to put it in writing because spoken words weren’t landing.
But the same drive that produced the email is what produced the Saturday morning crisis. The ownership that makes someone draft a policy before 9 AM is the same ownership that keeps them up at 3 AM wondering why nobody else seems to care as much. You can’t have one without the other. And if you’re their manager, you can’t celebrate the Monday without reckoning with the Saturday.
The same week (because apparently the universe likes themes), I was in a coaching call with a different lead. Different team, different challenges, same syndrome.
This one was drowning. Not in bad work, in too much of it. Every QA gap caught personally. Every priority deviation corrected in real-time. Every miscommunication between team members mediated, explained, re-explained.
“I feel very tired,” they said. “Too many things in my head and nobody can do the job properly.”
I asked them why they were personally reviewing every piece of work from a particular engineer instead of distributing reviews across the team. They said I’d told them to. I hadn’t. Somewhere between a suggestion and a recollection, they’d constructed an instruction nobody gave and built their entire workweek around it.
I said something I’d been trying to say for months: “You choose to engage with behaviours. That’s your comfort zone. The fact that it makes you miserable doesn’t mean it isn’t comfortable. You keep choosing it.”
They didn’t love hearing that. I wouldn’t have either.
But the pattern was the same. A highly capable lead, investing everything in their team, absorbing every failure as a personal responsibility, and slowly running out of fuel. Not because the job was too big, but because they’d taken on a version of the job that no single person could sustain.
I’d been coaching both these people for months. Teaching them to delegate, to step back, to set constraints instead of methods, to define end states and let their teams find their own path. Standard leadership development stuff. The kind of coaching that looks great in a quarterly review.
And it was working. The first lead had grown more in six months than in the previous two years. They were making decisions independently, pushing back on product pressure, handling difficult conversations with composure. The second lead had built testing practices from nothing, established accountability structures, created real quality culture. Both were objectively better leaders than when we’d started.
So why was one almost quitting and the other burning out?
Because I was only doing half the job.
I was developing their capability without protecting the conditions for it to survive. Building muscle while the gym was on fire.
Development without protection isn’t development. It’s exploitation with a coaching wrapper. You teach someone to take ownership, but you don’t shield them from the organisational dysfunction that punishes ownership. You teach someone to delegate, but you don’t address the culture that makes delegation feel unsafe. You grow their skills while the system around them consumes those skills faster than they can replenish them.
A few days before that Monday email, I’d done two things in the same day.
The first was a conversation with the CTO. One of my engineers had been on the receiving end of a behaviour pattern from a senior stakeholder, dismissive feedback in public forums, requests routed around her, credit for her work landing on someone else’s slide. None of it individually firing-line stuff. All of it adding up to the kind of climate where her growing leadership would quietly suffocate.
I walked into that conversation knowing I might lose it. I named the pattern, attributed the specific incidents, and asked for a change in how the stakeholder engaged with her team. There was no agreement. There was a “let’s keep an eye on it.” I left the room not knowing if anything would change, and three weeks later I’m still not sure. That’s the texture of protective work. Nobody applauds. The graph nobody draws goes flat for a quarter and you call that a win.
The second thing, that same afternoon, was enrolling that same engineer in a management training programme. Sent the message to HR, outlined the goals, set the timeline. Constructive. Tangible. The kind of action with a visible artifact.
One felt like a fight. The other felt like progress. The second only works if you keep doing the first.
Within forty-eight hours of being formally given the team lead role, this engineer had completed a plan of attack, run her first daily standup, announced execution to the team, and independently started exploring how the team would use AI tooling in its workflow. Zero direction from me. Months of quiet investment compounding into self-sufficiency.
The difference between her and my two struggling leads wasn’t talent or motivation. All three had those in abundance. The difference was that for her, I’d been doing both halves: developing the capability and protecting the space for it to grow. Hard conversations upward, coaching conversations downward.
For the other two, I’d been mostly teaching.
I’ve been writing about leadership philosophy for a few weeks now. Constraints, not methods. Define the end state. Get out of the way. Let teams stand on their own feet.
All true. And none of it sufficient.
The lead who almost quit on Saturday had perfectly internalised every piece of coaching I’d given them. Set clear expectations. Document rather than verbalise. Hold people accountable through evidence, not emotion. They’d done all of it. And the result was that they absorbed all the accountability while the system around them continued to produce the problems they were accountable for solving.
I told them: “Focus your energy on the people who listen. Stop trying to squeeze blood from a stone.”
Good advice. Also a confession: I hadn’t done enough to fix the environment that was making blood-from-stone the default mode.
The protective work is less satisfying than the developmental work. Coaching someone through a difficult conversation is rewarding. You see growth in real-time. But having a hard conversation with your own boss to shield a team lead from political pressure? That’s just Tuesday. Nobody notices. The lead doesn’t know the conversation happened. The outcome is the absence of a problem rather than the presence of a win.
Turns out the absence of problems is exactly what leadership development runs on. You can’t grow someone in soil that keeps getting salted.
I’m paying more attention to the soil now. When I coach a lead on delegation, I’m also asking: what in their environment makes delegation feel risky? When I tell someone to step back, I’m asking: have I cleared enough space for stepping back to be safe? And when someone almost quits, I’m not treating it as a crisis to manage. I’m treating it as a signal about which half of my job I’ve been neglecting.
The Saturday morning phone call never came. The Monday morning email did. I’d like to take credit for the email. The honest version is that I nearly caused the phone call. Same act. Same job. Miss either half and you get a resignation written by someone who would have been your best leader.
]]>Turns out, neither was reading from the same page. Because there was no page.
Our L&D lead pulled up the actual company policy and started going through it. One-year waiting period before training budget eligibility? Not company policy. Maximum three people per conference? Not company policy. Mandatory presentation after attending? Not company policy.
These were R&D-specific decisions, made at some point by someone, passed down through conversations and Slack messages and “I think the rule is…” until they felt as solid as anything in the employee handbook. One person’s preferences, never documented, became institutional truth.
The room went quiet for a moment. I remember one of us saying, “This is new information for us.” Which is a polite way of saying: we’ve been operating under rules that don’t exist for years, and nobody thought to check.
Here’s how it happens. Someone senior makes a practical decision in a specific context. Maybe they had ten interns that year and the budget was tight, so they said “let’s hold off on conferences for new hires.” Reasonable. Context-dependent. Temporary.
But nobody writes down the context. The decision gets relayed as a rule. The rule gets relayed as policy. Within a year, managers are citing it in 1:1s as if it came from HR. Within two years, people who joined after the decision was made enforce it more rigidly than the person who made it, because they never knew it was a judgement call. They think it’s a wall. The original decision-maker has probably forgotten they said it.
The training budget rules were a textbook case. We consistently spent only about 60% of the allocated training budget each year. The phantom policies were doing their job: discouraging claims that would have been perfectly valid under the actual policy. And then, because the budget was underspent, Finance cut it the following year. Underutilisation justified reduction, which justified stricter phantom controls, which justified further underutilisation. The fiction became more real over time.
Phantom policies are indistinguishable from real ones until someone checks. They carry the same authority. They shape the same behaviours. People get reprimanded for violating them. New hires get onboarded into them.
Once I saw the pattern, I started seeing it everywhere.
A few weeks later, I was in a discussion about engineering standards. Someone had written a comprehensive standards document. Seven sections. Dozens of pages. Coding conventions, architecture principles, review processes, deployment practices.
The problem wasn’t the content. The problem was that nobody could tell me which parts were actual requirements and which parts were one person’s preferred way of working. The document mixed enforceable minimums with architectural philosophy with training material, all presented with the same weight. Everything looked like policy. Nothing was labelled as opinion.
So when one of my engineers, let’s call them M, proposed an event-driven approach for a new integration, the document was no help. There was nothing on event-driven patterns. Nothing on broker selection. The standard was silent, and into that silence walked the phantom policies. The first review meeting questioned whether event-driven was “really our pattern.” The second meeting questioned whether the proposed broker fit “our way of doing things.” Three weeks in, M presented essentially the original design back to the same room, and it was approved. Same proposal. Same approver. Different week.
The only thing that had changed was that a senior architect had, between meetings two and three, said in a corridor conversation that the approach “made sense to him.”
M’s observation, which I haven’t been able to shake: “It’s not what you say, it’s who says it.” That’s what happens when the written standard goes quiet. Authority fills the gap.
That’s what phantom policies do at their worst. When the rules are unwritten, enforcement becomes personal. The same exploratory work that’s celebrated when it comes from one direction triggers a governance review when it comes from another. Not because anyone is being deliberately unfair (usually). But because without a written baseline, every decision about what needs approval and what doesn’t is made on vibes.
Then a SOC2 auditor walked in and asked a very simple question: “Please provide evidence depicting that a documented Code Release Lifecycle is in place.”
Not “do you do good work” but “can you prove it to someone who wasn’t in the Slack channel when you decided how to do it.” Without an artifact, the answer is no. Functionally invisible is functionally non-existent.
We have release processes. Canary deployments. CI pipelines. Rollback procedures. Teams that ship reliably. What we didn’t always have was the artifact: the written thing that says “this is how we do it” in a way that someone outside the organisation could point to and verify.
The auditor asked the same question about bug resolution. We fix bugs. We don’t always document that we did, or how, or against which definition of “fixed.” For anyone who joins next year, or audits you this year, or tries to understand why two teams do the same job differently despite supposedly following the same standards, that gap is the whole problem.
I committed to drafting ten baseline engineering items for our organisation. Not a manifesto. Not seven sections of aspirational architecture principles. Ten things. Non-negotiable. Written down. Short enough that everyone reads them, strict enough that nobody escapes them.
To make it concrete: things like “every production change has a documented rollback path,” “every service has a named on-call owner,” “every bug fix references the originating issue.” Not “good engineering culture.” Not “we value quality.” Things you can hold up against an artifact and check, yes or no.
The philosophy is simple, and it’s the same one I keep coming back to: define the end state, shut up about the path. Tell teams what must be true. Don’t tell them how to get there. If a standard needs fifty pages of explanation to be understood, it’s not a standard. It’s a textbook masquerading as one.
The harder work is the cultural audit. Going through every rule we enforce and asking: is this written somewhere? If not, who decided it, and when, and does the context still apply? Most of the phantom policies I’ve found were reasonable when they were created. The problem was never the original decision. It was the failure to document it, revisit it, and eventually either formalise it or kill it.
I haven’t finished this work. I probably won’t for a while. Phantom policies are, by definition, hard to find. You don’t know what you don’t know until someone asks a question that exposes the gap, like a junior engineer who heard two different answers about conference eligibility, or an auditor who asked for a piece of paper we assumed existed.
I have phantom policies too. Of course I do.
Somewhere in the way I manage my teams, there are preferences I’ve expressed once that became rules I enforce without remembering I made them up. Communication norms I set through behaviour rather than words. Expectations I hold people to that I’ve never articulated clearly enough to be challenged.
The question isn’t whether your organisation has phantom policies. It has them. Every organisation does. The question is whether you’re willing to go looking for them before something else does.
Write it down. If it’s worth enforcing, it’s worth documenting. And if it’s not worth documenting, maybe ask yourself whether it’s really worth enforcing at all.
]]>I’ve been saying this for months. And then one week in early April, it happened. Not with a celebration or a milestone review. I nearly missed it entirely.
It started on a Friday. I was working from home, not particularly paying attention to what my teams were doing. When I finally checked in on Monday morning, I found a trail of things that had happened without me.
One team had handled a leadership transition cold. Their squad lead had gone on paternity leave, and within days the new person was assigning reviewers, sharing reference implementations, and running the show. No escalation. No velocity drop. Nobody asked me what to do.
The same team’s frontend chapter had volunteered, unprompted, for a Node version migration. Someone offered their personal dev day time for pair work on it. They’d self-organised a knowledge-sharing session for AI coding tools. Bottom-up, no mandate. Separately, they’d run a full quality sprint: accessibility hardening across 49 files, 35 new tests, CI restructuring, and a compromised dependency patched. Nobody told them to.
I scrolled through Slack channels for twenty minutes trying to find a single place where someone had asked for my input. Nothing.
A second team, smaller and younger, had started adopting conventional commits. Their own initiative. In the same week, one of the engineers had taken a brainstorming idea from a sprint retro, where they’d discussed using AI to learn from past PR review comments, and turned it into a working prototype. A PR review tool that learns from how the team actually reviews code. Built outside the sprint. Nobody asked permission.
The same team’s lead, someone I’d been coaching for months on everything from sprint planning to managing up, conducted his first technical interview. He spotted an angle from the candidate’s CV and probed it in real time. Prepared beforehand without me telling him to. I sat there thinking: I’d be comfortable handing him the next one.
And then the sharpest signal of all. My third team, the one with no team lead (we haven’t hired one yet, and I manage them directly), received 20-plus edge-case review comments from a senior stakeholder on a complex integration PRD. Batch processing limits, cursor behaviour on failure, deduplication logic, rehire scenarios. The kind of detailed scrutiny that typically sends people running for cover.
Their principal developer answered every single question. Clear technical depth. No escalation to me. The team with the least structural support produced the most independent response under the most pressure.
Here’s what I wrote in my notes that week: “The constraint has shifted from what they can do to the room they’re given to do it.”
I’d been so focused on building capability (teaching, coaching, pair-programming, reviewing) that I’d missed the inflection point. My teams weren’t struggling to make good decisions. They were struggling to find the space to make them, because the organisation around them kept pulling them into meetings, ad-hoc requests, governance theatre, and, let’s be honest, my own involvement.
This is the kind of realisation that sounds obvious when you write it down. It was not obvious while I was living it. For months, my internal narrative was: “my teams need me to grow.” The evidence was saying something different: “your teams are growing. You are the constraint.”
The first version of this post stopped there. Clean arc, satisfying landing. Then I went back and looked at what else happened that week, and the story stopped being clean.
The Node migration that first team had volunteered for? It was real work, started enthusiastically, then quietly slipped two sprints. The accessibility work got prioritised because it was visible and clean. The API contract debt they’d been deferring since January wasn’t getting raised, because nobody celebrates cleaning up someone else’s mess.
The third team, the one whose principal developer answered the twenty review comments? Same sprint, their integration roadmap went yellow. Two commitments they’d made to other teams slipped quietly. The visible win got raised. The invisible miss didn’t.
Capability showed up in places we were watching. Accountability went quiet in places we weren’t. And because nobody was watching, including me, the pattern had nowhere to land.
The teams hadn’t stopped needing me. They’d stopped needing me on the bright side of the road. The dark side was where I should have been looking, and I’d been so busy applauding the autonomy I hadn’t noticed I’d traded one bottleneck for a quieter one.
Around the same time, I was having coaching conversations with two of my leads about something I’ve started calling the competence trap.
One of them, covering for a colleague on leave, was answering support DMs within minutes, jumping on customer issues after hours, catching QA gaps her team missed. She was excellent at it. And that was exactly the problem.
Every fire she put out was a fire her team never learned to handle. Every DM she answered was a DM that trained the sender to keep bypassing the process. Every time she caught a gap, she removed the feedback loop that would have taught someone else to catch it first.
I told her: “The more you firefight, the less anyone learns to prevent fires.”
She knew this. She’d heard me say it before. She still couldn’t stop. Because when you’re competent and you see something going wrong, every instinct in your body says fix it. The gap between knowing you should step back and actually doing it is wider than anyone admits.
I had the same conversation, different flavour, with another lead who was absorbing chaotic product requests rather than pushing back. He had the skills to handle them. That was the trap.
And then I gave myself away. Earlier that week, I’d quietly rewritten part of a release plan one of my teams had drafted, because I “just wanted to clean it up.” Nobody asked me to. Nobody saw the original. I was giving this advice while caught in the same trap, on the same week, in the same building.
The fires I was putting out were lessons everyone else skipped learning.
The standard advice goes: delegate more, give context not instructions, set constraints not methods, define the end state and let them find their own path. All of which is correct. None of which prepares you for how it feels when it works.
It feels like loss. Not the dramatic kind. The quiet kind. The kind where your calendar gets a little emptier and you’re not sure what to fill it with. Where you read a Slack thread and realise your input would have been fine but unnecessary. Where the team makes a decision you would have made differently, and it turns out their way was better.
A colleague told me once that the goal of a manager is to make yourself redundant. I always thought that was a nice metaphor. I didn’t expect it to feel so literal. And I didn’t expect to need entirely new ways of watching for the things that go quiet when no one’s looking.
I’m writing this about two weeks after that week. The coaching conversations continue. The teams continue to grow. I continue to fight the urge to be useful in ways that are no longer useful.
What I do know: the first time one of my engineers independently answered twenty questions from a senior reviewer without looking my way, I felt something I didn’t expect. Not pride, exactly. Something closer to relief. Like I’d been holding my breath for months and someone finally told me I could exhale.
The teams are standing on their own feet. My new job, the one I’m still learning, is watching for the places they stand without looking down.
]]>Exploratory code. A draft PR, the kind of thing you push to a branch because you’re playing with an idea, testing whether a new abstraction might clean things up. Not merged, not even intended for review yet. A senior colleague from another team saw it and escalated: where’s the ADR? Why wasn’t this discussed? When I said the interaction felt demotivating, the response was two words: “your problem.” The incident passed. The lesson my team took from it hasn’t.
Engineering governance exists for good reasons. ADRs, architecture reviews, technical standards: these are tools for alignment. They protect teams from costly surprises and give everyone a voice in decisions that affect them.
But governance can be picked up by anyone for any purpose. And when a senior person uses process language to shut down a junior team’s exploration, something breaks. Not the code. The team.
Here’s the pattern I keep seeing: the same people who make architectural decisions unilaterally (framework choices, ORM adoption, infrastructure changes) become governance enthusiasts when someone else’s team tries something small. The ADR process, meant to be a tool for collaboration, becomes a gate. And gates have gatekeepers.
The question isn’t whether process matters. It does. The question is: who gets to explore without a permission slip, and who gets cross-examined for writing draft code?
Here’s the philosophy I keep coming back to, the one I try (and sometimes fail) to live by: be tight on the what, silent on the how.
Define the end state. Be crystal clear about what needs to be true when the work is done. Quality standards, security requirements, performance targets, customer commitments: these are non-negotiable. Write them down. Make them specific.
Then shut up about the path.
I gave this feedback just this week on an engineering standards document. Seven documents covering every aspect of how to write code. My response: make it one. A short, strict spec of what must be true. Rules, not methods. Then let teams figure out how to get there in their own way, on their own terms.
This isn’t soft management. Constraints are hard. “Every API endpoint must have contract tests” is harder to live up to than “follow these 14 coding guidelines.” Constraints expose gaps ruthlessly. Methods let you hide behind compliance.
But constraints also create space. Space for draft PRs and exploratory code and half-baked abstractions that might turn into something brilliant or might get quietly deleted. Space for the kind of messy, creative engineering work that actually moves things forward.
Governance that prescribes the method instead of the constraint isn’t alignment. It’s control.
I manage three engineering teams. My main goal is helping each team stand on their own feet: engineering capability, management maturity, the confidence to make decisions without looking upstairs first.
That goal lives and dies in moments like the one that started this post. When a team takes initiative and gets treated like they’ve committed a governance violation, they learn something. Not the lesson you intended. The real lesson: don’t try new things unless you’ve pre-cleared them with someone more senior. Play it safe.
Safe teams don’t build anything interesting.
I don’t have the high ground here. I’ve been territorial about code I felt ownership over. I’ve shut down conversations I should have stayed in. You don’t get to this level without having been, occasionally, the problem.
But knowing that doesn’t change what I’m building toward. The next time one of my teams pushes a draft PR with a half-formed idea, I want them to feel like they did something brave, not something that requires an apology.
Define the constraints. Make them clear and hard. Then get out of the way. That’s the job.
]]>It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.
Darwin probably wasn’t thinking about tech hiring when he wrote this, though I first encountered this quote in Kent Beck’s “Extreme Programming Explained.” But here we are. Over the past three-plus years, our engineering hiring process has been on a wild ride of transformations. Not because some consultant told us to, not because we read it in a blog post, but because… well, things kept changing and we kept trying stuff. This is that story.
Three-plus years ago, when I took over hiring responsibilities, I inherited what seemed like a solid, time-tested process. Private portal, comprehensive assignments, PHP specs, EER diagrams: the works. This had been the way things were done for years (I’d gone through it myself when I was hired back in 2019). Candidates would disappear for 3-5 days and emerge with their solutions.
It mostly worked. We could spot who understood patterns, who thought about security, and who could document their thinking. But my favorite discovery? README files became this unexpected window into people’s minds. The way someone explains how to set up their project, how they anticipate confusion, how they communicate with a future stranger - pure gold.
At some point, we had this collective moment of “Wait, are we asking too much?” Five days of someone’s life for maybe getting a job? That felt… heavy.
So we pivoted. Live coding! Respectful of time! Only 1-2 hours! What could go wrong?
For backend folks, we cooked up these Slim framework challenges. 30-40 minutes, boom, done. People seemed to appreciate it, and we could watch them think in real-time. Pretty cool.
Frontend was… a different story. For an entire year (I kid you not, a YEAR) we couldn’t find Vue.js developers who could handle basic tasks. “Fetch data from an API and put it in a table.” That was it. And yet, when we did find people who breezed through? They became absolute rockstars on our team.
Then my direct reports wanted to take ownership of the hiring process. Fresh eyes, fresh ideas. Their theory? Maybe live coding was too stressful. Maybe we were losing gems to performance anxiety.
Back to take-home we went. For the frontend, we switched to Vue 3 projects with public APIs. Backend reverted to our original portal assignments. And wow, suddenly everyone was passing! Success rates through the roof! We were geniuses!
…Until these same stellar assignment-completers joined the team and proved less capable than those who’d excelled in our live coding sessions.
This got us thinking. The people who breezed through live coding consistently outperformed those who aced take-home assignments but struggled with real-time collaboration. Maybe we were onto something with that live format after all.
Just when we thought we had it figured out (narrator: they didn’t), ChatGPT and friends crashed the party. Our carefully crafted assignments? Obsolete overnight. What took juniors days now took anyone with decent prompting skills about 20 minutes.
The generational shift was fascinating to watch. Early on, candidates would get this deer-in-headlights look when we mentioned they’d clearly used AI. Like kids caught with their hand in the cookie jar. Fast forward a few months, and NOT using AI was the weird choice. It became as natural as breathing.
Suddenly, we’re asking different questions. If AI can write the code, what’s left? Turns out - everything that makes us human. How you think, how you communicate, how you collaborate, whether you can navigate the beautiful mess of ambiguity that is real-world software development.
After all this experimentation, we’ve learned some things. Or at least, we think we have:
The best code isn’t always the cleverest code - it’s the code your teammate can understand at 3 AM during an incident.
Seniority used to mean “can implement any spec flawlessly.” Now it means “can figure out what we should build when nobody’s quite sure, and help the team get there together.”
AI changed the game, but it didn’t replace the players. The engineers thriving now are the ones who see AI as another tool in the toolbox, not a magic wand.
We’ve gotten great feedback about our process from candidates, which makes us feel pretty good. Then we go through other companies’ interview processes and… yikes. Humbling. If we had it all figured out, we wouldn’t still be changing things.
Will we change our approach again? Actually, we already are. Vassilis Poursalidis, our Engineering Director, is spearheading a new unified approach that goes live-by-default for everyone—frontend, backend, QA, the whole crew. Because here’s the thing about working in tech: the moment you think you’ve got it figured out, the ground shifts. The process that works today might be laughable tomorrow. And that’s actually… kind of exciting?
We’re not adapting because we have to survive. We’re adapting because it’s interesting, because we’re curious, because every failure teaches us something new. Even when those failures are spectacular.
Our hiring journey has been messy, nonlinear, sometimes frustrating, often surprising. But it’s been ours. Every weird experiment, every “what if we tried…”, every pendulum swing - it’s all been part of figuring out how to find people we want to work with.
In technology, evolution isn’t optional; it’s the path to excellence.
At TalentLMS, we’re always trying new things and learning as we go. If that sounds like your kind of environment, come join the experiment.
Originally posted in the TalentLMS Tech Blog
]]>This site is built with Jekyll and hosted on GitHub Pages. The presentations section uses Reveal.js for interactive tech talks, while the blog uses simple Markdown for easy writing and maintenance.
Stay tuned for more content!
]]>