Tag Archives: performance

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.

If they can do it, why can’t we?

Sooner or later, but inevitably, this questions seems to come up  when developing digital services:  someone requests a feature,  the team responds that they can’t easily implement it, and the requester states: “Well, website xyz has this feature, why can’t we have it?” Things rapidly get worse when an implication of incompetence is perceived.

Whenever this question comes to mind, it might be useful to ask ourselves a few questions:

  • Are xyz working in a similar context?
  • Are xyz pursuing a similar purpose?

Context may include organisational policies, available technology and the ease of changing this context. Purpose may loosen or tighten constraints on available funding or the selection of (potentially controversial) means. (Dean Bubley tweeted about context and purpose in networking, I touched on it here.)

It might be beneficial to remember that we usually don’t have any idea how much it cost xyz to implement that feature, or how long it took them. It is also not clear that xyz’s feature, i.e. a solution to one of their problems, is necessarily a good solution to our problem.

So, if we really want that feature, we need to sit down with the team and take the time to truly understand what makes it difficult, slow or expensive to build. Often we might be able to clarify goals or accept constraints that will make implementing (a version of) the desired feature feasible. Or, together with the team, we might discover other, perhaps even better, options.

Let’s just not assume the team is full of half-wits.