First-time CTO pitfalls, implementing TDD, breaking through resistance | Denis ?ahuk, Leadership Coach & Technical Trainer

Denis ?ahuk is an Engineering Leadership Coach who helps technical leaders shape high-performing teams and establish sustainable delivery practices.

Drawing from his experience across gaming, e-commerce, and technical consulting, Denis shares practical insights through his newsletter "Crafting Tech Teams," helping engineering leaders move their teams from firefighting to sustainable delivery, while maintaining technical quality and team wellbeing.

Highlights

• Building technical leadership from hands-on knowledge
• Avoiding early leadership style traps in startup environments
• Making TDD adoption feel natural by aligning team priorities
• Growing quality culture beyond metrics and enforcement

Yassine: What inspired you to start writing Crafting Tech Teams?

Denis: I've definitely wanted to have an outlet where I can connect with my role models, people like Kent Beck, Allen Holub, Kevlin Henney, Uncle Bob, The Poppendiecks, Sander Hoogendoorn, and others I've met along the way.

While I’ve had many ideas, blogging didn't really appeal to me at the start, but I decided to start Crafting Tech Teams because I wanted to share my process and thinking transparently, with the goal of helping the next generation of engineers, while also connecting with and learning from other thought leaders in the industry.

Y: What common pitfalls do you see first-time CTOs encounter when trying to establish their leadership style?

Denis: One of the biggest challenges for first-time CTOs, especially in startups, is that the role demands a high level of self-awareness. You need to understand who you are in order to choose a leadership style that truly fits. A common issue arises when CTOs lack that self-awareness, they will pick a leadership style early on and stick with it for too long, especially if it doesn't fit them.

This can lead to imbalances, like becoming too strategic or too tactical. They might be neglecting the appetites and interests of the board, other C-level executives, or key stakeholders. On the other hand, they might stay too hands-on with coding, which pulls them away from leadership responsibilities.

This creates risks because the CTO role is an all-encompassing position with no direct peer. Every major technical issue in the company eventually lands on their plate, and there’s no higher authority to escalate them to. As a result, they must learn to delegate, handle problems directly, or simply say no to certain things.

Y: What's your take on first-time CTOs staying technically involved? Have you observed any particular challenges (or benefits) with staying hands-on?

Denis: Yes, there’s a real benefit to staying technically involved, especially when promoting your first leaders, whether it’s tech leads, engineering managers, VPs, or heads of development. No matter what titles make sense for your organization, it’s important to understand the responsibilities of these roles firsthand.

If you’ve never done the work yourself, you risk setting expectations that are difficult to meet because you have no idea and no predisposition to what success looks like. It's easy to get promoted and then say “I got promoted five years ago, I didn't code in a while, now I can no longer onboard or hire an EM because I have no idea what EMs do nowadays.”

Your first hire in any of these roles should be someone you can guide to a high standard of success. That's very important. That means leading by example through pairing, test-driven development, or other engineering practices. You should be able to demonstrate what high-quality collaboration looks like, set up the right environment for success, and distinguish experts from just regurgitating agile coaches.

It's very important to just have a gut feel for, “Hey, what's going on in my company? What's going on in my industry?” It allows you to engage with teams empathetically without micromanaging. The key is having the courage to experience the pain points firsthand, whether in board meetings, pairing sessions, or sales calls. This allows you to create transparency, optimize learning, and ultimately reduce the need for constant intervention.

Y: You advise leaders on implementing TDD (Test-Driven Development). How can leaders overcome potential resistance and get their teams on board with TDD practices?

Denis: You normally get resistance [to TDD] when you don't show awareness for understanding what the priorities of the developers are. That's usually a lack of transparency, or a lack of shared incentives, or just everybody having different goals, different incentives, and different interests.

You can do TDD without resistance when everybody agrees on what the number one problem is, everybody agrees on where the company is headed, and everybody is sharing the victory, sharing the sense of success. If the situation is, “Our biggest bottleneck is the absence of TDD, and we’re struggling because we don’t know how to implement it,” then introducing TDD becomes natural, either through internal training or by bringing in an expert. But that scenario is rare.

For most companies, the TDD practices are there, and they want to have that capability of refactoring quickly and fearlessly because every time your virgin code touches another human for the first time, there's a very high possibility that you will want to refactor what was just created.

That’s why practices like continuous integration (CI), continuous delivery (CD), and continuous deployment (also CD) are important. They represent different stages of new code encountering a human for the first time:

• Continuous integration: The first time new code interacts with another engineer.
• Continuous delivery: The first time new code is reviewed by a business stakeholder.
• Continuous deployment: The first time new code is exposed to real users.

All these three scenarios create spike points where you would want to very earnestly refactor without having to call a meeting. And if you are doing those things, then TDD is very helpful.

However, in organizations trapped in feature silos or operating as feature factories, where code is rarely shared, reviews are inconsistent, integration is infrequent, and deployments are rare, TDD naturally struggles to take hold. If a team has no intention of iterating or improving their code, they won’t see the value in writing tests in the first place.

Y: As teams grow larger, maintaining consistent TDD practices becomes challenging. How do you preserve test-driven culture while scaling, and what qualities should leaders look for during the hiring process?

Denis: As a team grows larger and develops a strong sense of identity, it naturally reinforces its existing culture. A team that has successfully adopted TDD will continue building on that foundation by establishing sensible defaults.

A sensible default might be:

• Writing components in a specific way.
• Avoiding certain types of mocks due to X, Y, and Z, except in cases like database access, where it aligns with our design principles and insurance policies.

Sensible defaults scale well. Every now and then, you can check in with staff engineers and tech leads: "Are our sensible defaults still working?" If not, they might have evolved into something better, and that’s fine. Just don’t frame them as best practices.

Metrics like test coverage are often process-reinforcing but that comes with risks. If a team naturally doesn’t practice TDD when no one is watching, then enforcing TDD through metrics can create resistance:

• We don’t do TDD.
• We only follow it because of the metrics.
• TDD is nonsense, and we’re just gaming the numbers.

The harder you push these metrics, the more you reinforce the identity of not being a TDD team.

The real challenge is shifting that identity. A team might start from a mindset where quality means human inspection, where a person reviews code to ensure it meets a standard. Shifting that to self-testing code requires a fundamental change:

• Understanding that humans make mistakes.
• Writing tests that are reliable and maintainable.
• Ensuring tests enable refactoring rather than blocking it.
• Following TDD not because of oversight, but because it’s how the team defines quality.

This mindset means that even if nobody is watching and even without a code review, the team will still write and ship high-quality, well-tested code. It becomes the default.

When hiring, look for candidates who have demonstrated this maturity. Have they consistently, but not rigidly, embraced an identity of quality? Have they upheld high standards even when no one was measuring them?

Ultimately, it’s about creating a culture where the right thing happens naturally, not through coercion, metrics, or external motivation, but because the team truly believes in it. This leads to better outcomes, shared success, and a stronger company without the need for constant enforcement through rewards or punishments.

Thank you Denis 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.

P.S. If you prefer your content on Substack, I'm also there.

Yassine.