I have worked in multiple startups and dabbled in venture capital, I’ve seen my fair share of engineering teams at the growth stage. If those companies built the right product at the right time, their engineering teams scale, and quickly.

Sometimes, we get to see these small scrappy teams composed of engineering generalists mature into well structured specialized teams, with well-functioning processes and automation. But what happens in between? Why is there always pain? And if the only universal truth about DevOps is that it’s hard to implement at maturity, why not do it earlier?



The “Let’s Keep It Simple” Small Team

Working in a small team, on a new product, is one of the most energizing experiences. If you have been fortunate enough to have worked in one, you can practically feel the mood. The energy is infectious. Everyone on the team is close-knit, pulling together on projects and releasing quickly and often. Issues pop up often but everyone rallies to solve them efficiently.

Small teams are masters at triage with the superpower of being able to solve any problem that comes their way.

There is usually at least one go-to developer who has the full context of the product and technology. These lynchpin devs are easy to reach and can provide a quick stamp of approval. In fact, communicating with your team is as frictionless as calling a desk over (or if you’re in a pandemic, messaging on Slack from a safe distance).

There is absolutely no need to implement world-class DevOps for your team of 10. Spending valuable time on unnecessary structure could mean you miss out on your market opportunities.

DevOpportunities

  1. Chaos never lasts. The best thing you can do at this stage is to be aware that this chaotic bliss will not last forever. This will and should change quickly and nothing should be set in stone.
  2. Think about tomorrow. I’m a big believer in building things not to scale but it’s also prudent to keep tabs on what the future state of DevOps would look like when things scale. Even if you believe scalability isn’t an issue now or in the medium term, always ensure you account for maintainability.
  3. Keep it simple, stupid. If you are keen on implementing DevOps tools, adopt them in small units which are low cost and can be assembled later into a larger DevOps plan. Whatever you adopt needs to be easy to operate, simple to understand, and able to be removed or changed if needed.

The “Things Are Happening Fast” Growth Team


The business is going well and feature requests are coming in. What happens next? The business will necessitate the engineering team to grow. When the team starts to increase in size, communication will break down.

This isn’t necessarily an inefficiency problem, it’s human nature. It’s difficult to keep the same professional relationship with your team of 30 engineers as it was when you were eight. To compound this issue, the team will still be putting out fires constantly. Even if everyone on the team has the same willingness to jump in, it is increasingly likely most will no longer have the context to do so.

Expect more stress to be put on the CTO as it becomes more apparent they are the last remaining soul on the team with the institutional knowledge to solve problems. As a result, they will spend less time being the forward-looking chief technologist in favor of solving the problems of today.

DevOpportunities

At this point it’s important to recognize what worked in the past will no longer be sufficient. Adaptability is going to be a core tenet of success, and simplifying processes and practice is a prerequisite to being adaptable.  It is probably not a good use of time to implement a ‘Spotify Model’ of DevOps but that doesn’t mean small steps can’t be taken to ease the transition. It’s important to remember that DevOps is going to be a journey. Being able to accurately measure what is helping your team is just as important as immediate efficiency gains.

Potential solutions include:

  1. Implement Lean Delivery Metrics. I said lean! you don’t need an entire dashboard of metrics (this can actually be detrimental). Identify the bottlenecks specific to your team and use metrics to monitor those key points.
  2. Increase transparency. Increase release/delivery transparency as well as more transparency on decision making. This will increase the likelihood of discovering issues quicker and bring more innovative ideas to the forefront.
  3. Build Communication. Be intentional about creating structured communication and create a pathway for team members to call out errors and voice important information
  4. Definite Roles. Be as clear as possible about defining roles and responsibilities across your team.

The “We Need it All” Mature Team


Successful teams will still grow at a rapid pace. There are many uncontrollable business and market variables (let’s call them IRL environment variables) which drastically impact the structure of the engineering teams. The industry competitiveness or sudden product popularity might necessitate changes that impact a team dynamic.

It’s inevitable that changes required in engineering will be reactionary to what the company needs at that moment. Team leads emerge, PMs are hired, technologies are implemented which all represent the best short term solution with less than ideal foresight in future structure. I see this as a new era of specialization for the team and provides some momentary relief to the growth chaos (or a maybe a shift to a different type of chaos) as responsibilities become more defined.

Without careful monitoring, a culture will erode from “I know what my job is” over to “that’s not my job.” At the surface, it seems like a semantic change but if we double click on that culture shift it can have monumental impacts. Siloed units within teams will emerge and communication will break down further.

A bad engineering culture with the absence of any DevOps is the worst-case scenario for any software engineer, and the consequences for companies go far beyond losing top talent. When releases are slow, bugs persist and new features don’t get into the hands of users, the engineering team becomes a threat to the business instead of the source of value creation.

DevOpportunities

  1. Avoid it all together. This is the stage we find our stereotypical engineering team in shambles. They finally realize they have fallen behind the industry and have to embark on a long painful journey to implement DevOps.The best thing to do is to not get to this point.
  2. Chip away at it. Mitigation is key, always keep foresight on future DevOps needs as your team grows. However, if you do find yourself in the position of a deteriorating engineering culture and don’t have the benefit of a time machine, the best thing you can do is start. How do you climb a mountain? One step at a time.
  3. Keep at it. Implementing (and committing to) standard processes is a small step but over time processes become practice and practice becomes culture.


There are some key milestones your team will cross as a business grows. These points in time will provide a loose indication that changes to the DevOps process are required. However, it’s important to keep in mind that no two teams are alike and what works from some won’t work for all. There is no magic bullet solution that will make DevOps simple for all teams, if it was, everyone would already be doing it.

The most important thing we can do is be diligent and constantly revisit what best practices mean for your team. That means making some tough decisions. If you come across a tool or process which helped tremendously in the past that no longer works. Stop. Breathe. And have no fear in removing elements that are no longer useful. Your future self with thank you.