Bottom-up or Top-down?

The theme at LLEWT this year was Rules and constraints to ensure better quality.  My experience report concerned a team I'd been on for several years which developed (bottom-up) a set of working practices that we called team agreements.  

The agreements survived "natural" variation such as people leaving and joining and even some structural reorganisation which preserved most of the team members but changed the team's responsibilities or merged in a few people from a disbanded team. The agreements did not, however, persist through a significant round of (top-down) redundancies where the team was merged with two others. 

I'm interested in thinking about the ways in which constraints on how people work affect the work and whether there are patterns that could help us to apply the right kinds of constraints at times they are likely to be useful. 

I'm going to use this post to dump my thoughts. My starting position is that there are three broad classes of constraint: top-down, contextual, and bottom-up. For example, in that order:

• management: use Jira for managing work items
• market: use standard technologies to be able to integrate and compete 
• team: we want to build our product using hexagonal architecture

--00--

Top-down constraints come from an authority such as company management. They set or reflect the vision of an organisation and are, or are intended to be, non-negotiable. Examples include product requirements, resourcing decisions, and standard operating procedures.

Potential benefits

• Clarity and direction: especially valuable during times of uncertainty or crisis
• Cross-team alignment: strategic coherence and a common goal, reduced friction
• Improved focus: reducing wasted effort on out-of-scope work
• Sharing: spreading something that worked locally more widely

Potential negatives

• Reduced autonomy and motivation: can feel like micromanagement
• Resentment: if perceived as arbitrary, untrustworthy, or disconnected from the actual work
• Stifled creativity: no room for initiative; compliance over outcome
• False sense of order: management feel in control but miss the ground truth

 More successful when

• The why is clear: not just clear, but also believable and proportionate
• There is flexibility: the what is given, but there is room for local context in the how 
• An example is set: management are living by the same rules
• There is consistency: ideally with other company actions and values, and with team practices
• The end is visible: the conditions for repeal of constraints with friction are clear

--00-- 

During re-orgs the hierarchy changes and so top and bottom might move. Re-orgs usually happen because the context has changed. Do organisations typically review their constraints at that point? Do teams?

--00--

Bottom-up constraints are developed by the team itself, based on their collective expertise, experience, and needs. They will typically be concerned with ways of working inside other constraints. Examples might include WIP limits, coding standards, or meeting etiquette.

Potential benefits

• Ownership and buy-in: deciding together, in their own interest, builds team morale
• Focus: make a decision once instead of every time a particular situation comes up
• Relevance: constraints are tailored to the team and their specific needs
• Psychological safety: everyone gets to contribute and is heard

 Potential negatives

• Dogma: because the team decided it, it must never change
• Insularity: the team looks inwards, suppressing collaboration with others
• Misalignment: too much weight given to team constraints relative to company constraints
• Groupthink: no voices challenging decisions and suggestion alternatives

More successful when

• There's mutual trust: conversation is easier when the participants trust each other
• Decisions are made together: decisions made by a Scrum Master are not team decisions
• There is servant leadership: management making space for the team to operate  
• Change is possible: when a constraint stops being valuable, the team can revisit it
• Context matters: the team have something unique to deal with
• Team members have done it before: reassuring others is a way to encourage experimentation

 --00--

Sketchnotes from my talk at LLEWT by B Mure

--00-- 

Top-down and bottom-up make it sound like there are just two players, but that's not the case. Those things are relative, directions of travel. There are levels in a hierarchy, and those in the middle can push constraints higher or lower in their stack. Or, at least, try to.

Although I've couched this brain dump largely in terms of "management" and "workers" I need to remember that, even within an implementation team, there is usually some kind of structure, whether organisational or societal.

Not only that, but in organisations with multiple teams there are lateral as well as vertical considerations. My instinct is to think of the activities of other teams as changing the context rather than imposing direct side-side constraints, but perhaps that merits more thought.

--00--

Contextual constraints can come from the market, a regulatory framework, the technology space, or other environmental factors related to the work. For example, if you're active in healthcare in the US, you probably need to conform to HIPAA.

