What Does a CTO Actually Do?

I’ve made the Postgres versus MongoDB call more times than I can count. At Firefly Events, we chose MongoDB deliberately for its timeseries data capabilities, native geo-sharding, and the eventual consistency model we’d successfully applied in earlier work at Hertz for localized geo records. A document store gave us the schema flexibility we needed to ship MVPs and PoCs fast, with clear levers like sharding and tunable consistency we could pull later as we scaled. Postgres with TimescaleDB could have handled parts of it, but MongoDB gave us startup flexibility without locking us into premature schema decisions.

I’ve also been in rooms at large companies where directors debated the same question for entirely different reasons: ease of local-first development, sync between distributed systems, replication strategies, or simple team familiarity. The right answer changed every time, but it was never actually a hard call. You gather context , you know the tradeoffs, you decide. Any senior engineer can give you a solid answer for $150 an hour.

“The database question, the framework question, the cloud provider question—these are commodity decisions. What a CTO is actually there for is something entirely different.”

And if your CTO is spending most of their time on that, you hired them wrong, or they haven’t figured out their real job yet.

Let me tell you what the job actually is.

The Translation Layer

The single most important thing a CTO does is translate.

On one side: the business. Revenue, burn rate, roadmap, competitive positioning, investor expectations. Business people speak in outcomes. “We need to launch by Q3.” “We need to cut costs by 20%.” “The competitor just shipped that feature; how long to match it?”

On the other side: the engineering team. Trade-offs, technical debt, dependencies, architecture constraints. Engineers speak in constraints and possibilities. “We can ship that fast, but we’ll accrue significant debt.” “The current architecture doesn’t support that without a rewrite.” “If we rush this, we’re going to be fixing it for the next two years.”

These two groups can sit in the same room and completely fail to understand each other. I’ve watched it happen at EY, through client engagements, and at early-stage startups. Smart, well-intentioned people on both sides, genuinely trying, and nobody’s getting through.

The CTO’s job is to bridge that gap, in both directions.

Translating from engineering to business means turning “we have significant technical debt in the payments module” into “we have a time bomb that will cost us a full sprint to defuse, and here’s why now is cheaper than later.” It means explaining that taking three months isn’t a sign of incompetence; it’s the reality of maintaining a production system that thousands of customers depend on.

Translating from business to engineering means protecting the team from the chaos and urgency that naturally flows from a growth-stage company. When the CEO decides at noon on Friday that we need a new feature by Monday, that’s a leadership moment. You either take the heat for saying no, or you watch your engineers burn out chasing an impossible deadline. One of those choices is the CTO’s job. The other is abdication.

Good translation protects engineers from the business. It also protects the business from jargon, over-engineering, and engineers who build beautiful systems that solve the wrong problems.

The Strategic Layer: Decisions, Data, and Dollars

A CTO makes a lot of decisions. But treating them all as equal is a fast way to waste everyone’s time. The real work is in three key areas: strategic choices, data integrity, and cost architecture.

Build vs. Buy vs. Hire

This is a constant calculation. Do we build this feature ourselves, buy a third-party tool, or bring on someone who’s already solved this problem?

At Hertz, delivering a 6,000% throughput improvement—scaling from roughly 100 to 6,000 requests per second—was a clear “build-it-ourselves” situation. I recognized the event-driven architecture pattern from earlier work and adapted it to their specific context. You don’t outsource that kind of foundational systems work; the expertise and control are paramount.

At Frontiers Market, needing image-recognition capabilities at the edge for RTSP streams on Raspberry Pi clusters running offline, we evaluated commercial tools and found they all failed our edge workload and cost constraints. We built it ourselves. Different context, same conclusion, but you have to actually do the evaluation to know.

Negotiations and Cost Architecture

Every line item is a negotiation: cloud contracts, data providers, dev tooling. I’ve seen engineering leaders sign agreements with pricing structures that become existential threats eighteen months later. Understanding the cost architecture of what you’re building is not a finance function. It’s yours.

Cloud infrastructure costs are not an afterthought. I’ve seen startups get surprise bills that could fund two engineer salaries. More efficient systems cost less to run—the Hertz throughput work wasn’t just a technical win, it was a cost optimization story. That matters.

