11 KiB
Is your team a "glue team?"
Glue teams help keep an organization running smoothly. Here's how to
help them do their best work and avoid burnout.
In his book How to Win, New York Times senior economic correspondent Neil Irwin championed the role of "glue people" in bringing about better alignment, collaboration, and organizational maturity. "There is particular value in being a 'glue person,'" Irwin writes, "someone who understands how their specialty fits together with other types of technical expertise, who can ensure that teams containing people with diverse skills can work together to create something greater than the sum of its parts."
In many organizations, "glue people" are identified by their roles—product managers, team leads, program manager, project manager, agile coach, business systems analyst. They're people like me—an agile program manager who's been developing cross-team and cross-organizational initiatives for the past seven years at large- and medium-sized companies.
In one company, I served as program manager for a company-wide open source initiative—aligning 1,800 developers behind a common strategy and setting development practices. In another, I worked with three teams building out a self-service deployment platform based on Kubernetes and AWS. In these days of Coronavirus, I'm helping 14 delivery teams to launch an MVP offering that augments our core business.
The subject matter has been different in each role, but the same key activities that I bring to work every day remain consistent:
- Drive alignment
- Coordinate people, efforts, and teams
- Call out ambiguous language to drive clarity and replace assumptions with facts
- Be the neutral party or "fresh eyes" who distills detailed conversations and plans down into simple questions: "Are you doing this, or that?"; "Are you building two things or one thing?" So often, these basics go overlooked!
- Coach leaders on delegation, prioritization and strategic thinking
- Facilitate informed decision-making
- Forecast dependencies and other risks and help mitigate them
- Visualize complex packages of work in simple, clear diagrams and language to improve transparency and accountability
The glue people in your organization might also be program managers, or agile coaches, scrum masters, or engineering managers. Some organizations rely on their savviest product managers and engineering managers to provide the glue; in other organizations, the CEO doubles as Chief Glue Officer. In any case, we glue people spend much of our workdays connecting the dots between people, topics, and themes, to paint the whole picture instead of little corners.
Maybe you are a glue person. Have you ever considered the specific ways you may fulfill this role?
Understanding the need for coherent storytelling
Do you ever think of yourself as a storyteller, embracing or asserting a narrative as a means of keeping your organization aligned? If so, you're fulfilling a valuable glue-person responsibility.
Coherent storytelling essentially amounts to connecting the dots. In your average tech organization, there is lots of activity moving forward; maybe this is even documented. But does it all add up to a story anyone can follow? For example:
- Have you ever seen a roadmap that was formatted as a to-do list, and wondered how the different items corresponded to each other?
- Have you ever seen goals stated on a vision document and wondered, "we've never fulfilled that function before, and we don't have a team set up to do it anytime soon. So what are the steps between now and that team forming? How do we get there?"
- Have you or your team ever been asked to drop what you're doing right now, even though last week it was "super-urgent," and start doing this other thing right now because it's suddenly also "super-urgent?"
- Does your product roadmap look more like spinning a bunch of plates to keep different customers happy than building increments of value to serve current and future customers?
- Does your organization try to do too much, making an extreme sport out of context-switching?
I've seen all of the above. They're all pretty failsafe ways to get talented people to burn out, lose motivation, and leave your organization. These frustrated folks see their companies constantly disrupting themselves and determine that they will never get anything done. They don't know where they're headed, and no one is telling them that story in any clear, purpose-focused way. What's unfortunate is that such problems are usually not difficult to solve—the content and context are there, but no one is assembling it into the narrative or editing out the filler.
Even the most clear-headed companies struggle to permanently bake common sense fundamentals like prioritization and evidence-based decision-making into their cultures and habits. They're aware of the importance of values like focus, clarity, and prioritization. Maybe the companies even worked hard to attain them through pragmatic-sounding values statements, objective and key results (OKR) strategies, offsites, workshops, and other common tools of the transformation trade. Nevertheless, hierarchies form, and a few teams start getting left out of decisions that affect them. Politics seep in. Inertia creeps. Docs—what are docs? Decision logs—what are decision logs? Meetings get longer and more boring. Time starts to run out, and you end up at the point where you "just have to ship something." The plot gets lost.
"We used to be excellent at getting work done. The more people we add, the less we're getting done."
Some organizations lose the plot of their own story by over-reliance on oral storytelling. They hold a lot of meetings where much is said, but no one takes notes. There's no basic roadmap or vision posted; in fact, there is resistance to the idea of those things. "It takes too much time," is the usual argument. "No one will read them anyway," is another common one. Often, in these organizations, the processes they've developed rely too much on personal connections, and not enough on well-designed communication flow. Their processes are lightweight because they're nonexistent.
From time to time, I've asked colleagues, "would you rather write this down once, or have three or four meetings where you have to clarify the same point with the same people?" Usually, they decide to write it down. But the habit of oral storytelling and hallway negotiation can take time to break.
As a former reporter, it's not much of a stretch for me to view my role as that of a storyteller. Much of what I do on a daily basis is similar to when I was reporting:
- Asking people questions
- Clarifying the responses
- Challenging the responses ("but what about this?") to sharpen their meaning
- Organizing the information into stories, starting with the most important details ("the lede") first
- Constantly asking, "who is going to care about this detail?" and segmenting the content by audience
- Categorizing related types of information to form sub-themes and identify sub-narratives
When I give road-mapping workshops, I cover the 5 Ws—it feels like giving a Journalism 101 class to engineering managers and product teams:
- WHO is the customer? The team/set of teams about to do the work?
- WHAT are we doing?
- WHY are we doing it? Why are we not doing this other thing instead?
- WHEN do we start? When do we hope to finish something?
- WHERE does this effort reside in the landscape of our other efforts?
- HOW do you want to do it?
In leading these road-mapping sessions, I'm looking for a few key outcomes of success:
- A story that reflects a very strict work-in-progress limit—i.e., a primary plot, and two to three related sub-plots maximum, but no more
- Stated objectives for whatever the organization is working on that are customer-agnostic and framed in a broader context (i.e., doing X will strengthen or complement Y, in these ways)
- Metrics and data points that clearly show the impact of delivering something
One other similarity between being a "glue person" in a tech organization, and being a journalist, is that it's vital to ask tough questions, to get to the bottom of stories. This is to ensure that the "readers" of those stories—the teams, the departments, the C-level, and anyone else seeking the information—have all the clarity they need to follow the plot. Here some example questions from my real-life experience:
- To a group of 15 engineering managers who have spent an hour-long meeting prioritizing a bunch of greenfield development initiatives—"How did protecting customer data from known potential leaks end up near the bottom of your list?"
- To a head of engineering, who wanted to create dashboards so he could survey team progress—"Who needs these bug-counting dashboards; the delivery teams, or you? How does this scale? Is 'number of bugs' a reliable metric?"
- To two teams who want to build their own Kubernetes cluster when one is sufficient—"Hey, what's the value of doing that?"
A lot of what I'm suggesting depends on changing habits, which takes time. Unfortunately, you're in the middle of a global pandemic and don't have time to waste on getting the right teams and people assembled and a plan in motion. You probably don't have the bandwidth to do it all yourself.
So, don't be the sole glue person in your organization. Be one of many glue people, and help other people adapt to playing this role. It's especially crucial during a crisis.
via: https://opensource.com/open-organization/20/6/glue-team
作者：Lauri Apple 选题：lujun9972 译者：译者ID 校对：校对者ID