In two recent posts, I offered cautionary tales for managers of self-organizing agile teams:

Tale of a Yo-Yo Manager

Tale of a Too Hands Off Manager.

So what is it that managers should do to move from big boss to partnership?  It’s actually quite a long list, so let’s get started.

Expand Contextual Knowledge

In June, I wrote on how knowledge is bifurcated in many organizations.  People at the top of the hierarchy know about the business model and the context (at least we hope they do) and people closer to the bottom of the hierarchy know how things really work, have technical knowledge and skills to build what ever it is the company builds.  People at the top don’t know much about what it takes to get work done, and people doing the work don’t know so much about how the context. The extent of the bifurcation varies in different organizations, but once there is a hierarchy–even a fairly flat one–it shows up.

So one job is to extend the overlap between contextual and “how things really work” knowledge.

Expand the overlap of contextual and "how things really work" knowledge

So part of what managers Dev teams need to know how their company makes money. This may seem painfully obvious, but somewhere in my distant past, I met a group of programmers in a financial services company who suggested that the fund managers avoid trading options because programming for options was proving difficult.

Once the programmers understood how much money there was to be made trading options, they figured out how to write the programs.

Dev teams need to understand how their company fits into the market and what their company’s aspirations are. For example, one manager communicated that the company aspired to handle 100,000 simultaneous users. Team members had this fact in their minds as they built the Web site incrementally. While the software they built in the first few iterations couldn’t handle the load, they made choices that made it feasible to build up to that level.

Some teams explicitly defer  all decisions about the cost and benefit of building features to a product owner. But I find that the more team members know, the more they can ask intelligent and relevant questions that hone not only their own thinking but also that of their product owner partners.

The best way to understand customers is to see them in their natural environment, using the product.

You might use this little map (from Osterwalder and Pigneur) to talk about these topics.

What is our value proposition?

Who are our customers?

How do we build and maintain a relationship with our customers?

By what channels does our value proposition reach our customers?

What are our revenue streams?

What’s our cost structure?

What are our important people and resources?

What are our key partnerships?

Of course, we’re not looking for a mind-meld, where everybody knows everything that everyone else does.  But when people understand what it takes to do work and how the work fits in the big picture, partnership becomes a possibility.