I riffed recently on the idea of PIP (promises in progress).

The idea is growing on me. First, because it explains how some organizations go downhill. And second, it helped me reflect on how and why I throw off promises in my day to day work (and sometimes don’t keep those promises).

https://louisandmelcomics.wordpress.com/tag/cartoon/Imagine you have a note taking robot at your disposal. The robot records every new promise made by people in your company — explicit or implicit, emotional or functional or social, aspirational or realistic. Everything! Gifted with an unlimited power supply (and storage)

, it moves on to survey for existing promises, expectations, and commitments. The robot does this every day.

How long is the list? How many items get added every day? How many things get ignored? Who has dashed hopes? Maybe no one cares? Maybe they do.

During a day at work recently, I tried to be that robot. I recorded every hint of a promise made during the three hours of meetings that day. The list was massive, and only a tiny percentage of the promises were captured somewhere (outside of my list). Most of the officially recognized promises lacked real clarity, next steps, and shared understanding. The implicit ones were all over the place… who knows how people interpreted them. Even when there seemed to be agreement, I couldn’t really tell.

A CEO once told me that he expected “motivated” people to “load themselves up with too much to do, and routinely drop balls, but don’t screw up the important tasks.” According to their view of work (and life), unless someone is maxed out, they aren’t trying hard enough. Now multiply this across the organization. What happened? Predictably, people struggled with debilitating stress. But they were also hurt because other teammates (including leaders) had broken their promises to them, often unintentionally. The situation slowly spiraled out of control.

Every person there wanted to please and wanted to make things work. The decay starts when — in our effort to keep some promises — we let other promises slide. We mean well, but just can’t deliver on all fronts. Most of the time it’s OK. I mean hell, everyone is so busy! But the cracks in trust, psychological safety, and respect begin to form.

Maybe we start to drift on something fundamental — like a promise to ship high-quality products, do right by customers, hire the best, or respect our co-workers. But the increments of drift are small. They happen one iteration, one vanity feature, one hire, and one frustrated snide remark at a time. And all the while we are generating new well-meaning and hopeful promises. How many meetings end with a couple of good ideas, and some offers to “check that out and follow-up”? How many all-hands conclude with a small group deciding to take on a problem outside of their day-to-day?

In Drift into Failure: From Hunting Broken Components to Understanding Complex Systems, Sydney Dekker describes how drift works:

Drift occurs in small steps. This can be seen as decrementalism, where continuous organizational and operational adaptation around goal conflicts and uncertainty produces small, step-wise normalizations of what was previously judged as deviant or seen as violating some safety constraint. Each decrement is only a small deviation from the previously accepted norm, and continued operational success is taken as a guarantee that the small adaptations are safe, and will not harm future safety.I have observed this dynamic with broken promises (what Dekker would probably call “goal conflicts”). As mentioned above, many of these promises are never made concrete or explicit.

David Allen (the Getting Things Done guru) calls these things “open loops,” “incompletes,” or “stuff.” His method recommends getting these things “out of your head and into a system” so that you can focus on getting things done. But anyone who has managed a product backlog (or set of action items for a complex project, or software development team) knows how quickly this can get out of control. You quickly hit a point of acute cognitive overload. There’s no way you can keep it all together, and still get any work done.

In any busy environment, you’ll find people at their absolute limit.

Something has to give. So while functioning at a high level, we also let things slide. Which then brings about Dekker’s “step-wise normalizations.” When I talk to people who are frustrated by their work environment, they frequently refer to what I now call broken promises:

• Someone has betrayed their trust or has stopped showing respect
• People act in ways that are not coherent with stated values
• The extra resources never arrived
• Another team failed to do their side of the bargain
• Their teammates didn’t offer to help in a bind
• The company transgressed on its commitment to craft and quality
• Promotions feel unfair and not equally applied
• Their team never iterated on the MVP, as promised
• The challenging projects never arrive
• Success theater is rewarded over hard work
• The company has stopped caring about innovation To top it off, they frequently don’t notice their broken promises.

The terrifying thing here is that to turn the tide you need to both 1) start delivering on your promises, and 2) do so while trust is lacking and you need people’s help. When you need trust the most, it is missing. That’s fricking hard, especially when the person might be blaming individuals and situations that are suffering under the same state of overload. The irony is that all of the hard, cognitively taxing work in the current situation has become normalized, whereas the hard work required for change is acute and distasteful. It is easier to remain in the status quo.

But remember when the company knocked [some effort] out of the park? It all seemed to change then, right?

Most software product developers have experienced a “swarm” or “surge” or “final push” on a high priority initiative. The team rallies to get something high priority done. Later at the bar (because, you know, you celebrate these types of things…it’s actually rewarded), the stereotypical executive says something like this:

Don’t you see what we can do when we put our mind to it! Why can’t all efforts be like this! We should do this all the time!To which the maxed out (and buzzed) individual contributors reply:

Of course it worked …. because we focused on something. Are you willing to let us focus in the future? Or do we need to keep all of the other promises we’ve kept.A project manager ambles along with their white wine and says something like:

Well, if we only had a better system for tracking all of our deliverables, and for estimating better, we’d be able to handle all of this. We just need a better process. Then we can split story points across all of our tasks, and hold daily dependency and risk-mitigation check-ins.What happens next? Does anything change? No, the drift continues. Something gives (probably quality, or keeping your best team members). Schedules eventually slip because quality has slipped, and you’ve lost your best team members. An environment of low trust percolates, and only the fittest (most adaptable in low trust environments) survive.

I’ve written a good deal about Kanban and the value of WIP (work in progress) constraints. But I realized recently that “the work” is only a small percentage of the promises we keep “at work”. As we add complexity to our products and organizations and relationships, we do so by creating a web of promises and commitments, ranging from explicit and actional to “open loops,” “incompletes,” and “stuff.” Promises are, in effect, dependencies. We can break them — and break the dependency — but that will have a ripple effect elsewhere.

To counteract this drift, I’d like to advance the idea of limiting PIP (promises in progress), and reducing the size of your promise overhead to what is manageable and humane. Optimize for promise flow efficiency.

Why use a loaded word like Promise? It feels kind of contracty. It feels like a manager asking for predictability, and “doing what you said you were going to do”. That’s not what I’m thinking about. Though that might be a byproduct.

I feel that trust is built and grown by frequently keeping our promises. Research says that delivering frequently on small promises beats out large promises delivered infrequently. I am NOT just referring to our promises to finish projects or check off action items (which might indeed be the least important promises we make). I include things like the promises in your culture deck, the promise to keep reasonable work hours, the promise of psychological safety, the promise to mentor co-workers, and the promise to engage people with challenging, but meaningful work.

To succeed at keeping our promises, we need to be incredibly disciplined about communicating and building shared understanding. One person’s “great idea you must do immediately” is another person’s “thing I might want to try eventually.” One person’s “they are going to help me advance in my career” is another person’s “we’ll chat about career stuff occasionally.” So you need that discipline.

Make fewer promises! Keep more promises. Deliver on promises. Respect the cognitive overhead of active promises. Prioritize. And make the promise that matters most: to trust and respect the people you work with.