Two years ago, I took over the leadership of a growing cybersecurity startup. I had spent most of my career in startups, mostly on the tech side, as contributor and in tech management. Later on, I had few experience co-founding, failing and exiting startups. But this was the first time I stepped into the CEO role of a company already running at full speed.
Moving from CTO to CEO doesn’t change what you know, it changes the weight of what you carry.
At startup scale, any C-level sees the same picture: the same information, the same constraints, the same growth target. The difference is weight.
As CTO, my impact was company-wide but my leverage and burden were anchored in the “T.” I owned the tech: teams, delivery, roadmap. Everything else touched my work, but it wasn’t mine to carry.
As CEO, everything connects back to me. But my true responsibility is not to do everything. It’s to provide the full picture: clear enough to see, strong enough to believe, shared enough to commit, and resilient enough to fail within.
In a lean, flat and small organization there is no buffer. You are exposed to every micro and macro operation. The context-switching is relentless. What saved me was my past in delivery management in startups: the ability to prioritize instantly, balance urgent versus important, and keep moving.
Managing director: the difference with a founder, the similarities with middle management
It’s not my company. I have a board to answer to, the actual owners. In that sense, it isn’t so different from middle management, where as a VP of Engineering I reported to the C-suite.
The big difference is this: the board validates (or not) my strategy, but they don’t hand me theirs. Strategy is the core of my job. They collaborate, bring insight, and challenge my thinking, but in the end they endorse my call.
In that way, it’s close to “managing up” as a VP or director. You build a plan with your teams, you present it, you advocate for it. The difference is that at this level you don’t work under top-down targets. You define the targets yourself. And you own the outcome.
So the job feels strangely familiar, yet heavier: you still need to commit both ways, convincing the board above and the teams below. Top-down and bottom-up at the same time.
Like any role in my career, the relationship with your “bosses,” direct or indirect, matters a lot. It comes down to trust and cultural alignment. When I choose a job, I always look closely at the person above me and the culture they bring. That’s what provides the safe space to do my best work.
The obsession with the why
Why does this company exist? Why does this product sell? Why do customers stay? Why do these problems repeat? Asking why has always been my most reliable tool: in code, in management, in strategy.
I had co-founded companies before, mostly on the tech side. As a co-founder I picked up some basics in legal, contracts, HR. Those hard skills eased the workload, but they never made the difference. What makes a startup succeed is always the same: the value you bring to a market.
In my previous startups, that market understanding came from my business co-founders. Here, it was different. I had to ask a new set of questions: why does this market exist? Why does it buy at this price? Why now?
My first responsibility was to trace the chain of events that brought the company here, in order to shape the strategic question that matters most: why will this company still be relevant five years from now?
Not every why is worth chasing. Sometimes the answer changes everything. Sometimes there is no answer, and I am still learning to accept that.
Stepping outside the comfort zone and into the customer’s shoes
I did not know much about cybersecurity before. But throughout my career I have loved jumping into new domains: retail, e-commerce, social, payment, education, music, AI. That is one of the privileges of software engineering. You can keep coding in your familiar stack while solving entirely new problems and delivering completely different solutions.
The sales motion also felt familiar. Most of our growth came inbound, through digital channels I already understood as a builder: SEO, social, community. The team was mostly software engineers, echoing my past responsibilities. And the company was still in its earliest years, a stage I know best.
As a former tech, the product we offer is something I could imagine buying myself. In a way, I moved from being in the customer’s shoes to being the provider. I swear by dogfooding. Seeing your product through the eyes of a real customer is the most authentic driver of a truly customer-centric culture.
The big question then became: why didn’t I buy this product before? Some of those answers became the foundation of my strategy. But you also have to challenge it with another question: why am I not the target?
Observability, business-wide
To ask the right questions, I first needed the right ground truth. I spent several months digging to understand everything. Launching a startup is overwhelming, and documenting every decision is usually overlooked. But here, the founding team had been meticulous. A company built by engineers tends to put observability at its core, and it showed.
It wasn’t about fancy dashboards or over-engineered KPI frameworks. It was about raw data of what was done, when, how and how much. The kind of ground truth that makes it possible to really measure a business.
Observability is more than tools and data. Data without a story is noise. A story without data is fiction. The real value lies in interpretation, and that goes far beyond dashboards or metrics.
It lives in meeting notes, in memos, and ultimately in the people who experienced those datapoints. You have to ask them “why,” listen to their interpretation, align the stories, and surface the conflicts. That is where observability becomes understanding.
Velocity and the feedback loop
One of the first principles I learned in developer experience, I think it was from Basecamp or GitHub, was simple: the speed of the feedback loop defines performance.
That idea stuck with me. I became obsessed with shortening every loop: local setup time, CI execution, branching, release cycles. Later it became onboarding time, and how quickly a team could pivot.
The same principle drives me today, just on a wider scope. The units of measurement have changed. Sometimes they are quarters or years instead of minutes or hours. But the strategy is the same: reduce cycles from months to weeks, operations from hours to seconds.
Sales cycles, support response times, customer onboarding, releases, incident resolution. The faster the loop, the faster the company iterates. Speed not only makes a business more resilient, it makes the product more valuable. In many markets, speed is the feature.
Ask for help, from the right people
Stepping into new areas like marketing and sales was one of the biggest challenges. In management that usually means hiring the right talent. But when you have zero experience in a field, how do you even define talent? The whole logic of skill authority I used in tech did not translate directly.
Or maybe it did, just differently. I realized I already knew people who were true experts, not because of their followers or their books sales, but because they were operational, in the field, grounded in the day-to-day reality of building. That context made their insight invaluable because it connected to mine.
I cannot thank enough those who picked up my calls, answered my emails, replied to a LinkedIn message, shared a lunch, or a few minutes over coffee. People in marketing, in sales. Some even helped me qualify resumes. I owe them, big time.
For everything else, it’s not that different from engineering. Marketing is a pipeline. Sales is a pipeline too. Of course, they’re very different kinds of pipelines, but conceptually the logic is the same: something goes in, and if the system works, something valuable comes out.
The same principles apply: observability, acting on information, iterating. The actions themselves are different, but that’s where talent comes in. It’s no different than in engineering management. As a manager, I would hire someone prolific in a technology I understood conceptually, but without being hands-on myself.
Performance is a culture
That has not changed. I have always believed performance is cultural. The difference now is that I joined a company already performing. That meant its culture was working. The real task was not to fix it, but to understand why it worked, and why some changes were still needed.
It is about continuity, not perpetuity. In engineering we talk about continuous integration and continuous deployment, frameworks that enable fast change. It is the same here. The goal is to build a company that embraces change, not one that changes everything for the sake of it. Like engineers say: “if it ain’t broken, don’t fix it.”
Conclusion
Software engineering and tech management gave me great tools to onboard into this new adventure. The agile manifesto is not about code, it's about value. That’s why its principles of iteration and collaboration apply just as well outside engineering.
Of course, it has its biases. But the key is to stay aware of them. And sometimes the most powerful thing you can say as a leader is simply: “I don’t know.” That’s not weakness. It’s awareness and honesty.
Top comments (0)