Does your organization have an enterprise architect or Chief Product Person? We create these positions to check that the teams don’t try to implement something “wrong.” However, a single person in this position creates bottlenecks and dependencies. (A committee might create even tighter bottlenecks.) Those dependencies slow the work.
If a person delays the work, how then can we “know” the product proceeds in the “right” way? We can’t “know” in advance. We can create small experiments and learn from them. And, instead of using one person to decide for everyone, we can use our collective wisdom to decide for ourselves.
That’s the value of a small-world network.
This image, from Agile and Lean Program Management, shows a small-world network. The teams on the upper left have fewer connections. In contrast, the teams on the upper right have more connections. I see those kinds of connections in organizations.
No team is “bad” or “good” for their connections. As long as no team is isolated, they all have access to the networks.
But, you say, the Enterprise Architect helps you. I’m sure he or she does.
Here’s the story of Pat, the Enterprise Architect.
Pat, the Enterprise Architect, at Company 1
Pat was thrilled with her promotion to EA at her company. This year, she’d already helped six teams avoid major problems in how their products worked with the rest of the products.
As she became more and more useful, more people asked for her time. When I worked with her, she felt as if she was pulled in hundreds of directions.
I asked her to graph her value stream map on the three most important pieces of work. Just three. She sketched this.
Item 1 was a request from one team. (The top line on the value stream image.) Pat conducted some initial research, a few experiments, and then she was able to accept the proposed design. But notice all those interruptions. What took a little over a day in work time took more than eight days of calendar time.
It was the same interruption problem with Item 2, but that was worse. That’s because the team waited 6 days for Pat to reject their ideas, and she didn’t have the time to explain why in detail. (Because Pat had so many interruptions.)
Item 3 was stuck in what Pat called “never-never land.” From experience, Pat knew that the longer she got stuck in the research phase, the longer it would take her to learn what the issues were. She’d have more interruptions and the cycle time would extend to weeks, not days.
Pat asked what she could do.
I suggested she stop being the one-and-only expert and create more experts across the organization.
She wasn’t sure how to manage that. She felt she was paid to use her expertise, not help other people develop theirs—and she was right.
Her bosses didn’t want her to share her expertise—they wanted her to loan her expertise.
She and I had several conversations with her bosses. She decided to leave after another six months because she could not make the job work for her.
Pat, the Enterprise Architect, at Company 2
When Pat took a new job, she negotiated time to work with teams, not for teams. She also created an Architecture Community of Practice (CoP), so everyone could learn how to assess their architecture and designs. Part of the CoP was to start asynchronous discussions for how to research and experiment different architecture and design options.
It was a lot of work at first. Pat’s cycle time was still about a week for the first six months. That’s because it took time to create the CoP and to explain how to discuss architecture in a psychologically safe way. However, by about the six-month mark, Pat’s cycle time decreased to roughly two days. She still had senior leadership interruptions, but she rarely had more than one request in her personal queue. Instead, teams discussed their architectures inside and between teams.
Everyone thought they had much more robust designs. And because more people understood why the teams made their decisions, the organization was more resilient when they had to change.
Avoid the Single Person Outside the Team Dependency
If we choose to have a single person outside a team approve/accept/reject, we create a dependency on that person for the entire organization. And, the more of those people with solo expertise, the more we can expect dependencies.
I’ve suggested several ideas here to reduce those dependencies:
- Make that person responsible for helping other people learn what the expert knows.
- Create a Community of Practice around that body of knowledge.
- Use the internal small-world network and see what other people know. Socialize the architecture, other expertise, instead of approving it.
You might have more options that I don’t see. But let’s be honest about dependencies and how we might manage them.
The Series
The series so far (which arose from A Common Tool Trap: the Tool Will Help Your Delivery and Planning Problems):
- See and Resolve Team Dependencies, Part 1: Inside the Team
- See and Resolve Team Dependencies, Part 2: One Person Outside the Team
- See and Resolve Team Dependencies, Part 3: Some Component Teams, Some Feature Teams
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: See and Resolve Team Dependencies, Part 2: One Person Outside the Team Opinions expressed by Java Code Geeks contributors are their own. |
