Out of every 10 startups, roughly one survives the first five years. Startups that worked with Squads have a better ratio, and over the years we've seen a few that went on to grow into larger companies. This process is not always smooth. More often than not, the moment that multiple teams are needed, a company merges into a larger company, or scale of creative work increases in some other way, there are challenges. This is normal and expected, but there are a few ways to do it well, and many ways that can be rather painful. This article is intended to share our learnings in this phase and explain how to avoid some typical pitfalls.

From Startup through Scaleup to the Corporate Maze

Let's call a startup a company with less that four engineering teams, a scaleup four to 15, and a corporate or enterprise everything above. I'm messing with definitions here a bit, but I'd like to not introduce new words for readability. 

In the first stages of a startup, team work is easier. There's either a high level of collaboration, or a benevolent dictator that has the full overview of what's there and what's needed. Squads itself is still in this mode after a decade, and it works just fine.

Once market demands or ambitions force a company to scale up their development efforts, there comes a time when one team is not enough. Often a good coordinator of work transcends the team boundaries and becomes the central point of control. Many creative workers like this, because if all you have to do when you get stuck is talk to Lisa, life is easier than if you have to categorize your problem before you know who to talk to next. 

The central point of control can be an authority figure, but more often than not, the actual brains hide behind an authority figure that merely serves as a lightning rod for distractions. To find such a central control in a mature organization can be quite difficult. Often the people that make up this central authority don't even realize that they're doing it. In one organization that I worked at, the central authority was a few unlikely people that had drifted apart at the bottom of the org chart, but still met at the coffee machine and the Friday drinks. One middle manager knew them all, and got his magic done by simply asking them questions and shielding them a bit from the official work. Once a startup becomes a scaleup, watch for the tipping point where this can still be identified. In my limited experience, this tipping point is at around 80 people. Once passed, fixing things is going to be expensive. I have never in fact seen an organization recover from established corporate culture, but I refuse to believe it is impossible until I see a logical proof.

Past the tipping point, many creative people accept that there's a bureaucracy that is simply a fact of life. They don't challenge it anymore, because that results mostly in local negative feedback, and if there is global positive feedback, the real fixers don't get to enjoy much of it anyway. The best people move to more appealing positions, and the second best quiet quit. You are now in a swamp, and getting out is not going to be easy.

Impediments Causing Lower Effectivity 

From a very early stage in creative work, shortcuts can give you something more impressive to show at the cost of having to do more work later. This is what software developers call technical debt, but it also exists in fields like visual art, building, and mechanical engineering. When two bits of feedback are separated from each other in space time, they are at risk of being received by different people. This is problematic when the causer of the feedback only receives the positive feedback and the negative is left to be dealt with by someone they don't care as much about. The risk of this is higher in larger organizations.

People are prone to favor their comfort zones. As a result they are at risk of learning bad habits that allow them to stay in their comfort zone longer, or get back there quicker. Bad behaviors are most often not intentional, so people are always at risk of becoming unconsciously incompetent. Example: if I'm able to get through my morning meeting with my boss more quickly and happily by giving myself a sugar rush just before, I might have something sweet, or an energy drink just before. This causes me to put on weight, and have less energy during the rest of the day. This may make the meetings more dreadful, so I might take two energy drinks. This reinforces the (probably unconscious) habit of taking a sweet or an energy drink before all difficult encounters. But it also brings down overall productivity and happiness. It's easy to not see something small like this for what it is: an easily fixable problem.

There are several obvious impediments to watch out for:

1. Favoring meetings and discussions over creative work

2. Documentation instead of experimentation

3. Favoring to work alone over collaboration

Many methodologies in larger organizations include ceremonies (1) and artifacts (2). Some of these are useful at times, but they can also become dead weight in our storage and calendars. A knee-jerk reaction to the perceived waste of them is often to isolate oneself from the whole ordeal (3). This creates a communication barrier. 

