EM = Engineering manager
EMs = Engineering managers

Whenever they are given the opportunity, engineering managers emphasize the importance of growth and the importance of teamwork. Yet, they often forget about their development and turn their backs on the techniques they use on their teams.

The fact is that when EMs work as a team, they can get the benefits of a team. Sounds simple? Well, it isn’t straightforward.

Are we… a team?

As a team, we work as a unit, share a mission, have common goals, and be accountable for our accomplishments. Naturally, engineering managers identify their groups as teams. They have a shared mission and goals they are set to accomplish (hopefully).

Here are some signs that will allow you to figure out if you are working as a group or a team.

Signals

Some simple signals that can help you understand if you are a group.

What’s my name?
People usually refer to their fellow EMs as “The EMs group”.

Can you cover for me?
Can a fellow manager fill in for one of the EMs if they are absent?

Do we have a shared memory?
Are different teams making the same mistakes and failing on the same issue?

Do I have 1:1s with other EMs?
Is the manager the only one who facilitates communication?

Forming a team

Inside jokes

I decided to start here since most EMs completely miss it, skipping straight to the advanced part. Before you move forward, first ensure your team has some inside jokes.

Teams need shared moments, a time to create unique behaviors that will make them feel proud. Make some time for fun and discussion. A positive signal will be hearing people say, “Remember the time we…”

Each team has its style, and you can try different things until you hit the spot. Maybe it’s a fun session or a collaborative effort to resolve a critical situation. Nothing is more powerful than a good battle story to define a team.

Designing cross-team goals

The lack of a truly common goal achieved together instead of separately is a significant issue. EMs may share common goals related to engineering standards or company objectives. Nevertheless, they are often interpreted in terms of team objectives, making EMs feel they are working separately towards these goals.

Goals are a tool. Usually, they push execution excellence or align the team, but they can be much more than that. Goals set the culture and can bring people together. They can transform a group into a team.

Design cross-team goals that purposely touch multiple teams and set the expectations for EMs to work together.

Examples:

1. We aim to reduce 4-weeks customer churn: team growth and team app will work together and figure out initiatives that lead this change.

2. Under 5-min CI running time for mobile releases: The team platform and the team mobile will work together to develop a solution.

Let the EMs figure out together how to accomplish that goal and split the work between the teams. Make sure to match teams that need to improve their collaboration and keep iterating.

Matchmaking game

For EMs, there is a lot of work to build the system, and this is not day-to-day product work. Things like the hiring process or improvements to your development flow are critical for keeping the system well oiled and reducing friction.

A common practice is to split these areas between the EMs. This can be done based on individual strengths. The idea is that these are critical projects, and no mistakes can be made.

In my opinion, this is a big mistake. As with any team, people must be matched to grow each other’s skills.

Example
Carlo has never built a hiring process. Every company that he joined already had a very robust process in place. On the other hand, Natasha had experience building a few. Rather than giving Natasha ownership, it would be more appropriate to allow Carlo to conduct research and create a proposal. Then Natasha can review and mentor him to level up his skills. Win-win.

Generate a healthy friction

While it is necessary to keep everyone aligned, healthy friction is needed to produce high-quality results. EM teams must create friction and bring different perspectives to the table. If the team always agrees on every decision and minimal pushback, that’s a warning signal. In some cases, this has to be artificially created by encouraging a few EMs to be vocal about different points of view.

Example
The company is about to change the systems development life cycle. An EM that used to work in a Scrum-oriented organization has planned to adopt a similar approach. All the other EMs are perfectly fine with that, and with some minor changes, the organization is ready to change. While it appears to be a compelling example, I will argue that there is a lack of friction. There are many different models out there that might fit better for your specific culture and situation. I want to get a few more options and let 2-3 EMs debate each other until the first iteration is ready.

The team should choose the right battles depending on the level of risk. The above systems development life cycle is an excellent example of a high-risk change.

So what?

All of the above require a lot of work. There are no magic tricks when it comes to building a team. The team must put down the effort and spend the time thinking and designing the culture they would like to have.