The junior engineer on my team was great. Fast learner, sharp instincts, the kind of person who makes you feel smug about a hiring decision. Six months in, I was proud of the progress she had made.
Then she told me she was leaving.
When I asked why, she said something I haven’t forgotten: “I feel like I’m still waiting to do real work.”
She wasn’t being ungrateful. She wasn’t wrong. I had run a textbook onboarding: graduated her through a learning path, assigned well-scoped tickets, shielded her from ambiguity while she “found her footing.” I had read the right blog posts, used the right frameworks, done everything a thoughtful engineering manager is supposed to do.
I had also accidentally built a school. And she had spotted it.
The School We Built Without Noticing
Most engineering teams grow people with school logic.
New engineers get a learning phase full of bounded tasks. Sprints become curriculum. Code reviews feel graded. Access still moves level by level, with someone else deciding when the next gate opens. The backlog comes with a reading list of internal wikis, architecture docs, and “here’s the ten things you need to understand before we trust you with anything real.”
We do this for understandable reasons. We want to lower the odds of public failure, so we remove ambiguity and sequence the hard parts.
But the effect is the same as any classroom: we have placed the learning before the doing.
Simon Sarris made the point well in 2024 in School Is Not Enough. People learn through the work itself.
What the school model looks like in a codebase
On an engineering team, the school model shows up as pre-decomposed tickets.
A senior engineer turns a project into small, bounded tasks before handing it to a junior. That feels generous. It also strips out the part of the job that grows senior judgment.
I’ve done this plenty of times. It makes contribution easier, but it also lets the senior keep running the project. The junior executes pieces of a design someone else already made.
That is staffing, not growth.
Senior engineers earn judgment by defining success and sizing scope. They also choose risks and explain uncertainty. They learn that by working through vague briefs, not by clearing neat tickets.
Bradford Cross makes a similar point about the damage of “just take the next ticket.” The deeper problem is the model it teaches. Engineers start to think their job is execution. They wait for someone else to define the problem. Then they stall when the edges disappear.
I’ve hired technically strong engineers from competent teams who froze the first time a problem arrived without predefined edges.
The Fake Work Problem
People can tell when the work is fake.
Starter projects and learning tickets tell the engineer that nothing important is at stake. We assign them because they seem educational, not because the team needs them done. Engineers can feel that difference.
I saw it with two onboarding engineers. One got our standard learning path, a sequence of scoped tickets designed to build context. The other got a real project with a fuzzy brief, real users, and a deadline that mattered. I gave her a senior as a backstop and made clear that a stumble would not count against her.
Three months later, their technical knowledge was roughly similar. Their behavior was not. The engineer on real work thought about outcomes. The engineer on the learning path thought about tasks.
Real work created care; the learning path created compliance.
”Safe” Is the Most Expensive Word in Your Vocabulary
Managers often say, “They’re not ready for that yet. Let them build confidence first.”
I think that gets the sequence wrong.
Confidence comes from surviving hard work, not from completing safe tasks. Real confidence is what lets an engineer walk into ambiguity, make a call, and stand behind it. K. Anders Ericsson’s research on expert performance points the same way. Expertise grows at the edge of current ability, with feedback from real outcomes. Safe tasks do not produce that.
Sarris puts it plainly. “It is building skill itself that builds self-possession.”
In engineering, that shows up when someone owns an incident from detection through post-mortem. It also shows up when someone carries a project from fuzzy brief to shipped feature and handles the stakeholder conversations that come with it.
Those experiences are the development. Engineers can pick up technical facts on demand, but judgment grows when someone makes a call and then lives with the result.
When you shield engineers from that work, you are postponing the bill. It comes due when they are nominally senior and still have never made a hard call.
The Apprentice Model
The alternative I’m reaching for isn’t “throw juniors in the deep end and see who swims.” That’s not how apprenticeships historically worked, and it’s not what I’m advocating.
The apprentice model is different. In Verrocchio’s studio, da Vinci didn’t show up and immediately produce masterworks. He mixed pigments. He prepared canvases. He did the unglamorous, real work of an actual studio. But the work was real: not simulated, not graded, not designed for his education. It existed because the studio needed it. And he was in proximity to people doing more complex work - watching how decisions got made, occasionally doing pieces of it himself, eventually being trusted with more.
The studio metaphor is more useful than the school metaphor for engineering teams, and I’d encourage you to spend some time with it. It also has a serious theoretical grounding: Lave and Wenger’s situated learning research found that newcomers in craft communities didn’t learn by being taught - they learned by participating, starting at the periphery and moving toward full membership as their competence grew. The community of practice was the curriculum.
In a school, the point is the curriculum. The work exists to teach.
In a studio, the point is the work. Learning is what happens when you do real work seriously.
Your job as an engineering manager is not to be a teacher. Teachers transfer knowledge deliberately, sequentially, to students who are temporarily exempt from the demands of the real world. That model made sense when knowledge was scarce and expertise was hard to access. It doesn’t map well to an environment where any engineer can learn almost anything on demand.
Your job is to be a studio owner. You find real work worth doing. You make sure your engineers have enough context to attempt it. You are a backstop when they go off the edge, not a railing that prevents them from going anywhere interesting.
Will Larson writes about the art of finding “safe learning projects that also provide real value to the business.” I’ve long admired how precisely Will thinks about organizational problems, and he’s right that this is an art. But I’d push back on the framing. The goal isn’t to make the project safe. The goal is to make the environment safe for learning, which is a different thing. A project with real stakes, a patient senior as a backstop, and a manager who will not punish honest failure - that’s a safe learning environment. A project with artificially reduced complexity is just school with a paycheck.
The Permissionless Principle
There’s a specific point Sarris makes about software that I keep returning to when I think about engineering culture.
He argues that programming thrives because of its “permissionless culture.” You don’t need a building permit. You don’t need an audience or a patron. You don’t have to ask anyone. You can just create. He argues this is one of the reasons precocious children are drawn to it: it is one of the few domains that doesn’t make them wait.
He’s right. And most engineering managers are quietly dismantling this.
The permission creep is subtle. It starts with process: tickets must be groomed before you work on them, PRs need two approvals, production access requires a six-week onboarding milestone, architectural decisions require an RFC. Some of this is necessary. Infrastructure has real blast radius. But at some point, you’ve built a bureaucracy that requires explicit permission at every step, and you’ve sucked the agency out of what should be the most agentive environment in any company.
The engineers who grow fastest are almost always the ones who don’t wait to be handed problems. They notice something broken in the codebase and fix it. They read the roadmap and find an inconsistency and bring you a proposal. They implement the improvement that wasn’t in the sprint and show you the metrics afterward. They move ahead and course-correct when needed.
Your job is not to make this harder in the name of process. Your job is to create conditions where this happens. That means being explicit about what engineers can do without permission. It means celebrating the engineer who shipped an unrequested improvement more than the engineer who waited patiently for a ticket. It means tolerating - even welcoming - a certain amount of productive noise.
(I’ve worked at places where shipping unrequested code was a fireable offense. Those places did not grow good engineers. They grew compliant ones. Compliant is not a career outcome.)
The permissionless principle also extends to how you define scope when you do assign work. Leave something undefined. Leave the hard question unanswered. Not because you’re being lazy - and this is important, because there’s a real difference between generous ambiguity and careless ambiguity - but because the act of the engineer having to find the answer is part of the education. Carnegie didn’t learn the telegraph because someone designed a learning path for him. He convinced his boss to let him try, and then he figured it out.
What Real Stakes Actually Feel Like
Real stakes don’t require catastrophic risk. I’m not suggesting you put a junior engineer on-call for a P0 service in their first month.
Real stakes means: the work matters. The outcome affects something real. The engineer can feel the difference between doing it well and doing it poorly, without needing a code review comment to tell them. Someone, somewhere, actually cares whether this gets done right.
In practice, I’ve found this shows up in a few specific forms.
One is owning a user-facing feature end to end - not just implementing the code someone else designed, but making the product decisions about scope, communicating about trade-offs with the PM, and being the person who explains in the post-release review what shipped and why.
Another is writing the post-mortem after something they own breaks in production. This one is uncomfortable and I’ve had to resist every instinct to do it for them. But there is no substitute for the experience of writing a document that explains, to stakeholders and colleagues, what went wrong on your watch and what you’re going to do about it. It develops a kind of seriousness about reliability that no training module comes close to.
A third form, and this one is underrated: becoming the person other people route questions to. When an engineer becomes the domain expert that their colleagues ping before pinging you, something shifts. They start thinking about their work differently. They notice the edge cases at the boundary of their domain. They start caring whether the thing is actually good, not just whether it passes review.
That shift - from executing to owning - is the thing you’re trying to produce. And it only happens when someone else depends on you for real.
The Senior Engineer’s Role in All This
Senior engineers often get the wrong instruction.
We tell them to mentor juniors, review code, and stay available. That pushes them toward the role of teacher.
The more useful framing: the senior engineer’s job is to be the studio, not the classroom. They model the work, not the curriculum.
Bring junior engineers into real decisions. When you scope a project, think out loud with them in the room. They learn how good engineers handle ambiguity by watching the work happen.
Review PRs like conversations between peers. Code review should feel like joint problem-solving, not grading.
Sometimes a senior engineer has to step back and let a junior wrestle with the hard part. It is slower in the moment. It is still the better trade.
An Honest Note on AI
I can’t write this post in 2026 without acknowledging the AI acceleration context, because I think it changes the argument slightly.
If your theory of the world is that senior engineers are valuable primarily for their execution speed - their ability to produce correct code quickly - then you might worry that AI is compressing that value. You’d be at least partly right.
But if your theory is that the real value of a senior engineer is judgment - knowing which problem to solve, when to push back on a product decision, how to frame a technical risk so leadership can actually reason about it, when a simple solution beats an elegant one - then AI makes the apprentice model more important, not less. The work that remains most distinctively human is exactly the work you can only learn by doing it under real conditions.
Training an engineer to complete pre-defined tasks is now, more than it has ever been, a mistake. The tasks are the part that will be automated. The judgment is the part that won’t be. And judgment only grows through experience with real stakes.
What to Actually Change
Stop pre-decomposing everything. When you’re tempted to break a project into tasks before handing it to a junior, ask yourself: what’s the minimum scoping I can do here and still have this be viable? Can I give them the (sub)problem instead of the tasks? What do they need to know, and what is it more valuable for them to discover?
Give ownership of outcomes, not activities. “You own the reliability of this service” is different from “you own the on-call rotation for this service.” The first creates an engineer who thinks about the system. The second creates an engineer who rotates through tasks and runbooks. The language you use sets the frame for how people think about their work.
Make the stakes visible. Engineers often don’t know that what they’re working on matters to real people. They don’t know the customer has been complaining about this bug for six months. They don’t know the PM has been asking for this feature in every planning meeting for a year. Tell them. Let the real weight of the work land. Some engineers will rise to it. The ones who don’t are telling you something useful early. Of course, do this in a safe environment, acknowledging what’s actually feasible.
Explicitly carve out permissionless space. Tell your team: if you see something broken and you have a fix, ship it. If you have an idea for an improvement that fits in an afternoon, try it. Make a clear distinction between “things you can do without asking” and “things that need coordination,” and make the first category as large as possible.
Bring people into the room when decisions get made. When you’re making a hard call about technical direction or navigating a difficult stakeholder conversation, bring a junior engineer with you. Not to vote, but to watch. They should see how a good engineer handles a situation that isn’t clean. You will teach them more in that hour than in a month of tickets.
Make the onboarding project real. This one is uncomfortable. It’s tempting to design a perfect starter project: safe, bounded, non-critical, pedagogically structured. Resist it. The best onboarding projects are the ones where the engineer is doing a thing that actually needs to happen, and someone else on the team genuinely cares whether it gets done well. The sense of contribution has to be real. Fake contribution produces fake confidence, and fake confidence is worse than no confidence because it’s invisible until it fails.
There’s a question underneath all of this that’s worth sitting with honestly: what are you actually trying to produce?
If the answer is “engineers who can reliably complete the tasks on their backlog,” the school model is fine. It’s efficient. It produces people who are skilled at defined tasks and comfortable in defined environments.
If the answer is “engineers who can figure out what to build and why, who can navigate genuine ambiguity, who can grow into senior and staff roles and eventually solve problems you haven’t encountered yet” - then you need something different.
Sarris writes that “the purpose of education is to develop agency within a child. Purposeful work and achieving mastery are tools to getting there. They aren’t the results of learning and imagination, it’s the other way around.” Swap “child” for “engineer” and you’ve described what most of us should be doing differently.
Agency is learnable. But only through agency. You cannot teach it by proxy. The engineer who spends three years completing pre-decomposed tickets has learned to complete pre-decomposed tickets. The engineer who spends three years owning real problems has learned to own real problems.
That’s the only kind of growth that actually transfers.