Potential benefits

• Strategic alignment: particularly true if the team can understand why these constraints exist
• Market fit: motivates the team to follow process required by e.g. regulatory requirements
• Structure: encourages teams to find ways to work effectively within the constratints

Potential negatives

• Lack of innovation: a focus on existing norms can inhibit disruptive innovation
• Waste creation: such as unncessarily heavy compliance processes
• Burnout: people get fed up of the friction and leave to work in more flexible environments
• Confusion: staff members don't want to be domain experts so have a limited understanding

More successful when

• The context is relevant: no-one wants to be constrained unnecessarily 
• The context is stable: it's hard to keep up with constantly-changing constraints 
• The team is able to conform: constraints that are unrealistic are at best demotivating 
• Other constraints align: e.g. if company goals costradict the market there's a problem

--00-- 

Is "this is how we've always done it" a contextual constraint? I think probably yes. By the time this kind of thing is old enough to fit under that banner it doesn't matter whether it originated above or below.

Often it will have evolved to fit a specific context and become part of the culture of a team: an approach that works well enough at an acceptable cost that it is not contested. This kind of thing reduces decision fatigue and makes certain kinds of work predictable.

On the other hand, not questioning an approach can miss a better alternative or, worse, miss the context changing in ways that invalidate the approach altogether. The team might lose some capacity to innovate, or become biased towards people or contexts that the approach fits. 

Sometimes this type of constraint is implicit, in the culture. I recommend calling these constraints out when you see them. Explicit FTW because explicit can be discussed.

Once visible, before dismantling such a constraint it's worth remembering Chesterton's Fence.

--00-- 

 A constraint's success is a function of its relevance and credibility. Choosing the right time to introduce a constraint is important because the context plays a role in the kinds of constraints people will not only accept but also those they will clamour for. After a data breach, for example, people are a lot more interested in friction-heavy access controls to production databases.

Unfortunately negative context, and human nature, are the key ingredients for a knee-jerk reaction.

We must ensure this never happens again

Yeah, and every sign tells a story, but rules and constraints are not in the business of ensuring. They merely guide, and even then only to the extent that they specify, can be understood, and are followed. 

--00--  

If you are going to impose some kind of constraint, these factors are worth thinking about:

• Timing: when to announce, speed of rollout, deadline for completion
• Scope: who it applies to, when, and how widely
• Necessity: why this needs to be done at all, versus something else
• Flexibility: what levers can be pulled, where there is freedom within the constraint 
• Communication: clarity of, and transparency around, the constraint
• Monitoring: how will we know it's working (or not)? 
• Reversibility: can it be undone if it's not working?
• Credibility: the justification makes sense and we are trusted to go ahead
• Capacity: is the propsed constraint within our capabilities?
• Reality: is it likely that the proposed action will achieve the desired goal?
• Value proposition: is the price of the change proportionate? Are the right people paying it?
• Side-effects: who or what is affected by this, and when, outside of the intended target?

--00--

Might an organism be analogous to an organisation? 

In evolution, a living entity is subject to constraints that influence from the bottom up (gene mutation), from the top down (physiological limits) and those that impose boundaries from the context (the environment).

That feels relevant and interesting and provides a useful opportunity to take a step back. A really significant difference between those two worlds is the idea of agency and intention: evolution has none, and business runs on that stuff.

In business we might regard top-down as strategy and bottom-up as tactics or top-down as boundaries and bottom-up as route-finding inside them, or any number of other decorations on top of the basic structure.

Stripping this layer away makes it clearer that the three-way constraint puzzle is a dialogue (a trialogue?) where feedback loops between and across the parts naturally work towards some kind of equilibrium. 

And of course this happens in business too. Management might push particular restrictive practices to the point where compliance breaks down in the workforce, and then relax them just enough that they are accepted. A feedback loop.

