Jun 062020
 

(originally posted on, ha, Facebook, June 3 2020)

It’s time. Data is the new capital, the new power. Zuckerberg has shown that Facebook’s quest for data — and thereby, power — is limited not by ethics, or even by morality. It’s limited ONLY by the limits that We The People will set. So…
 
Not suspending. Not temporarily disabling. Erasing as much data and then deleting as thoroughly as Facebook makes possible.
 
I will not willingly contribute to systemic oppression.
This is hard. It’s like throwing away a garage full of family keepsakes. It’s like volunteering for a lobotomy to erase treasured memories. It’s going to put a crimp in my ability to grow and manage my business on social media. It’s even going to be one less channel that I cannot use to help organize and connect good people together.
 
As someone who depends on social connection, this is very scary for me.
 
I realize now that it is exactly these sentiments that give Facebook the power that it has. And that power is harming the lives of too many other people. If people of color can stand up to armed police, this middle-aged white guy can delete a social media account. And urge others to do the same.
 
I’ll be posting instructions on how to back up and download your data. I’ll be reaching out to every single person on my “friend” list and sharing my email and phone number so we can stay connected via other means. A convenient way to maintain connections across the miles must never be paid for with the erosion of objective truth, equality, and basic human rights.
 
I’ll be off for good by 12am Central Time, Sunday June 7. (Due to Facebook’s own attempt to retain its users the actual deletion won’t go into effect until two weeks later, but I will not be logging in after the date above.)
 
I urge you all to join me.
Do your own research, a little reading on “big data.” A little reflection on oppressive systems. On political contributions. Some googling on how conflict and highly emotional exchanges actually help a platform like Facebook. On how different the very very rich are from the rest of us. Join me in some soul-searching about, hey now, just how serious are these claims, anyway?
Think about how our own very real, very good, very human senses of empathy, compassion, and connection are being used to power an unfeeling corporation to promote brutality.
 
And then please, do your part to take that power away. Vote. #DeleteFacebook
 Posted by at 6:22 pm
May 182017
 

My mother is going to laugh a lot at the fact that I’m writing this post, even if she’ll never admit it to me.  The idea that her son — who always used to get home late, sometimes knocking over the pots and pans that his father had set up against the door to announce his late arrival — is writing about time is a bit ironic.

But here we go. My good friend and excellent Agile Team Guide David A. Koontz (really, he’s an artist with teams; you should try to hire him) wrote an excellent article about Lead Time vs. Cycle Time, and the difference between how long we take to do a job vs. how long the customer waits for the results.

I’ve been working with Lean Kanban Inc. since last year, and I appreciate the sharp point they’ve put on terms around this issue. Here they are in a picture:

1. Customer Lead Time

The time from when we accept the customer’s request until deliver that request to the customer.

That’s it. Plain and simple. This is all the customer cares about!  The item could be “done” 5 minutes after the order is taken, but if it sits in a warehouse for a month before the customer gets it, the customer is still gonna be peeved.  Or as in David’s example, the item could sit around for a month and only take a few minutes to actually deliver. Either way the result is the same.

2. System Lead Time

The time from when we accept the customer’s request until the request reaches the first unbounded queue in the system.

This is a metric we care about when it comes to measuring and improving systems. Notice the Work In Process (WIP) limits in the picture above.  That last state, “Done” has no WIP limit. It’s potentially infinite. Even though we serviced the customer’s request at the end of Process C, it could sit around in a queue forever.

The reason we measure this only up to the point of the infinite queue is because we can only design and control systems that have WIP limits in them. Sometimes we can’t control what happens in that “Done” queue, so we can only work to improve everything up until that point. (At first. Once we get that under control, it’s time to have some conversations with the people in “Done.”)

This is why it’s important to have WIP limits on all work queues and buffers: if you don’t, then you don’t really have a pull system, and your ability to predict delivery is shot.