One particular methodology I'm pretty qualified to bash is SCRUM, but there are many others. In software development, Agile and DevOps provide iterative and continuous delivery approaches. For project management, PRINCE2 and PMBOK offer structured frameworks. Quality management can benefit from Six Sigma and TQM, while service management can use COBIT and TOGAF for IT governance and enterprise architecture. All these methods have a reason to exist, and some merits when applied with intelligence. All of them also open a giant pitfall to spend time looking busy with the ceremonies, while (unconsciously) hiding the intellectual laziness to solve real problems for the business. 

Once a bad habit is established, it _becomes_ intentional. This happens when people feel good, looking important and busy, and assign themselves roles that revolve around the ceremonies, and not the real goals of the organization. Usually this happens with major consent from all parties involved, and results in hopeful and congratulatory presentations up and down the chain of command. It's not a good thing. The best people (those that see through it) are looking for the doors while this happens. 

Intentional Redundancy in Creative Work

From before mentioned problems, follow intentional redundancies. But if you read well, you noticed that I also mentioned those methodologies and frameworks have _some_ merits. As an organization scales, some risks tend to blow up, and mitigating them is extremely important. Even if that annoys the crap out of some of your best people. This is often used as a disingenuous argument to stick with the ceremonies. This is also the crux of this article.

Knowing when redundancy is desirable, and when it is toxic is exceptionally hard, and crucial for your survival. Let's look at an example outside of software companies to illustrate the problem first.

–

As a second job I do tree work. This involves climbing trees with ropes and then using a chainsaw to cut bits of the tree. All the while not falling to your death of course. I like being outside, and I've studied physics, so it's an interesting and challenging activity. There's also decent money in it if you can do it fast enough (I can't). The rate of injury and fatality in this job is quite high, so it's often discussed what the rules should be to do it safely. It's also very hard to regulate, because we do this job in places not easily controlled and reviewed. The rules are therefore mostly culturally enforced by peers. Nobody wants to spend their day putting a buddy in an ambulance, so if you act unsafely you get negative feedback. Also, most of us need to make a living, so if you waste time, you also get negative feedback. Arborists in my country are not rich, so both factors involve existential risk for them. The feedback is real, so we don't mess around.

Some regulating body introduced the 'rule' that we should from now on always climb with two independent life lines. The life line is a line that is anchored via or to the top of the tree, hence also called top anchor sometimes. For those of you who don't know, tree climbing is similar to both lead climbing and top roping because we can sometimes toss a line into the tree, but often we also need to move our top anchor later. To do this we use a shorter line (flipline) to make sure there's always at least one line attached for safety. Now raising that number to two, and demanding that we are always attached to two lines, more than doubles the work needed to position ourselves to the point where we want to saw. More work means higher cost. The first companies to introduce this would immediately lose business over it, and unless it becomes obvious that it really saves lives, it's not going to happen.

This requires making good decisions about human lives and the future of our business. You can probably see that this is not an easy call to make. We keep doing this because it's what we always did is obviously fallacious. But under what circumstances is it allowed to prioritize profit over human lives? 

In this case we reasoned that human error is a larger problem than lack of redundancy in accidents. The added complexity of a second line increases the probability of human error more than that it reduces the risk of equipment failure.Therefore the extra rope won't save lives effectively.

Thus the investment into extra ropes is canceled, and instead we invest in extra equipment maintenance, and training. 

–

The example decision in the arborist company makes sense hopefully. But by illustration of what happened with Boeing, and more recently with CrowdStrike, it becomes clear that in larger organizations, such risk assessment is assigned lower importance than covering one's ass.

That said, for example the risk of good people leaving, and the organization ending up not knowing how to maintain some brilliant invention is real. We need redundancy for that. A friend of mine running IT at a larger enterprise told me flat out that they were happy to spend 3x as much time and budget on a solution if that meant that the lesser gods also understood exactly how to keep it up and running because: "it may sound cynical, but we already know that the smartest people will not stick around, so we have to make sure the softies can do it. Sorry to say." I can't prove them wrong.

