For six years, Rainui and I ran every project together. He led design, I led strategy and architecture, and our development team built what we specified. It worked when projects lasted six weeks. It stopped working when projects lasted six months. We needed someone whose full-time job was technical excellence. So we brought John Li on as our engineering lead.
What You Need to Know
- As project complexity grows, technical architecture needs its own champion, not a part-time responsibility of the managing director
- Small teams scale by adding leadership capacity in the areas where complexity is highest
- The engineering lead role isn't about writing more code. It's about making better technical decisions, faster
- Hiring leadership early costs more in the short term and saves far more in delivery quality
The Bottleneck
I was the bottleneck, and it took me too long to admit it.
My role at IDESIGN has always been broad: client relationships, project scoping, commercial decisions, technical architecture, delivery oversight. When projects were smaller, that range was manageable. A six-week website build doesn't need a dedicated architect. A six-month enterprise platform does.
The projects we're taking on now have real architectural decisions. Multiple data sources, complex business logic, integration points with third-party systems, user roles and permissions models, caching strategies, deployment pipelines. Each decision shapes the project's maintainability for years.
I was making those decisions in the gaps between client calls and scope negotiations. Not because they weren't important, but because there were only so many hours. The decisions were good enough. But "good enough" architecture accumulates problems that surface twelve months later when the client needs to extend the system.
What John Brings
John is the kind of engineer who thinks about the problem before writing the solution. He's methodical, thorough, and has a depth of technical knowledge that I don't. My strength is understanding the business problem and mapping it to a technical approach. John's strength is making sure that approach is implemented in a way that will still make sense to the next developer who reads the code.
His role as engineering lead is three things:
Technical decision-making. Framework choices, architecture patterns, database design, infrastructure decisions. These are now John's primary responsibility. I'm still in the conversation, but the recommendation comes from someone whose full attention is on the technical landscape.
Code quality and standards. Every team develops habits, good and bad. Without someone explicitly watching code quality, those habits drift. John reviews architecture, establishes patterns, and makes sure the team is building consistently. When a developer has a question about the right approach, they ask John, not me.
Developer mentorship. Our team is growing, and newer developers need guidance that goes beyond "here's the task." They need someone who can explain why one approach is better than another, review their work with depth, and help them grow. I can do this for business logic and client context. John does it for engineering craft.
The best thing I did for project quality this year wasn't a process change or a new tool. It was admitting that technical architecture needs someone whose only job is getting it right.
Isaac Rolfe
Managing Director
How Small Teams Scale
There's a pattern in small companies that I've watched play out in our own team and in our clients' organisations. A founder does everything. The company grows. The founder keeps doing everything, just faster and with less sleep. Eventually something breaks: quality, relationships, health, or all three.
The fix isn't hiring more of the same. It's hiring someone who takes a specific responsibility and owns it completely. Not delegates, owns. The difference is that the founder stops being the decision-maker in that domain. They stay informed, they stay involved, but they're not the bottleneck.
For us, the sequence was:
- Isaac and Rainui do everything (2011-2014)
- Hire developers and designers to do the execution (2014-2016)
- Hire an engineering lead to own technical direction (2017)
Each step changed what Isaac and Rainui could focus on. More developers meant less time coding. An engineering lead means less time on technical architecture and more time on client relationships, scoping, and the commercial side that keeps the team employed.
The Cost Question
An engineering lead costs more than a senior developer. For a small company, it's a noticeable increase in payroll. Is it worth it?
We think about it this way. One bad architectural decision on an enterprise project can cost weeks of rework. A database design that doesn't scale costs months when it needs to be restructured. A codebase without consistent patterns becomes progressively harder to extend, meaning every feature takes longer than the last.
John prevents those problems. Not always visibly, and not in a way that shows up on a project timeline. The absence of problems is hard to invoice for. But the projects are running more smoothly, the code is more consistent, and the team is growing faster because they have someone dedicated to helping them improve.
The cost question answers itself after two projects.
What Changed
Three months in, the differences are visible.
Architecture reviews before coding starts. Every project now has a technical design phase where John maps the architecture, identifies risks, and documents decisions. This used to happen in my head during the scoping phase and never made it into a document.
Consistent patterns across projects. The team builds in a recognisable way now. A developer moving from one project to another can read the code and understand the structure. This wasn't true six months ago.
Better estimation. John's technical input into scoping has made our estimates more accurate. He catches complexity that I miss because he's thinking about implementation details that I'm thinking about at a higher level.
My time back. I'm spending more time with clients and on business development. The technical conversations in those meetings are sharper because I'm drawing on John's analysis rather than my own stretched attention.
The Lesson for Other Small Teams
If you're running a small team and you're the person making every technical decision: that doesn't scale. It works until it doesn't, and the breaking point comes faster than you expect.
You don't need to hire a CTO or build a management layer. You need someone who owns the technical direction with the same focus you bring to the business direction. One person, the right person, changes what the whole team can deliver.
We should have done it a year earlier.