It goes without saying that systems thinking is required to understand and to intervene in an ecosystem with some reasonable hope that the actual outcomes will be similar to those that are desired. (But I'll say it anyway because it's easy to forget and to focus on "the one thing" that will solve today's problem.)

--00--

Are heuristics a kind of constraint? 

--00--

I am interested mainly in the effect on teams, but there is an effect on management too. In Seeing Like a State James C Scott details how a central command and control system wants homogeneity in order to model the system from the consistently and efficiently (from its perspective, at least). 

It's easy to understand the appeal of all teams reporting the same metrics so that they can be compared, of people being fungible resources that can be swapped in and out without of tasks without great concern or cost, and the imposition of global working practices regardless of local contextual factors.

However, with this kind of perspective, management tends to have a rose-tinted view of top-down constraints, in my experience. As Thomas Campbell said in Pleasures of Hope:

Distance lends enchantment

By which he meant that the further away from something you are, the easier it is to avoid seeing how it really looks. So where might there be a disconnect between a top-down edict and its implementation?

Mostly people.

We come from and, particularly now with so much remote working exist in, different cultures which will give us a different spin on the same constraint. Likewise, two people might judge the context and hence the applicability of any particular constraint differently. Sometimes, of course, the context will be different: statutory regulations in different geographies vary.

An organisation is rarely just management and workers. Between them there's layers of hierarchy staffed by people with different takes on what any given constraint means, the degree to which it needs to be followed, and the extent to which checking is carried out. At best, this will result in outcome inconsistency but it can also breed resentment at perceived injustice, slacking, overzealousness, or other differences that flow from one group seeing that another group is allowed to work differently. 

It may also lead to different constraints being emphasised in different places or, potentially worse, constraints being set up in opposition to each other, leaving those asked to implement them with a problem. 

That may all happen even with everyone working in good faith. Another dimension to consider is those people who don't act in good faith. The political operators, the rule benders, the power-hungry snakes. They'll do whatever makes most sense for their own needs, and look to take credit or redirect blame in the same way. 

There's another class of workers that don't play ball: people who just want the freedom to do what they want to do, seemingly impervious to the need to deliver business value in order for their job to continue to exist. They'll move on to another job at some point. 

--00--

Coincidentally, while I was musing on this stuff the Cautionary Tales podcast reran Office Hell, an epsiode which describes the effects of higher powers imposing working or living arrangements on their staff. Spoiler: it tends not to go well, however good the intentions, and there's research that indicates this is due less the particular approach chosen and more the extent to which those being imposed upon have input and autonomy.

The closing sentence quotes the renowned Swiss-French architect Charles-Édouard Jeanneret, more commonly known as Le Corbusier, whose theoretically and architecturally pure Cité Frugès de Pessac project was rejected by its intended residents who, when they eventually moved in, installed all sorts of impurities of their own, including garden gnomes. (The image at the top is a design document from there.)

It also references Jay Chiat who in the mid-1990s forced hot-desking, mobile devices, and zany office interiors onto his advertising business Chiat/Day, generating an enormous amount of resentment in his staff as a result.

Le Corbusier, when told about the garden gnomes of Pessac, said something surprising: 

You know, life is always right. It's the architect who is wrong.

--00--

I sat with Le Corbusier's statement for a few days while compiling my thoughts for this post. I have an intrinsic bias to want to build bottom-up by default, while understanding the top-down constraints. Taken literally, the quote suggests that there might be no place for top-down but I don't believe that.

I eventually reframed it this way: 

The doers decide what gets done.

I liked that a lot but wondered if someone else had been there before me. Naturally, yes, but I still like it because, ultimately, regardless of where the constraints come from or what purpose they are intended to serve, the outcome depends on what gets done, and that depends on what the people doing it actually do.

We know this instinctively and see it everywhere in desire paths. For me, the wise top-down constrainer will look for, and take careful account of them. 

 --00--   

I'd like to thank and credit The LLEWT organisers and other participants: Chris Chant, Joep Schuurkes, and  Elizabeth Zagroba; Maaike Brinkhof, Gwen Diagram, Isabel Evans, Berwyn Mure, Duncan Nisbet, Vernon Richards, Oliver Verver, and Neil Younger.
Images: Le Corbusier World Heritage, B Mure, Reddit, The Guardian