The Kindergarten, the Construction site, and the Assembly Line

Last night, I went to a local meetup where we played Legos. It was an event organised by Krzysztof Niewinski. In particular, it was a simulation workshop of large scale product development using alternative organizational structures. But there were lots of colored bricks involved. And the specs were pictures of the end products that needed to be built.

Without getting into too much detail, we covered 3 alternatives with the same group of 20 something people: component teams, cross functional teams of specialists, and finally "T-shaped" interdisciplinary teams where everyone could do everything. In short, we were experimenting with output using alternative ways of working. Each round took roughly 10 minutes.

Here's what happened

In the first round, we had specialized component teams each dedicated to working with only two different lego colors, a supply team, an integration team, a quality team, and 8 different product managers who wandered from table to table. Sound familiar? Kind of like a massive construction site with lots of project managers. Or in a large company developing and installing software. Most of the building teams sat around doing very little in practice. There were lots of bottlenecks and confusion around getting supplies and exact requirements. I had a chance to engage in chitchat with my table mates. And a stressed out senior executive that walked around and yelled at anyone for not doing anything.

The second round, we continued to have individual performers who were specialists, but they worked together, which resulted in a lean assembly line. The time required to first output went down almost 50%. But there was less top down control. And more legos on the table, relative to the previous round.

And finally--the last round--everyone pitched in and contributed how they could. There were still some constraints, in that people working outside of their expertise could only use their left hand. Despite that, it only took a minute to get the first outcome, so almost 9 times faster. But there were lots of extraneous legos on the table. It was lots of fun, and it was a very tactile learning experience for everyone who pitched in. Just like kindergarten.

What does this mean

This boils down to control, profitability, and speed. This is just as true for startups as it is for large companies. Most of the conflicts among co-founding teams boil down to differences how founders value control and money, according to Harvard professor and researcher Noam Wasserman in Founders' Dilemmas. In big companies, any larger product development program will implictly or explicitly make a call on these three, based on how the work is organized. It depends on what you optimize for, as Krzysztof the facilitator pointed out.

The construction site was optimized for control, especially of costs. There were enough people to do the work, and enough legos could be procured if you were willing to wait. But the level of resource scarcity locked up the system, relatively speaking. And it took a long time to finish anything.

The assembly line required a slightly larger up front investment but the speed at which things happened increased dramatically. Even though the constraints on each individual were exactly the same. As an expert in yellow and green bricks, I was still only allowed to touch these, even though the configuration was completely different.

The kindergarten required even less top down control and more resources, as well as trust that the teams will get on with it. There was be a higher use of resources (lego blocks laying on the table). At any given moment, you won't know exactly what is going on, because everyone is contributing and collaborating. The teams were releasing stuff like crazy. So at that point, does it really matter that you need a bit more money up front? If they are releasing stuff so quickly, presumably this translates into revenue, which keeps the kindergarten afloat and then some.

Choosing the metaphor works that best for your company

The way you organize the work matters. And it feeds into culture. Larman said "Culture follows structure". In a software context, it means you want to allow for chaos and experimentation. And not really just squeezing features out of development teams.

As a company scales from a successful startup to a larger company, the trick is to keep enough of that "kindergarten juice" in the culture and in how the work is organized, in order to allow your company to continue innovating. If the emphasis on control changes as a product matures, you can introduce more of that as needed. But do so consciously, and watch your output and outcomes like a hawk.

By micromanaging the process, even as an assembly line in a feature factory, you're still missing out on pretty big upside (assuming you care about having lots of new products released).

That said, even a kindergarten needs boundaries. So that the teams don't cut corners in quality for example. That's kind of the point. There are a handful of non-negotiables around safety, health, and security in a kindergarten, and everything else is optimized for discovery.

So for a bunch of interested strangers on a random school night, who dug into a few alternative structures and held everything else constant, it was clear that there could be very large differences at play. 14x faster, not 14% faster. These would be results any agile or digital transformation program would love to achieve. That said, it wasn't clear if these differences came from structure only, or the culture around it. And if culture is involved, that could be what's preventing the massive change in the first place.

Key Takeaways