The actual LKI term for this metric is “Kanban System Lead Time.”  But if the first unbounded queue in your system is the Request buffer, guess what — you don’t have a kanban system. This, right here, is the most common pain I see when I’m asked to help with Agile delivery: a great Scrum engine with tightly-controlled WIP (from Sprint Planning), and a whole chain of unbounded queues upstream of it.

PRO TIP: your biggest predictability problem in this case is NOT your development process. :)

3. Time In Process (TIP)

The time that a particular request spends in a given process state.

This is what David called “cycle time,” and it’s a pretty common usage of the term. I prefer Time In Process because it’s clearer. “Lead Time” and “Cycle Time” can get confusing, so we just throw one term out. Yep, we don’t actually ever say “Cycle Time.” (Well, I try not to — old habits die hard.)

What about the time from Process A to Process C?  Easy, that’s just “the Time In Process for Process A, B, and C.” In our example above, TIP (Requests+A+B+C) for an item is the same as the System Lead Time for the item.

We use this in systems design to get a more fine-grained view of the system than System Lead Time.  And we use it day-to-day to meet our Service Level Expectations.  Do we expect most requests to spend 7 days TIP in Process B? Is this request here currently 6 days TIP? Then maybe we better get a move on and get it out of here — or think about renegotiating the customer request.

4. Working Time

Time spent on actually increasing the value of the item. Also called Touch Time.

In David’s example, this was also what he called “Cycle Time;” the time spent installing the basketball hoop. Often, the Working Time represents only a small fraction of the total Lead Time for the item. Which brings us to…

5. Waiting Time

Time where the item is not being actively worked on.

This is often a large portion of the total Lead Time (System, or Customer) for an item. This is where high WIP limits (or no WIP limits!) kills us. This is where multitasking kills us.  So much of the customer’s total wait time is just the request sitting around, or being shuttled back and forth from one person to another.  Which brings up…

6. Flow Efficiency

The ratio between total Working Time and total Waiting Time, expressed as a percentage of System Lead Time.

And here’s the second most common pain I see when asked to help with Agile delivery: poor flow efficiency.  In the example above, we take the customer’s order, and then it sits for a bit.  Then we start Process A and finish quickly… but it sits for a bit until it gets to Process B. Same thing happens with Process B. Process C is better; mostly we work on the request, with one brief interruption.

For systems with lousy flow efficiency, changing the system to reduce waiting times is going to be a huge bang for the buck — much more than improving the actual working processes. You’ll get faster delivery, and more focused, happier people who aren’t task-switching all the time.

One Last Distinction

In my recent AgileIndy talk, I made a call for 21st-century management to raise the game: we need to get better at managing systems, and leading people.

We sometimes use the terms above to refer to an individual request. “What’s the Time-in-Development for this FooBar Story? Is that going to affect our SLE?”  That’s valid. That’s the kind of question you’d hope to hear within the team, not from a manager.

If we are managing the systems, we use the terms I’ve outlined here to refer to requests in the aggregate — which really means referring to the system as a whole. “How can we get the System Lead Time down by 30% for all standard requests?” That’s also valid. And that’s the kind of question I really like to hear from management. 

Let the workers self-manage the work. Manage the systems. Lead the people.

Feb 232017
 
Image source: AOPA Flight Safety

My friend Scott Barnes tagged me about this article on factors affecting pilots’ decisions to land.

Scott’s share of this article reminds me of one more way in which my training as a Commercial Pilot and Flight Instructor influences my business consulting practices.

In aviation, we don’t think of an aborted landing as merely a landing that we “failed.” The aborted landing is actually a maneuver with procedures and performance standards. We train for it like any maneuver.

The Go-Around

Go-Around procedures. Source: code7700.com

Go-Around Procedure (image: code7700.com)

