Working in many different environments provided me a good perspective on what scaling models are applied by different companies. Today I'd like to spend a bunch of keystrokes on one of the worst scaling models I've ever encountered.
I call it:
Scaling by bubbling the problems out
How does it work?
A 'busy person', usually a leader or manager, identifies a persistent problem within the organization: something that consumes focus and time, impacts the quality, slows down the value delivery, etc. This problem is either completely new (caused by the growth) or has evolved over time, but now its severity is more apparent.
Here are a few examples (of such problems) to make sure we're on the same page:
- the number of quality defects (for the whole product) is increasing; until now, each team had been able to deal with their deliverables' quality
- the quality of internal communication deteriorates - people start complaining they don't know what's happening in the org, there are more and more misunderstandings and misalignments
- the engineering unit needs to grow, and the recruitment takes more time increasingly - hereby hemorrhaging the last reserves of time of the unit's manager
Initially, such a problem is dealt with in an ad-hoc way (through a one-off, point-directed action). But it keeps popping up back (as due to its nature, it can't be eliminated permanently). Apparently, that kind of a problem requires continuous effort and ownership (to make sure it doesn't get out of control).
Finally, the 'busy person' (mentioned above) decides that burying her/his head in the sand won't work anymore, so why not do what all the handbooks advise?
Let's delegate!
That sounds like a tremendous idea, but the devil is in details. The 'busy person' doesn't delegate responsibility, function, or role. (S)he outsources the problem by creating a new (formal or no) position (or even a sub-unit) to deal with that problem, so all the annoyances are out of the 'busy person's' back.
This way the problem is contained within some sort of a bubble, but it's someone else's bubble! Problem-related black box our 'busy person' doesn't have to worry about.
Got it?
- Problem X -> X Manager / X Team
- Quality problem -> Quality Manager / Quality (Assurance) Team
- Communication problem -> Communication Manager / Communication Team
- Recruitment problem -> Recruitment Manager / Recruitment Team
Oh, how convenient is that! If the problem re-appears, it's clear who's guilt...^M^M^M to be asked to fix the situation.
As the crisis is prevented now, the 'busy person' continues with her/his quest, smug and oblivious to the consequences of the change just made ...
The issue
Yes, it seems that short-term, we're all good here. Putting someone in charge of the crisis sounds like a decent plan. But it's not really what happened here. A new position has been spawned not to solve the actual problem (which may be hidden and unobvious) but to patch its visible symptoms, potentially making the organization more complex, inter-dependent, and bureaucratic.
Instead of well-thought-through systemic change, we're adding a sub-unit (usually with the manager in charge) with the responsibility of dealing with problem X. If you had any hopes for getting rid of problem X permanently - abandon any faith in that. If problem X is the sole reason for the sub-unit's existence, it will subliminally act to preserve and solidify that problem (under control, but still).
In more simple words:
- no wider context
- no holistic view (to understand the flow of work and value, or the nature of the problem)
- no systemic approach (System's Theory)
While in fact the solutions to before-mentioned problems may be much more simple and straightforward:
- the quality issues may be a result of reaching the critical capacity of manual regression testing (with test automation as a likely answer) or pushing quality checks towards the end of process (e.g. by not doing proper reviews)
- internal communication could deteriorate because of the increasing number of actors - a good idea is to check the component/area boundaries to verify the number & validity of dependencies; other potential root cause may be an underlying conflict or misaligned priorities of two (or more) parties
- extensive recruitment will be a problem if you centralize the 'gating' too much - although acquiring talent is manager's/leader's duty, (s)he should get a lot of control over it directly to the teams (who are looking for more members) - it's their skin in the game of getting the most proper people on board
Just to make sure I'm clear - what I'm saying here is not against the popular principle of 'single-threaded teams' (ones dedicated end-to-end, exclusively to well-defined narrow topic). I'm all for crystal-clear focus and unequivocal responsibility range, but the area covered by such a team should be defined by product/service vision, instead of what kind of piece of garbage has been thrown over the fence to save you some time ...