So there's the conundrum: the hardies will be annoyed by the mitigation of the risk of them leaving (inefficiency, slowness), and then they'll leave faster, probably. Using this as a general rule would therefore introduce a self fulfilling prophecy, a vicious cycle towards the slowest, most boring corporate you've ever seen. In the end that materializes the other risk that's always looming: simply not being able to keep up with the market.

Finding a balance between safety and speed is the hard and crucial skill. Each case is unique, so it requires careful analysis on a case by case basis to make the right decision.

Not everybody needs the same things, not every organization needs the same things

There are different types of people that shine in different circumstances. Sometimes a behavior in the wrong place can do an insane amount of damage. My friend Rahul pointed me to M. Scott Ford's talk 'Makers vs Menders' where he puts this really well. 

He came up with a picture of quadrants for different people that play different roles in organizations. I'm not going to repeat all that he says, so watch the video if you have time. Just the picture could give you an idea already. 

The main point I would suggest of discriminating between different roles a creative worker can assume is to intentionally pick a mode of working, based on risk and opportunity, and collaborate with someone that augments the skills needed for the job. If two people comfortable as rapid prototypers attack an emergency response problem, the organization will have more chaos and less useful things learned than when a feature builder and remodeler do an emergency response together. Or so I would expect. 

Human beings are unique, and don't fit exactly in one of these quadrants, but thinking with our discriminating mind on the behaviors that are appropriate for what we want to achieve can be very helpful at times. 

I'll use these concepts in the next sections for structure.

Symptoms

We can have symptoms of good balances, and symptoms of disturbed balances. I'll list a few here, but I am under no illusion that the list is complete. If you have anything to add here, in the form of a comment, or a scathing response article, I'd be very happy to read about it.

People complaining is the most obvious symptom, but depending what they're complaining about, it can be good or bad.

A rapid prototyper complaining that there is not enough interesting work for them could mean that the organization needs to do more innovation. But it could also mean that product market fit was achieved for the product that this developer was working on, and a change in team behavior could help. 

A remodeler complaining that there's too much tech debt could mean there's too much experimentation going on and too little solidification in conquered market areas. It could also mean that product market fit has not been achieved, and we should be accepting the ephemerality of experimental software more as an organization. 

No complaints is also a symptom. It is possible, though rare in my experience, that nobody complaining is a sign of efficient and healthy operation of the organization. More often than not, lack of complaints is a sign of cracks in the cultural foundation.

Remedies High Level

Desirable changes in team behavior can be achieved by setting different goals and performance metrics for the team, but it can also be done by allowing people to move themselves around to more interesting areas in the organization. If some concern does not get enough attention, consciously hire, internally and externally for the right profiles to fill the need.

The importance of setting goals from the right level and at the right level and designing feedback around them cannot be overstated. From the organizational mission, the goals should flow naturally. When the organization is hierarchical, and doesn't have a clear mission other than 'Make the founders and shareholders happy' this is a constant active process driven from the top down. When the mission is part of the culture, and the organization is a tool to make the entire community happy, goals will be set from the bottom up. 

In both bottom up and top down management, we need people that are willing and able to oversee the whole picture and can pinpoint friction due to goals set incorrectly, or at the wrong level. Perhaps even more importantly, we should all look out for unhelpful or missing feedback. 

Feedback is extremely important, and the best way to identify its usefulness is at the receiving point. Receiving feedback almost always invites emotion. If the invited emotion is unwholesome, and leads to unwholesome actions, this is a sign that the feedback is not timed well, not directed at the right receiver, or is wholly incorrect. This can be caused by either the setting of unhelpful goals, or the use of unhelpful measurements around them. This is always caused by lack of skill, which can always be solved by learning or training. Mind you, an organization can also learn by letting go of members, and it is not unlikely that in many cases that is the least harmful way to do it. Not everybody needs to fit everywhere.

Make it OK to look for imperfections to improve on.

Remedies Practical and Small 