Sometimes a landing shouldn’t happen. The entire flight path to the runway was fraught, so those final 100 feet to wheels-down are going to be messy. Another aircraft is on the runway you were just cleared to land on. You got distracted and got “behind the airplane” (you aren’t thinking ahead, and have become more of a passenger than a pilot.) The landing was going great, but the wind gusts are worse right now than they were sixty seconds ago… and as you fight the gusts, you are running out of runway.

As a student pilot, I had my share of unpleasant landings, including one which came close to scraping the tail of the aircraft on the runway tarmac.

My instructor — after examining the tail of the aircraft and breathing a sigh of relief to find it unharmed — informed me that any of these is a totally valid reason to skip the landing and go around.  In fact, I should plan every landing as if it were going to be a go-around.

“Get back up safe in the sky, re-plan, and come around and try again. Landings don’t cause crashes; pilots forcing themselves into bad landings cause crashes.”

This was eye-opening advice. How cool: as Pilot-In-Command, I have choices! I’m NOT doomed to follow my plan down into a fiery impact with the ground!

Warning Signs

But how often, in business, do we “force ourselves into bad landings?” The article lists six factors for why pilots do so, and they should ring a bell for us in business.

I’ve taken the liberty of translating the article’s six factors into typical sound-bites that represent the thinking behind these factors:

  1. Plan Continuation Error — “We need to stick to the plan. Why else did we make one?” 
  2. Sunk Cost Effect“We’ve invested a lot of time/money in this course of action, we need to see some return.”
  3. Cognitive Dissonance“The alternative you suggest sounds too complicated. Our current course of action is simplest.”
  4. Complacency“We’ve done dozens of deployments like this, I don’t see why you’re so pessimistic.”
  5. Hindsight Bias“Those warning signs you talk about aren’t warning signs; they are they only thing that could have happened. Stop worrying about what DID happen and focus on what SHOULD happen.”
  6. Bounded Rationality/’Satisficing’“I’m not rationalizing risk away; I just don’t think a few annoyed theoretical customers is as risky as delaying our product release by a month.”

How often have you heard statements like these, prior to the business equivalent of a crash into the ground?

Image source: AOPA Flight Safety

Image source: AOPA

Crashes in business can take longer than in aviation, but both are awful to watch.  I once saw one go on for 4 months. There were dozens of “passengers” (senior employees) involved in this particular venture, but despite all evidence, the “pilot” (C-level leader) continued to make statements that sounded a lot like those above.

Right up until the point that the company’s core business and customers were threatened.

It was the business equivalent of feeling the aircraft tail scrape the runway.

Plan the Go-Around — Detect When to Execute

I’m not trying to paralyze you with crash stories and accident reports. I’m hoping to show you that you have options besides “do or die.”

But only if you plan to have options. If there are warning signs, don’t simply hope that everything will be okay. Don’t shove the responsibility for a successful landing off onto your people. Question. Test your assumptions.

Here are some antidotes to the above risky soundbites:

  1. Plan for AlternativesWhat “go-around” procedures do we have if a risk manifests? Are we ready to execute them?
  2. Think Incremental ROIWe’ve invested a lot of time/money; how do we ensure that we get at least partial ROI no matter what?
  3. Be SkepticalWe’ve done dozens of successful deployments like this. But what’s different about this one?  
  4. View Risks as Discovered Work — I hear some concerns. Sounds like we’ve discovered some new risks. What work do we have to do to minimize these risks? Is this work in the new plan?
  5. Set Triggering ConditionsLooking ahead, under what circumstances might we need to change our plans? How can we tell if those conditions occur?
  6. Be Open to Peer ReviewI don’t think the risk of failure is as great as the risk of delay. But maybe I’m biased. So I’ve asked people outside my department for their assessment.

In aviation, we say:

“Plan every landing as a go-around, plan every [instrument weather] approach as a missed approach.”

Hope is not a strategy. “Go around triggers” for a project at risk from outside commitments.

In business, this means that while yes, we should “think positive” and “plan to ship it,” successfully delivering means that we also detect when that plan is no longer feasible, and then re-plan using newly discovered information.

