How Many Teams Does It Take To Screw In a Lightbulb?

A marketing landing page should take one developer a few days. If your organization can turn it into a quarter-long program — and you already know it can — you don’t work somewhere agile. You work in its opposite.

---

Everyone knows the joke. How many [pick your group] does it take to screw in a lightbulb? The humor always lives in the gap between how trivial the task is and how absurd the answer turns out to be. One bulb. One socket. One twist. And yet somehow the answer is five, or eight, or a committee and a working group.

I want to tell you the corporate version. It has exactly the same structure. The only differences are that it isn’t a joke, it’s your last quarter, and by the end you’ll be able to finish it without my help — which is the entire point.

The bulb

Here is our lightbulb: a marketing landing page. One web page. One call to action. Some analytics so the campaign can count visits and conversions. That is the whole feature.

Be honest about what it takes to build. A developer with access to the relevant systems builds this in two or three days. Add content, a design pass, QA, and a stakeholder look, and you reach a week, generously. The engineering is neither interesting nor hard, and nobody who has actually done it pretends otherwise. Hold that number — a few days — because everything that follows is measured against it.

Now let’s screw it in

The page can’t simply be built, because building it isn’t something anyone is allowed to just do. It has to be requested — through an intake form, into a demand queue, where it waits to be prioritized against everything else. In a lot of shops it then waits for the next quarterly planning cycle to even be scheduled, and if it misses the window it waits for the one after. Six weeks can disappear right here, and not one minute of it is work.

Then it has to be refined, estimated, and story-pointed, and pass a Definition of Ready — two meetings to decide whether a landing page is a three or a five. Then the dependencies fan out: you don’t own the site platform (the CMS team does), or the analytics (martech does), or the design (the design-system team does), so the page becomes three tickets in three other backlogs, each with its own intake and its own quarterly rhythm.

Then come the reviews, run one after another instead of together — brand, legal, accessibility, and, because counting conversions means collecting user data, the data-governance gate, where a new tracking event waits on an approval that has no clock on it. Architecture review, queued behind the two overloaded architects whose calendars are the real release schedule. Security review, because it’s a new public surface. And because every one of these happens late and in series, each rejection bounces the work back to the end of a queue: privacy doesn’t like the tracking approach, redo; brand wants a different button, redo.

Finally — built, reviewed, approved — it still can’t ship, because shipping needs a change ticket, a Change Advisory Board, a release window that isn’t during the freeze, and a couple of tickets to networking for DNS and a certificate.

Then the page that took three days goes live. A quarter later.

The arithmetic

Add up the hours anyone actually touched it. A few days against thirteen weeks is a flow efficiency of three to five percent. The bulb spent ninety-five percent of its life in a drawer, waiting for someone who paid no price whatsoever for making it wait.

And now notice the thing this entire essay has not mentioned, anywhere, across a full quarter of elapsed time: anyone writing the code. The actual act of building the page — the part this whole apparatus supposedly exists to govern — never came up, because against thirteen weeks of queue it rounds to zero. We spent two thousand words on a feature and never once reached the keyboard.

So let me say it as plainly as it can be said: your developers are not the problem, and accelerating your developers will not fix it. Every improvement the organization will reach for targets the same wrong five percent. Hire more engineers. Buy the AI coding tool. Push the team to raise its velocity. None of it touches the queue. You could make the engineering instantaneous — a flawless senior developer with an AI swarm finishing in zero seconds — and the landing page would still take a quarter, because the developer was never the bottleneck. The waiting was. An organization that answers a flow problem by optimizing the one part that was never slow has just told you something true about itself.

It gets worse, because the bulb starts breeding

Somewhere in that quarter, someone reasonable says the reasonable thing: we should make sure the next landing page isn’t this painful. Hold onto that sentence, because it’s a genuinely good instinct, and it is about to become the problem.

That sentence spawns an initiative — a Landing Page Center of Excellence — and immediately two things happen. The first is that your landing page, the real one, with the real campaign date, now waits on the initiative, because it would be wasteful to ship the old way while the new way is being designed. The second is a quiet war over who owns the Center of Excellence, because whoever owns it gets to attach the business results of every landing page, forever, to their portfolio.

Sit with that second one, because it’s the tell. People are fighting to own the capability, not to ship the page. In this organization, owning a thing earns headcount, budget, and promotion; shipping a thing earns a thank-you in a Slack channel. The org has quietly made control more rewarding than contribution, and the turf war is just everyone behaving rationally in response. Watch what people fight over in your meetings — territory or outcomes — and you’ll have your diagnosis inside ten minutes.

While that plays out, the page also has to survive an engineering review, where someone rejects the simple version because it wouldn’t hold up at Google scale. It will never see Google scale. It will see a marketing campaign. But “this needs more rigor” is a safe thing to say and “this is fine, ship it” is a dangerous one — because if it ever breaks, the person who said ship owns the failure, while the cost of over-building gets smeared invisibly across everyone’s next year. The incentives quietly pay people to gold-plate, so they gold-plate.

And the page needs to be in four languages, so the Translations team is inserted — not as a service the team can call, but as a team the work must be routed through, with its own intake and its own queue. The need is real. The form it takes is the disease: every legitimate requirement gets answered with a team you must go through instead of a capability you can use.

