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
- 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.
