Every engineering team I have led has had the same argument at least once. Someone gets a pull request blocked, sighs, and says process is killing their creativity.
I get it. I have said it myself. Nobody got into software to fill in change request forms.
But I think we have this one backwards. The most inventive teams I have worked with never ran without rules. They ran with the right rules, and they owned them.
A Small-Town Company Gets It Right
Sally Gibson helps run Dawleys, a company of about 60 people in Ross-on-Wye. When she joined Debra and me on Corey-osity Unleashed, she said something I keep coming back to:
"Systems and processes give people a framework with which to work. They don't stifle creativity or proactiveness."
Dawleys builds guardrails, then lets the people inside them adjust those guardrails. Their "Every Second Counts" program asks staff for small improvements and money-saving ideas. In a few months, employees pitched 38 ideas. The company put 20 of them into practice.
Look at the ratio. More than half the ideas shipped.
Most companies with no process at all never get close to those numbers. Ideas die in hallway conversations. Nobody knows where to send a suggestion, who says yes, or who tests a change. The absence of a system does not free people. It strands them.
What 145 Studies Say
In 2019, Oguz Acar, Murat Tarakci and Daan van Knippenberg reviewed 145 empirical studies on constraints and creativity for the Journal of Management. They pulled research from strategy, entrepreneurship, operations, organizational behavior and marketing. The constraints covered rules, deadlines, tight budgets and formal processes.
Their conclusion: the relationship follows an inverted U. Too few constraints and people drift. Too many and they suffocate. The best creative work happens in the middle.
The part I find most useful comes next. The same rule sits at a different point on the curve depending on how people experience it. When people see a constraint as a creative challenge, it pushes them to explore new options. When they see it as a control attempt, it shuts them down.
Read it twice. The rule itself is rarely the problem. The story people tell themselves about the rule decides whether it helps or hurts.
The Blank Page Problem
Dr. Seuss wrote Green Eggs and Ham after his publisher challenged him to tell a story with fifty words or fewer. It became one of his best sellers.
Psychologist Catrinel Haught-Tromp named an experiment after it. In her study, 64 undergraduates wrote two-line greeting card rhymes. On half the rhymes, they had to include a specific noun... shirt, dog, kite, drum. Three independent judges scored the results.
The constrained rhymes scored as more creative. The effect carried over too. Students stayed more creative after the restriction went away. A second study let 46 students pick their own nouns first, and self-imposed limits worked the same way.
Haught-Tromp's explanation: constraints "limit the overwhelming number of available choices to a manageable subset."
Any engineer who has stared at an empty repo knows this feeling. "Build anything" produces nothing. "Build it in Python, on Postgres, behind our existing auth, shipping Friday" produces working software. The constraints do the first hundred decisions for you, so your brain goes to the decisions worth making.
Rules You Already Love
Look at the rules good engineers defend without a second thought:
- The linter rejecting your formatting, so review time goes to logic instead of whitespace.
- The CI pipeline refusing to merge a red build.
- Code review before anything touches main.
- The on-call runbook you open at 3 a.m.
Nobody calls these bureaucracy. They free your head for the hard problems. You stop arguing about tabs and start arguing about architecture.
Surgery offers the most dramatic example. In 2009, Atul Gawande and colleagues tested a one-page WHO surgical safety checklist in eight hospitals, from Seattle to Ifakara in Tanzania. It takes a few minutes to complete. Across 7,688 patients, major complications fell from 11% to 7% and inpatient deaths fell from 1.5% to 0.8%, according to the Harvard Gazette.
Surgeons did not lose skill or invention because of a checklist. The checklist caught the boring failures, so their skill went where it mattered.
So Why Does Process Feel Like a Cage?
Because the people who write most process never follow it and never revisit it.
Using the Acar framing, a rule turns into a control attempt when:
- Nobody explains why it exists.
- The people it binds had no say in it.
- Nobody has permission to change it.
- It outlives the problem it solved.
The last one quietly strangles engineering teams. Someone adds a manual approval step after an outage years ago. Someone fixes the root cause. The approval step stays, adding two days to every release, and nobody on the current team remembers why.
The team does not hate rules. They hate one fossil nobody will let them bury.
Dawleys handles the other side well. Their guardrails move, and the people inside them do the moving. Staff pitched 38 changes to their own ways of working. They did not wait for permission from on high. They had a path, and they used it.
I wrote before about handing a team autonomy with no scaffolding and watching it fail. This is the other half of the lesson. Structure without ownership breeds resentment. Ownership without structure breeds chaos. You need both.
How to Write Rules People Want to Follow
1. Put the why next to the rule. Every CI check, every approval gate, every template. One line on the problem it prevents. If you struggle to write the line, delete the rule.
2. Let the people who follow the rule change the rule. Give them a clear path: propose, test, adopt. Dawleys shipped 20 of 38 ideas because staff knew where ideas go and who decides.
3. Give every process an expiry date. Review each one on a schedule. Keep what earns its place. Kill the rest without ceremony.
4. Constrain the what, free the how. Tell the team the budget, the deadline and the non-negotiables. Leave the solution to them. Haught-Tromp's students got a noun, not a finished rhyme.
5. Watch for the tipping point. Remember the inverted U. When your engineers spend more time satisfying process than solving problems, you have gone past the peak. Pull back.
The Real Enemy
Creativity does not die from rules. It dies from rules nobody explains, nobody owns and nobody changes.
A 60-person company in a small English town pitched 38 ideas to improve its own systems and shipped 20 of them. Your engineering org has more people, more tools and more budget. What is stopping you?
Here is my challenge for this week. Pick one rule your team complains about. Sit down with the people who live with it and ask one question: does this still earn its place? Then hand them the wrench.