And the page needs somewhere to live — which is where the tech debt arrives to collect. The platform it would naturally sit on is being decommissioned; there’s a multi-year effort underway to replace it, and the standing rule is that nothing new gets built on the thing that’s being sunset. Fine: put it on the new platform. Except the new platform isn’t built yet. So your three-day landing page is handed a choice between waiting for an infrastructure migration with no firm date, or “helping” — by building, or finding the budget to fund, the slice of the new platform it happens to need. A marketing page is now a stakeholder in a replatforming initiative, and nobody in the room finds this strange.

Notice what just happened across every one of these. The organization didn’t grow because something went wrong. It grew because people tried to do things right — reuse, rigor, localization, modernization. The dysfunction doesn’t only feed on failure. It feeds on your virtues. The instinct to make the next one easier became the structure that makes the next one harder. The reform became the disease.

And I could keep going

The accessibility audit. The vendor security questionnaire. The VP who needs a readout before sign-off. The new intake form for requesting time from the team that owns the intake form.

But I don’t need to write any of those, because you already did. You read “I could keep going” and your brain supplied three more before you reached the end of the sentence. You weren’t surprised by a single line of this. You were nodding.

That — the nodding — is the diagnosis. You don’t recognize this because it’s well-observed writing. You recognize it because you live there, and somewhere along the way the absurd became the expected, and the expected stopped looking absurd. Your ability to extend the list effortlessly is not a sign that you’re clever. It’s a sign of where you work.

But there were two ways you just reacted to that list, and they are not the same. If you read it wincing — if you supplied your own examples the way someone names their own bruises — then you’re a fellow hostage, and this piece is on your side. If, on the other hand, your instinct was to correct me — if some part of you wanted to point out that I left out the architecture council sign-off, or the cost-allocation tagging review, or the data-classification questionnaire, and you wanted to add them not as fresh absurdities but as necessary steps I had carelessly omitted — then I have news you are not going to enjoy. You weren’t finding holes in the argument. You were demonstrating it. If you read all of this and concluded it was normal, or correct, or the responsible way to run software, and your contribution is a longer list of gates: congratulations. You are not the person stuck behind the apparatus. You are the apparatus. You are the reason the lightbulb takes a quarter, and you have mistaken that for the reason it’s safe.

None of the gates are villains

Privacy review exists because privacy law is real. Security looks at new surfaces because attackers do too. Platforms can be genuinely wonderful, and some features really shouldn’t be built the cheap way. So the argument is not tear out the governance. The argument is about the line between governance that serves shipping and governance that obstructs it — and that line is unusually crisp.

A good platform is pulled into existence by demonstrated, repeated demand; a bad one is pushed into existence on speculation. A good one is opt-in and judged by whether teams get faster; a bad one is mandatory and judged by how much work routes through it. A good review knows how to say “this is appropriately simple”; a bad one only ever says “more.” A good capability is a tool you pick up; a bad one is a line you stand in. Good gates run early and in parallel; bad gates run late and in series. The disease was never review, or platforms, or localization. The disease is governance that is unowned, undifferentiated, late, serial — and that has no floor, no sense of how little process a small thing deserves.

The only diagnostic you need

Forget whether you do standups. Forget whether you have a board with the right columns and a certified coach. Ask one question:

Can your organization let a small thing stay small?

Because the cautionary-tale organization has lost the ability to do small things. It has no small things left — only initiatives that haven’t grown up yet. Every feature is a program in larval form, and a landing page that should have cost one person three days instead grew a Center of Excellence, a turf war, a scale review it didn’t need, and a quarter it will never get back.

Agility was never the ceremonies. It was the capacity to do a small thing at the size of a small thing. An organization that can turn a lightbulb into a quarter-long, multi-team, politically contested program can call itself whatever it likes. It can have every ceremony and every certification on the wall. By the only measure that means anything, it is the precise opposite of agile.

The lights were already on

When the organization finally flips the switch — a quarter, maybe two, after the request went in — it discovers something it would rather not. The lights are already on. They have been for months. Back when the page was first needed, the marketing manager who needed it did the arithmetic the organization couldn’t: she put a domain on her corporate card, hired a freelancer on Fiverr — a designer based in India — and had a working page, CTA and analytics and all, live in three days for a couple hundred dollars. The campaign it was meant for has already come and gone. It converted fine. Nobody reviewed it for brand, privacy, accessibility, or scale, and it did not matter, because it was a marketing landing page and not a Mars lander.

That is the entire argument in one anecdote. The work was always a three-day job — I told you so in the first paragraph, and a stranger on the internet proved it while your apparatus was still booking its kickoff meeting. The only thing the organization added to a three-day job was the quarter.

And here is the part that should actually frighten you. The response to discovering that page will not be reflection. It will be an investigation into the unauthorized spend, a new working group on SaaS-procurement controls, and a policy requiring pre-approval for any corporate-card purchase — because, they will say, and not entirely without merit, the thing was never reviewed for security or privacy or brand. The act of routing around the apparatus becomes the incident that justifies expanding it. There is no escape hatch, because the machine eats the escape hatches too; even your rebellion is just more fuel. That is what anti-agile really is. Not the absence of standups — the presence of an organization that can turn a lightbulb into a quarter, and then, when someone finally screws the bulb in by hand, convene a committee to forbid it.