Chapter 28: Leading the Humans - Hiring, Meetings & Remote Teams

The previous two chapters covered where the bottleneck moves and how adoption actually lands. This one is about the organization itself: who you hire, how you spend their hours, and how you lead them when nobody shares a room. AI raised the price of judgment across the whole SDLC - and hiring, talent development, meetings, and distributed leadership are the places where judgment gets hired, grown, spent, or quietly lost. Every section here is the same lesson wearing different clothes: clarity and ownership, written down, with one name attached.

Hire Drivers, Not Doers

I recently passed on two senior engineering candidates. Both were technically competent. Neither made it past me. The feedback I sent back to the firm sourcing for us applies well beyond one open req: I am not looking for a do-er. I am looking for a driver.

Both candidates presented as executors. They could describe what they built when handed a spec. Neither could point to a problem they owned end to end, made the calls on, and drove from ambiguity to shipped. That distinction is the entire role.

My teams are 100 percent remote. Nobody is looking over anyone's shoulder, and I do not want there to be. That model only works with people who take initiative by default, set their own direction inside a goal, and close the loop without being chased. A do-er waits to be told the next step. A driver finds it.

At the senior level I also need the why and the how, not the what. "I built the payments service" tells me nothing. Tell me the tradeoffs you weighed. Why you chose one approach over another. What you would do differently. How you reason about a system you have never seen before. That is what separates a senior engineer from a mid-level engineer with a longer resume.

Here is the uncomfortable part. Senior hiring right now is flooded with people who look strong on paper but have only operated inside well-scaffolded teams, where a lead broke the work down and they filled in the code. With AI tooling absorbing more and more of the pure implementation work, that profile is worth less every quarter. This is the skillset shift from Chapter 1 showing up in the hiring funnel: the market stopped paying a premium for translation-to-code the same quarter agents got good at it. The scarce skill is judgment - deciding what to build, deciding how to architect it, owning the outcome when it does not go to plan.

What I actually screen for is evidence of ownership, because ownership cannot be faked in the past tense. Walk me through a decision you got wrong and what it cost. Show me the moment you chose boring technology over interesting technology, and why. Tell me about something you shipped that you argued against building. Those answers require having been the owner - a candidate who only ever executed someone else's breakdown has no material to answer with. I would rather see two candidates who clearly clear that bar than ten who match the keyword list.

The Junior Pipeline: If AI Does the Junior Work, Where Do Seniors Come From?

The hardest question other engineering leaders ask me right now is not about tools. It is this: if agents absorb the work we used to give juniors - the well-scoped ticket, the boilerplate, the first bug fix - the apprenticeship loop that produced every senior engineer you employ is broken. Seniors were made by doing years of junior work under supervision. That path is closing while the demand for judgment goes up.

The lazy answer is to stop hiring juniors, and plenty of companies have quietly done exactly that. It is also eating the seed corn. A decade from now the industry's seniors have to come from somewhere, and "someone else will train them" does not survive everyone believing it at once.

The real answer is that juniors skip the typing years, not the judgment years. The entry-level job is no longer producing code from a spec - an agent does that. It is reading more code than you write, running structured review on agent output with a senior within reach, and learning to say "this is wrong" with a defensible reason. Code reading is the new entry-level muscle, and it builds the same instincts code writing used to - faster, because a junior reviewing agent output sees a hundred design decisions a week instead of ten.

Concretely, what that looks like on my teams: juniors start with verification work - tests, review checklists, eval failures - because verification teaches what correct looks like before you are asked to define it. They write the intent spec for their own tasks and defend it before the agent runs, which forces the "should this exist, and where does it sit" thinking that used to arrive in year five. And they own small outcomes end to end early, because implementation capacity is no longer the gate - judgment is, and judgment only grows under load.