When you can articulate to your board exactly why the infrastructure budget went up 30% and tie it directly to growth, you’re a business leader. When you can’t, you’ve ceded control of a major cost center.

The hiring vs. outsourcing vs. tooling decision is one I make repeatedly. Do we hire a data engineer, buy a data platform, or invest in training the team we have? Do we bring on contractors for a defined sprint, or build the capability in-house? There’s no universal answer. But the CTO needs to be the one doing that math, not the CEO, not the CFO, not the VP of Product.

Becoming the Analytics Reality Check

This one stings a lot of startups: most “data-driven decisions” are not actually data-driven. They’re gut-driven with a thin veneer of analytics.

Here’s the pattern I’ve seen repeatedly: conversion rate drops 8% over a weekend. A nervous stakeholder wants to ship a dozen UX changes Monday morning to “fix it.” But if you had 300 visitors that weekend, you have no statistical signal. None. You’re looking at noise. A/B testing requires meaningful volume to reach statistical significance. Chasing a 10-user blip on a Saturday afternoon is how you introduce bugs to solve a problem that never existed.

The CTO’s job is to build a culture that distinguishes between vanity metrics and real metrics. Vanity metrics feel good: total signups, page views, monthly active users at a surface level. Real metrics tell you if the business is actually working: activation rate, retention cohorts, revenue per user, feature adoption among paying customers.

Even with real metrics, you have to ask the harder questions. If retention drops with 100 users, the question isn’t which feature to change; it’s whether you ever found product-market fit. At that scale, you genuinely don’t have the data to judge features. Your metrics spiking after a podcast mention only proves people will try your product, not that it delivers lasting value.

I spend a lot of time saying, “The data doesn’t support this yet.” It’s an unpopular sentence, but it’s part of the job.

The Ultimate Constraint: Executive Override

I’ll be honest about something: not every recommendation survives contact with the person writing the checks. At a startup, the CEO has the final say, and they always do.

At Frontiers Market, this was a constant optimization. Small team, ambitious product scope, finite capital. Every architecture decision had a cost dimension. We built for efficiency not because it was elegant, because it had to work on limited hardware with limited budget. When those constraints were respected, they produced good engineering decisions.

But I’ll be honest about something: not every recommendation survives contact with the person writing the checks. At a startup, the CEO has the final say, and they always do. The tension between sound technical judgment and executive override is real and constant. You make the case, you document the tradeoffs, and sometimes the decision goes the other way anyway. At Frontiers Market, our architecture decisions were driven by efficiency because they had to be. Whether that thinking was applied consistently is a different story. That friction is part of the job too.

The efficiency curve matters too. There’s always a point where adding more engineers produces diminishing returns, sometimes negativereturns as coordination overhead grows. A team of four shipping consistently beats a team of twelve arguing about architecture. Knowing when you’re on the wrong side of that curve, and being willing to say so, is a leadership skill.

The People Layer

This is the one that matters most, and the one most technical leaders underinvest in.

Hiring Is Everything

Team composition is the single biggest variable in your success. More than architecture, more than stack, more than process. Get the people right and everything else is solvable. Get them wrong, and no amount of technical excellence can save you.

After hiring across Ascendant Technology, Avnet, Zilker Technology, EY engagements, Frontiers Market, and Firefly Events, what I’ve learned is that hiring the most technically impressive candidate in the room isn’t always right. I look for a specific combination: strong enough technical skills to get the work done, genuine problem-solving ability (not just pattern-matching), self-direction, and the ability to make the team better.

I’ve hired engineers who could whiteboard any algorithm you threw at them but were a nightmare to work with—hoarding knowledge and being dismissive in code reviews. They build resentment.

I’ve also hired engineers who weren’t the top technical candidate but could reason clearly, take ownership, and elevate everyone around them. The second type buildsThey build companies. The first type builds resentment.

Your first 10-15 hires define your culture for the next five years. That’s not an exaggeration. The norms that get established early—how you do code review, how you handle disagreements, how you respond when things break—these calcify. Hire careless people early and you’ll be fighting carelessness for years. Hire people who take ownership, and ownership becomes the default expectation.

