In the startup phase, you just get stuff done. The company founders do everything along with everyone else, from marketing and financing to even, yes, delivery. With most companies that grow beyond the startup phase, you’re joined by a few crazy people and become a team. Then, as the organization grows, it becomes a team of increasingly specialized teams. Ultimately, leaders organize and operate these groups by function, each with a department head overseeing the people who do the work — in other words, functional silos — to get work done.
A few, mainly software development or so-called digital organizations, adopt an agile approach, seeking to eliminate the functional system’s bureaucratic barriers to get work done. The famed agile manifesto featured four key principles:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
A tiny minority organizes and grows in an even less structured way. For example, in the startup world during the pre-2008 years, books promoting “holacracy” were popular, and successful company founders touted flat structures and decentralized systems. One example is Zappos’ “no job titles, no managers, no hierarchy” motto.
When we launched Aramis Auto, we, like many startups, did everything — Nicolas and his cofounder Guillaume Paoli delivered cars in the early days. However, we started dividing work very early on, not out of any theoretical conviction but because it seemed to be the easiest way to… get stuff done. Everyone continued to talk to everyone and was always there to lend a hand. When a fire broke out, it was always all hands on deck — no questions asked.
… as we grew, like most startups, we had to decide how to organize and manage the business and its work.
Still, as we grew, like most startups, we had to decide how to organize and manage the business and its work — what approach would work best? Soon, we had grown up and were suddenly selling cars by the hundreds with a turnover in the millions. Artemis was no longer one team but several teams. All the systems we’d cobbled together in the startup phase now needed to be robust, safe from cyberattack, and, to some degree, efficient.
Software, for example, had become a code factory.
Our team certainly subscribed to these principles, more out of pragmatism than conviction. We didn’t know how to do things any other way. We had grabbed the dragon by the tail and were trying not to fall.
Mitigating the Challenges of Growth
As we began to face these challenges created by growth, our backers counseled us to “structure” the company and hire experienced functional directors. They supported creating departments with department heads and a clear separation between line and staff — in other words, functional silos. They believed that the mess of internal complexity would otherwise eat us up.
Still, the lively debate in the startup world about “holacracy” appealed to us as a solution to our problems. We had integrated all our systems to deliver the service, but we needed to make the website, ERP, and physical delivery processes work together, blending software and brick-and-mortar. We feared that a functional organization would weaken these interactions and slow us down.
Ultimately, we listened to our elders and formalized a functional structure, hiring high-level directors. And this new structure ended up slowing everything down, as the directors started worrying more about the internal working of their department rather than serving customers. As a result, collaboration slowed down, as did the productive arguments of the past, as people focused more on processes and interacted less with each other.
Today, twenty years after the manifesto, the jury’s in, and we can state that agile doesn’t scale.
Before long, we discovered ourselves facing an entirely new set of issues. In hindsight, choosing to structure the company was the right call. Today, twenty years after the manifesto, the jury’s in, and we can state that agile doesn’t scale. Studies in contemporary management literature show that even when a product or service meets a real need in the market, many startups fail due to poor organization.
Ultimately, we felt vindicated by choosing to structure the business, although doing so brought us a share of new problems. We had little patience with these new challenges and regretted the early days of working as a single team or as individual teams. Instead, we realized that the true aim was creating a team of teams, but we had no idea how to do that — which is when we turned to lean.
As we describe in Raise the Bar, our first attempts at lean were somewhat inconclusive. Every kaizen workshop showed promise, but the gains never materialized or stuck. We looked to lean techniques to compensate for the functional focus and to reinforce transversal (or cross-functional) processes. It took us three attempts at lean (two with consultants and one with an internal program) to realize that lean was not an organizational method but a comprehensive cognitive approach. (Lean Thinking, as a book title, is a giveaway, but it simply hadn’t clicked for us.)
Framing the Right Questions for Learning and Growth
With that insight, we realized we had been seeking the wrong answers to our problems because we weren’t correctly framing them. We were learning that any functionally organized business will develop syndromes — systematic biases — or, as we called them, “big company diseases.” These included:
- Putting processes ahead of customers: choosing what is more convenient for the business rather than responding to customers’ specific demands.
- Spending time and energy on turf wars: dealing with territorial fights and boundary friction rather than working seamlessly as a team.
- Favoring bureaucrats over talented staff: supporting managers seeking compliance rather than competence to run the function according to its procedures and culture, and putting talent down, which leads to not promoting the right people.
- Confusing legacy and heritage: some things are legacy, maladapted remains of the past, which indeed happens with software. But others are heritage: practices or code that make us who we are and are at the core of what made us successful in the past and will do so in the future because customers like us for it.
Lean, we discovered, is a people-driven system to counter these and other ‘big company diseases.’
Lean, we discovered, is a people-driven system to counter these and other big company diseases. For us, it succeeded as discrete countermeasures to emerging problems, more of a customized and situational antidote than yet another layer of structuring systems. We were inspired by what Taiichi Ohno once said: first, learn to recognize the waste and then eliminate it, day in, day out.
So, we adopted lean thinking and practices to train people to recognize the waste in their area, starting with the waste they passed on to their customers and colleagues and then to their suppliers and partners. Throughout, they needed to learn to explore countermeasures to fix this together.
The lean-thinking perspective points to a fundamentally different question: ‘who should talk to whom?’
“Fix the team” has been one of the key lessons from our years of lean practice. We learned that a functional structure answers the wrong question of “who does what?” (So, if everyone would do their job better, then, surely, the whole would work better). The lean-thinking perspective points to a fundamentally different question: “who should talk to whom?” Then you can explore this question using lean tools, such as visual management (both on the gemba and with A3s), that clarify and share people’s thinking when they intend to do something.
So, we now know there is nothing wrong with a functional organization. Indeed, we understand that a functional organization is necessary to support scale if directors orient together toward customers and help each other solve their issues. And that they consider the impact of what they do on other functions, share their thinking, and take others’ advice seriously.
Finding and Developing the Right People
We ultimately realized that “structuring” a scaleup is less about finding the right structure and more about finding the right people and getting them to work together. Who are these right people? Individuals with sound judgment and the ability to listen. People who can get things done while caring for others, both in their department and across departments. Such people are much easier to spot internally than externally (it’s hard to spot them at job interviews). We also learned that people are rarely ready for the next level up in the company, meaning that your full-time job is to develop people.
This realization led us to rediscover a 1930’s insight about structure from the people who set up the New Deal, Allied Command, the Manhattan Project, the Marshall Plan, etc.). Certainly, a chain of command is essential (someone needs to take that final call). Still, the communication structure has a far greater impact on how the entire organization behaves.
We learned to ask, “Who needs to talk to whom?” before “Who needs to do what?” and we now know that when these questions are considered early, both day-to-day performance and intelligent reactions to unexpected crises improve. Communication, it turns out, is just as crucial as subordination — if not more.
Lean thinking and practices are the most effective system to develop this shared mindset of learning and curiosity.
Lean thinking and practices are the most effective system to develop this shared mindset of learning and curiosity. Lean takes you to the gemba to look at problems, where you can discuss judgment (questions like What is the right problem? What are the possible countermeasures? What is the right call?). Lean methods pressure you to focus on problems and then articulate standards helping people self-assess their work, spot their own mistakes, and learn. In the end, startups and established organizations need a learning structure, which the Toyota Production System provides.
For us, learning how to transition from startup to scaleup meant building teams to face, frame, fix, and form countermeasures to a daily deluge of problems, finding the development issue for each executive and then encouraging them to work together, not against each other. This approach creates a circle of trust that then spreads throughout the company. We know this because, with the rapid growth, we’ve had periods of great teams dealing successfully with difficult odds, such as the Covid-19 crisis, and moments of not-so-great teams with lesser performance. Of course, it’s never easy because, well, people are people. But in the end, people are the answer, whatever the structure.