The counterintuitive part: AI makes a junior productive faster than ever - a junior with agents ships like yesterday's mid-level from week one. The risk is not that they produce too little. It is that they plateau there, shipping forever on borrowed judgment, if nobody builds the curriculum for the layer above. This is the "drivers, not doers" bar applied as a development plan instead of a hiring filter. You cannot hire your way out of the judgment shortage. You have to grow drivers too.

Meetings: Run RACI Against the Calendar

You probably do not have too many meetings. You have too many people in them.

Here is the pattern I see everywhere: a meeting gets scheduled, someone adds "anyone who might care," and now eight people are sitting through a sprint planning session where two of them will speak and six will quietly answer Slack messages under the table. Most engineers treat every invite like a summons - and leading engineering teams, I constantly watch developers burn their best deep-work hours in meetings they simply do not belong in.

The fix is not a productivity hack. It is a decision-making framework most people learned once, forgot, and never applied to engineering. I use RACI to decide who actually attends:

* A - Accountable: attend. You own the outcome.
* R - Responsible: attend. You are doing the work.
* C - Consulted: join only for the agenda items that need your expertise.
* I - Informed: do not attend. Read the summary.

That last one is where most companies fail. We confuse "needs to know" with "needs to sit in a meeting." They are not the same thing - and AI just removed the last excuse for conflating them. "Informed" used to be a broken promise because nobody reliably wrote the summary. Now the summary writes itself: an agent processes the recording and produces the decisions, action items, risks, and owners within minutes, more faithfully than anyone's hand-typed notes. AI did not fix meetings. It eliminated attendance as an information channel, which is the only thing most attendees were there for.

So my standing rule for recurring engineering meetings is simple: A and R attend. C joins for relevant topics. I gets the AI-generated summary. Fewer spectators, faster decisions, more hours where software actually gets built.

And if everyone is invited anyway, your RACI has quietly evolved into RANCI - where the N stands for "Nobody knows why they're here."

Remote Teams: Distance Does Not Break Teams - Ambiguity Does

I have led remote engineering teams since 2012. Not 2020 - 2012, back when "we have a team in Eastern Europe" was something you explained to your board rather than something they assumed. That is not a flex. It is a long, expensive education in what actually breaks when people are not in a room.

Distance does not kill teams. Ambiguity does. Colocated teams survive vague ownership because someone overhears the confusion and fixes it. Distributed teams do not get that accident. Every unclear decision quietly becomes two people building two different things across a nine-hour time gap.

So the fix was never more meetings. It was writing things down and naming the person. RACI is boring - it is also the difference between a distributed team shipping the right thing and shipping something reasonable that nobody asked for. One name on the decision. Not a committee, not a channel, a name.

The second lesson: async does not mean slow. It means decisions have to survive being read. If a decision only makes sense when you explain it out loud, it is not a decision yet - it is a vibe with a Jira ticket attached.

The third lesson took me the longest: you cannot manage a distributed team by watching. You can only manage it by defining what done looks like and then getting out of the way. Every leader who moves to remote and reaches for activity metrics is trying to recreate the view from their old desk. It does not work, and the good engineers leave. Across teams in Eastern Europe, the Philippines, India, Ukraine, and China, the pattern has never changed: the teams that work are the ones where autonomy and accountability arrive together. Autonomy alone is abandonment. Accountability alone is surveillance.

The industry spent 2020 discovering remote work and 2023 declaring it dead. Both takes missed it. Remote was never the variable. Clarity was.

And here is the part that belongs in this book: fourteen years of leading distributed humans turned out to be direct preparation for leading agents. An agent is the ultimate remote teammate. It cannot overhear anything. It does exactly what the written context says. It fails on ambiguity faster than any offshore team ever did. Everything in Chapters 2 through 4 - context as infrastructure, success criteria written before work starts, one named owner per outcome - is the remote-team playbook applied at machine speed. If your organization already writes decisions that survive being read, agents slot in. If it runs on hallway conversation, agents will surface that debt within a week.