Feelings are excellent signals to base actions on. Allowing for some contemplation before taking action is usually best. When you notice someone is feeling uncomfortable, unhappy, annoyed, this is an opportunity. Especially if that person is yourself of course. Notice and name the feeling. Approach it with compassion and curiosity. Once all involved feel safe and heard, ask these questions: 

• "What can be learned here"?

• "What feedback caused this emotion?"

• "What measurement caused this feedback?"

• "What goal caused this measurement?"

After this is known, try to align the goal with the mission, improve the measurement to be in line with the goal, improve the feedback to be more effective and cause less negative results, and then maybe accept that some things are not 100% fun and great, but when we understand that they must happen, we can do them quickly and efficiently without feeling overwhelmed.

When in doubt, direct the feedback at a team, not an individual. At Squads we went to an extreme with this by incorporating direct financial feedback into our terms. A client pays up-front when setting a goal, but until the goal is reached _according to the client_ nobody in the team gets paid. This incentivized both the team and the client to make sure attainable and valuable goals are set iteratively. Often clients and teams veer away from this intention, and set monthly budgets, sometimes even on individual level. Always when that happens, I politely object, then go along, and then I put a few reminders in my calendar for the 'Told you so' moments that happen at 6 months, 1.5years, and even longer after. The timings and circumstances differ on a case by case basis, but it always goes south. Why? Because people lean into their comfort zones, even if it's bad for them and they know it is. Which brings me to my next point.

Actively make comfort zones uncomfortable, and invite people to step out of their comfort. Yes it's easier to just talk to Jack, because Jack knows everything. But when Jack went to a Vipasana retreat, and we had to shut down the factory for three days because one detail was known by nobody besides Jack, we made a decision. The decision was that Jack never accepts any work without a ticket. Jack is supposed to be a jerk if you don't give him a ticket. Jack now has a stick, and a carrot. Give him a ticket, you get the carrot: he'll tell you how to fix your problem. If you come to him without a ticket you get the stick. This is for your own good, as we decided together on that horrible weekend post mortem, remember? We see stuff like this go bad around us everyday. It's not OK to simply accept them as facts of life. In fact it is commendable to try and expose those people that try to make it seem that is OK. Expose them for what they are: saboteurs. That may sound very negative, and you're welcome to be very nice about it, for example by sending them a link to this article ;) But eventually, the sabotage must stop.

Empowering actions are often simple and easy. For example if a Jack asks for help getting something real done, because we decided to prioritize knowledge sharing through peer instruction over short term gains, but at the same time you have a bilateral with your boss, tell your boss, while the others can hear: "I'm going to prioritize helping Jack get machine X going again, because he had the courage to ask for help and I want to reward that. Pairing is more important than our meeting right now." If you have a good boss, they will love that. And if it causes problems, it should be remembered that these problems were already there, and we can be thankful that they are now visible. 

Do it well or don't do it. In tree work, we don't leave the job if it's not done well. Meaning we never leave an unsafe situation, and we have a plan to come back if we need to prevent bad stuff from happening in the future. The first part is obvious: if a large branch is hanging over a house ready to fall in the next storm, we can't just go home, even if it's past our working hours. This means we either plan well and execute effectively, or we do overtime. 

In software, we don't encounter life threatening situations very often, so the practice is much more that high pressure arises if some business goal needs to be met earlier to make some extra profit. The risk is much less direct to the bottom line of the business. If you drop a tree on someone's house, that's going to cost immediately. If you burn out and abuse your people, that's going to cause a much slower consequence, that is likely not (completely) shouldered by the business that caused it. We, the people, are responsible for our own safety. Start a job only if it can be finished without doing harm.

It's hard to come to a general conclusion here. The most important point would be that each organization is different, so the particular refactorings and desirable designs are going to be different. 

Use the tips in this article to iterate towards a fitter organization, keeping in mind these are not silver bullets. If there are any silver bullets they would be team centric feedback and pair/ensemble working sessions. Introducing those when in doubt, will create room to maneuver and more intentions to find out what the next steps should be