Working 14-Hour Days in Someone Else's Startup Taught Me More Than Any MBA Would Have.

There is a version of the MBA argument that says structured learning compresses experience: two years in a classroom gives you the frameworks that would otherwise take a decade of working to develop. This is partly true and partly wrong in a specific way. Frameworks are transferable. The judgment required to apply them correctly in conditions that do not match the case study is not. That judgment comes from having been in the situation, made the decision, and seen what the decision produced. No classroom compresses that.

Before starting ConsultBae, I spent years at companies that were operating at very different stages of growth. From an established firm like Tata Steel to startups at zero-to-one stage, to companies scaling aggressively through funded growth. In each of those environments, I worked the hours that the situation required, which across the startup stints averaged somewhere between fourteen and sixteen hours a day. That is not a badge of honour. It is the rate at which the learning came, because the problems arrived faster than any structured education could have prepared for them.

What I took from those years was not a collection of strategies. It was a set of instincts about how organisations break, how they scale, and where the assumptions that seem reasonable at one stage of growth become the liabilities that create problems at the next. Those instincts are the foundation of every significant decision made at ConsultBae, and they came entirely from the operational immersion, not from the classroom alternative I seriously considered taking instead.

What Operational Immersion at Scale Actually Feels Like

Working inside a company that is growing fast is not like observing one. The texture is different in ways that are difficult to convey from the outside. Decisions that would take weeks in a stable organisation happen in hours because the market is moving and the window is short. Processes that would be documented and tested in a mature business are invented and deployed simultaneously because there is no time to separate the two. The person who builds the process is also the person running it, which means the feedback on whether it works arrives in real time and the adjustment has to happen immediately.

This pace is uncomfortable and clarifying at the same time. It strips away the kind of professional hedging that stable environments allow, where the cost of a wrong decision can be absorbed and the learning can happen slowly. In a fast-growing startup, the cost of a wrong decision is visible quickly, the correction has to happen quickly, and the person who made the decision and the person who corrects it are usually the same person. The learning is compressed not because the experience is efficiently designed but because the conditions leave no room for delay.

What this produces, over time, is a very specific kind of operational confidence: not the confidence of having studied a situation thoroughly, but the confidence of having been in a situation that was close enough to the current one that the judgment required is already calibrated. This is the practical value of having spent years in environments that were genuinely demanding rather than comfortably educational.

The Zero-to-One Lesson and Why It Does Not Transfer Automatically

The zero-to-one phase of a startup, the stage where nothing exists yet and the first version of everything has to be built from scratch, teaches a specific set of skills. It teaches how to make decisions with incomplete information. It teaches how to build credibility before you have the track record to justify it. It teaches how to identify the minimum viable version of a process that will work well enough to begin without requiring the perfection that can only be developed through use. These are real and transferable skills.

What they do not automatically teach is how to manage the transition out of the zero-to-one phase. The instincts that make someone excellent at building from nothing: high tolerance for ambiguity, willingness to improvise, comfort with the absence of documented process, are exactly the instincts that become liabilities when the organisation needs to stop improvising and start systematising. The person who was the asset in the early stage can become a friction point in the next one if they cannot recognise that the requirements of the role have changed even though the role title has not.

Seeing this dynamic play out at multiple companies, watching founders and early team members navigate the transition with varying degrees of success, was one of the most practically useful things the startup years produced. The pattern is recognisable once you have seen it enough times, and recognising it early changes the decisions made about when to build process and when to keep improvising.

What the Ten-to-Hundred Journey Reveals About Systems

The ten-to-hundred stage of a startup is different from zero-to-one in ways that consistently surprise founders who were excellent at the earlier phase. At zero-to-one, the constraint is usually energy and resourcefulness: can you find enough clients, hire enough people, and move fast enough to get to the point where the model is proven? At ten-to-hundred, the constraint is usually systems: can you build the operational infrastructure that allows the business to deliver at ten times the volume without requiring ten times the direct involvement of the same people who built the original version?

The companies that scale successfully through this phase are almost always the ones that invested in process documentation, role clarity, and operational infrastructure during the earlier phase, rather than waiting until the scale problem was already present. The companies that struggle are usually the ones where the founders were excellent at the scrappy, improvised version of the work but never built the documented version that other people could learn from and operate without constant oversight.

Watching this at organisations that were further along the growth curve than where I had previously operated gave me a clear picture of what ConsultBae needed to build before it would need it, rather than after. The systems and processes that were built into the recruitment vertical, the three-team structure, the candidate relationship management tools, the documented playbook for each stage of the hiring process, were built earlier than they would have been if the only reference point had been the immediate operational need.

Why the Failure Stories Matter as Much as the Success Ones

The startup ecosystem's storytelling problem has been noted before, but it is worth being specific about what the bias actually produces. When the stories that circulate are predominantly success stories, the mental model of what a startup looks like in its early stage is calibrated against the ones that worked. The decisions, the risk tolerance, the pace, the funding choices of the companies that succeeded become the template for what startup building should look like.

What this misses is that many of those decisions looked reasonable from the outside precisely because they ultimately worked. The same decision, made by a company that did not survive to tell the story, looks reckless. The funding round that seemed bold when it was followed by a successful exit looks irresponsible when the same round preceded a shutdown eighteen months later. The outcome changes the evaluation, which means the lessons drawn from success stories are always somewhat contaminated by survivorship.

The failure stories, when you can get access to them through proximity rather than through the curated post-mortems that occasionally appear in the press, teach something different. They teach about the gap between what seemed like a reasonable decision at the time and what it produced in conditions that were not as favourable as the plan assumed. That gap, and the humility it produces about the limits of planning under uncertainty, is one of the most useful things the startup years generated.

What This Experience Looks Like When Used to Build Something of Your Own

Starting ConsultBae was not a departure from the years spent at other organisations. It was a direct application of what those years had produced. The decision to start with recruitment was not arbitrary: it came from having spent seven or eight years doing hiring work across multiple organisations and understanding the process well enough to identify where it was consistently broken and what a better version would look like. The decision to stay bootstrapped was not ideological: it came from having watched what external capital does to the decision-making in organisations that take it, and deciding that the constraints it would impose on ConsultBae would cost more than the capital would provide.

The operational habits that the startup years formed, the willingness to work the hours that a problem requires, the comfort with building process in real time rather than in advance, the calibrated risk tolerance that comes from having seen what happens when risk tolerance is either too high or too low, did not have to be developed at ConsultBae. They were already formed. What had to be developed was the specific domain knowledge of each vertical, the client relationships, and the team that could carry the work beyond what any individual could sustain alone.

The MBA I seriously considered taking before joining the startup world would have given me frameworks for thinking about these things. The years I spent inside organisations that were living them gave me something more specific and more useful: the pattern recognition that comes from having seen the same problem type enough times to know what it is before it has fully manifested and what it requires before the cost of addressing it has escalated. That pattern recognition is what the hours built, and it is the most durable thing the working years produced.