We use teams all the time at work. When they can deliver by themselves, it’s a thing of beauty.
Too often, teams encounter big problems: it’s unclear how to collaborate with other teams to deliver the needed results; there’s still hierarchy that gets in the middle of problem-solving, and people on the team aren’t able to access the expertise across the rest of the organization.
How do we best organize the people for the work we need to accomplish?
There is no one right way to organize. That’s because people don’t work to make their teams successful first. They work to achieve autonomy, mastery, and purpose. Once they know they can satisfy themselves, the work for the betterment of the team.
First, we need to talk about personal satisfaction with work.
People work for autonomy, mastery, and purpose
Dan Pink, in his book, Drive, popularized the ideas of autonomy, mastery and purpose. He’s had plenty of company throughout the years. I recently read Under New Management: How Leading Organizations are Upending Business as Usual, by David Burkus. I’ve also read some of the agile management books, such as Joy Inc: How We Built a Workplace People Love, by Richard Sheridan.
Agile makes the ideas of autonomy, mastery, and purpose transparent to everyone. But you don’t have to be agile to use those ideas, or even to provide a fulfilling work environment.
That’s because people don't work to be agile. People work for their satisfaction. Often, autonomy, mastery, and purpose will satisfy them. Keep people satisfied at the personal level and they will provide the results you want in their team.
You might think people work for money. Money is necessary, butnot sufficient.
You can see this in action when people select among multiple job offers. They do not always take the highest one. People say things such as, “I like the team (or my boss) and I think I would fit in well there.” Or “I can learn with or from other people there.” Or “I want to do work that means something to the customers of the product.”
These answers are all about autonomy, mastery, and purpose. The autonomy is about successfully using the culture to work. The mastery is about learning. And, the purpose is about what the product means to others.
Once each person knows that their personal satisfaction is possible, they can succeed as a team. And, the teams need autonomy, mastery, and purpose to deliver.
What happens when teams need other teams to deliver the results the organization needs?
Teams need other teams to deliver results
If you’ve ever been part of a large effort to deliver a product or service, you’ve seen teams collaborating—or trying to do so—with other teams. Sometimes, it’s great. At other times it’s a disaster. What’s different?
When all of the teams coordinate, as in a program, the teams know the purpose for the product or service, assuming someone has created a program charter that shows the value to everyone.
How can you create an environment that helps people see when they have interdependencies? I like program management with rolling wave deliverables. That’s where the program product owner value team (the product manager and the product owners) say, “Here are the results we need for the program, now and for the next few weeks. We’ll update those results as we see you deliver.”
This creates a loosely coupled environment with autonomous teams who understand how to deliver their chunks. If the program management creates rolling wave plans, the teams can adapt to the ever-changing environment and adapt their plans.
Not everyone understands how to do that.
If you don’t use program management, you can use holacracy, which says, “As teams, we have the responsibility to deliver. We will make our decisions and coordinate so we deliver the results.”
Teams take responsibilities. They might shift those responsibilities over time. And people might shift responsibilities over time, too. For example, if a team completes its designated work for a given product, it might help another team complete its work.
If a person sees a need somewhere else in the organization, that person can take that responsibility. He or she would explain, “I see the need for more build automation. I’m going to attack that for all of us, okay?”
In holacracy, each person’s role is fluid. The job description doesn’t drive the work. The work drives what people and teams deliver to the organization.
Notice how teams and people have authority to make their own decisions. The teams iterate rapidly, not just for the product, but for how the organization works.
Holacracy introduces the notion of circles, with a specific role of “cross-link.” This person has the responsibility to work across the organization in order to initiate the discussions with other teams and circles. Each team has the responsibility to deliver its results, and each has a responsibility to work across the organization as its members like, in a way that fits the organization.
Note how the teams take their responsibilities. That means the team has the autonomy to work the way its members like to work. They build mastery as a team, and take roles when needed to serve the higher purpose.
In holacracy, teams have no top-led decision making authority. That helps the hierarchy problem. But what if holacracy is not for you? Fortunately, you have other options to reduce hierarchy.
Eliminate hierarchy with servant leadership
Here’s the problem with hierarchy: Problems travel up, across, and down for solutions. Rarely do the people who have the problem and the people who have potential solutions talk together. Instead, the solutions travel back up, across and down to the team with the problem.
This is ineffective and inefficient. I bet you’ve seen proposed solutions where the recipients shake their heads and wonder what those other people were thinking.
It’s even worse if management hands down a solution, because the people doing the work understand the problems more than the managers do.
Hierarchy often creates a mess. What are your options?
One way to change things is to change how managers manage. If managers become servant leaders instead of turf owners, they can facilitate the teams’ work with no organizational reorganization.
Working in an agile way does not eliminate hierarchy. I’ve seen many organizations that want teams to commit to a quarter’s worth of work, or where the erstwhile scrum masters (really controlling project managers) tell people what to do, and when. You can call that agile, but if the team doesn’t collaborate and deliver, it’s not.
Servant leadership is all about the leadership facilitating the work of others. How can you help people deliver their best results?
So far, we’ve talked about organization. Once you have cross-functional teams, how do you help people access expertise across the organization? Do we need yet another organization?
Access agile expertise with communities of practice
You’ve seen this problem. Sometimes, functions of people need access to each other, such as test automation developers needing access to architects. Sometimes, the developers (or testers or architects) need to share information across the organization. Because people work in cross-functional teams, they no longer have access to their function’s expertise.
Communities of practice can help with this. Spotify’s idea of chapters and guilds for scaling agile is an excellent example of how to use communities of practice in a way that scales.
Each person is a member of their local chapter, and they get together regularly to discuss their challenges. For example, the backend chapter in one product area might meet to discuss their challenges. Chapters work well for the sharing information across that area of the product. And, for smaller organizations, that might be all backend people.
Spotify recognizes that the chapters might not be enough. What if a tester has a question that he thinks the backend people can answer? That’s where the Guilds are useful. Guilds provide across-organization information for interested people.
If a tester or product owner has a question across the organization, the guilds can help either provide the answer or suggest where to go to find the answer.
Understand your management challenges
If you or your management is reading this and you’re saying, “Not here. No way. No how,” think about the smallest change you could make to help people and teams work with autonomy, mastery, and purpose.
Could you move from specific team responsibilities to more flexible responsibilities? You don’t have to embrace holacracy to use some of the ideas. If a team can deliver results, does it matter where they sit or what they know?
Maybe eliminating the hierarchy is a pipe dream where you work. Can you move from a hierarchical approach to problem solving to using the small-world networks that already exist in your organization?
Organizing communities of practice might be the place to start. Who could object to knowledge sharing across the organization? (I know, plenty of people, but that’s okay. You have to start somewhere.)
Remember what people work for: autonomy, mastery, and purpose. If you exercise your servant leadership, you can provide that to people and teams. You will evolve your organization into a place where people want to deliver their best results.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