Agile Development methods bake this re-planning into their process. Unfortunately too often the surrounding business processes do not. Too often, the people leading those processes view re-planning as a sign of failure.

So watch out for those warning sound bites. And stop thinking of deviation from the plan as failure. Start thinking of it as a procedure to be practiced and performed just like delivery.

As we say about go-arounds in aviation:

“Better to explain why you DID it, than for others to find out after the crash why you DIDN’T.”

 Posted by at 12:50 pm
Dec 152016
 

The rules of the post-WWII economy are becoming less relevant. Ben Thompson offers a view of what we could hope will replace it:

…instead of trying to recreate a 1950s fantasy of employment for life on an assembly line, the goal should be to create a far more dynamic labor market with a defined floor and significantly greater upside than the old system.

We are already seeing a hint of the opportunities offered in such a world with the rise of the “gig economy.” People sell crafts on Etsy, raise money for charities on Twitch, and drive for Uber.

But taking this to its extreme sounds pretty scary without some “floor” on income. You mean, I’m going to have to sell on Etsy and drive for Uber just to be able to afford food and medicine?

No. The idea is that, free of the need to struggle for basic subsistence, you can pursue different ceilings:

…a universal basic income alone offers some degree of financial security, but it does not offer dignity to the recipient, or any return for society beyond a reduction in guilt. What is most important, and what offers the highest return, is enabling more and better ways to work and ultimately create…

…who knows what sorts of products and services might result from an emboldened and secure middle class?

This reminded me a lot of the RSA Animate of Daniel Pink’s “Drive.” Specifically the findings about incentives for post-industrial work:

For work requiring rudimentary cognitive skill, people are motivated by Autonomy, Mastery, & Purpose — once you take security off the table.

Ben encourages those of us in the technological elite to focus less on using our tech to become (pardon the phrase) uber-rich and comfy, and more on helping bring about the world he describes:

To that end, technology executives and venture capitalists should lead the campaign for the type of reforms I have listed above. More importantly, they should match their rhetoric with actions: companies like Apple and Google should strive to be technology leaders, not tax avoidance ones…

He goes on to list a number of specific things that tech execs and VCs should support. Really, read the article.

I’m not hopeful, myself. In my own work, I’ve observed a strong temptation in tech leaders to apply old-world thinking to the new world of technology. “Well,” goes the (ir)rationale, “I went to school and worked hard, I deserve to make as much money as I can from it. It’s unfair for me to pay more in taxes.”

And baked into some of these conversations that I have is this undercurrent of “besides, it’s not like people can do without their Twitter/online banking/videogames. Anyone who blames technology is just a Luddite.”

Ben cautions

…people are not always rational, especially when they are desperate. It is absolutely in the industry’s best interests to not only participate in but lead the creation of a new system that works to the benefit of all…

The alternative is far worse: once automation arrives, guess who is going to be the scapegoat?

Ah, what does he know? It’s the 21st century. And we upper middle-class technologists have never had to fear a Reign of Terror.

But America is still young, as a nation goes.

There’s still time.

 Posted by at 4:04 pm
Sep 232016
 

No, even though 2016 marks the 50th anniversary of Star Trek, I’m not talking about James T. Kirk and the starship Enterprise.

zumwalt

DDG-1000, the USS Zumwalt (U.S. Navy)

I’m talking about Captain James A. Kirk and the USS Zumwalt, America’s “largest and most technologically sophisticated destroyer.” The Zumwalt grabbed my attention when it was commissioned earlier this month because not only is it larger, more powerful, and stealthier than current destroyers, it boasts a crew that is half the size of other ships in its class.

The story of this real-life, science-fact-not-science-fiction vessel and her crew is a great read, and not just because of the cool tech.  There are many lessons here for leaders of non-military “enterprises” such as software development, business, scientific research, and non-profit/NGOs.

