TL;DR No org composition is perfect & given forever - things that didn't matter much when you were 10 may suffocate your whole engineering unit when it grows to 30. That's why engineering units should keep evolving - to make sure that local maximum (at some point in time) won't become a global minimum just because a shortsighted decision that has solidified into concrete. Interestingly, it's we, people who often block / slow down such an evolution - we feel (too) comfortable with what we've manage to establish to secure our perimeters ...

I've already written at least 1 blog post about the Conway's Law some time ago, but as it was referring to larger enterprises that have separate units that build & maintain separate software products (systems/services), it may have been abstract for some of you.

Today, I have a different idea (/concern) on my mind. Another one, yet inherently similar. And yes, based on real-life scenario.

Let's start with the battlefield overview ... Here's the single organization, working on a single product with a simple & straightforward revenue stream. Additionally:

  • delivering a product increment requires skills & knowledge of 2 specialties: A & B
  • A & B are not interchangeable, a person is either A or B
  • in general A should go first, as B relies of A's work outcomes
  • work of both A & B can (& should) be organized in sub-areas, using the same boundaries
  • ... but A & B together contribute to ONE, SINGLE product

Organization is successful, it was (& is) growing, but ... rapid growth can be controlled only up to some degree, some rushed decisions can have consequences you can't predict, e.g. some org composition (into teams, units, departments even) may have worked in the past, but can be a root of a lot of evil nowadays ... In this particular case, A & B are separate units, with different bosses, not even co-located physically.

Building walls

Effects are quite easy to predict (standard functional VS cross-functional teams dilemma):

  1. as efficiency between A & B is different (it ALWAYS is different), even most careful planning can't eliminate waste (excessive inventory, that gets outdated)
  2. no-one has the responsibility over full product, As & Bs are happy with their separate parts, "seal" their boundaries
  3. of course both As & Bs declare full availability for the co-operation but they are in PERMANENT RE-ACTIVE MODE; what does it mean? they politely answer questions when someone comes to ask these, but they do nothing pro-actively; they limit themselves to their local perspective only, to the "local optimum" -> they don't feel accountable for the big picture (or other people problems)
  4. obviously, that don't want a change, they are comfortable with how the stuff is done - familiar environment among others of your specialty makes a great "comfort zone"
  5. managers are afraid to change the status quo, as currently whole work system there is in a comfortable equilibrium - each of them has plenty of operational work in his area, other managers do not interfere as they are playing with their own toys, etc. Calling for action would mean stepping on someone's toes & who know what could happen, so it's better to defend their 'princedoms'.

As a result, this whole setup solidifies even more & more. Organic growth makes it harder & harder to break as A & B drift further & further away from each other: build separate knowledge bases, lingos, implement different tools & processes ... In fact, potential solution sounds unbelievably simple (if introduced early enough):

  1. change units to competences -> e.g.: manager of unit A should be a leader of competence A (it may actually appear in the end that some competences never needed managers ...)
  2. break & join teams in a way that makes them cross-functional ones: both A & B people should be on board in each team
  3. make whole (joint) team accountable for whole product increment within their boundaries (in their area) -> for both A & B competences

Resistance

Sadly, (based on my past experience) very few have guts to go for it. Breeding excuses is far more popular:

  • "we all have urgent work to do now, there will be time for org shifts afterwards"
  • "splitting competences across teams will make coherency-keeping efforts harder, developing competency expertise will get slower & tech leadership will suffer"
  • "but we're open for any collaboration, we're just not getting questions/requests we should be getting ..."
  • "we'll be more efficient (as A or as B - separately) if we work grouped by competency"
  • etc.

Of course it's all rubbish & approaching the problem from "squashed frog's perspective" (without any context outside of the nearest surroundings).

This issue severely impacts the everyday work of the most basic value-producing unit: team. It introduces an inefficiency "tax" on each quantum of functionality produced. Shifting focus onto fixing almost any other kind of issue in development pipeline is (in this case) an over-optimization. It reminds me a worker who doesn't have time to fix a critical leak, because he's busy running hence & forth with an empty wheelbarrow ...

Share this post