Search for a command to run...
Envisioning and nurturing ideal team composition and teamwork, as enacted by the Director of Engineering at Docker
Director of Engineering @Docker
⌇ Leadership • JavaScript • Kindnessship ⌇ DMs open, here to help ⌇ Follow for tips + news + a friend 🚶
https://twitter.com/shawnaxsom
I'm glad that I read this article, I didn't knew that people think about this topic so deeply. I really like working with people who actually do help out their juniors instead of looking them as competition, and treating them with hostility.
They often forget that they were juniors once as well, and didn't know a lot of the things which they learned later.
Thanks for this wonderful article, Shawn.
This is absolutely amazing, I love the idea of sharing from the experience background. I appreciate providing this wisdom Shawn Axsom
Thanks Ali! 🙏
Loved the article! Thanks for sharing!
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
I thought a lot about this lately. That's why we started (Remote) Mob Programming sessions a couple of weeks ago. I love the way the devs participate. It just feels good to work this way! I think this activity leverages some of the things you mentioned, like Teamwork, Camaraderie and Growth. Also, feedback was great so far :D
That sounds nice. So like paired programming, but more than 2 people?
Are you going to write a blog post about it? Do share 🙂
Correct! We are 7.
I might write something in the near future. I'll let you know for sure :)
A very detailed write-up. Thanks for sharing. I like the hiring criteria you have at Docker - it provides a great insight into the team member.
Just curious - Do you share the individual response across the team once hired so the team can benefit from the knowledge? Personally, I tend to find out the pitfalls of one’s strength as well. This helps to ensure that an individual’s strength is not detrimental to the team’s success.
Hey Narmada Nannaka!
Nope, we keep the information shared about the candidate confidential to the hiring panel.
The hiring manager is usually the direct manager of the individual, and the manager will therefore have the knowledge of the strengths/weaknesses (along with aspirations, ideal work environment, etc that I often ask about), and some of that may carry over to employment.
Great write-up Shawn. Definitely like your points in relation to generalist vs specialist "Why not both?"
It's important to have a team of varied strengths.
Yeah!
Fullstack vs Frontend/Backend is a great example.
It's nice to have a mix of deep knowledge, along with others that are flexible when frontend/backend ebbs and flows.
Fullstack engineers can be great for throwing together POCs, unpacking tightly coupled UIs with APIs, etc.
Frontend or Backend can have much deeper experience in their domains and in areas like design, accessibility, or devops, infra, cloud.
Teams with both can work well for most teams.
And for specialists, it can be good to have a more technical Frontend Engineer, a more designer-focused Frontend Engineer, etc. Specialization doesn't stop at Frontend versus Fullstack.
Thanks, Eleftheria Batsou!
I appreciate your feedback, as always 💛
This is something I am unfamiliar with. As I have never worked in a software team. But it helps me set a point of reference for my expectations. Thanks Shawn
I am curious on how would you handle groupthink, in cases where it may be damaging to the output of the team? I ask because of the emphasis you put on diversity and psychological safety, so I think you value honest opinions from team members 😅
Great topic.
Diversity and psychological safety help prevent groupthink.
Diversity helps bring diverse viewpoints.
Psychological safety helps make sure those individuals feel safe to share their viewpoints, rather than going with the group.
Other aspects for avoiding groupthink include anchoring.
In the book "Leadership is Language" IIRC (or some recent book I read 😅), it discussed if you're the leader, don't be the first to speak up, or you anchor the conversation, reducing variability of follow-up ideas more so than other people due to appealing to peoples' bias towards authority.
“A team is only as good as the sum of its parts, which includes having complementary skillsets.”
I absolutely love this quote. Shawn’s process from hiring teams to scaling them is masterclass. 💯
Aw thanks 💛
It's something I don't hear a lot of from hiring managers and recruiters.
People are overly focused on the individual, and finding "top talent".
Versus focusing on the team, and finding "top fit".
You can change quickly, in ways you never thought possible - the approach I used
Understanding the profession, and whether it's the right path for you
The State of Affairs of Engineering Management Engineering Management is ripe for growth as a craft. After a decade of leadership, I've felt mostly alone. For such a people-focused profession, it's a surprise that I see more community engagement from...
My Inspirations Now as a Director of Engineering at Docker, I’ve been doing some type of engineering leadership for the last decade. I have learned from the best over the years, and many resources have shaped who I am and philosophies for how I lead....
Let's jump right in.
What does an ideal team look like? What would your experience be on that team?
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.
Many hiring managers hire in a vacuum.
Or at least I did when I started years ago.
When hiring, make sure to consider:
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.
Many of the holy wars of team composition are misguided:
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.
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.
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.
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.
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.
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).
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:
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:
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.
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
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!