The First Critical Steps Toward Scaling Your Software Organization

I’ve noticed a pattern I want to share with you guys.

When a company is small, still probably led by it’s founder, likely around 20-40 people… there is a great sense of camaraderie. You’ve got folks that all know each other, all working toward a common goal, all trying to solve the same problems. To a large extent folks are willing to work across role boundaries and do whatever it takes to get the work done. The code is new and fresh, we probably haven’t accumulated a bunch of technical debt. We are able to move fast and get stuff done.

As the company finds success and starts to grow, they begin adding more people to the team. Often, as they add more people, things become less clear, people aren’t always as connected to the core purpose of the organization, communication slows down… and because it just seems to be the way things are done… they decide people need a manager. They inevitably hire a manager for the developers, a manager for the quality folks, and a manager for the business analysts.

I think it’s human nature that we have a tendency to optimize around the stuff we are responsible for delivering. Back in the early days, everyone was responsible for delivering the product, but the product got too big. Now, as a dev manager, I am responsible for delivering great code. As the QA manager, I am responsible for delivering great test plans and test execution and finding defects. As the BA manager, I am responsible for making sure we have the best requirements.

Somehow as we grew, we forgot to make someone responsible for the product.

To remedy this situation, we begin hiring project managers. In theory, if the functional managers are responsible for optimizing their function, the project manager will be responsible for optimizing the delivery of the project. But now we have a matrixed organization, and people are rarely inclined to make the project side the strong side of the matrix. The functional manager is still largely in charge of the work, with the project manager relegated to performing a support function for the project.

If the project manager is really good, they will build relationships, and work with the management team to help get work done. They will help keep track of stuff and make sure work is progressing. That said, they still don’t have any power on the project, just influence. If they aren’t particularly good, you get folks running around asking for estimates, building Gantt charts, filling out project documentation, and providing meaningless status reports.

They become the checklist managers on the project and get in everyone’s way.

In order for this system to work, we have to slow down the speed of the game. We have to be really clear on all our requirements up front. We have to make sure we are providing great estimates. We have to make sure we know who is going to do the work before the work is even approved. In reality, we find that more often than not, we don’t know the requirements up front, we don’t have very good mechanisms for estimating, and we don’t know who is going to do the work.

If we are operating in a market where, at least to some extent, the requirements need to emerge… we need to experiment with new technology… we need to have some room to inspect and adapt… this is going to be VERY, VERY frustrating for the project manager. Think about the incongruence. Think about all the things that would have to go right for the project manager to even have a shot at getting the plan somewhat close to realistic. Think about all the other projects the functional team might be working on across the matrix that would have to go right too, all of which are beyond the project managers control.

Honestly… in most of the software product development and IT organizations we work in… this is a recipe for failure. If you are able to slow down the game enough to do good project management… you lose. If you don’t manage your schedule, cost, and scope… you are out of control and you lose. Think about all the variables at play that have to be managed. Think about your actual ability to get them right. Think about the time and money necessary to get them right.

I don’t think you have the ability, the time, or the money to get them right.

Okay, so what do we do?

I think we need to go back to the beginning, to look back on how we started, to look for ways to organize around small cross-functional units that have all the people and skills necessary to deliver the product. We need to make sure the unit has a clear vision around what to build and autonomy around how to build it. This means that we need to stop organizing around what we do and start to organize around what we build. Instead of organizing around what we do, organize around the value we produce.

Agilists tend to understand this, but the advice is always to organize around end-user value. The advice is to organize around the product or the feature set. The challenge is that some products are just too big and complicated. They are built on legacy architectures. They are serving multiple internal and external customers. They don’t have sufficient safety in the code base. They aren’t instrumented with tests and we don’t have the infrastructure necessary to do continuous integration or continuous deployment.

I think about the problem similar to what we face when we take a tightly coupled legacy system and refactor it into a services oriented architecture. The service is the value. The team is the group of folks that deliver the service. The service has to operate behind a contract. The contract has to be maintained and validated with tests. We need to break dependencies between services. Over time we need to change how we invest in projects, and products, and the platform.

In effect the service over time becomes the product.

How you do all this is a topic for a different blog post… but this is the problem that our company is focused on solving. It’s interesting, the patterns are understood both at the team level and at scale… it’s the organizational change management that is the hard part to solve. How do you get people to understand it, then how do you get them to do it? How do you get them to see the nature of the problem and get them to work together to fix it?

Anyway… getting back to the point of the blog post.

I think there is one critical organizational mistake that companies make when they first begin to scale. They scale around functional area. When things get hard, they hire project managers to make it better. For project managers to be successful, they have to slow the game down such that the projects can be managed. Work starts moving slower, so we pack more things into the pipeline, hire more project managers to manage the work, and basically grind everything to a halt.

Here is the pattern I’ve seen at least 5 times in the last year or so… company is great until about 40, functional until about 150 but struggling… company grinds to a halt at 400.

The answer is to make decisions when you’re small that allow you to scale around the value you provide rather than the activity you do.

If you’ve already organized around the activity you do, you have to refactor your organization around the products and services you provide.

In my opinion, it’s the only way.

In a fast moving product delivery company… I can’t see anyway to be fast, responsive to change, and able to scale… if you choose to organize around function and rely on project managers to stitch together the value. It’s not the project managers fault. It’s an impossible problem for them to solve. We can talk about where project managers and project management fit… and I do believe there is a valuable role for them, but… in this context, it just doesn’t work.

Any examples to the contrary?