Assessing Your Role

Recognize the size of the vessel you’re steering. This will be determined by a combination of the number of people in the company, the age of the company, the size of the existing business infrastructure (software, processes, and the like), and risk tolerance:

The more people you have, the more thoughtful structure you need to get everyone moving in the right direction. Leaders who want a high degree of control over their organization tend to need more structure in place to make sure their wishes are enacted. Modern companies often put their structural focus on goal setting instead of trying to make all decisions from the top, but don’t underestimate the structure you need to successfully set and communicate goals.

The longer a company is around, the more habits become entrenched. On the other hand, the longer a company has been around, the more likely it is to continue to survive.

If you have few established business rules (such as “this is how we determine what to charge our customers”) and little code or physical infrastructure (like stores, warehouses, or inventory), there is less need for structure. On the other hand, the more existing business rules and infrastructure you have, the more you’ll need clarity on how to handle them.

Are you in a highly regulated industry? Do you have a lot to lose if certain types of mistakes are made? Or are you in an unregulated industry, with little on the line? Your structures and processes should reflect this. In general, the more people you have depending on you and the larger the business is, the less risk you’ll be willing to take even without regulatory requirements.

Structure grows as the company grows and ages. In fact, there’s even a law that accounts for this, from John Gall’s book Systemantics:¹

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Your company started as a very simple system that contained a few people, and as more and more people and rules and infrastructure were added, it evolved into a complex system. I don’t think there’s a huge benefit in overdesigning your team structure or process when your team is small and functioning well. However, at some point you’ll start to experience failure, and failure is the best place to investigate and identify where your structure needs to change. In the creating a career ladder example, one person quitting because of a lack of a career path might not be enough to push you to create a career ladder, but you may reconsider when multiple people quit or fail to join. You’ll need to weigh the value the lack of structure brings the team against the cost of losing people you might otherwise want to employ.

My advice to leaders is simple: when failures occur, examine all aspects of reality that are contributing to those failures. The patterns you see are opportunities to evolve your structure, either by creating more or different structure or removing it. Think about how often the failure happens and its cost, and use your best judgment about the changes that need to be made. Using failure to guide evolution lets you apply structure at the right level. If a failure is occurring in only one part of the system — say, on one team — you can try to address the structure on that team without necessarily changing the larger structure. What about examining success? Well, you can learn things from success, but it is often a poor teacher. Ironically, while luck plays a role in both failure and success, we often attribute failure to bad luck and success to our own actions. As Gall’s law says, a simple system that works can evolve into a complex system, but that doesn’t mean that applying the lessons from a successful complex system will let you replicate that success in other places. As humans, we tend to blame failure on bad luck until it’s impossible to ignore our own contributions to that failure. Therefore, we’re less likely to overstructure our teams based on lessons from failure. Success, on the other hand, tempts us with the silver bullet, that one weird trick that could make everything great. If you want to learn from success, make sure you can identify the actual improvement you’re seeking when applying those lessons more broadly, and that you understand the context required to repeat that success.

The age of the company and size of the team plays into this issue. If you’re at a company that’s been around for a while and will be around for a while, using structure (adding or removing) to improve efficiency is very helpful, even if it costs something up front to implement. That’s part of the trick. Learning rarely comes for free. Analyzing situations and thinking about good takeaways takes time. If the value of your future time is less than the value of your current time, then you’re probably not going to worry too much about saving future time. Just because your company is big, old, and stable doesn’t mean you can have as much rigid, unchanging structure as you want. Technology changes often enable formerly risky moves to become safer than the slow-moving alternatives. Software release frequency is a good example of this. For a long time, releasing software frequently was difficult and expensive, largely because you were shipping that software to the user. In the modern SaaS world, bugs can be easily fixed, and the risk involved in shipping a bug is much lower than that of not expanding features quickly enough to keep up with competition. It’s this type of unconditional attachment to old structures that makes many people hesitant to adopt structure at all. But if you don’t adopt structure when you need it, things can also go wrong.

When every new hire slows the team down for months because there is no onboarding process, that is a failure due to lack of structure. When people regularly leave the company because they have no path to advancement or career growth, that is a failure due to lack of structure. The third time you have a production outage because someone logged directly into the database and accidentally dropped a critical table, that is a failure due to lack of structure. I said earlier that I prefer to talk about learning and transparency rather than using the word structure, because really what we’re talking about here is identifying the causes of failures, especially frequent failures, and trying to figure out what we can change to solve for those failures. This is fundamentally about learning.