For more on what I actually look for in engineering interviews: [/blog/how-to-hire-engineers](/blog/how-to-hire-engineers).

Talent Has a Price

If people are working under market rate for your vision, that investment must be recognized and honored. Not with vague promises about the future, but in how you treat them day-to-day, how honest you are about where things stand, and whether the upside you’re selling is real.

The cost of getting this wrong is high and compounding. Losing an engineer is expensive in recruiting costs, onboarding time, and lost institutional knowledge. More importantly, it sends a negative signal to everyone who stays. Hiring into a team with a bad culture reputation is extremely difficult. The best engineers have options, and they ask around.

If you’re asking someone to take below-market compensation for equity and mission, you owe them honesty about where things stand. You owe them respect for what they’re giving up. You owe them a real shot at the upside you’re describing. The alternative is a revolving door that costs more in the long run—in money, in culture, in what you’re able to build—than paying closer to market would have in the first place.

This isn’t just ethics. It’s math.

Protect People from Burnout

This part of the CTO job doesn’t get said plainly enough: your job is to protect the team.

Engineers break after too many weekends, too many all-nighters, too many sprints where “one more push” becomes the new normal. I’ve seen well-meaning founders say “funding is coming next month, just one more push” for twelve months straight. By the time the money arrives, half the team is gone or checked out.

That’s a CTO failure. The CTO is the person who’s supposed to read that pattern and say stop before the damage is permanent.

The mechanics are simple: real downtime between intense sprints, honoring commitments about scope and timeline, and noticing when someone is running on empty before they quit or implode. If you have offshore team members covering time zones, remember that’s people spending their nights working. It’s easy to forget that when you’re not seeing them every day.

One thing that’s also genuinely unfair and worth naming: equity at early-stage startups is often structured in ways that leave employees holding nothing. No pre-seed strike price locked in, or terms that shift after the fact. And if you’re asking people to grind for years on a promise of equity, make sure that equity is real. Engineers talk. And how you treat the people who built the thing matters, both morally and for your future ability to hire.

I’m writing a longer treatment of this topic in [Startup Culture and the Human Element](/blog/startup-culture-and-the-human-element)[.](/blog/startup-culture-and-the-human-element)

Set Direction, Don’t Micromanage

Engineers need to see the thread between their work today and the long-term vision. But “Build the most reliable real-time marketplace in agriculture” isn’t actionable at 9am on a Tuesday morning. You have to decompose that into milestones, quarter by quarter, sprint by sprint.

Empowering creativity within guardrails is the balance every engineering leader struggles with. Too much guardrail and you stifle the innovation that good engineers are capable of. Too little and you get beautiful chaos—systems that don’t interoperate, tech choices made for personal interest rather than business need, scope that drifts indefinitely.

My approach is to provide guardrails: here’s the business outcome we need, here’s the quality bar, here’s the timeline. How you get there is mostly up to you. Push back if you see a better path. Own your decisions.

The best thing you can do as a CTO is build a team that doesn’t need you for the day-to-day. Your goal isn’t to be the smartest person in the room. It’s to hire people who eventually make you the least technical person in the room—and be completely fine with that.

Startup CTO vs. Large Company CTO

These are different jobs. Significantly different, and conflating them leads to misery.

At a startup, you’re doing everything: translating, hiring, architecture, vendor negotiation, budget, and maybe still writing code. You have limited process, high ambiguity, and decisions have outsized consequences. The role is about building structure from ambiguity.

At a large company, the structure already exists, and that’s both a feature and a constraint. Decisions are often political—which team gets the budget, which vendor relationship the company protects, which legacy system doesn’t get touched because it’s owned by someone with organizational power. Some are vendor-locked in ways that have nothing to do with technical merit. And some are genuinely good business decisions that just feel slow from the outside.

A CTO expecting startup latitude in a large enterprise will fail, not because of technical issues, but because nobody wrote down what “success” looked like.

Not every large company or industry actually needs a full-time CTO. Some need a VP of Engineering or a strong principal architect. The CTO title gets applied broadly in ways that don’t always reflect what the role actually requires.

The fractional model often makes more sense than either extreme, providing senior judgment without the full-time overhead.

