What an ideal engineering team looks like

Let's jump right in.

What does an ideal team look like? What would your experience be on that team?

• Teamwork
  • Your blockers are unblocked quickly
  • You see that most Slack messages are responded to fairly quickly, especially questions that are blockers
  • You see team members thinking about each other in sprint planning, offering to help, sharing the load, offering to pair up, and suggesting ad hoc meetings or Slack discussions inclusive to those interested
  • You see team members soliciting feedback on their ideas and consulting with other members or teams
• Camaraderie
  • You feel uplifted by your coworkers
  • You are happy to sign in to Slack and chat
  • You wouldn't mind meeting up
  • You know you're supported and any conflict won't break the bonds
  • You're given thanks and shoutouts from both leadership and team members
• Growth
  • You have the opportunity to lead projects and take on challenges
  • You realize your coworkers are there to see you grow and succeed with them
  • You have an understanding of what others' goals are, and how you can help
  • You have leaders and mentors that are coaching and cheering you on
• Diversity
  • You feel appreciated for your unique strengths and differences
  • You have skills that others don't have, inside or outside the job description
  • You see the team discussing inclusivity and explicit awareness of any biases
  • You see team demographics align with what the industry averages are in the regions you are hiring
  • You see team members acknowledging interviewee strengths outside their own skillset

I hope many of you reading this are employed on teams that fit these characteristics.

I'm sure no team fits all of the criteria, and there's always room for improvement.

Let's talk about how to form and build these teams.

Hiring the right team composition

Many hiring managers hire in a vacuum.

Or at least I did when I started years ago.

When hiring, make sure to consider:

