Lies CTOs Tell (Themselves and Others)

7 min read3 days ago

Every CTO wants to believe they are steering their company in the right direction. However, in the pursuit of success, many fall into self-deception, repeating comfortable lies that sound logical but ultimately undermine their leadership and their teams. These lies come in different flavors—some are internal justifications, others are strategic misalignments. The problem? They feel true, and that’s what makes them so dangerous. Which of these are you using?

Special free livestream: Discover fresh, proven ways to transform every manager on your team into a high-impact leader. In this fast-paced 45-minute livestream, you’ll learn to treat management as a true profession, find the core skill sets that matter most, and foster a culture where managers coach, mentor, and sharpen each other in real-time. Details + free impact coaching framework ebook here.

“Understanding the business isn’t my job”

🚨 Reality check: If you’re pigeonholing yourself solely to tech matters, you’re not an executive/senior leader, but a highly-paid team lead.

It doesn’t matter whether you think you’re good at the “business stuff” or not, or if your peers want you to be more business-oriented. When you choose to limit yourself, you’re essentially limiting the tech organization’s ability to be maximally effective. To ensure alignment and efficacy, there has to always be an ongoing discussion, business-centric, that maintains the focus on delivering value, not tech for tech’s sake.

Fix it: Force yourself into business conversations. Move upstream so you’re able to participate in the right discussions and speak business, rather than overwhelm your peers with tech-jargon.

“Our team is a family”

🚨 Reality check: Families don’t fire people.

The simple truth is that your team is not a family. You might be close, which is good, but when we embrace the feel-good approach we quickly lose our effectiveness as leaders. That’s because you will place yourself in cognitive dissonance: how can you be a family if you need to tell someone they’re underperforming?

The family-thinking blurs the boundaries in an unhealthy way that leads companies to leave people who are clearly bad fits, contort organizations to retain someone that has outgrown the company or be completely blind-sided when key employees decide to leave (which is a natural thing, and shouldn’t be a surprise).

Fix it: Build a high-performing, rapidly-growing team. Professional work environments don’t have to be cold, but when we remember this is work and not our entire lives, we create healthier relationships all around.

“We’re innovative”

🚨 Reality check: Running one hackathon a year doesn’t make you innovative.

Most hackathons are just innovation theater, where we snap some nice pictures but don’t create anything of sustainable value. Real innovation requires risk-taking and should be consistent. Hackathons essentially cage your team’s creativity to 36 hours a year, teaching them to be Jira-monkeys the majority of the time.

To be genuinely innovative, you have to discuss what is a good bet, learn how to address experiments that fail (because there’s no real innovation without some failure), and make the space for that innovation. In addition, your team needs to be in close contact with the product to be able to come up with experiments that would move the needle, and not just look cool on LinkedIn.

Fix it: Implement intermissions/innovation weeks, and help your team gain product mastery and regularly experiment with ideas they or others in the company have. See the free sample chapter of TEOS for more on this.

“Delivering 100% of commitments means success”

🚨 Reality check: Teams that consistently achieve everything they committed to are playing it too safe, and still aren’t successful.

It’s too easy to be in a situation where you are so obsessed about delivering everything that you’ve got on your plate, missing the forest for the trees. How many times did you realize after a few sprints that you shipped all the work, but the needle hasn’t budged? Plowing forward with our blinders on, just focusing on the next thing on our todo list, often means we become feature factories and don’t focus on impact.

In addition, if your main KPI for your org’s health is whether you reach 100% sprint completion, you will end up creating an organization that never takes any risks, and that plans work too cautiously. To reach 100% certainty, we have to be too conservative in our estimates, which Parkinson’s law teaches us will always be used up completely. Thus, you’re creating a negative feedback loop that will always get your organization to work slower as time progresses.

Fix it: Shift your success metrics from rote delivery to business impact. Have regular impact retrospectives and ensure people do things that they can see are important and that they understand, as opposed to solely taking orders and rushing for the keyboard.

“If only the roadmap stopped changing, we’d succeed”

