The builder’s first contribution - visibility

Intro - the builder's contribution

As a follow-up to ‘building a better lego brick’ (January 2021, huh…), the last few years have offered me some noodling time on the problem of individuals swimming in the maelstrom of sociotechnical systemic forces. What can one do in the face of such systemic momentum?

If everything is ultimately made up of unassailable systemic forces, what is an individual worker - the builder - to do? What’s my job, my contribution, my responsibility? Is there anything to aim for beyond the job description? When there are chronic problems that aren’t just going to go away, do we collapse in a heap and take up goat farming?

While animal husbandry seems like an idyllic pursuit, most city by-laws prohibit such activities (goats are fiends, anyways). So if you are languishing in the doldrums of a day job, rather let’s talk about what you can do… and that is… contribute! No matter the state of the system we work in, it’s a foundational principle that we must simply do the best we can with what we have - there’s always something to contribute that will make an impact.

There’s much written about the role of senior leadership in system re-design, but most of those materials effectively assume that workers (builders, as I’ll be calling them) have zero or minimal input. So, distilled from all the reading and living I’ve done - I’m going to explore what some basic guidance for the builders might look like.

The builder’s first contribution - visibility

To explain the paradigm behind this argument, we’ll say there are two buckets of system participants - system re-designers and builders (model caveats apply!). In one bucket you have the system re-designers, those tasked with systemic design and outcomes. This group - again, for the sake of argument - is mostly comprised of directors through CEOs. In the other bucket are the builders, those who make the mission and vision come to life, who fix the bugs, who collaborate to make something from nothing.

Consider this simplistic mental model. At one end, building happens. At the other, redesign happens. Ideally, each activity type (build or design) is pursued by contributors who are skilled and enthusiastic about their type. For example, a CEO doing coding, architecture, or workstation setup - this yields much sadness. Similarly, an engineer attending board meetings or investor meet and greets, or writing company policy - this too, is a sadness. But a CEO who lets a builder build - this is a great thing. We can see this reality play out around us every day, such as when you consider what I will call ‘character blast-radius’. An engineer with an irate disposition has lesser impact compared to a CEO with an irate disposition. One will make a team’s life unhappy (5-10 people) - the other will make the organization’s life unhappy (50-50,000 people). At the one end you have limited influence, even if you want more; at the other end you have immense influence, whether you like it or not.

However, there is overlap, interconnectedness, interrelatedness, interdependence - re-design responsibilities are not absent for the builder, just at a different level and function. This is our stop for today - exploring what re-design means for the builder.

To start, we’ll label the first contribution of the builder as ‘helping make visible the state of the system’. While abstract and empty-sounding, this task is very important. The farther you get into re-designer land, the less context you have of what is actually going on in the system - both technically and socially. A clear signal of ‘what’s happening on the factory floor’ is crucial for effective management.

So, builders - remember your first contribution to systemic change: making visible what is really going on!

Practical examples

Down to brass tacks. What does this actually mean, in practice? This topic is enormous, so I will keep it to a limited context: I work in software development, specifically SaaS platforms, so expect bias in that direction. And as usual, the disclaimer of ‘visualizing complexity is a fool’s errand’ applies.

Story: Development environment woes

‘We have development environment problems that really slow us down.’

Consider the goals of the system of software development - delivery of code to production in the hopes of better satisfying ‘jobs to be done’ and making more money (or wasting less) while you’re at it. Consider the systemic assumptions - more work done on code = more code = more code to production, or, more code = more money.

Applying our problem to our context and goals and assumptions gives us the natural question, if we have throughput constraints that are costing us both actual and potential money, what kind of time is being spent waiting in the queue rather than ‘producing’?

Question: How much time (hours/week, day, etc) do developers spend waiting on development environment problems?

It’s a startling revelation to find that - in my experience - nobody has an answer to this very simple question. What’s even more startling is how quickly you can get actionable data. On several occasions the teams simply started jotting notes on paper and capturing the results at the end of the week. The numbers-made-visible prompted swift re-prioritization of work onto the development environment issues.

Action: Write it down.

Remember, you are not seeking scientific accuracy! You need enough data simply to make a sufficiently informed decision.

So, follow up with another question (this also requires framing in the systemic problem, context, goals, assumptions).

Question: How much time spent waiting would be enough to prompt investment and reprioritization?

Facilitating this question should include considerations of how long a current work item takes to execute. Does the data warrant a single ticket’s worth of work? Week? Month? Major roadmap refactor?

As part of the story-telling, consider how long the problem has been around for, and do basic napkin maths to illustrate the cost of inaction. In the least, a single discovery ticket is worth pursuing, and these usually tell the tale of whether or not this was actually the real problem.

Consider the themes:

Track your observations: Has it been written down? Be methodical and systematic!

Consider: What are the implications/outcomes of this? What’s missing from your own picture? Are you investing time in this?

Make it visible: Are your conclusions/observations ticketed or metricized somehow? (pen/paper is a valid methodology!) Remember that tickets are one of the unfortunate realities of work - unpleasant to learn the discipline, but it generally pays dividends.

Verbally communicate: Is your manager aware? Your colleagues? Voice-talking is much more revealing than text-talking. Stories are more compelling than spreadsheets.

Track. Consider. Make it visible. Verbally communicate.

Take action

For the builders out there…

Take note - with the right audience and story, anyone can influence outcomes with these methods. Perseverance required in heavy doses. The bigger the systemic forces, the longer they take to redesign.

Try a disciplined experiment with this for the next month. Talk to your colleagues and manager and see if you have shared understanding about the problems you’re observing - get them to challenge your theories. Work with your manager to figure out what numbers might help with storytelling, and how might you collect them.

For the re-designers…

Some considerations: Are you enabling these practices? Have you designed feedback and actioning of it into your work methodology? Does your manager ‘see’ the system areas you are re-designer over? Are your mental models aligned?

Try a disciplined experiment with this for the next month. Work with your builders on the number one problem they face - how can it be made visible? How will you tell that story? What is the impact? What is not being done because of it? Keep tabs on this initiative over the coming months - what outcomes did you realize?

It’s actually a really simple process, but it does require someone to actually follow through on the disciplined actions. That’s the next topic I have in mind - the second contribution of the builder is themselves.