Root Cause of Business Pain Series Part 1: Functional and Technical Mismanagement of Solutions

The "Second Machine Age" has shifted the world underfoot. No memo has been sent out to make the mental shift. Below is an exploration of how work has changed for the "knowledge worker" along with implications for the management of workers and work.

Tim O'Reilly explains the mental shift needed in the following quote:

"If you think with the 20th century factory mindset, you might believe that the tens of thousands of software engineers in companies like Google, Amazon, and Facebook spend their days grinding out products just like their industrial forebears, only today they are producing software rather than physical goods. If instead you step back and view these companies with a 21st century mindset, you realize that a large part of what they do--delivering search results, news and information, social network status updates, relevant products for purchase, drivers on demand--is done by software programs and algorithms. These programs are workers; and the programmers who create them are their managers. Each day, these managers take in feedback about their workers' performance..." (emphasis added)

It's been my observation that these "worker solutions" (digital reports, automations and tech solutions of various kinds) are being mismanaged and no wonder. If they are not even seen as a thing to manage properly, that's going to lead to mismanagement. The investments needed to manage these solutions properly will not get made under the pressure of resource constraints.

So, what you end up with, are technical environments within businesses that become a disaster area of poorly mismanaged solutions. Yet before I dig into some experiences in the wild, I'd like to explore O'Reilly's analogy of programs as workers a bit more.

No management organization, one would think, would be so negligent as to hire scores of people and assign them all to a single manager, or worse yet, nobody at all.

Think of the insanity of hiring scores of people and one after the other, they ask "Who will I be reporting to?" and you answer "Well, nobody in particular. We just thought that we'd set you off and you do your job, Jane/Janice/Jenny - whatever your name is. If something seems to go wrong, we may go track it down and maybe find somebody to talk to you." The worker wanders off, wondering who will help manage her career over time. And yet, this is precisely the situation that happens to an automation or "worker solution" that's added to an environment with no clear plan for how it will be managed.

So, there are scenarios where an operations or development team are collectively made managers over sometimes vast arrays of these "worker solutions" without any clear sense for what all of these things are named, what they do and when, who has the expertise to give them feedback and adjust them, what feedback has been given to them in the past, what business functions gave rise to their need, when they will be retired, what consistent strategy do they need to stay well maintained, and the list goes on.

When a request comes in to "give feedback" to one or more of these solutions, a host of problems have to be overcome upfront to find the right one, discover its inner workings and determine just the right feedback to give it. As an aside, often the feedback, done quickly under duress, lacks continuity and will actually degrade the solution over time. So, the mangers of these worker solutions just plain look bad because it takes sometimes hours or days to do the discovery and a mere few minutes to actually give feedback. The business wonders why it's taking so long. Frustration and resentment grow.

The industry sees the folly in assigning vastly too many people to a single people manager. All the people under that management scenario would get starved for people building, career building and other forms of attention they would normally get in a people-centric work culture. Yet the industry seems to commonly operate obliviously to the incredible folly of assigning 50, 100, 300 or more "worker solutions" to people who sometimes have never received the slightest effective briefing on where these solutions live, what they are named, how they should be maintained, etc. What could go wrong?!

What I'd like to add here, is the notion of thinking about these "worker solutions" as needing both functional management and technical management. In other words, they need matrixed management that is coordinated. They need management both from the business function standpoint and the technical management standpoint. I'll elaborate below.

From functional management, they ought to get things like:

• A Unique, and Descriptive Name that everyone will use to address it

Have you ever seen a case where a solution will have multiple names used by various people, causing a lot of confusion and dialogue overhead as various departments try often unsuccessfully to communicate about what's needed? That's functional mismanagement of naming. Names of things are very important and often out of indecision or neglect, it gets done poorly. A price is paid as a result.

• A Business Value Context to explain what function the worker solution serves and what workflows does it support

Without knowing the business needs a function serves, the feedback often lacks the context of business value and criticality. Have you ever seen this information missing? That's functional mismanagement of business context.

• A Marshaling Context for people to know when the solution is used (seasonal, periodic, one-time, etc.)

