In two recent posts, I offered cautionary tales for managers of self-organizing agile teams:
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.
Nice post!
There is normally a lot of gap between what the big leaders in the organization say in several of meetings with employees and what the employees actually see as what is important to them. The management has normally good intention to arrange meetings every quarter or so where all the people including the developer community could participate, ask questions and share thoughts.
But it is seen that during the course of any such management presentations, many employees start having their own “local” discussions or leave the room or sometimes even start falling asleep. I think that the main reason is like what you have said, they are not able to really connect to what is being said and how it relates to their own day-to-day tasks.
The Product Owners do an excellent task of translating the customer requirements to easy to understand “stories” that the developers can understand.
I have seen in the past that in co-located setup (I mean where the Product Managers are also located along with the developers), the awareness of the developers related to customer requirements, understanding of sales and revenue streams, partneships etc is much better than in a multi-site setup. The reason is that developers are able to go back to the product managers asking lots of questions face-to-face than picking up the phone or writing long emails.
Also, developers want such information to available on regular basis. For e.g., every month or at the least in every quarter, they would like to have visibility on:
a) customer deals that are prospective
b) deals won
c) features being used by the customer from their previous release and feedback (what is good, what is not good) so that that can be improved upon
d) how is the product doing (or not doing) as compared to their competitors and why
Hi, Parbhu –
I agree, quarterly “all hands” meetings are seldom an effective method of communication–even when people do understand how the business works.
Talking with a Product Owner is no substitute for seeing a customer interacting with the software, though a competent Product Owner is certainly an asset.
It seems like the data you mention would be useful for many people in the company.
e