In this series, I’ll point out just four.

Lesson 1. Technology & Automation Are Required

The Zumwalt doesn’t have gunners’ mates to operate her guns, a separate radio room for communications, or a helmsman to steer the ship. All these tasks can be performed by an officer standing watch in the Ops Center because these routine, manual tasks are handled by automated systems.

The technology of automation is quite a bit more capable now than it was a decade ago.

A good friend of mine used to work in “network operations security.” His team would spend their days in repetitive tasks that resembled manual labor. Inventorying hardware and software. Researching the latest threats online. Manually patching vulnerabilities wherever they could. It was a Sisyphusian and sometimes scary job, always trying to stay one step ahead of the hackers.

Zumwalt Ops Center (Raytheon)

Zumwalt Ops Center (Raytheon)

But today my friend’s team has software to automate the tasks they used to do. The tech hasn’t replaced the people, it’s raised their game. The software still needs to be told what to do in order to accomplish the why of the company’s risk management strategy. And it’s my friend’s team — now called “risk management” — who is responsible for accomplishing that “why.” The tech has enabled his team to deliver better, stronger services to their company.

Proper automation can enable humans to focus on tasks like synthesizing information, making good decisions, setting strategy, and employing their own technical know-how.  Skills that, you know, require a human.

Let the machines handle the repetitive mechanical tasks; they’re better at it. Don’t expect your systems to be able to handle too much variance and unpredictability; that’s what your people are for. Use the tech to raise the game of your peoples’ service delivery. Tech should allow your people to directly implement the overall goals and strategy of your organization.

If you employ technology this way, you can free up your smart, motivated people from the routine tasks of data-gathering and paper-pushing. You can unlock a pool of potential capability for your organization.

In the next article we’ll look at why automation and technology, while necessary, are not sufficient.

All articles in this series:

  1. “Raise the Game” — Automation is Required (this page)
  2. “Same Sheet, Different Data” — Tech is Not Enough
  3. Management Overhead — Reduce the Waste
  4. Team Skills Needed — Diversity, Communication, Mutual Support
Sep 222016
 

In the previous section, we explored how technology can potentially free up capability. On a high-tech destroyer or in cyber-security, tech can “raise the game” of people in the enterprise.

Technology offers tireless, rapid, low-variance behavior. That doesn’t necessarily mean more intelligent behavior.

Lesson 2. Automation Is Necessary, But Not Sufficient

green-bar-paperOne of my first jobs was loading magnetic tapes onto a backup machine and physically delivering printed reports around the office. (Yes, green-bar paper!) Occasionally I’d mis-load a tape or deliver a report to the wrong place and oh boy, would the phones would start ringing. Cool story, bro, but now we’re better than that, right? Today we’d consider this an egregious waste of human talent.

Yet we think nothing of employees spending hours fighting Excel. Sorting, querying, transposing. We haven’t raised the game. We’ve just made it harder to win. Technology gives you more of what you already have, faster.

“S.S.D.D.” used to mean “Same Sh*t, Different Day” but now it means “Same Sheet, Different Data.”

Image: Walt Disney Co.

Mickey’s automation problems in Fantasia (Walt Disney Co.)

If you add automation without engaging your people, you accelerate whatever already exists in your org. And you may accelerate the bad faster than the good.

If your enterprise (starship, sailing ship, or company) is full of reporting, bureaucracy, fear, or butt-covering, adding a “technical solution” may just amplify that.

I’ve seen far too many orgs drowning in data, yet thirsting for insight. Where people have become servants of the systems, not the other way around. And the mission is forgotten.

The crew of the Zumwalt avoided this by designing around the human side of the equation. Every new shipboard computer system was prototyped and adjusted based on feedback from the crew. Then they trained hands-on, side-by-side with the engineers to be ready to sail the new space-age destroyer.

