Tag Archives: teams

Cross-functional product management teams

Over the years, we have achieved some success with the cross-functional software delivery teams established (well, popularised) by lean and agile methods. More recently, the perspective has broadened somewhat to delivering usable solutions rather than working software.

I think it’s time to broaden the perspective a little more and to think of software-supported solutions in terms of products more consistently and to manage them accordingly. Kristofer Layon’s book Digital Product Management is a good start.

My experience mostly comes from fairly sizeable digital business initiatives in fairly sizeable organisations. While your mileage may vary with the size of the initiatives and the (network of) organisations you are involved, I believe that the basic argument put forward in this most still holds true in a smaller context.

Years ago I’ve seen projects succeed whose leadership included a competent functional architect and a competent technical architect. This duality was de-emphasised by the Unified Process with its strong focus on the (fairly technical) software architect role and by Scrum with its focus on the (fairly functional) product owner role. To make things worse, providing the “content leadership” (a better term, anyone?) on any sizeable initiative is a tall order for any single person, at least in my experience. Disciplined Agile Delivery begins to address this issue be re-emphasising this duality with its product owner and architecture roles.

To me, this looks like a good start but I think we ought to go a step further: I suggest that introducing cross-functional product management teams is likely to yield similar benefits in the area of “content leadership” as introducing cross-functional solution delivery teams did in the area of producing software-supported solutions.

For example, in addition to business and technology design expertise, we certainly want to include experience design expertise in the product management team in most contexts. Other expertise can be added as and when necessary.

In addition to the immediate benefits of the cross-functional approach, this will also help to reduce the load on the two people that used to be “the architect” or “the product owner”.

In the type of contexts that I tend to work in, this leaves a digital business initiative with three major groups: project management, product management (in a staff position to project management) and the delivery team(s).

The concerns addressed by these groups can be delineated quite nicely, which offers the benefits of clear focus for each of them. In combination with a shared purpose, these clearly defined responsibilities provide a strong basis for collaboration across these groups’ boundaries

Scaling down my problems

Recently someone said something like the following somewhere (on Twitter? A link would be much appreciated):

Instead of scaling up your team, try scaling down your problems.

How would scaling down large problems work? Wouldn’t we have to solve large problems by composing the solutions to small ones? Wouldn’t we need another small team for doing this composition? Wouldn’t this bring us full circle to some sort of large-scale agile approach? Wouldn’t this be exactly what we set out to avoid?

How do two-pizza teams collaborate? What about coordination? Direction? Guidance? Funding?

In brief, how do I actually, concretely, practically scale down my problems in enterprisey e-commerce environments? I don’t have the faintest clue, but I’m bloody well going to find out. I’m done with scaling up!

 

We don’t need another hero…

 

…but we do need to know the way home. All by ourselves.

Jeff Gothelf and Josh Seiden said it well in Lean UX:

Over the long haul, collaboration yields better results than hero-based design… Teams rarely learn or get better from working with heroes.

The same is true for any other discipline the hero might practice. And there isn’t really much to add to this.

Except, perhaps, for a little more context:

The most effective way I’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields better results than hero-based design (the practices of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, designing together increases the design IQ of the entire team.

’nuff said.

Just one more thing: Read Lean UX. Much of its content is applicable way beyond UX.