How to Turn Engineers Into Product Thinkers, Not Ticket Closers | David Kavanagh, CTO, Tillo
My Dialog guest this week is David Kavanagh, Chief Technology Officer at Tillo, a global embedded rewards platform transforming how people and businesses connect through digital value.
David was the founding CTO at Purplebricks, where he built the company’s global technology platform and scaled its engineering organisation from zero to more than 400 people. Before and since, he’s led technology transformations across startups and scale-ups, building teams, systems, and cultures designed to thrive through hypergrowth.
With over 25 years of experience, David has become known for combining deep technical understanding with an unusually human approach to leadership, championing context over control, clarity over complexity, and autonomy over hierarchy.
He shares his insights on modern technology leadership, engineering culture, and scaling organisations through his writing and talks, helping others design systems where innovation becomes inevitable.
📝 Takeaways
Remote engineering teams that own complete workstreams stay connected to outcomes instead of becoming isolated. Ownership creates accountability that transcends time zones.
Engineers develop product thinking through exposure to customers and commercial decisions, not training sessions. Teams measured on impact instead of tickets closed shift from feature factories to true product builders.
Technical credibility as a CTO comes from asking sharp questions and making good architectural bets, not writing code. Hands-on coding actually slows teams down at scale.
Hiring for learning ability and intellectual honesty beats hiring for current technical skills. Tech stacks change every two years, but curiosity and resilience compound over careers.
Yassine: Many CTOs worry about knowledge silos and communication overhead when expanding globally. What measures do you take to prevent Tillo’s Cape Town team from becoming isolated?
David: Isolation creeps in quietly if you’re not intentional. For me, it starts with ownership. Cape Town isn’t an “offshore” team—they own streams of work end to end, and their names are on the outcomes.
Then it’s about rituals. Standups that cross time zones, Slack threads that cross teams, and flying people over often enough to remind everyone this isn’t a video game, it’s real people building real things together.
And finally, tools. Weak tooling creates meetings; strong tooling creates momentum. With solid CI/CD, observability, and AI-assisted knowledge sharing, distance stops being a problem and starts being irrelevant.
Yassine: You believe amazing software comes from “treating software practitioners like intelligent people, giving them the tools they need, and getting out of the way.“ What does “getting out of the way” actually look like in practice?
David: It means no ivory-tower roadmaps and no micromanaging. Nothing kills momentum faster than leadership by PowerPoint.
My role is to set direction, not to play backseat driver. Engineers get context, clarity on the outcome we want, and the best tools I can find for them, then I step back.
“Getting out of the way” doesn’t mean absence; it means presence without interference. I still hold people accountable for outcomes and step in when something’s off track, but I don’t second-guess every decision.
If you hire intelligent people and then treat them like robots, don’t be surprised when they stop thinking. Autonomy at the lowest level of competence is what I strive for. As David Silverman said, “An organisation should empower its people, but only after it has done the heavy lifting of creating shared consciousness.”
Yassine: Your hiring philosophy is to “see in them what they could become in ten years and help them achieve it, even if it sometimes conflicts with your short-term interests.“ How do you actually assess long-term potential during interviews?
David: I look for three things. First, intellectual honesty, can they say “I don’t know” without shame, then show me how they’d figure it out?
Second, resilience, how do they behave when things get hard? Do they stay curious, communicate clearly, and keep perspective, or do they hide, blame, or freeze? That tells you more about someone than any success story.
And third, breadth of curiosity—do they tinker, read, and explore beyond their job description, or just wait to be told what to learn next?
Yassine: You’ve said that effective leaders must “make product engineers out of software engineers.“ What’s your definition of a product engineer, and how are they different from a regular software engineer?
David: A software engineer builds what you ask for.
A product engineer wants to know why you’re asking. They connect every line of code to the customer, the business, and the outcome it’s meant to drive.
That shift changes everything. They stop chasing tickets and start chasing impact. They ask sharper questions, cut scope with intent, and care less about how much they ship and more about whether it mattered.
The future of engineering isn’t about writing more code — it’s about writing the right code, in systems that make good decisions inevitable.
Yassine: When you’re leading a team that needs to make this shift, how do you help engineers develop that mindset?
David: You can’t just say “think like a product person” and expect it to stick.
Engineers need to see the customer, the commercial pressure, the trade-offs in real time.
Once they see what happens beyond the code commit, they start asking better questions. That’s the moment they shift from shipping features to solving problems.
I’ve always been naturally attracted to companies like Tillo that are ultra collaborative and transparent about business and commercial wins and challenges in equal terms. This provides the bedrock of a great culture that you can build product engineering on top of.
Yassine: You’ve said that CTOs eventually have to leave code behind. What moment made you realise you had to stop coding, and how did you maintain technical credibility afterward?
David: The penny dropped for me at Purplebricks. I was still jumping into code, convincing myself it was helping, when in truth I was slowing people down.
I realised the highest-value work wasn’t another pull request—it was fixing the system around the code: hiring, strategy, culture, tooling. And that was the hard work, the important work. Once I accepted that, I set a rule for myself: no more shipping features.
Instead, I stay close through design reviews, architecture discussions, and by being honest when we drift off course. Credibility doesn’t come from how many lines of code you’ve written lately. It comes from asking sharp questions, making good bets, and showing you know what good engineering looks like—even if your hands aren’t on the keyboard.
Yassine: You often talk about what’s next for engineering. Where do you see the biggest shift coming?
David: The next decade won’t be about bigger teams or faster sprints—it’ll be about intelligent orchestration between humans and AI. Our work will move from building software to designing systems that build software.
AI tools are incredible accelerators. They remove friction, surface knowledge, and make developers faster. But they won’t replace them. The “vibe coding” movement—tools that spin up apps in minutes—has its place. It’s fantastic for startups, prototypes, or getting from zero to one quickly. But that’s not the same as building the complex, high-stakes systems that power real businesses.
At enterprise scale, the challenge isn’t typing speed, it’s complexity. The codebase, the dependencies, the context spread across teams and years. AI can help navigate that, but it can’t own it.
The engineers who’ll thrive are the ones who can combine AI’s speed with human judgment. AI is the new electricity; it doesn’t replace the craft, it amplifies it. My role as a CTO is to design environments where creativity, data, and automation work together so people can focus on what only humans can do curiosity, empathy, and judgment.
📚 David Kavanagh’s Go-To Resources:
3 people you follow and recommend:
Etienne de Bruin — for building engineering cultures with soul.
Eckhart Tolle — for presence and self-awareness.
Rick Rubin — for creative flow and discipline.
Together, they remind me that leadership is equal parts art, systems design, and consciousness in motion.
A podcast I make time for:
The Blindboy Podcast — thoughtful, irreverent, and human. It’s a reminder that intelligence and vulnerability can coexist.
The Knowledge Project with Shane Parrish — long-form conversations on decision-making, clarity, and performance.
Newsletters I rarely skip:
Both cut through the noise and focus on how technology actually changes behaviour, not just markets.
Books that shaped my thinking:
Managing Oneself by Peter Drucker — grounded me in the discipline of knowing my strengths and focusing where I create impact.
The Power of Now by Eckhart Tolle — taught me the importance of presence, so those strengths aren’t hijacked by ego or distraction.
Creativity, Inc. by Ed Catmull — showed me what it really means to build creative systems that scale without suffocating the humans inside them.
Core philosophy:
Build systems that think, people who feel, and cultures brave enough to do both.
Thank you David for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.