• Ideal team size (balancing having the right capacity and diverse skillsets, while not having too much communication and coordination overhead)
• Embedded resources (Product Manager (PM), Designer, Technical Writer, Data Engineer, QA, etc)
• Existing strengths and weaknesses (hiring people with complementary strengths)
• Missing skillsets on the team
• Mixing generalists and specialists (having both deep knowledge in the team, and flexibility if capacity needs to shift)
• Aspirations of existing team members (make sure you don't have too many competing over limited roles)
• Having at least 2 people interested in each responsibility of the team (avoid silos or having neglected areas due to disinterest)
• Evaluating on virtues/values of the team and company (company culture matters)
• How each individual will make the team a net positive (energize each other, support each other, inspire each other; don't drag each other down or create conflict)

That's a lot to consider!

Many new hiring managers only look for "can this person do the job?" ("can this person code")? That's a big miss and can lead to conflict, misalignment, unhealthy competition, and more.

Many new hiring managers try to aim for "top talent", not considering these aspects or whether the person will enjoy the job or be overqualified, or uninterested.

I'll give some advice on where to get started with hiring as a team at the bottom of this post.

Diverse skillsets/backgrounds

Many of the holy wars of team composition are misguided:

• Generalist versus Specialist
• Fullstack versus Frontend/Backend Engineers
• Platformy, technical Engineers versus Designy, Product-minded

Why not both?

A team is only as good as the sum of its parts, which includes having complementary skillsets.

If you have a duplication of strengths, interests, and skillsets, each duplication has diminishing returns. It helps in the "bus factor", but it leads to groupthink, competing interests, lack of opportunities per person, and missing skillsets on the team.

Where EMs/Directors should focus

Engineering Managers can start by answering the "bus factor" question:

If I was hit by a bus, how would the team differ from the ideal team?

The ideal team can run without you.

That doesn't make the Engineering Manager useless at that point, mind you.

Engineering Managers are involved in many meetings, for example, that Individual Contributors (ICs) aren't in. Make sure you are leading by context, distilling that information without overloading the team with meetings similarly.

Engineering Managers should also act as glue and connectors. There will always be some conflict, communication gaps, delegation and role assignment, roadmap steering, distilling of company strategy, representation of non-attendees and stakeholders, and more.

You will never be useless.

Unless you don't put building your team first.

How to Direct an Ideal Team

A quick note for Directors.

You are still accountable for the needs above, across your teams. Macromanage, but don't be absent. Allow autonomy, but do give guidance and context.

You should make an appearance with your teams. You can be selective as to what teams need your support the most. But don't confuse autonomy and empowerment thinking that you need to fully disconnect and not be involved.

There are strategies to still being present as a Director. You can declare that it is the Engineering Manager's call. Say you are going to be a "fly on the wall", or "here for questions". Ask questions, rather than telling people what to do. Use phrases like "it's just a thought", letting people know it's not a command.

Your Engineering Managers should be responsible for acting on most issues, with you as coach and guide. But it's hard to really be effective if you aren't around to observe from time to time.

Psychological Safety

No team is going to meet all of the ideal team criteria without Psychological Safety.

It's unfortunate that the phrase "psychological safety" isn't universal; I've spoken with people in coffee chats that were unfamiliar.

Psychological Safety is the concept that you are free to be yourself and speak as you wish and believe you should on a team, as long as it isn't at the expense of the team.

It does take the active effort of a team to reach the feeling of safety.

It takes work. Hiring the right people that fit values (like Humility and Open Collaboration at Docker) is a start. But even with the right team members, the team won't be fully formed and gelled on day 1. It takes relationship-building, practice in working as a team, and familiarity with each other to reach the potential safety level those individuals could feel.

Even with the right team and experience, it is a constant battle in realizing biases and effects.

I'll leave this section with a hint:

Looking for unsolicited demonstrations of empathy while hiring can go along way to ensure the team naturally achieves psychological safety without much effort on the manager's part.

Flow of communication

Communication looks like a spider's web. Not an organization chart.

Or, at least it should.

Because that's how the real world works: the dispersion of knowledge and skill has some hierarchy and organization, but some are also semi-randomly distributed across teams.

And because hierarchy also doesn't scale. (See: Team of Teams by General Stanley McChrystal).

(graphics from https://readingraphics.com/book-summary-team-of-teams/)

how does the ideal team interface with other people or teams, is it best to delegate that to someone who's good at translation or should everyone play a role

Everyone should play a role.

An Engineering Manager (EM) should establish Points of Contact (POCs) / Subject Matter Experts (SMEs) / Tech Leads / Project Leads.

These people should play primary roles in different areas of the team's responsibilities, along with the EM, PM, Designer, and other non-engineer roles.

The Engineering Manager should act more as a conductor, orchestrator, and facilitator. The EM can be who external teams reach out to when they don't know who the internal POC should be. The EM can direct the.

But the EM shouldn't act as the only point of contact on a team, or expect to be the decider and expert in all areas. The EM can't know it all, do it all, or be everywhere. The EM won't always be available for all meetings.

It won't be possible in most environments to do it all, and the EM will also be too removed from code and architecture at times to be the best to answer certain questions. And in those cases, EMs and PMs shouldn't be playing telephone.

These are also opportunities for engineers to grow to Staff+ levels and demonstrate and grow leadership skills.

However, do keep the pulse on engineers' aspirations, happiness, workload, and capacity.

It's best to not overly shield and disconnect a team from stakeholders, customers, and the business.

It's good to discuss how it's going in 1 on 1s, keep an eye on calendars, and give friendly nudges to external teams when the engineers are getting overloaded.

It's also good to look at scalable processes and artifacts, like having shared office hours, ticketing systems, and creating team FAQs for scaling and self-servicing needs.

Scaling ideal teams

This can be a large blog post or more on its own.

I'll keep it short.

The ideal team will constantly be in flux. This doubles or more as you are hiring, especially if you don't hire well.

Your work isn't over when you've hired the right team and built relationships.

Every team member added is going to shift the dynamic for better or worse.

In The Culture Code by Daniel Coyle, he speaks about studies where even just one individual is enough to throw off everyone else (a jerk or a slacker, for example).

Expect to revisit old discussions, and periodically do team-building (support socializing, help in conflict resolution, connect individuals to support each other).

How to identify the right teams

If you're looking for a job, revisit the ideal team criteria at the top of this post.

Ask questions that reveal how far off the team is from the ideal:

• Teamwork
  • How does the team collaborate?
  • How do team members support each other?
• Camaraderie
  • How does the team socialize?
  • When might the team discuss continuous growth?
  • What are examples of where team members have gone out of their way for each other?
• Growth
  • How do team members support each others' growth and career aspirations?
  • How does the Engineering Manager coach or guide team members in their careers?
  • What programs does the company provide to help the growth of the team?
• Diversity
  • Can you tell me about the different team members?
  • What skillsets might the team lack?
  • How do you as a hiring manager determine what team members would best fit with the existing team?

How you can push your team in the right direction

Look back at the start of this post. Where does your team fall short?

If you're building a new team, start with hiring.

At Docker, I've taken my teams through a "Hiring Criteria" exercise:

• Draw one circle, that's your core. Primary requirements, like can an engineer code. Items closer to the center are the biggest requirements
• Draw 3 boxes:
  • Domain
  • Strengths and Interests
  • Missing Strengths and Interests

We also realized we were lacking diversity on the team, in many ways.

For example, we were an average of 15 years of experience, which made interviewing juniors difficult. And we were slanted toward technical/platform engineers.

Having these discussions has helped change our discussions and appreciate diversity in team composition as we've scaled and hired 13 engineers on my teams so far this year.

Post-hiring, similar conversations, and retrospectives can go a long way towards meeting the ideas.

You might even want to have a retrospective on where you as a team are further off of the criteria I listed at the start or other criteria your team holds as ideals.

Further reading

The cover photo was inspired by this Atlassian post, which is a great article to read in itself:

https://www.atlassian.com/blog/technology/engineering-team-structure

Have anything to add?

Leave a comment! I'd love to hear from you.

You can also discuss these topics on our Practically Leading Discord: https://discord.gg/ghdjvEZfDM

And feel free to DM on Twitter: https://twitter.com/ShawnAxsom

Thanks for reading and sharing!