🚨 Reality check: Your responsibility is not to complain about changes in startups, but create a team that’s resilient enough to enable it.

Rigidity and total clarity are possible, just not in a startup or quickly moving tech company. Sticking to plans and not changing them is more likely to lead you astray, only to realize too late that the market has shifted while you kept heading in the wrong direction. Your approach should be to enable this agility rather than trying to bolt everything down.

Like in some martial arts (or at least that’s what I learned from the cinema), we have to learn to move with the shifts and use the force of the changes, instead of trying to stop them in their tracks. To achieve that and to make your team resilient to change, you can create processes that make changes less problematic and expected.

Fix it: Teach your team to anticipate changes. Break work into the smallest bits possible, to allow for natural breaking points instead of having every change come at the cost of losing days of work. Prefer non-prescriptive goals (e.g., “ship feature Y”) but business objectives that the team then works toward (e.g., “increase freemium to paid conversion within 30 days”). Those allow the team to change its tactics without feeling like everything done so far is being thrown away.

“We cannot do better because we’re told about things too late”

🚨 Reality check: If you’re just sitting there waiting for formal notifications about everything, you’re not leading—you’re reacting.

Going hand in hand with the team to embrace the business aspects of your role, you have to inject yourself into the right discussions so you can always tell what’s coming down the line. If you wait for when things have matured enough to be formalized into plans, you’ll inevitably learn about things too late.

Further, focusing on being told what to do “on time” instead of realizing your responsibility is to be there as part of the shaping of the work to ensure it maximizes your team’s potential, is a big part of why many teams are just in-house software agencies and not an integral part of the company.

Fix it: Make it your business to know what business is planning. Do not shrug it off when you’re told about something “too late.”

“My role is to keep the team happy”

🚨 Reality check: Your job is to create an effective team, not a comfortable one.

If they want unconditional love, they should get a dog. Again, you’re not a family, and you are all there because the company has a need. When we’re afraid of making anyone feel uncomfortable, we’re really saying they should all remain forever ensconced within their comfort zones.

There will never be any meaningful growth in such an environment. That’s why so many CEOs lament their tech executives caring about their team more than the business—without which there will be no team. You can focus solely on your teams and then write very touching LinkedIn posts when layoffs inevitably happen, or you can grow up and do things correctly before it gets to that point.

Fix it: You cannot make people happy, nor is it your job to motivate anyone. You should find people who are aligned with the company’s goals, intrinsically motivated about improvement, and the challenges the team is facing. Then, help those become better, with proper coaching.

“It’s up to us to tell stakeholders when something’s impossible”

🚨 Reality check: No one needs you to say “no”—they need the person that can unlock “ here’s how.”

Effectively, nothing is impossible, it might be too expensive or impractical. But when that’s the case, we’re looking at a continuum, and your job is to suggest points on that continuum that are feasible and valuable for the business. Poking holes in every idea might feel clever, but I don’t need an engineering organization for that.

Don’t be a CT-No. Learn to negotiate with your peers and find the right solution—like Goldilocks. Skillfully finding the middle path that’s just right is a priceless ability.

Fix it: Replace binary yes/no thinking with realizing that we’re living in an analog world. Treat constraints, trade-offs, and risks as different switches that you can play with to find a novel approach to make things work.

“Teams with excellent tech succeed”

🚨 Reality check: Plenty of companies with subpar tech dominate their markets, and the annals of tech are filled with startups that had amazing technology, spotless code, and no tech debt—but also no clients.

Execution matters more than tech purity. Great tech doesn’t guarantee a great business, and being overly focused on the tech part of the work means the team is not properly aligned and gains its motivation doing things that don’t necessarily move the needle. Of course that tech matters, but it is a tool.

In a world where coding is getting more and more commoditized, those who are oriented by the business impact of what they do, even if it means not using the shiniest tech or having to live with some tech debt, are those who will come out on top.

Fix it: No tech debt or similar work should be prioritized if you cannot make the case for why it will actually help the company. Mindlessly spending hours updating old code to use the latest conventions is useless busywork.