In November 2025, we published a conversation with Raisul Kabir, founder and CEO of Brain Station 23, where we explored one of the most consequential questions in business: how do you scale? When we last interviewed Mr. Raisul in 2019, Brain Station 23 was a 185-person software services company. Today, it employs nearly 1000 people and is growing. This trajectory is not common in Bangladesh's technology sector and offers an opportunity to investigate questions that matter to anyone building organizations: What causes growth? What prevents it? What changes when a company scales, and what should change?
Brain Station 23 started in 2006 as a software outsourcing company. For years, after the initial growth of the company, Mr. Raisul contemplated that the company had missed the bus, that other countries had captured the market, and there was little room left to grow. This belief limited both strategy and effort. Then something shifted. New partnerships happened. A CFO joined. Structure evolved from flat to functional to strategic business units. Most importantly, Mr. Raisul learned that scaling was actually possible, and that belief change unlocked everything else.
No growth is a smooth sail. The interview offers a window into the messy reality of growing a business. Partnerships that broke before they worked. Financial planning is done on guesswork. Structural complexity that never fully resolves. And the slow accumulation of capability through deliberate system-building. The interview is a fascinating read in its entirety.
In this article, we've pulled several select lessons from this conversation on scale dynamics, structural evolution, cultural integrity, financial discipline, and the mental models that either constrain or enable growth. If you're building anything, these lessons matter.
After a few years into Brain Station 23’s journey, Mr. Raisul thought that Brain Station 23 couldn't grow meaningfully. Other countries had captured the software outsourcing market. The opportunity was gone. It wasn't pessimism exactly. He thought it was realism based on available evidence.
Then, in 2014, a conversation with Brummer and Partners’s Bangladesh office regarding a potential investment changed his perspective. The investment didn't happen eventually. But something more important occurred: he learned that a massive scale was possible. This single realization changed everything. Before, he thought Brain Station had hit its ceiling, and he should focus elsewhere, like their e-commerce business, Biponee. After, he realized the software services business could be their main vehicle for impact.
The lesson: your beliefs about what's possible directly constrain your effort and strategy. If you don't believe meaningful growth is achievable, you won't design systems for scale, you won't make necessary investments, and you won't pursue ambitious goals. The constraint isn't in the market, it's in your head.
This manifests in two ways. First, limiting beliefs cause you to under-invest. If Mr. Raisul believed Brain Station was capped, why would he invest in a complex organizational structure or hire a CFO? Second, they cause you to misallocate attention and effort. Mr. Raisul was focusing on e-commerce because he thought software services were a dead end. He was looking for opportunities elsewhere when the biggest opportunity was right in front of him.
The key takeaway is to challenge your assumptions about what's possible. Talk to people operating at scales you think are impossible. Look for companies that have achieved what you think can't be done. Your beliefs about constraints might be the actual constraint.
Mr. Raisul credits partnership as one of the key drivers of Brain Station's growth. When Mizanur Rahman, now the CTO of Brain Station 23, joined as co-founder and operating partner, the company went from 60-70 people to over 200. Mr. Mizan made significant contributions to revenue generation through sales and marketing. Later, Mr. Ferdous, now COO of the company, joined as another partner, contributing additional growth.
That said, partnership is not easy and doesn’t always work. The partnership with Mr. Mizan initially failed. They had friction. Both had been solopreneurs running their own operations. Neither knew how to accept input from an equal. Disagreement led to failure: Mr. Mizan left. They had to reconcile and bring him back, this time with a clearer understanding of how to work together.
Partnership is complex, requires continuous work, and often fails initially even between compatible people. Mr. Raisul compares it to marriage. There will be disagreements, someone will be upset, you need to work through issues constantly.
But when partnership works, it creates capabilities that simply don't exist otherwise. When you are a solo founder, you are doing everything that can limit your effectiveness. With Mr. Mizan on board, Mr. Raisul could focus on certain aspects of the business while Mr. Mizan focused on others. They could divide responsibilities based on natural strengths rather than forcing one person to do everything. The company could maintain momentum in multiple areas simultaneously.
That said, partnership is not easy. Expect it to be hard. Expect friction. But if you have fundamentally compatible people with complementary skills, that friction is worth working through because the ultimate capability gain is enormous. Just don't expect it to be smooth.
Beyond character qualities, every partnership needs a fair structure. Mr. Raisul is explicit: "If a partner thinks he is dealt an unfair hand, that partnership would not work." This seems obvious, but what constitutes "fair" is often unclear.
Mr. Raisul recommends the book "Slicing Pie" by Mike Moyer, which provides a framework for structuring business partnerships based on contribution rather than arbitrary splits. The core idea: equity should reflect what each person actually puts in: time, money, expertise, relationships, risk.
Most partnerships fail not because people are unreasonable, but because the structure creates perceived unfairness. One partner feels they're contributing more but receiving less. Another partner feels their early risk isn't valued. A third feels their specialized expertise is being under-weighted. These perceptions, even if not objectively correct, destroy partnerships.
Fair structure solves this by making the logic explicit and agreed upon upfront. Everyone understands the formula. Everyone can see their contribution reflected. When situations change, someone takes on more responsibility, someone brings in a major client, the structure has a way to account for it.
The mistake most founders make is thinking equity splits are simple negotiations. They're not. They're incentive systems that will govern behavior and perception for years. If the system feels unfair to anyone, it will poison the partnership eventually. Better to spend time upfront designing something everyone genuinely believes is fair than to have quick conversations that leave resentment.
In Brain Station's early days, Mr. Raisul did everything: CEO, project manager, architect. This works when you're four people. It stops working around 30. At that point, Raisul started delegating project management responsibility to others.
This is the first scaling threshold: moving from founder does everything to specialized roles. It is a fundamental shift in how the company operates. Instead of one person with full context making all decisions, you now have multiple people with partial context making domain-specific decisions.
This shift is rarely smooth. Mr. Raisul notes he trained and coached the project managers based on what he learned from PMP certification, but it wasn't formalized training; it was more ad hoc transfer of knowledge. Despite imperfect execution, this specialization allowed them to grow to 50-60 people, of which one or two people could manage seven project managers or tech leads each.
Specialization creates capacity, but it requires letting go of control. Mr. Raisul couldn't personally manage every project anymore. He had to trust project managers to handle things their way, based on principles he'd taught but without his direct oversight.
Identify repeated work that could be specialized, find people to own that work, give them training and frameworks, then actually let them own it. The psychological part is harder: accepting that things won't be done exactly as you would do them, but that's okay because it allows you to focus on higher-leverage activities.
Functional specialization gets you to 120-150 people. Beyond that, you hit another constraint: the CEO can only effectively manage certain direct reports. If each of those manages seven more, you're at roughly 50-60 people. The next level requires managers of managers.
Brain Station organized these managers around technology specialization. Each head managed multiple project managers or tech leads in their domain. This structure allowed them to scale beyond 150 people without overwhelming top leadership.
But notice what this creates: another layer of management, which introduces new complexity. Now information flows through more nodes. Decisions take longer. Context gets lost in translation. You gain capacity but lose some speed and clarity.
This is the perpetual scaling dilemma: each new structural layer solves capacity problems while creating coordination problems. You can't scale without adding layers. But each layer adds friction. The goal isn't to eliminate friction; that's impossible. The goal is to add only the layers that provide more benefit than cost.
Functional managers got Brain Station to several hundred people. To reach 1000+, the company needed a new structure, and that’s how the company landed on Strategic Business Units (SBUs).
Mr. Raisul learned about SBUs while exploring an M&A opportunity. A consultant recommended an Infosys article about how they used SBUs to manage growing complexity. The concept resonated: instead of one massive organization with tangled interdependencies, you create smaller, self-contained units that operate semi-independently.
Each SBU at Brain Station has a focus area: FinTech, enterprise e-commerce. Each has P&L responsibility, meaning they're accountable for their own profitability. Each has its own managers and operations. This structure allows the company to scale to 1000+ people without everything being tangled together.
But SBUs introduce new problems. Different SBUs have different priorities, creating coordination challenges. Some people report to both SBU heads and functional heads, creating matrix complexity. Moreover, some functions are centralized that creates the question of priority.
Mr. Raisul is honest about this: the complexity never fully resolves. Structure must continuously evolve. SBUs solve certain problems while creating others. The goal isn't a perfect structure; it's a structure that's appropriate for the current scale and can adapt as the scale increases.
Mr. Raisul admits he didn't understand the difference between finance and accounting for years. He thought they were the same functions. They're not.
Accounting tracks what happened, recording transactions, maintaining books, and ensuring compliance. Finance plans what should happen, forecasting cash flow, determining how many people you can hire, managing growth investments, and optimizing capital structure.
In the early years, Mr. Raisul personally handled financial planning. Based on current project revenue, he'd estimate how many junior developers they could afford to hire. It was mostly guesswork. He had projects generating certain amounts, so he could hire proportionally. This worked when they were small.
As they grew, this approach broke down. They needed systematic financial planning, not guesswork. They needed someone who understood finance, not just accounting. But Mr. Raisul didn't know what questions to ask a finance person or how to manage them because he didn't understand the domain well enough.
This led to hiring a part-time CFO—his friend Raj, who committed half a day per week for three years. That part-time engagement transformed the company. They got monthly P&L statements. They got project-level P&L tracking. They got cash flow visibility. They went from a hand-to-mouth operation to planned financial management.
Eventually, Mr. Raj joined full-time as CFO, which Raisul credits as transformational: "It changed Brain Station completely. We started operating differently."
Raisul is unambiguous: "Having a CFO is critical. Finance is the business." This isn't about being prudent or having good financial controls. Without a proper finance function, you can't scale reliably.
As companies grow, financial complexity increases non-linearly. With 20 people, you can track things informally. With 100 people, you need systems. With 500+ people, you need sophisticated financial planning, scenario modeling, capital allocation decisions, and constant trade-offs between different uses of resources.
Without a CFO, founders typically make these decisions based on intuition or guesswork. Sometimes that works. Often it doesn't. You over-hire and run out of cash. Or you under-hire and miss growth opportunities. You take on the wrong clients because you can't properly calculate project profitability. You make investments without a clear ROI because you can't model scenarios.
A proper CFO brings three things. First, visibility: you actually know your financial situation in detail. Second, planning: you can model different scenarios and make informed decisions. Third, optimization: you can allocate resources effectively across different opportunities.
Raisul notes that Brain Station went from a hand-to-mouth operation to planned management after getting CFO involvement. The company stopped having cash flow crises, not because it was making more money, but because it could see problems coming and plan accordingly.
Mr. Raisul references a book called "Strategy and Structure" that McKinsey partners allegedly used in the 1960s-70s, charging for implementing its concepts. The core idea: if your strategy lacks a proper supporting structure, the strategy is impossible to execute.
This seems obvious, but companies violate it constantly. They create ambitious strategies without adjusting the structure to support execution. Or they maintain old structures while trying to execute new strategies. The mismatch guarantees failure.
At Brain Station, structure evolved in clear phases tied to growth: flat structure for the early stage, functional roles at 30+ people, managers of managers at 120-150 people, and SBUs approaching 1000. Each structural change was necessary for the next phase of growth. The strategy "we want to scale" required appropriate structures to execute.
But it goes both ways. Structure also enables new strategies. The SBU structure allowed Brain Station to pursue specialized market segments—FinTech, enterprise e-commerce—in ways that weren't possible with a flat structure. The structure created a capability that made certain strategies viable.
Mr. Raisul is honest about organizational complexity: it doesn't get solved, it just changes form. SBUs solve certain problems while creating new coordination challenges. Matrix structures clarify some responsibilities while confusing others. Every structural choice involves trade-offs.
He gives a specific example: Brain Station's marketing and sales are centralized, but SBUs are decentralized. This creates tension. If an SBU focuses on FinTech, should centralized marketing specialize in FinTech? But then what about the e-commerce SBU? Some people report to both SBU heads and functional heads, creating ambiguity about priorities.
These aren't problems Brain Station is uniquely bad at solving; they're inherent to scale. This happens at large, sophisticated organizations worldwide. Complexity is a feature of scale, not a bug you can eliminate.
The mistake is thinking you'll find the right structure that solves everything. You won't. Every structure optimizes some things while making other things harder. The goal is continuous evolution, adjusting structure as problems emerge, accepting that new structures will create new problems.
Mr. Raisul noticed that Amazon's people showed exceptional customer care and wondered how they achieved it at scale. His conclusion: Amazon is a highly value-driven organization with a strong culture, but more importantly, they have systems to maintain that culture as they scale.
This insight led him to operating systems, frameworks like Scaling Up and Entrepreneurial Operating System (EOS) that provide structure for running companies at scale.
After reading "Scaling Up" and "Traction" (the EOS book), Raisul chose EOS because it felt more manageable to implement. They hired a coach, Haraya Rosario, who helped them implement the system over two years. One key output was defining company values using a structured process: identify people you admire, list characteristics you admire about them, consolidate and prioritize those characteristics, create memorable acronyms (Brain Station's OwnPATH: Ownership, Passion & Commitment, Agility & Excellence, Team Spirit, Honesty).
Operating systems solve the scaling culture problem. Without systems, culture depends on founder charisma and personal attention. That works for 20 people. At 200 people, founder's charisma reaches some people but not others. At 1000 people, it's physically impossible for founders to personally transmit culture. You need systems that encode culture in processes, rituals, and structures.
When Mr. Raisul talks about rhythm, he means something specific: a tempo and coherence in how the organization executes. Complex things get done but feel natural. You're operating in a flow where work doesn't feel like constant firefighting.
Rhythm includes: two-day annual sessions where leadership sets yearly targets, quarterly reviews where progress is assessed and adjustments made, weekly team meetings where coordination happens, and daily stand-ups where immediate issues are resolved.
Without rhythm, execution is reactive. Things happen when they happen. Coordination happens when someone remembers. Planning happens when a crisis forces it. At a small scale, this works because everyone has context. At a large scale, it creates chaos because context is distributed.
Rhythm creates predictable points for coordination, decision-making, and alignment. Instead of constant ad hoc meetings, you have regular cadences where specific types of work happen. Instead of people wondering when to raise issues, they know there are forums for it. Instead of decisions lingering indefinitely, there are deadlines.
Mr. Raisul notes that achieving this rhythm isn't easy. It takes work to establish and maintain. But once established, it transforms how the organization feels. Instead of chaos with occasional progress, you have consistent progress with occasional chaos.
Looking across these nineteen lessons, a pattern emerges: scale comes from systematic capability building, not individual heroics or lucky breaks. Partnership multiplies capability but requires work to function. Structure evolves through clear phases, each appropriate to the current scale. Finance provides visibility and planning that enables confident growth. Operating systems create a rhythm that coordinates execution. Training builds capability. Vision provides direction.
None of this is dramatic. There's no singular insight that transforms everything. Instead, it's a steady accumulation of capability across multiple dimensions—partnership, structure, finance, culture, systems, vision. Each component matters. Miss one and you'll struggle to scale regardless of how well you do the others.
The challenges Raisul describes are universal. Every scaling company faces them: structural complexity that never fully resolves, partnership friction that requires continuous work, and the gap between current capability and ambitious vision. What separates companies that scale from companies that plateau isn't the absence of these challenges. It's willingness to systematically address them.
The message isn't "this is how you should do it." Brain Station's journey is specific to their context—their market, their people, their circumstances. The message is more fundamental: scaling requires systematic work across multiple dimensions. It requires believing scale is possible, then building the capability to achieve it. It requires an evolving structure as you grow. It requires investing in finance, systems, culture, and training. It requires partnership when you can't do everything alone.
Most importantly, it requires rejecting the narrative that scale is for others, not you. Once you believe scale is possible, the work becomes clearer. Not easy, but clearer. You can see the systems you need to build, the capabilities you need to develop, and the evolution required.
