How to align engineering teams

One of the ways I love to learn from friends and mentors is to compare the problems we’re solving. One such example is this unresolved issue: How do you get multiple different teams, working in isolation, to align? How do you resolve the incorrect assumptions about the details of what the others are building? Once on track, how do you keep on track?

It sounds a lot like a remote work or international team problem that has been-solved by many tools. Or it could be a problem of structure, inadequate role management for key aspects of software delivery. Maybe it’s unclear development management, unclear requirements, inadequate epic, story writing, sprint planning, and backlog grooming. All of these implementation-level aspects of dev are absolutely vital, but that’s not really where the question is coming from. In this case, all of those pieces are in place. Every best practice and best tool and best person is in situ. This question comes from an elite company and is voiced by a highly skilled, switched-on, and personally engaging development director. When you have all of the process and tools in place, and everyone on the team is great talent, how do you get everyone pulling together consistently?

It’s easier to solve the implementation-level problems. Don’t get sucked into the process and technology as the solution. Yes, you’ll create or rejigger process, you may adopt new tools or change the ways you use them, but the question of how to get everyone pulling together is about the people. And it’s not about motivation or engagement—you’ve already got that. How do you draw elite teammates into an elite team? How do you deliver together? How do you keep carving out the space ahead of you?

Purpose.

Your teams must share a purpose. Not a mission statement, not a set of goals, not even a software product, a purpose. You might have those other things, certainly at minimum a software product, but your purpose must needs be first and last.

Your individual contributors and managers each need to have their own purpose that relates to that shared purpose. Necessarily, the higher level team’s purpose must be closely related to the business, but there is such diversity of individual purpose in what a team achieves. For example, my individual purpose is to make engineering organizations great. That’s a tight fit with my company’s make the world of work work better for people and is also narrowed to my individual scope. It’s measurable, but it’s also always just out of reach—the work will never be done. That’s a good purpose for me to work with.

I make my engineering organization great by how I work in it every day. Tactical examples: Was this a great engineering meeting? Are people smiling and relaxed? Do we have all of the design decisions and artifacts we need to move forward with building a great fit-to-need automation? Did everyone have their technical concerns addressed fairly? Does the priority and resourcing match the business needs? Upon seeing it, will our users be satisfied? Upon completion, will this reduce or at least minimally impact our operating technical debt? Does the work offer opportunity for its contributors to grow and shine? (I don’t get to ask this last one because I don’t directly manage developers, but I think about it every time I see an enthusiastic developer present solution design.)

How do you build purpose for multiple independent technical teams? This may require a fair amount of reflection among the leaders and members, and that’s where strategic purpose comes into play. Most tech companies operate on short horizons (2-3 quarters, 2-3 years), so that can be a small area to solve purpose for. Think about: what do you build, who is it for, what does it do for the customer, and how do you envision its growth beyond the coming horizon? Frame it in bold language, use all caps if it helps, and put it out there with intention of accepting edits and reframes.

Work with your team, individually and as a group, on framing their individual purpose. What’s their part? What calls to them? Where is there heart in it? What resonates at a gut level? Where do they personally want to stake a claim for glory or mastery? If this is the greatest work of their career, what do they want to name as their legacy? Ask: When other developers work on your code, how do you want them to imagine you? How do you want your contributions to be remembered?

How to do it? Assign some points to everyone’s sprint for homework and the meeting. Workshop it with your team via the Lean Coffee method. Ask a lot of open-ended questions and build consensus. Ask about what’s not working with the isolated teams and solicit ideas about building bridges that reflect the shared purpose. Add questions to your retrospective to assess whether the material work and the process continues to support the purpose. Do a scrum-of-scrums with your multiple teams to reassess planned work in light of the purpose. Purpose-driven teams become self-aligning so long as the purpose is clear and consistently tracked.

Once your team, teammates, managers, directors and VP are all tracking on an alignment of purpose, then the process and tools are much more capable of supporting the work you need to do. Purpose is not enough, however tools are also not enough and process alone is like standing in line at the DMV all day. You need all three, but always remember process and tools are there to support the purpose.