The first time I heard the following expression was from my friend Gene Kim
. We were in Boston?, Vegas?, in his space travel portal, I honestly don’t remember, but I’ve used it a million times since:
“START STOPPING & STOP STARTTING”
It wasn’t soon after that, despite the traction and investor interest, I decided to pack it on my own software startup.
Frankly, I’ve been accused from many of my peers and all of my staff, that I’m the guy who grabs the plane parts, jumps off the cliff and tries building the plane before we hit the ground. I absolutely take on too much. It’s not because I’m some sort of ego-maniac… I mean, I might be, but that’s not why I say “yes” to what was asked of me. It’s simply because I don’t have to say “no”. Occasionally I was the CI”No”, who would dogmatically tell the business to go pound sand, or throw out the “that violates IT policy” card. For the most part though, I found a way to get things done. In fact, a lot of times I said NO, and got it done anyway, like from marketing who needed an emergency change to change the banner from blue to red.
The Value of Saying NO
The reality is there is value in saying NO. When you look at your current in-flight IT projects, there is a tremendous amount of Work In Progress (WIP) happening. For the most part, this is planned work which has been prioritized and resourced appropriately. Many of my projects were planned extremely well. Ok, most.
When scope increase is interjected, this disrupts the flow of in-progress work. When the infrastructure is fragile and unstable, this also interrupts the flow of work. These interruptions not only increase cost, risk and time, it can severely impact the cadence and rhythm of your teams.
One of the impressive cultural norms I’ve come to see with high-performing IT organizations, is there ability to say “NO” without actually saying NO. Keeping a limit on the DevOps team size, their ability to handle WIP is fairly fixed. Having work activity broken down into deliverable components, stacked into a specific measurable outcome, drives the scope to be tightly defined. And here is the big piece: “CHANGE requests are expected”. These teams know they will not get it right, so they are planning on un-planned requests. Feedback that something is not right, something is not working, or it can be better. So when these planned “un-planned” events happen, the answer is YES. The issue now is WHEN.
Team size, back-log scope, and automation are all built around these constraints by design. The objective is to accelerate the flow of work in progress and increase quality. By design, “annoying stupid” requests are simplified, and validated quickly.
This allows IT to be a willing and able partner for ideas and requests. It makes us look like we are actually asking for more, but in reality, we are helping our business partners to refine and prioritize their work on their own. Giving them enough functionality to enable them to truly see what it is they want and what they truly need to achieve their business outcomes.
Transparently showing the work in progress, brings our business partners into the conversation of value.
So let em watch you WIP and watch them nay nay.
In my next blog ill talk about why & when labeling your work matters, and when they don’t.