Have you ever seen short lead times for something, where the short lead time is a result of someone attempting to use a solution on the very day that an output is due only to find that the solution is in need of feedback that only the technical management can provide? Could it have been checked much earlier? That's functional mismanagement of marshaling context.

• Impact Context to understand what risks or impacts are caused by an outage, incorrect or low performance of the solution.

Have you ever seen a case where nobody seems to know whether a workaround exists and what the alternatives are if a solution doesn't perform as expected? Have you seen cases where a requester is just told to go put in a request to have technical managers fix a solution, but maybe someone else who is less of a bottleneck has the ability to provide the same solution just as soon or sooner?

• Feedback context of past feedback requested from business and delivered by technicians

Have you ever seen a case where the business side of the house has no sense for what feedback has been given to a particular solution? Perhaps nobody decided where that feedback can be chronicled, or maybe it was all in somebody's head, but now that person is gone. Is that good functional management?

Okay - now on to the technical management of these worker solutions.

• Feedback Readiness. 

Have you ever seen a case where only one single person or maybe even nobody is in a good position to troubleshoot and adjust a given solution at a given point in time? Perhaps it's going to take hours or days to load particular software tools and set up various environments in order to undergo a feedback development cycle appropriate for the risk context - and none of this was prepared for upfront - it's all done at the time feedback is needed, putting the business in a tough spot. That's technical mismanagement.

• Location Context

Where does the solution live? If the technical managers don't know where it lives, that's a problem. Where is the interface to the business or clients located? Where on the network are the components stored? Where in version control is it located (if at all)? If a search and rescue effort is needed just to go find these various locations before progress on a fix can be started, that's going to slow down the response time and cause frustrations all around. Has anyone seen this happen?

• Technical Feedback Context

What technical feedback has been given, by whom, for what reason? If none of this is available, then we'll have to re-learn things all over again or perhaps just suffer under the loss of this important contextual information in the life of the solution.

• Sustained Strategies to give technical managers a shared understanding of how the solution will be maintained over time and various technical risks related to the solution will be mitigated over time.

The organization will suffer if it's got no good idea as to what it will cost and what efforts will be made to sustain the useful life of various solutions. Has anyone seen the business act oblivious to the need to sustain existing strategies, and seem to have an unhealthy obsession for focusing on new solutions while making incorrect assumptions about what it takes to maintain existing solutions? Has anyone seen a technical strategy shift multiple times for the relevant set of solutions, causing incompatibilities, inconsistencies and other barriers to scalability due to indecision and lack of management of sustained strategies?

In one case study, I found every one of the ailments mentioned above. When I got exposed to Tim O'Reilly's statement noted above, it occurred to me that every one of those ailments were linked to it. When I thought of the need for both functional and technical management of these workers solutions, I was able to neatly organize all of the observations I made over an 8-month time period under either functional or technical mismanagement.

In this case study, the ongoing part is the deciding of what to do about it. If the business is "asleep" and just so used to working the way it does, and it doesn't see this root cause of problems, or just has become so accustomed to the pain that it becomes an accepted expectation, then what is to be done?

In some circles (kanban), the industry talks about STATIK: Systems Thinking Approach to Implementing Kanban, which includes identifying pain points. That becomes an anchor and an orientation point that will be needed as various people in the organization start to get oriented about what's wrong and what needs to be done about it. If the pain points aren't surfaced and made clear, the possiblility of radical disorientation often derails the continuous improvement initiative. That's good stuff. Yet if a business isn't willing or able to acknowledge the pain, it's not going to get very far.

For my case study, the jury is still out. We'll see. Meanwhile, I hope this Part 1 has been helpful to spot a key root cause that could be plaguing a business you work with.

Experience Report: Blitz Planning Technique Used to Plan a Year of Scouts

I've written this report so people versed in blitz planning can review quickly and then move on to consider implications and wider applicability of the small adjustments to other scenarios.

For those who need more material on blitz planning basics and who are interested in how BSA suggests the planning be done, supplemental sections are there for you near the end.

Experience Report:

Figure 1

To accommodate this age group (age 11), brainstorming options was done beforehand.

To set up, I brought in two chalkboards to hold the menus of options in addition to a third chalkboard to represent the final calendar deliverable.