• The way you organize work matters, and it feeds into the culture, particularly in a larger company.
• By organizing work, you will be making choices about tradeoffs among variables that matter.
• Control, in particular, seems to be inversely related with learning and speed.

Why addressing errors effectively lies at the heart of team performance

No one wakes up in the morning excited to go to work and look ignorant, incompetent, or disruptive. While it's not true of everyone, I think it's fair to say that anyone who gets a job wants to be there and usually wants to do well--for the purpose of self-respect. Look at how elated most people are when they accept a job after getting an offer. It's when they enter into the "systems" at a particular company, that everything usually takes a left turn.

Modern Times (1936) trailer: capturing the essence of managing

In established companies, it's sadly common for employees to be habituated in a context of fear of failure. Especially if there is a lot of pressure from management to perform at a high level. There are ambitious goals, often coupled with a lack of clarity on how they will be achieved. In practice, employees focus on looking busy (however that is defined). They end up fearing failure, of not living up to expectations.

As a manager, there is a fine line to draw here. You don't want to set the bar too low and cause everyone to just slack off. The starting point here is one of psychological safety; according to the research, this is one of the main factors driving high performance in teams. In particular, how you handle errors, failures, or surprises in a way that keeps the team accountable while enabling them to believe that they will be listened to--if they speak up.

Common error types

According to Amy Edmondson in The Fearless Organization, there are 3 different types of errors which happen professionally, and their meaning is largely driven by context:

1. mechanical errors in a highly repeated process that just need to be minimized in frequency: this is what Modern Times parodied
2. interaction errors which result from highly complicated relationships, especially in a larger company
3. thwarted expectations around a goal in the context of experimentation, often a surprising result of an experiment

A large part of the challenge of large companies is that they treat all errors as if they were all #1 by default. This approach may be tied to political gamesmanship. But not everything is just a deviation from a standard (regardless of who actually decides and imposes that standard). Especially in knowledge work like software, where completing something requires you to learn something you don't know up front. Edmondson quips, “For knowledge work to flourish, the workplace must be one where people feel able to share their knowledge!”

Photographer: Sarah Kilian | Source: Unsplash

In my software experience, most of the problems encountered, especially around people and process, were due to #2. Company systems were wrong, inadequate or just misaligned. Unfortunately, this typically meant that a person or department was singled out and blamed. I tried hard to bring the discussion back into a discussion around how the work was done, and if something could be done to prevent a similar problem from re-occurring.