I’ve written more about this in [Why Your Startup Doesn’t Need a Full-Time CTO](/blog/why-your-startup-doesnt-need-a-full-time-cto)[.](/blog/why-your-startup-doesnt-need-a-full-time-cto)

Three Traps Every CTO Falls Into

I’ve made most of these mistakes myself at some point. Recognizing them is the first step to avoiding them.

Staying too technical, too long. The hardest transition for most CTOs is giving up the work you’re good at. Coding is concrete and satisfying. Leadership is diffuse, slow-feedback, and often thankless. The temptation to stay in the code is real. But every hour you spend coding is an hour you’re not doing the things only you can do: translating, deciding, building the team, managing up.

“If you’re coding 30 hours a week as a CTO, you’re probably leaving critical leadership work undone.”

Measuring the wrong things. Teams optimize for what you measure. Measure lines of code, get bloated code. Measure story points, get inflated estimates. Instead, measure customer outcomes, system reliability, time to ship, and cost to operate. Connect engineering activity to business results. This takes real work to set up correctly, but it’s the difference between an engineering org that knows if it’s succeeding and one that’s just busy.

Underinvesting in communication. Technical people often believe the work speaks for itself. It doesn’t. If you don’t tell the story of your team’s wins to the CEO, board, and investors, they won’t know. You made an architecture decision that will protect you from a class of security vulnerabilities for the next three years? Your engineering team knows. Nobody else does. The CTO has to communicate constantly—to the team, to leadership, to investors, to recruits. Communication is not soft skills garnish on top of the technical work. It’s the leverage that makes the technical work matter.

What the Job Actually Looks Like

Most of my days as a fractional CTO look nothing like building systems. They look like this:

• A call with a founder, explaining why their two-week feature is really a six-week project, and what we can realistically ship in two weeks that gets them 80% of the value.
• A budget review, walking a COO through cloud costs line by line.
• A recruiting call, selling a senior engineer on meaningful equity, real ownership, and the chance to build something from scratch because we can’t match a FAANG salary.
• A technical review of a vendor’s architecture before we sign an 18-month contract.
• An architecture review that takes two hours but prevents six months of work in the wrong direction.
• A hard conversation with a founder about whether it’s time to let someone go, and walking through what that actually costs in terms of team morale, replacement time, and the implicit signal it sends about standards.
• A conversation with an engineer who is technically brilliant but creating team friction.
• And yes, sometimes, picking a database in thirty seconds because I’ve already run through the decision framework in my head before the question is even fully asked.

That’s the job. It’s not glamorous. It doesn’t always feel like engineering. But it’s the thing that determines whether a company actually ships the product it means to ship, and whether the team that builds it is still functional in two years.

At Chick-fil-A, through an EY engagement, we rebuilt core POS systems that had to work offline-first in stores that can’t afford downtime during a lunch rush. That wasn’t just a technical problem; it was an operational, people, communication, and vendor coordination problem requiring deep technical judgment to solve. The DevOps layer—how systems get deployed, monitored, and recovered—was load-bearing.

More on this in [Stop Wasting Time on DevOps Complexity](/blog/stop-wasting-time-on-devops-complexity)[.](/blog/stop-wasting-time-on-devops-complexity)

That is what good CTO execution looks like. It’s not athe genius who writes the best code; it’s athe leader who holds the entire system—of people and technology—together.

So if you’re building something and wondering whether you need a CTO, the question isn’t “Do we need someone who knows technology?” The real question is: “Do we have someone who can hold the line between the business and the engineersengineering, protect the people doing the work, and make the hard decisions that neither side can make alone?”

If the answer is no, you need one.

Let’s Talk

If any of this resonates—if you’re a founder trying to figure out when to bring in technical leadership, a startup hitting a scaling wall, or an enterprise looking for an outside perspective—I can help.

I work with companies as a fractional CTO. You can see how I engage on my services page, or browse [case studies from Hertz, Wayfair, Frontiers Market, and others](/portfolio).

If you want to talk through your specific situation, book a call directly: cal.com/mdostal/meet. No pitch, no pressure: just a real conversation about what you’re building and whether I can help.