Options were posted on the board to make it easy for each scout to walk up and vote on their top 5 choices by placing a vote sticker on the option.

What you see is four menus of options: core scout activities, elective interest activities, service projects and camping locations.

When voting was complete, a subset of options was decorated with vote stickers. So, it was clear which options should be included in the plan. Counting it up, hundreds of decisions are represented by the various options, the votes, the slotting and the support decisions.

Figure 2

In Figure 2, options were transferred to a simplified calendar. Activities for this troop happen on a particular day of the week, or on particular weekends. So, the calendar was paired down to a set of relevant dates. There was room to place an activity in a date slot. Later, an alternate activity was added as well.

Adults and volunteers were given white sticky notes to place their name on. They walked up to the calendar and picked dates that they will help plan, execute and support. Some dates remained unsupported, but we had a clear view of the gaps that would need to be filled later.

The meeting took less than an hour. Any longer than an hour would have been a problem and would have required a special dispensation.

In short, I deem the experiment to be highly successful in outcome particularly on gaining awareness and engagement from the broader group.

Wider Applicability:
Part of what's novel here is the age range. It worked on 11-year-olds. So, the simplification of complex planning shines through.

It would be easy to miss this point, but this was subcommittee work - so this is relevant to the planning work done by subcommittees. Parents tended to see themselves as part of the wider set of stakeholders but wanted little to no part in the planning. That was to be done by a subcommittee of volunteer scout leaders and the scouts.

If all work to be done by an organization were done in general assembly, each decision would cost (effort time) x (expense of each member per time unit). That's usually too expensive in time and money. So, certain work is broken out to the subcommittee for efficiency. Yet what's often neglected is that the general assembly then needs to become briefed effectively on the subcommittee work. Not only that, but the engagement of the general assembly needs to be achieved in an environment of competing demands on attention. It's common for general awareness and engagement to suffer greatly. People underestimate the cost of the subsequent awareness and engagement.

So, in a non-trivial planning effort such as this, the magic comes from combining the virtues of general assembly work with subcommittee work. That means doing the subcommittee work in a short timeframe that can fit within a general assembly meeting - usually not possible with traditional planning techniques.

If you can pull that off, you get the awareness and engagement of the general assembly while knocking out the subcommittee work.

That's the magic I found in using the blitz planning technique here. I got hundreds of choice, priority, mapping and support decisions made very quickly in a general assembly environment where everyone was briefed and maximum engagement could be achieved. The visual nature of the technique boosted awareness and engagement.

The Official BSA Planning Approach (From My Perspective):
When someone asked me to plan the scouting activities, they were asking me to do something I didn't know how to do. So, I had to look up how the scouting organization advises the planning to be done. To me, it looked implausible. I asked my predecessors about it. They told me they found it so difficult, they would just do a piece of it quarterly.

See here.

Upon reading it, there's a veneer of rationality to it. It seems to have some steps. But one doesn't have to look too closely to see some fatal assumptions and flaws.

The advice, as I interpret it, is to hold a "planning conference." This is a long-drawn, fairly mythical-sounding meeting with all stakeholders where a ton of work gets done in the timeframe of a meeting that people are willing to attend.

Some prep work is done beforehand, to identify constraints and assumptions for calendar dates. In the meeting, the group must brainstorm ideas and hear the ideas of anyone with ideas. Next, these ideas must be prioritized. Then, concrete decisions need to be made about what to add to the calendar. The objective is to produce the key deliverable, which is a calendar full of activities.

I was incredulous that all this could happen in a single meeting with any level acceptable level of quality of outcome.

At age eleven, a 20-minute or so brainstorm session could yield you very few workable ideas. The very crux of the exercise is to get a high-quality menu of options to choose from. A single brainstorm session under the duress of a planning conference isn't going to work ten times out of ten, in my estimation.

Blitz planning to the rescue.

Brief on Blitz Planning:
Sofware Development requires a group to make a lot of shared decisions quickly under constraint.

Blitz Planning is a technique to do this. It's been in the repertoire for a while, yet I don't often hear much noise being made about it. I've been in several environments where nobody had heard of it. It might need to be rediscovered. It's been highlighted by Alistair Cockburn, among others.

