I already looked this up for the article, so let me quote Wikipedia to save you the search: “Brooks's law is an observation about software project management according to which ‘adding human resources to a late software project makes it later.’ It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.”
In a Solution as a Service (SaaS) company, we struggle with that simplistic principle at all times. Since every project will add value to our main service, our ultimate goal is not to finish up a single project, but finishing as many projects as fast as possible, and all of them are part of our big solution. So, as a general rule, every new Avaturian who joins engineering will go into a team that is on the late stages of at least one project. That will have a negative impact in the short term, even while we work to minimize it, because bringing in a new member will necessarily add complexity to the team.
The first issue that comes to mind when reviewing this is the onboarding process: when new members go through training designed to make them catch up with the company's way of doing things as fast as possible. This allows them to start adding value right away. In SaaS, most people have to learn the same trades because most people work aligned towards the same goal. But once enough people join the company, the need to scale arises. This results in new teams being created and, with them, a whole new set of interactions: up to one new interaction per existing team! But let’s hope they don’t interact with everyone else.
Our goal as Engineering Project Managers is to constantly find ways for the company to become more efficient while it naturally becomes more complex. Software architecture principles are based on the same topics: good software architecture will allow developers to experience their coding as easier while the project grows, making productivity go up. This is achieved by moving talented people from the task of satisfying the clients, to the task of enabling their co-workers. As the company grows, there will be more members coding, and this makes enabling their job more valuable.
How can we get more people to be individually more productive when dividing their tasks gets harder? Well, if there was a simple answer, we'd be out of work. In a way, our job consists of constantly trying to eliminate our involvement, empowering the teams' autonomy. We set up processes, automate interactions, identify bottlenecks, plan and communicate projects... Anything we can do to allow people to become teams and teams to become areas while still being able to work with all the information and freedom that the initial person had.
Let's take a simple example that most companies would go through. Setting up processes: is emailing someone to get a reply as easy as loading a ticket with a structured form? Definitely not, but will a team reply better to a high output of emails, or tickets? At enough volume, tickets will get the prize. This is a trade-off we need to consider.
There is a cost to pay and we must evaluate who will need to pay it. If we step away from the problem, at enough distance, we will realize that it is always the company as a whole paying this cost, as inefficiency affects everyone indirectly. But on a smaller scale, it’s got to be either the requesting or the operating team. How can we decide which will pay? Here are a few example factors to take into consideration:
- Resources in each team
- The current bottleneck
- Possible future bottlenecks
- The need to implement a fast vs a good solution (hopefully we can achieve both!)
- The re-work that will be needed to migrate and the change management involved
Considering these factors, among those specific to the task at hand, requires a lot of collaboration with the involved teams. There is very little chance of achieving good results without understanding the context, and the people who best understand it are the ones in those teams. They are the ones most in contact with it, and either them or your metrics were the reasons that the issue was raised.
So, what do we do? Do we prioritize the ease of allowing requests by email? Do we provide a customized structure to request actions for each team? Usually neither: we need our freedom and we need some structure.
Instead, we figure out what the most common requests are, in an extremely non-scientific way, as they are still not categorized. Then, we set up a process to make those requests and design possible outputs for them. Requesting teams will need to go through a little more bureaucracy to ask for what they need, but they will get it sooner.
We are always looking for these win-win scenarios. And they exist on many levels, not only when relating teams, but also the people within them, especially with teams that have an inner structure, or whole areas, preventing issues from escalating to senior management, which is seldom the most efficient route for communication.
This sometimes ends up looking like a race between increasing complexity vs adding sufficient structure to keep things manageable without stifling adaptability, with the hope that the added structure results in an easier, better way to achieve stuff.
We should keep in mind that if we feel like we are in a race, it’s probably because we are losing. We strive to achieve an ideal scenario, where we work on the issues that we are going to have, but have not yet materialized. The ones that future growth will bring us, to minimize the impact of Brook's Law before it hits.