When we speak, we often use shortcuts, jargon, and cleverness to get our points across. If we confuse anyone in the audience, we can explain what we’re thinking in the moment. However, when we write, all that cleverness doesn’t always help our ideal reader understand. Sometimes, we alienate or confuse our ideal readers with our […]
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in
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,
Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the
Over the past couple of weeks, several potential clients have discussed problems they want to fix: What are the teams doing, at a detailed level? (The managers want to know when the teams will finish certain features in the short term.) How can they plan for six months at a time? (They want to understand
Tim, a first-level manager, asked me, “Is it reasonable for someone to quit after just a week? With no notice?” “No. What happened?” “Sam, a new developer, started on Monday. He told me today, Friday, he’s not coming back.” “Did he say why?” “He had a whole raft of reasons. He had too many questions:
If you’ve ever tried to write nonfiction, you probably encountered these problems: Your readers only understood what you wrote. Not what you meant to write. Only some readers got value from your pieces, not everyone. The writing you ended up with at the end might have looked very different from the piece you started with.
You have some terrific experience in your team, such as pairing, and you decide it’s time to write about it. And you have a problem. The developers and testers need one perspective, coaches need a different perspective, and managers need a third perspective. What do you do? Choose one ideal reader and write a piece
I said in the Modern Management books that managers lead and serve the team (at all levels). However, I’ve seen organizations try to separate the leading work from the serving work. That’s when the organization creates “people” managers. The people managers serve the team by creating a trusting relationship with each person on the team.