In short, blitz planning starts off with rapid-fire brainstorming in a visual way. Blank cards and pens are handed out. On the cards are written pieces of something big-picture to be done or built by a group. The group goes to work identifying smaller pieces until they think 80% or so have been covered.

Next, on tables, the cards are arranged into a timeline and subdivided to represent things to be done in set blocks of time. So, information is added to the cards to represent estimations of effort required. Risk and value are estimated to aid prioritization.

What you end up with in short order is a sketch of a complex project which can then be refined and evaluated. The lack of inertia caused by staring at a blank canvas disappears.

I've seen it work well on software projects. So, I thought I'd try it on this volunteer assignment I took on to plan a year of scouting activities. This would help test the boundaries of the technique, as these scouts were 11 years old.

Preparation Phase:
I categorized activities into three groupings: core scout, elective interest, and camping/outings. I sent out three separate surveys to glean well-formed ideas for each category, two weeks apart.

So, for two weeks, the objective was to send out the questionnaire to each scout and get their parents to assist them with filling out the survey. Two weeks worked well because some people were unreachable for a week, but all was not lost. There was a lot of forgetting to overcome. Multiple follow-ups were required, along with quite a bit of priming not only for the scouts but for the parents as well. If I were to do it over again, time permitting, I'd even allocate three weeks for each category.

Approach to the Deliverable:
The deliverable is a calendar, filled out. Well, calendaring is tricky and fairly overwhelming. I didn't worry about the calendar of specific dates per se. I decided to decouple the time slots into a more abstract concept: un-calendared time slots. The goal would be to fill in time slots, that could then be swapped in or out, and be given an extra option for indoor-outdoor to account for weather issues.

Some tweaks I would do in hindsight:
1. The posts of adult support for each activity was pretty slim as seen in Fig. 2. I would prime the parents better to get them to the meeting. I would create a mitigation for those that would not be attending - something like "your name will be placed on 4-6 activities. If you would like a choice in which those are, you can choose to attend. If you can't support an activity you're assigned, you'll need to find an alternative stand-in to take your place."

2. One of the menus of options, service projects was weaker than the other menus. I would have taken an additional week to boost the quality of that menu. I took 2 weeks for each, and I couldn't have done that quicker because I needed several opportunities to follow up and coach the responses to surveys sent out to solicit good options.

Getting Value from the Yearly Planning Cycle

Key Takeaway: If you take nothing else away from what I write below, take away this Vimeo video of Don Reinertsen: Decentralizing Control: How Aligned Initiative Conquers Uncertainty

A while back, I wrote an article about the yearly planning cycle. I don't argue that the common top-down yearly planning cycle should be scrapped altogether. Yet there are some typical problems with it.

My top two issues as I wrote then are as follows:

1. Being top-down, the cycle can easily miss out on all the wisdom found in the trenches.

2. When leaders go on retreat and come back with directives that nobody's seen before, the education and engagement lift to get buy-in from everyone seems as unlikely and as expensive as possible. Surely there's a better way to achieve buy-in.

After I wrote that I re-read a section of Don Reinertsen's "Flow" book on the topic of planning. As he rehearses, in the military, planning is done to achieve alignment.

According to this strategy, it's understood that the plans will change. That doesn't negate the purpose of the planning. Once people are initially aligned, then they can make the necessary adjustments from there. They are empowered to make appropriate adjustments.

This has been tested in the field of battle. There's a strong argument for this strategy. I find it compelling. Yet I don't hear much talk about doing this in business.

To me, this is yet another case where great practices and ideas are already here, but just not distributed widely.

So, the takeaway for me is, if an org is doing the yearly planning cycle with the goal in mind to achieve alignment, then the game plan still needs to be understood across the organization, but it's not a problem if adjustments are made if they're done strategically.

If the goal in mind is to make a plan and then stick to it no matter what (pretty much), that's a heavier lift. Whatever org decides to do that should be prepared to spend more time and effort achieving awareness, buy-in, and engagement.

From my experiences in business, the buy-in and engagement are both the more difficult areas to get right and the most neglected. So, I'll have to talk more about that later.