Optimize Team Output, Not Individual Output

As teams and products grow, workflows and development processes get ingrained into the team. It starts with the early employees; processes are formed around them and the way they work. When engineering teams go from small to medium and then from medium to large, old workflows can become a large issue.

Those workflows are often still optimized for the small to medium-sized team, not to mention optimized specifically for those first employees. Not everyone who joined later is properly up to speed, nor do they necessarily have the means to tackle problems that are coming up. I touched on this exact problem recently when I wrote about using cloud services to increase productivity in teams.

The issues with out-of-date workflows reach beyond engineering to impact marketing and sales as well. For example, it may take the marketing team a while to release content updates to the landing page because the process for releasing updates is optimized for the engineering team. Marketing and sales will constantly have to go through the engineering team to get updates shipped.

Over time, systems and processes need to be developed that don’t solely optimize for engineering output as marketing and sales become important drivers of the whole business.

Check the power to do anything

In the early days of building your product, developers typically have the power to do anything as long as they get the product shipped. They can log into any machine, look into any issue, they know where all the config or log files are, which metrics are tracked, and which code is used where. Mostly because they put all of it in place.

But when the team grows past a certain point, the individual power of one developer needs to be limited to set incentives in order to improve the workflow and power of the team as a whole.

When the entirety of your company’s architecture, metrics, config files, and documentation is in the heads of your earliest employees, there is little incentive to build a structure to make it easy to share that knowledge. Not maliciously, but they can get their job done so why would they push for a lot of changes to how the team is run. As a result, your growing team won’t be as effective as it needs to be. The knowledge won’t spread through the company, and tools won’t be built or updated to accommodate everyone on the team. That’s especially hard for new employees -- it takes them a lot longer to learn all the details they need to know.

Optimizing your team’s workflow isn’t just about making sure everyone in your team is effective. It’s also about making sure you’re able to fix future issues effectively. As an application gets larger, there will come a point when people who were able to debug everything in the beginning can’t do it anymore. The system will have become too complex to know every part and recognizing that while debugging a large system issue is a major problem.

Plan for this transition before scaling your team. Implementing a few first steps now will drastically improve your success later. Get your metrics and logging in place and set incentives for your development team to build an infrastructure that scales without your intervention. I laid out more examples of first steps like these in a recent blogpost on the AWS Startup Blog

Team growth has an undeniable effect on the power of the individual developer, which can be difficult and frustrating for some team members. In many fast-growing startups, early engineers leave as the company’s environment changes into something very different from what they were accustomed to in the past.

Dealing with frustration

During this time of transition, it’s important that those early engineers understand and fully support the company’s new needs. They may be frustrated with the changes -- they may be working on a much smaller part than they have in the past, and now there’s more process involved.

These problems need to be very openly discussed in the engineering team and individually with those engineers. This team has brought the company to its early successes and given it the chance to grow in the first place. These people are an extremely important part of your company’s long-term success. It’s critical that you make sure this transition is smooth and successful for those engineers so they can happily settle into their changed roles.

It’s also really important to give those early engineers the ability to influence the future of processes and workflows. They still need to feel they are in control over how the team is going to work in the future. Otherwise frustration will take over, and you’ll lose some of the longest-serving people on your team.

In other words, a large chunk of the knowledge about your infrastructure and processes could leave the company. Especially during high growth periods in your team, this would be disastrous.

Conclusions

Making sure that your processes, workflows, tooling, and team are ready to scale is important and painful at the same time. You’ll need to remove strategies that the team has successfully used up till now, and you’ll have to make sure that everyone will be comfortable and productive in the long term.

Make sure that you analyze your development and operations workflows constantly, especially before actively growing your team. If you have to collect the necessary knowledge to onboard new people while hiring them, you won’t be able to utilize them efficiently right away.

Your company’s workflows and tools need to be easily teachable by anyone on the team. If you leave all of the onboarding to your early engineers, you’ll run into bottlenecks. Relying on them to onboard every new engineer (because they’re the only ones who know your systems) will take time away from actually running the system. You need to break out of this cycle as early as possible.

This can’t be taken lightly and shouldn’t be handled carelessly. Understand the frustration that your team and early developers are going through. Work with them to build a successful and productive team for the future.

Let us know in the comments about the strategies you’ve used in the past to successfully grow and transition a team.