If You've Been At The Same Company 3+ Years, You're Already In A Box
TL;DR
If you’re comfortable 100% of the time, you’re probably coasting — Ian Miell’s rule of thumb is to feel uncomfortable about 30% of the time, because growth comes from stepping outside the technical domain that already made you successful.
Staying 3+ years at one company can put you “in a box” — after 14 years at one firm that grew from 39 to 770 people, Miell found colleagues had fixed expectations of him, while a new company gave him six months of fresh credibility and room to redefine himself.
Seniority is less about stronger opinions and more about better judgment calls — as CTO of Container Solutions, Miell says his value now is coaching, spotting what will work, hiring the right people, and matching engineers to clients, not overruling technical decisions from above.
A lot of “bad architecture” is just incentives made visible — Miell’s core thesis is that architecture follows money: in one gambling company, 30 customers with 6 driving 80% of revenue produced fragmented software because big patrons wanted fast, custom delivery, not a clean product.
Most organizational conflict makes more sense once you understand incentives — legal, compliance, security, regulators, customers, and business units all optimize for different outcomes, so the key to buy-in is speaking to what each group is actually measured on and afraid of.
AI lowers the cost of building software, but raises the cost of differentiation and maintenance — Miell expects more duplicate tools, more fragile systems no one fully understands, and more value accruing to people who can build the right test, security, and compliance harnesses around fast-moving code.
The Breakdown
Start With the Room, Not the Slides
The conversation opens on influence: how do technical people get buy-in from senior leadership? Miell’s answer is refreshingly human — don’t just present, read the room. If someone senior looks bored, he’ll literally say, “I feel like I’m losing you,” because naming the tension gives people permission to admit confusion instead of silently checking out.
The 30% Discomfort Rule
From there, they zoom out to career growth. Miell says you should feel uncomfortable in your job about 30% of the time; if you’re comfortable all the time, you’re probably just repeating what you already know. He shares his own experience of leaving a company after 14 years and feeling completely lost in a new domain — painful in the moment, but exactly the kind of reset that forces growth.
Why Long Tenure Can Trap You
One of the sharpest ideas in the episode is that other people box you in too. At his long-term employer, even as the company grew from 39 to 770 people, Miell had become “that person,” useful but predictable. Once he moved, he noticed people listened to him differently for about six months, which helped him break out of the role everyone had unconsciously assigned him.
From Engineer to CTO by Following Curiosity
Miell didn’t climb by chasing titles — he joined Container Solutions wanting to “get back to engineering” after a rough career patch. But he kept asking commercial questions like “What’s the cash flow?” and “Where’s the revenue versus profit graph?”, which pulled him into sales, then board-level conversations, and eventually the CTO role. His framing is that every career move is a trade: you give your current specialism and take new learning in return.
Why Engineers Clash With Legal, Security, and Compliance
The middle of the interview gets into org dynamics. Engineers are rewarded for moving fast and taking calculated risks; security and legal are often rewarded for preventing mistakes, which makes them the “department of no.” Miell’s point isn’t to complain about that tension, but to understand it — if you walk in having already mapped the risks and mitigations, those teams relax because you’re speaking their language.
AI Makes Building Easier — and Everything Around It Harder
When they turn to AI, Miell is less interested in hype than second-order effects. If software becomes cheaper to produce, you don’t get fewer systems — you get more, like adding lanes to a motorway and discovering traffic gets worse anyway. He expects a wave of AI-built tools, plus messy maintenance problems when businesses realize no one really understands how the code works, and says the real craft may be in the test harness, compliance, and security scaffolding around the code.
“Architecture Follows Money”
Miell then explains the big thesis behind his book. At an online gambling company, 30 customers — with 6 accounting for 80% of revenue — pushed the team toward fragmented implementations because those big patrons wanted their features fast, not a neat shared product. Later, at a bank with 220,000 people, he saw a Kubernetes/OpenShift platform whose user base doubled every three months but still couldn’t get more funding, because the finance model had no mechanism to reward internal adoption.
Systems Thinking Means Blaming the System Before the Person
The interview ends on why people misread organizations. Engineers often look at a weird schema, an ugly workaround, or a bad process and assume someone was stupid; Miell says the better instinct is to ask what business pressure made that decision rational at the time. That’s his version of systems thinking: don’t become defeatist, but do stop punishing yourself for not being able to “win” against incentives that were never designed to support your version of the right thing.