The last type (#3) is essentially an opportunity to improve the company, the product, or the workflow, packaged as an intellectual surprise. Sometimes, the team would come across a much better way to solve or define a technical problem than they had originally wanted to do otherwise. This was particularly common in the early days of designing a large system. The same can be true on the business side, if the company is open to experimentation on that end. These are so valuable, that most innovation circles try to maximize the number of these errors through structured experimentation and record-keeping, in order to speed up overall progress.

Be open to taking ownership and admitting mistakes

From the perspective of psychological safety, it's critical to start with assuming any error is a #2. This includes assuming that the leader in the system is responsible for the system. More importantly, he is also part of the system. Which means that the manager needs to be open to letting their ego bruised, and be willing to admit mistakes in front of their fellow team members, in the service of improving life for everyone. Once I did this enough times with my team, they realized and eventually believed that I was genuinely interested in optimizing how the team worked.

Photographer: Jen Theodore | Source: Unsplash

Essentially the way to solve the misaligned expectations problem (bar too high vs too low) is to view the work as a system. And that way, you depersonalize the work enough, that fears become less of a driver for action. Instead, employees follow their genuine interest in improving their own work life. This allays fears of failure. And gets everyone more involved and excited.

Ultimately, you care about the output your team produces, so focus your management on that, rather than on policing individual effectiveness. Paradoxically it produces better results.

Key Takeaways

• Psychological safety lies at the heart of high performing teams
• Most commonly errors are assumed to be individual mistakes, rather than the result of complicated interactions gone wrong.
• Get the team excited about improving the workflow

The Kindergarten, the Construction site, and the Assembly Line

Last night, I went to a local meetup where we played Legos. It was an event organised by Krzysztof Niewinski. In particular, it was a simulation workshop of large scale product development using alternative organizational structures. But there were lots of colored bricks involved. And the specs were pictures of the end products that needed to be built.

Without getting into too much detail, we covered 3 alternatives with the same group of 20 something people: component teams, cross functional teams of specialists, and finally "T-shaped" interdisciplinary teams where everyone could do everything. In short, we were experimenting with output using alternative ways of working. Each round took roughly 10 minutes.

Here's what happened

In the first round, we had specialized component teams each dedicated to working with only two different lego colors, a supply team, an integration team, a quality team, and 8 different product managers who wandered from table to table. Sound familiar? Kind of like a massive construction site with lots of project managers. Or in a large company developing and installing software. Most of the building teams sat around doing very little in practice. There were lots of bottlenecks and confusion around getting supplies and exact requirements. I had a chance to engage in chitchat with my table mates. And a stressed out senior executive that walked around and yelled at anyone for not doing anything.

The second round, we continued to have individual performers who were specialists, but they worked together, which resulted in a lean assembly line. The time required to first output went down almost 50%. But there was less top down control. And more legos on the table, relative to the previous round.

And finally--the last round--everyone pitched in and contributed how they could. There were still some constraints, in that people working outside of their expertise could only use their left hand. Despite that, it only took a minute to get the first outcome, so almost 9 times faster. But there were lots of extraneous legos on the table. It was lots of fun, and it was a very tactile learning experience for everyone who pitched in. Just like kindergarten.

What does this mean

This boils down to control, profitability, and speed. This is just as true for startups as it is for large companies. Most of the conflicts among co-founding teams boil down to differences how founders value control and money, according to Harvard professor and researcher Noam Wasserman in Founders' Dilemmas. In big companies, any larger product development program will implictly or explicitly make a call on these three, based on how the work is organized. It depends on what you optimize for, as Krzysztof the facilitator pointed out.

The construction site was optimized for control, especially of costs. There were enough people to do the work, and enough legos could be procured if you were willing to wait. But the level of resource scarcity locked up the system, relatively speaking. And it took a long time to finish anything.

The assembly line required a slightly larger up front investment but the speed at which things happened increased dramatically. Even though the constraints on each individual were exactly the same. As an expert in yellow and green bricks, I was still only allowed to touch these, even though the configuration was completely different.

The kindergarten required even less top down control and more resources, as well as trust that the teams will get on with it. There was be a higher use of resources (lego blocks laying on the table). At any given moment, you won't know exactly what is going on, because everyone is contributing and collaborating. The teams were releasing stuff like crazy. So at that point, does it really matter that you need a bit more money up front? If they are releasing stuff so quickly, presumably this translates into revenue, which keeps the kindergarten afloat and then some.

Choosing the metaphor works that best for your company

The way you organize the work matters. And it feeds into culture. Larman said "Culture follows structure". In a software context, it means you want to allow for chaos and experimentation. And not really just squeezing features out of development teams.

As a company scales from a successful startup to a larger company, the trick is to keep enough of that "kindergarten juice" in the culture and in how the work is organized, in order to allow your company to continue innovating. If the emphasis on control changes as a product matures, you can introduce more of that as needed. But do so consciously, and watch your output and outcomes like a hawk.

By micromanaging the process, even as an assembly line in a feature factory, you're still missing out on pretty big upside (assuming you care about having lots of new products released).

That said, even a kindergarten needs boundaries. So that the teams don't cut corners in quality for example. That's kind of the point. There are a handful of non-negotiables around safety, health, and security in a kindergarten, and everything else is optimized for discovery.

So for a bunch of interested strangers on a random school night, who dug into a few alternative structures and held everything else constant, it was clear that there could be very large differences at play. 14x faster, not 14% faster. These would be results any agile or digital transformation program would love to achieve. That said, it wasn't clear if these differences came from structure only, or the culture around it. And if culture is involved, that could be what's preventing the massive change in the first place.

Key Takeaways

• The way you organize work matters, and it feeds into the culture, particularly in a larger company.
• By organizing work, you will be making choices about tradeoffs among variables that matter.
• Control, in particular, seems to be inversely related with learning and speed.