Lightbulb Moment: All Work Is The Same
Work is balancing an outcome across constraints.
Think of any contest show where people make things for judges, such as The Great British Baking Show or Project Runway. “Your cakes must be high, light and fluffy but cannot fall.” “Your pie crust must be flaky and also tender.” “Your design must be imaginative and also practical for mass production.” This is the core challenge of work: how will the worker balance the outcome across constraints?
If you have ever changed a diaper on a baby you know that the outcome, a clean baby, has to meet a lot of different constraints: you have to clean the baby thoroughly but you cannot harm the baby, constraining your choice of cleaning materials. You have to remove and process the dirty diaper but cannot get yourself or the room dirty, which constrains the actions you can take with the diaper. You have to replace the diaper carefully but do it before the baby needs to pee again, which constrains the pace of your changing routine. You have to work at a comfortable height but cannot risk the baby falling, which constrains the number of hands you can use to accomplish tasks while the baby is wiggling on the changing table, or perhaps the shape and configuration of the table, or perhaps you may dispense with a table completely and change the baby on the floor.
When writing a software test plan one must develop a comprehensive plan but do so quickly enough to implement it in a timely way, constraining the breadth and tempo of your research and planning. One must touch upon as many risk areas as necessary but remain mindful of the budget in time and effort, constraining the list of priorities for testing. One must anticipate the affordances of the software that will bring real benefit to the people who rely on it, but be mindful of practical matters such as maintainability, constraining the degree to which the plan focuses on user outcomes.
In all of these situations one can craft a meaningful view of the outcome simply in terms of its constraints. Every time you see a bullet list in a document this is a good first-order approach to interpreting it: Ah, I see, a list of constraints defining an outcome. E.g.
Traditional Pie Crust
- Non-yeast dough
- Flaky
- Tender
- Golden brown
- Delicious
If it isn’t all these things it isn’t a good traditional pie crust. You can think of these definitional constraints as “quality criteria” or “requirements”, but I use the word constraints for a particular purpose which I will talk about later, having to do with arranging work using techniques from Operations Research and Theory of Constraints schools, and finding through-lines across higher-order and lower-order outcomes.
Viewing work this way, as a balancing act across constraints, has a lot of advantages. If we are running an Agile team and holding sprint planning sessions, listing the constraints on the outcome helps the team to gauge the level of effort to develop it. If we do a little more thinking we can define the constraint sufficiently well to develop mechanisms for observing the states of the constraints and steering the work so as to meet them. This is a form of test-driven development.
It’s also useful as a gauge of team skill. Skill at work is the ability to meet constraints over time. The larger the suite of constraints you can meet in a set time, the greater your skill. Meeting a set suite of constraints in a shorter time also indicates greater skill. A skilled pie crust maker requires one pie to demonstrate a flaky, tender, golden brown and delicious crust. An unskilled pie crust maker will require many pies to deliver flakiness, tenderness, golden brownness, and deliciousness, distributed unevenly across various outcomes. If they happen to deliver a single crust which is all of those things, then they are happy, but they aren’t yet skilled.
Skill is the answer to the Iron Triangle of Cost / Time / Quality. With reasonable skill we can deliver outcomes at a reasonable cost within a reasonable time with reasonable quality. With exceptional skill we can do even better.
Nobody asked but I’m going to do it anyway: my definition of an outcome in a work context is a named entity which delivers a felt benefit to a person. It’s important to name the outcome in order to direct attention to it. “Attention” of course comes from “tend”, keeping an eye on a thing so that you can act to ensure its constraints remain met. The outcome itself provides a felt benefit to a person, sometimes called the customer or the user. I call them the beneficiary — don’t worry I will get into the four work roles at a later time — and their opinion is important in shaping the work and recognizing the effects of its delivery.
The work, the outcome, and the constraints on the outcome exist to deliver this felt benefit. This simple statement might seem innocuous but check out Shirky’s Law: any outcome chartered to solve a problem will perpetuate the problem in order to maintain its own existence. The profound implication is that outcomes become reified, they take on “object permanence” in a corporate setting, and become divorced conceptually, energetically and financially from delivery of felt benefits to people. At this point workers begin to feel off-the-rails, and it is up to top management to de-reify the outcomes and shift attention back to the people waiting to derive a felt benefit from the skill of the workers.
The alternative to the cycle of reification and de-reification is provisionality: as soon as the benefit is delivered, the outcome must disappear and allow other work to subsume the skill of the team. For that to be the norm may require a shift in accounting and budgeting practices.
In the spirit of nobody asking me to define an outcome, I’ll also define a constraint: a constraint is a measurable aspect of an outcome which must be satisfied for the outcome to provide a felt benefit to a person. A pie crust that is golden brown and delicious but solid and hard is not a good pie, the diner will not feel the full benefit of the pie as they should. An internet that is fast and scalable but insecure and expensive is not a good internet for people who need their data protected and must keep to a budget.
I like this framing because constraints get a bad rap. Most people think about avoiding or overcoming constraints, but by casting them as the gateway to delivering benefits to people we see them for what they really are, the means by which we work effectively to meet the real needs of others.
