{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibovbdlfly7pnyjnfgtlat3rx3hxkvwk6sxzguro4kaeq3ryhll4y",
    "uri": "at://did:plc:fhnwwtr5bununtggzx7lgw6p/app.bsky.feed.post/3mks45win2nm2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifnhhl73dd6435cdu37k3ztf6o7ixv7qx5bx5gz6vuoc7pv4ojz5q"
    },
    "mimeType": "image/jpeg",
    "size": 301977
  },
  "description": "Your team is not a school. You are not a teacher. The studio model is what actually grows engineers, and most of us are running classrooms.",
  "path": "/your-team-is-not-a-school/",
  "publishedAt": "2026-05-01T12:13:11.000Z",
  "site": "https://leadership.garden",
  "tags": [
    "a piece",
    "research on expert performance",
    "situated learning research"
  ],
  "textContent": "The junior engineer on my team was genuinely good. 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.\n\nThen she told me she was leaving.\n\nWhen I asked why, she said something I haven't forgotten: \"I feel like I'm still waiting to do real work.\"\n\nShe 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.\n\nI had also accidentally built a school. And she had spotted it.\n\n## The School We Built Without Noticing\n\nLook closely at how most engineering teams grow people, and you'll find a remarkably familiar structure.\n\nNew engineers get a \"learning phase\" with bounded, pre-decomposed tasks. Sprints become curriculum. Code reviews become graded assignments. There is a syllabus - explicit or not - and someone is gating the next level of access until the previous one is complete. The ticket backlog even has a reading list attached to it: internal wikis, architecture docs, \"_here's the ten things you need to understand before we trust you with anything real._ \"\n\nThis isn't anyone's fault. It is the natural shape that protection takes. We care about our engineers. We don't want them to fail publicly. We shield them from ambiguity, pre-chew the hard problems, and drip-feed complexity in a sequence we believe is pedagogically sound. The intention is kindness.\n\n**_But the effect is the same as any classroom: we have placed the learning before the doing._**\n\nSimon Sarris wrote a piece in 2024 that's nominally about how we've failed children, but it hit me as a precise diagnosis of how we've failed engineers. He argues that \"learning is simply the consequence of doing\" and that we've inverted the sequence entirely. Leonardo da Vinci didn't become capable and _then_ become Verrocchio's apprentice. He became capable _because_ he was in the studio. Andrew Carnegie didn't master the telegraph by attending lectures about it. He convinced his superiors to let him operate the machine itself. The doing was the learning. The learning was not the prerequisite.\n\nThe same principle applies to your team. Most of us are violating it constantly.\n\n## What \"School\" Actually Looks Like in a Codebase\n\nI want to be precise about this, because vague diagnoses produce vague cures.\n\nThe school model, in an engineering team, looks like pre-decomposed tickets.\n\nWhen a senior engineer breaks a project into small, bounded, well-specified tasks before handing them to a junior, they are doing something that feels generous and is actually subtly harmful. They are stealing the cognitive work of decomposition - which is exactly the cognitive work that produces a senior engineer.\n\nI've done this hundreds of times. It feels efficient. You're lowering the activation energy, clearing the path, making contribution faster. But you're also, quietly, running the project yourself. You've outsourced the implementation to someone cheaper.\n\nThat's not growth. That's staffing.\n\nThe distinction matters because the work of becoming a senior engineer is almost entirely about learning to handle unstructured problems. What does success look like here? What's the right scope? Which risks are worth taking? How do I communicate a technical uncertainty to a non-technical stakeholder without either dumbing it down or terrifying them? None of these skills are developed by completing pre-decomposed tickets. They are developed by being handed a vague brief and having to figure it out.\n\nBradford Cross puts it well: the downside of \"just take the next ticket\" is robbing engineers of the learning opportunity to structure and decompose the work themselves. But I think the deeper damage is what it does to an engineer's _model of the world_. They come to believe that their job is execution. That someone will always define the problem before they have to solve it. That ambiguity is a sign something went wrong upstream, rather than a sign that the actual work has started.\n\nI've hired engineers out of perfectly competent teams who had this exact model. Technically skilled. Stuck the moment a problem arrived without predefined edges.\n\n## The Fake Work Problem\n\nThere's a pattern Sarris notices in schooling that I find chilling to recognize in engineering teams: the fake work problem.\n\nHe writes about how children eventually spot that schoolwork is fake. Teachers have to justify why the curriculum will be relevant. Students comply, but they know on some level that the assignments exist to fill time and produce grades, not to produce anything real in the world. And he argues that this is genuinely damaging: \"it is difficult to blame young adults for assuming that work is fake and meaningless if we prescribe fake and meaningless work for the first two decades of their existence.\"\n\nThe engineering equivalent is \"starter projects\" and \"learning tickets.\" Both are honest confessions that the work isn't real. You're not assigning these because the team needs them done. You're assigning them because they seem educationally appropriate. The engineer knows this. They can feel the difference between something that matters and something designed to be safe.\n\nI ran an experiment once. I had two engineers onboarding simultaneously. One got our standard learning path: a series of well-scoped tickets I had specifically designed to build context incrementally. The other got a real project - fuzzy brief, actual users affected, a delivery date that mattered. I gave her a senior engineer as a backstop and made clear I wouldn't hold a stumble against her.\n\nAfter three months, the difference was stark. Not in technical knowledge - they were roughly equivalent there. But in the way they approached problems. The one who had done real work was already thinking about her work in terms of outcomes. The one who had done the learning path was still thinking in terms of tasks.\n\nThe real work created something I can only describe as _care_. The engineer had a stake in it. The learning path created compliance. The engineer was waiting for the next instruction.\n\n## \"Safe\" Is the Most Expensive Word in Your Vocabulary\n\nThe standard defense of shielding junior engineers goes something like this: \"They're not ready for that yet. Let them build confidence first.\"\n\nI think this is exactly wrong. And wrong in an expensive way.\n\nConfidence doesn't come from completing safe tasks. It comes from doing difficult things and surviving. Real confidence - the kind that lets an engineer walk into an ambiguous situation, make a call, and stand behind it - is built only through having done ambiguous things. You cannot simulate your way to it. K. Anders Ericsson's research on expert performance found that expertise accumulates not from experience time alone, but from attempts at tasks at the edge of current ability - with real feedback from real outcomes. Safe tasks, by definition, don't qualify.\n\nSarris is direct about this: \"It is building skill itself that builds self-possession.\" He uses the example of a teenager who masters pastry-making to the point of selling it, and argues that the result isn't just culinary skill. \"He knows that he can make anything.\" Not because someone graded him. Because something real happened, and he did it.\n\nThe engineering equivalent is the engineer who owns an incident from detection to resolution to post-mortem. Or the engineer who carries a project from fuzzy product brief to shipped feature, including all the stakeholder conversations in between. Or the one who has to decide what to cut when the timeline compresses, and defend that call publicly to people who are unhappy about it.\n\nThese experiences are not decorations on top of development. They are the development. The technical knowledge is almost secondary - motivated engineers can acquire technical knowledge whenever they need it. What they cannot acquire from a book, a course, or a well-scoped ticket is judgment. And judgment only comes from having exercised judgment and then watched what happened.\n\nWhen you protect your engineers from this, you're not being kind. You are deferring a cost. The bill comes due when they're a senior engineer who has never actually made a hard call under pressure. Or when they leave because the work never felt real.\n\n## The Apprentice Model\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nIn a school, the point is the curriculum. The work exists to teach.\n\nIn a studio, the point is the work. Learning is what happens when you do real work seriously.\n\nYour 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.\n\nYour 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.\n\nWill 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.\n\n## The Permissionless Principle\n\nThere's a specific point Sarris makes about software that I keep returning to when I think about engineering culture.\n\nHe 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.\n\nHe's right. And most engineering managers are quietly dismantling this.\n\nThe 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.\n\nThe 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.\n\nYour 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.\n\n(_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._)\n\nThe 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.\n\n## What Real Stakes Actually Feel Like\n\nReal 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.\n\nReal 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.\n\nIn practice, I've found this shows up in a few specific forms.\n\nOne 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.\n\nAnother 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.\n\nA 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.\n\nThat 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.\n\n## The Senior Engineer's Role in All This\n\nI want to say something about senior engineers here, because I think they often get the wrong instruction.\n\nThe standard advice to seniors is: mentor your juniors, do thorough code reviews, be available for questions. This is fine as far as it goes. But it subtly casts the senior as a teacher, which reinforces the school model.\n\n> The more useful framing: the senior engineer's job is to be the studio, not the classroom. They model the work, not the curriculum.\n\nWhat does this mean in practice? It means bringing junior engineers into real decisions, not as observers but as participants. When a senior is scoping a project, they should be thinking out loud with junior engineers present - not to teach them how to scope, but because scoping is a real task that benefits from more eyes. The junior engineer learns how a good engineer approaches an ambiguous problem by watching a good engineer actually approach an ambiguous problem.\n\nIt means reviewing PRs in a way that treats the junior as a peer who made different choices, not a student who made mistakes. **_There's a version of code review that feels like grading. There's another version that feels like a technical conversation between people who both want the code to be good._** The second version is harder to do and much more educational.\n\nIt means occasionally stepping back from the interesting problem and letting the junior engineer fumble with it, even when you could have it done in a quarter of the time. This is genuinely hard. I find it one of the most difficult parts of growing engineers. But the hour they spend working through the problem themselves is worth more than the five minutes of explanation that would have spared them that hour.\n\n## An Honest Note on AI\n\nI can't write this post in 2026 without acknowledging the AI acceleration context, because I think it changes the argument slightly.\n\nIf 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.\n\nBut 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.\n\n> **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.\n\n## What to Actually Change\n\nI've spent a lot of words on diagnosis. Here's what I've found useful to change in practice.\n\n**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?\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n* * *\n\nThere's a question underneath all of this that's worth sitting with honestly: what are you actually trying to produce?\n\nIf 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.\n\nIf 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.\n\nSarris 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.\n\n> 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.\n\nThat's the only kind of growth that actually transfers.",
  "title": "Your Team Is Not a School"
}