Starting a web infrastructure team

Introducing a new team might seem straightforward. Create a Slack channel, add your Notion team page, schedule some standups and GO...

Well, maybe it isn't always that straightforward. In the case of our new Web Infrastructure team, we had an interesting start. In some cases it was problematic (some people just don't understand what "Web Infrastructure" really even means) and in some cases it was quite awesome, there were clearly some opportunities we were previously missing that surfaced once we introduced the team.

Start with why#

So why did we even introduce this team?

Not to oversimplify it, but it really came down to numbers. As of this writing, our Engineering team has over 20 engineers working on 12 discrete web applications.

What is a discrete web application?

This is a topic for another post but for now think: separate GitHub repos, separate subdomains.

It isn't a huge team but it isn't a small team either.

But the larger driver for the introduction of this team is the rate in which these 12 applications came into existence, which was about 1.5 years. And most of them came towards the end of that period as well. In the past 3 months, we introduced 6 applications into our suite.

With that many engineers and that many applications, we would be silly not to invest in making everybody as efficient as possible.

How we started#

This part was actually easier than I expected. I raised the idea with my manager, who was also noticing something might be missing. It only took a month or two for the idea to "make the rounds" and when we did the next team shuffle, we landed on a small team allocated.

The first thing I did was to work with our Architecture team on a Strategy Summary (also known as a strat sum). This is a high level document that captures things like a problem statement, a value statement, how to win, etc. This was a good exercise to get the wheels moving. I won't share all of the output but the most helpful section for me was the "How to win", which outlined our focus areas:

• Technology Advancement
• Engineering Productivity & Ergonomics
• Quality, Performance & Security
• Team Support

I'll cover details on what each of those means another time but these were the high level boundaries we created.

If there is one thing I learned through this process, it is that boundaries are crucial.

When it got confusing#

The beginning! And I didn't even realize it. Before we even started the team, people were already confused. We actually started with a different name "Core Web", which was interpreted in many different ways. I started receiving invitations to strange meetings and through the grapevine found that my team was getting tasked with all kinds of things I didn't really even understand, most of them being product or marketing initiatives.

All of this confusion happened in parallel while I was outling the afformentioned strat sum for the team. Once I was able to get in front of the confusion, I was able to clear things up with that document (and a few painful conversations).

The 4 categories of work created enough clarity that we were able to at least establish some boundaries. We also changed the name from "Core Web" to "Web Infrastructure". "Infrastructure" is a technical enough term that it at least made it more obvious that we were dealing more with technology issues and improvements and less with product or marketing initiatives.

In a future post, I'll update with some specific activities we are working on. Do you have a similar team at your company? Want more details on what our team is doing? Find me on Twitter.