The Hire That Looked Perfect on Paper
A long time ago….., I made what seemed like a brilliant hire. The candidate had twelve years of experience across three well-known tech companies, a computer science degree from a local prestigious university, and glowing references from former managers who called him “one of the best senior engineers” they’d ever worked with.
His technical interview performance was exceptional—he solved algorithmic problems with an elegance that made the rest of the team nod in appreciation. We made him an offer above our budget because everyone agreed we couldn’t let this kind of talent slip away.
Eighteen months later, I asked him to leave. Not because he wasn’t smart or capable, but because the technical debt he’d created in pursuit of clever solutions had become so severe that we had to allocate three other engineers full-time just to unwind the abstractions he’d built. What looked like seniority was actually intellectual vanity wrapped in experience.
And it taught me something I wish I’d understood a decade earlier about the difference between hiring for credentials and hiring for discipline.
The Seduction of the 'Senior' Label
We use the word “senior” in engineering like it’s a proxy for competence, as though the accumulation of years automatically produces the judgment required to build scalable systems.
But I’ve hired enough engineers across enough companies now to know that seniority and discipline are not only different qualities—they’re often inversely correlated. The most experienced engineers I’ve worked with are frequently the ones most enamored with complexity, most resistant to constraints, and most convinced that their expertise exempts them from the boring work of documentation, testing, and code review discipline.
There’s a particular archetype I learned to recognize too late in my career: the senior engineer who has spent a decade building clever solutions to simple problems, who treats every ticket as an opportunity to demonstrate intellectual sophistication, who dismisses process as something for junior developers who don’t understand the craft.
These engineers join your team, impress everyone with their velocity in the first three months, and then proceed to create architectural decisions that haunt you for years because they optimized for elegance over maintainability, for innovation over reliability, for personal satisfaction over team scalability.
The engineer I hired in this story, was exactly this archetype. He built a caching layer so sophisticated that only he understood how it worked. He created abstractions so deep that simple bug fixes required tracing through seven levels of indirection. He wrote code that was objectively brilliant and practically unmaintainable.
And when I finally asked him why he’d built systems this way, his answer revealed everything: “I was hired to be a senior engineer, so I built senior-level solutions.” He thought complexity was the marker of seniority. That’s when I realized we’d been selecting for the wrong variable.
What Discipline Actually Means in Engineering
Discipline in engineering is not about following rules for the sake of compliance or subordinating creativity to process.
It’s about internalizing that every line of code is a liability, every abstraction is a cognitive tax on the team, every architectural decision is a bet on the future that compounds over time. Disciplined engineers understand that their job is not to demonstrate how smart they are—it’s to make the system comprehensible to the next person who has to change it, to write code that their future self won’t curse, to build solutions that work reliably even when they’re not around to maintain them.
The disciplined engineer asks different questions than the senior engineer. Where the senior engineer asks “what’s the most elegant solution to this problem,” the disciplined engineer asks “what’s the simplest solution that won’t break when requirements change in six months.”
Where the senior engineer sees an opportunity to introduce a new pattern or framework that showcases their expertise, the disciplined engineer asks “can we solve this with the tools we already have so we don’t fragment the codebase.” Where the senior engineer optimizes for personal satisfaction and intellectual challenge, the disciplined engineer optimizes for team velocity and long-term maintainability.
I started noticing this difference most clearly in how engineers approached technical debt.
The senior engineers on my team would identify architectural problems and propose ambitious re-writes that would take months and touch dozens of files. The disciplined engineers would identify the same problems and propose incremental refactorings that could be done in a week without blocking feature development.
Both approaches had merit, but in a scaling SaaS company where we needed to ship features while simultaneously improving the foundation, only one approach was sustainable.
The disciplined engineers understood that perfect is the enemy of shipped, that incremental improvement compounds faster than big-bang rewrites, that the goal is progress not perfection.
The Eighteen-Month Tax
That brilliant senior engineer I hired created technical debt that took us eighteen months to pay down. Not because his code didn’t work—it worked beautifully in the narrow scenarios he’d designed for. But it failed in all the edge cases he hadn’t anticipated, it broke whenever we needed to extend it in directions he hadn’t planned, and it created a maintenance burden that slowed our entire team because only he understood the mental model behind his abstractions.
When he left, we discovered that:
- His caching layer was incompatible with the multi-tenant architecture we needed to implement.
- His abstraction framework made it nearly impossible to add the audit logging our healthcare compliance required.
- His clever optimization of the database layer had hard-coded assumptions that prevented us from scaling beyond a single region.
Every architectural decision he’d made was technically correct for the problem as he’d understood it, but catastrophically wrong for the business we were actually building.
The cost wasn’t just the engineering time spent unwinding his work. It was the opportunity cost of eighteen months where we couldn’t ship the features our customers needed, couldn’t improve our gross margins through multi-tenancy, couldn’t expand into new markets because our architecture was built for yesterday’s requirements.
Every quarter we delayed, our competitors gained ground. Every month we spent refactoring instead of building, our revenue growth slowed. The eighteen-month tax that single hire imposed on the business probably cost us millions in enterprise value by the time we finally escaped it.
The Framework That Changed How We Hire
I rebuild our engineering hiring framework around a single insight: discipline can be assessed in an interview, but only if you’re looking for it. Most technical interviews optimize for pattern matching on algorithms and data structures, which tests whether someone can solve puzzles under pressure but tells you nothing about whether they can build maintainable systems under real-world constraints.
We needed to test for something different.
Now when we interview engineers, we give them real problems from our codebase with real constraints that reflect our business context. We tell them we need a feature that handles this customer requirement, but it needs to integrate with these three existing systems, work within this performance budget, be testable without requiring a full environment setup, and be understandable to a mid-level engineer who might need to debug it at 2am.
Then we watch what they do.
The senior engineers—the ones optimizing for cleverness—immediately start architecting sophisticated solutions that ignore half the constraints because they’re “implementation details we can handle later.” They propose new patterns and frameworks that would require the team to learn new concepts. They build solutions that are technically impressive but would take weeks to implement and months to maintain. When we ask them to simplify, they defend the complexity as necessary for “proper engineering.”
The disciplined engineers take a different approach entirely.
They start by asking questions about the constraints we’ve given them, trying to understand not just what we’re asking for but why we need it and what happens if it breaks. They look at the existing codebase and ask what patterns are already established so they can maintain consistency rather than fragment the architecture.
They propose solutions that might be less elegant on paper but are dramatically simpler to implement, test, and maintain. When we push them to add features, they push back and ask which constraints we’re willing to relax rather than building complexity to satisfy everything.
The difference reveals itself most clearly when we ask candidates to explain their solution to someone less technical. The senior engineers struggle because their solutions require understanding abstractions and patterns that take paragraphs to explain.
The disciplined engineers can explain their approach in three sentences because they’ve built solutions that map cleanly to the business problem without unnecessary indirection.
That clarity is the signal we’ve learned to select for.
What Changed When We Hired for Discipline
Over the last years at that company, we’ve rebuilt our engineering team by systematically replacing senior engineers who couldn’t demonstrate discipline with engineers who could, regardless of their years of experience.
Some of our best hires have been developers with five years of experience who understand that simple solutions compound better than clever ones. Some of our worst hires continued to be developers with fifteen years of experience who treated every problem as an opportunity for architectural innovation.
The results have been dramatic in ways that go far beyond code quality:
- Our velocity increased because engineers weren’t constantly debugging abstractions built by their colleagues.
- Our technical debt decreased because every new feature was built with maintainability as a first-order constraint rather than an afterthought.
- Our onboarding time for new engineers dropped from three months to three weeks because the codebase became comprehensible to someone who hadn’t been part of every architectural decision.
- Our production incidents decreased because disciplined engineers build defensive systems that fail gracefully rather than clever systems that fail mysteriously.
But the most significant change was cultural.
When you hire for discipline, you create a team that values sustainable pace over heroic effort, that rewards making the system better over making themselves look smart, that treats code review as collaborative improvement rather than gatekeeping.
The disciplined engineers we hired started holding each other accountable in ways the senior engineers never did, because they understood that every compromise on maintainability was a tax on the entire team’s future velocity.
The Question I Wish I'd Asked Earlier
If I could go back and change one thing about how I hired engineers in my first decade as a CTO, it would be this: I would stop asking “how many years of experience do you have” and start asking “show me a time you chose a simple solution over a clever one and explain why.“
Because that question reveals whether someone understands that engineering is not about demonstrating expertise—it’s about building systems that outlast your understanding of them.
The senior engineers I hired early in my career were optimizing for intellectual satisfaction and résumé building.
The disciplined engineers I hire now are optimizing for team velocity and business outcomes. One group builds impressive systems that become maintenance nightmares. The other group builds boring systems that reliably scale.
In a SaaS business trying to grow profitably, boring wins every time.
Where This Matters Most
This discipline-first hiring framework is most critical if you’re building a B2B SaaS engineering team between product-market fit and scale, typically somewhere between $5 million and $50 million in ARR.
At this stage, technical decisions compound faster than you can correct them, architectural mistakes become existential risks, and the cost of the wrong engineering hire isn’t just their salary—it’s the eighteen months of compounding debt they create before you realize the problem.
If your engineering team is growing but velocity is slowing, if your senior engineers are building solutions nobody else can maintain, if your technical debt is accumulating faster than you’re paying it down, the problem is likely not insufficient seniority.
The problem is insufficient discipline.
And discipline, unlike experience, can be hired for if you’re willing to test for it.