Tag Archives: collaboration

Lead architects and collaborative design

Brenda Michelson had this to say on Twitter yesterday…

..and all I had was a smartass response. Brenda shared a valuable idea.

Somehow “lead architects” rubbed me the wrong way…so let’s get rid off it:

Considering…

All architecture is design… —Grady Booch

…we can just speak of “lead designers” who need to know all the questions…or at least many…or know folks who know questions.

Let’s also include “lead developers” and lead whatevers in that description and use this broad definition of designer:

Everyone designs who devises courses of action aimed at changing existing situations into preferred ones. –Herbert Simon

With that out of the way, why do we need lead designers when we’re all subscribing to collaborative design? What does leading design mean in the context of collaborative design?

What if we considered a lead designer to be an expert who then should be considered a knowledge manager as described by Andy Grove in High Output Management? From this perspective, leading (managing) is then much less about making (design) decisions than about gathering & distributing information and influencing decisions (nudging).

Leading design would then become facilitating and supporting collaborative design, i.e. helping the group design and designing with the group. Leading would then become helping the group figure out whom to follow with respect to different issues. Leading would then mean ensuring that all voice have a chance of being heard, especially the quieter ones.

Leading design would then be about helping the network make better (design) decisions (hat-tip Harold Jarche via Lisa Sieverts).

Leading design then wouldn’t rub me the wrong way.

 

 

Advertisements

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

It’s the process, not the product

Stuart Boardman retweeted a link to a blog post by Rob Vens: “Software is not a product“.

In this post, Rob argues that we ought to consider our (hopefully ever improving) process of creating software as the primary product of our work rather than the software itself. In this sense, he argues that software is only a by-product of our work.

Interesting. I exchanged a few more tweets with Stuart in which he observed that “product” does not mean (physical) “good”. Indeed, services are products, too, both in a general sense and in the context of Rob’s blog post.

In my experience, clients still want to buy the results of the software process (e.g. an evolving web shop) rather than the collaborative design process yielding this result. This is despite the fact that software development processes and methods can be the subject of great debate at all phases of the sales and delivery process.

But herein might lie great opportunity: What if we could shift the conversation away from that by-product of our work to that collaborative design process that creates that seemingly auto-evolving web shop?

And maybe there is a chance of actually making this happen, if Laura Colvine (via Jeff Sussna and James Rock) is to believed: “It’s H2H: Human to Human“. (Alright, so I’m quoting this out of context.)

I’m well aware that the above is a tiny step for humankind, but it has been a greater and very enjoyable one for this human. Thank you to all of you who contributed to it.

I know realise that “The process is the product” would have been a better name for this post.

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.

 

De-emphasising organisational boundaries unfortunately not a silver bullet

Many smart people have written many smart things about new ways of organising work that have become feasible in the last few years. Some of these smart people are Tom Graves and Dave Gray. A key aspect of many of these new ways of organising is de-emphasising traditional organisational boundaries, i.e. in effect doing work across organisational boundaries that would have been done within organisational boundaries just a few years ago.

The opportunities this brings have been discussed thoroughly before as actually have been the risks. So the following really is old news…but I feel strangely compelled to get it out of my system:

When you depend on others for critical parts of your performance, then critical parts of your performance actually depend on others.

When operating in a network of nimble and effective organisations this might be not much of a problem—assuming you can reorganise your value stream or value network in a swift and flexible way. Traditional corporate outsourcing can produce scenarios in which several large organisations are tied together by rigid contractual frameworks and complicated operating models over a fairly long time.

In these situations, the partners may feel they cannot obtain and, respectively, provide optimal value, but tragically feel they are unable to do much about it. Sooner or later, organising essential work strictly within the boundaries of the organisation looks preferable.

That sounds like rewinding a couple of decades and starting over. I think we can do better than this.

Consequences of yet-another-architecture-definition

I described my evolving thinking of what architecture is here and how someone called an architect could add value to a team here.

What consequences does this mindset bring about?

  1. Architecture is not a tangible artefact, but a social construct. (See note below.)
  2. Architecture cannot be created directly, but is the result of other activities (i.e. planning, designing, building and sustaining a system).
  3. The team creates the architecture through interaction. Someone called an architect doesn’t create the architecture by drawing diagrams for the team.
  4. Someone called an architect could promote the shared understanding of a system through conversations with fellow team members and potentially creating supporting artefacts.
  5. Someone called an architect may well contribute to making significant design decisions (sometimes called architecture in the sense of a system’s significant design decisions).

Note: I didn’t come up with the notion of “architecture as a social construct” myself. But then again, I don’t seem to be able to find a single source, so I probably mashed up some ideas from the sources on architecture I mentioned before and the notion of “software as a social construct”.

Updates

2013-11-24: Added note on “architecture as a social construct”.