Co-founder Doing Everything
When I started as the co-founder at Elexive, I did not plan or expect to dive back into developing software. I had spent years moving up the ladder into leadership, strategy, and advisory roles. The assumption was that my coding days were behind me. But when you are running on a skeleton crew, it is both a blessing and a curse to be allowed – and forced – to do everything and everything in between. So now I am the head developer, lead advisor, CFO, and janitor. All in one package.
And I am loving it. That might sound like startup romanticism, but it is actually more nuanced than that. The reason I enjoy it is not because wearing every hat is glamorous. It is not. Debugging code at midnight after spending the morning on a client strategy session and the afternoon reconciling invoices is objectively exhausting. But there is something deeply satisfying about understanding every single layer of your business, from the infrastructure to the customer relationship to the financial model. When you are the person writing the code, advising the client, and balancing the books, there is no abstraction layer between you and reality. You feel everything directly.
The corporate world trains you to specialize. You find your lane, you stay in it, you go deep. And there is nothing wrong with that – specialization creates expertise, and expertise creates value. But a startup in its early phase needs the opposite. It needs people who can context-switch aggressively, who can move from a technical architecture decision to a financial model to a sales conversation in the same morning. The generalist phase of a startup is not a sign of dysfunction. It is a sign that you are moving fast enough that roles have not calcified yet.
Of course this is not the long-term plan. At some point, we will hire specialists who are better than me at each of these individual things, and I will happily hand off the janitor title along with the CFO title. That is how it should work – you build the plane while flying it, and then you bring in people who actually know how to build planes properly. But for now, it is all about velocity and agility. It is about putting every capability you have into the game without waiting for the perfect org chart to materialize.
The part that surprises me most is how much going back to coding has sharpened my leadership perspective. When you actually build the product yourself, you have an intuitive understanding of what is hard, what is risky, and what is trivially easy. That understanding makes you a better leader later, because you never lose touch with the reality of what the team is actually doing. I would recommend this phase to any leader who has drifted too far from the craft. Get your hands dirty again. You will be better for it.