Electrician’s Mate 1st Class Donald Goldsberry and Electrician's Mate 2nd Class Radarwin Adams of the pre-commissioning crew of the future USS Zumwalt (DDG 1000) train to use the common display system console and engineering control system screen navigation at Naval Surface Warfare Center Carderock Division - Ship Systems Engineering Station (NSWCCD-SSES) in Philadelphia (U.S. Navy photo by Public Affairs Specialist Joseph Battista/Released).

Zumwalt crew members cross-train shared tasks on a shared console (U.S. Navy)

So pay close attention when you add technology. Consciously prioritize the human issues above the technological ones. Use technology to free your thought-workers for thinking. Be ever alert to the failure mode of people “feeding the machines.”

As a leader, you need to enable your teams to move from what to why.  You need to enable them to make the same shift that my friend’s “network operations security” team made when they graduated to “risk management.”

Set clear strategy, manage the work, and let people self-organize around it. Or your organization’s relationship with technology might look a bit like Mickey’s above.

In Lesson 3: Management Overhead, we’ll look at how raising the game for your people re-defines the value of “management.”

All articles in this series:

  1. Raise the Game — Automation is Required
  2. “Same Sheet, Different Data” — Tech is Not Enough (this page)
  3. Management Overhead — Reduce the Waste
  4. Team Skills Needed — Diversity, Communication, Mutual Support
 Posted by at 5:17 pm
Sep 212016
 

In “Same Sheet, Different Data“, we saw how subordinating human intelligence to technology is a failure to “raise the game.” The story of the Zumwalt highlights another opportunity of work in the 21st century: raising the game means that much of traditional management effort is waste.

Lesson 3. Reduce the Wasted Effort of Traditional Management

jose

An all-too familiar problem in many corporations. (Reddit)

Technology on the Zumwalt — and in the workplace — has shifted jobs away from routine tasks and toward those requiring technical expertise. Cross-training and crew communication have made layers of top-down supervision redundant.

Yet in the majority of organizations that aren’t a stealth destroyer, these redundant managerial structures remain in place. A recent HBR article estimates the current waste — that’s no value added — of management overhead in the U.S. at 17% of GDP. Three. Trillion. Dollars. Every year.

Roger Perlmutter has been at the helm of R&D at pharmaceutical giant Merck since 2013. One of his early tactics was to simply eliminate the redundant layers:

The problem, Perlmutter says, was that the labs had become tied up in bureaucracy, with too many people reporting to other people reporting to other people, all of them asking each other for permission slips. “Everybody stayed in their swim lanes. I’m actually interested in people who want to own the pool.”

Forget the pool, Captain Kirk and his crew are owning the ocean. Kirk’s job as a leader is to “create a sense of mission and teamwork.”  This enables his team to be responsible. To “not just accept delivery of the ship, but to take delivery of the ship.” And as we saw in Lesson 1, they use their game-raising automation to directly control the gunnery, communications, and steering of the ship.

Capt. James A. Kirk (U.S. Navy)

Capt. James A. Kirk (U.S. Navy)

The result? Despite being a much larger vessel, Captain Kirk’s modern destroyer has a crew complement that is the smallest since those of the 1930’s.

Maybe some organizations can get away with the extra bureaucracy. Maybe it’s okay for their service delivery to be thinly smeared across multiple managers/directors. As embarrassing as it might be to admit, perhaps their missions just aren’t as critical as that of Captain Kirk’s crew.

But just think what your enterprise could be like you were able to create that sense of mission and teamwork.  If everyone who worked there directly added value, because you aren’t creating waste with adult baby-sitters.

In our final lesson (for now), we’ll look at the skills that differentiate the superstars in the 21st century workforce.

 

All articles in this series:

  1. “Raise the Game” — Automation is Required
  2. “Same Sheet, Different Data” — Tech Is Not Enough
  3. Management Overhead — Reduce the Waste (this page)
  4. Team Skills Needed — Diversity, Communication, Mutual Support
 Posted by at 5:17 pm