From the Desk of Sean Jackson – The Peanut Butter Peter Principle, Part II: Effective Countermeasures
In July’s post we looked at how overburden limits one’s effectiveness – an effect I dubbed the “Peanut Butter Peter Principle.” In this post we will look at some effective countermeasures that my team and I put into place.
One day, when I was dropping off some clothes at the dry cleaner, the owner, after making note of my items and instructions asked, “Is next Wednesday okay for you to pick these up?” During the course of my many visits to this dry cleaner over the years, I had always agreed, often mindlessly, with the date proposed. But, this particular morning – with the analysis of the countermeasures to the Peanut Butter Peter Principle problem running around in my head – I said, “Tim, what’s the earliest that you could get these back to me?” “I can get them back to you in 24 hours, if you need them, but I will have to charge you extra.” “And if I need them a day earlier than the day you’ve offered?” “Well, three business days is our standard, but this week, things are light enough that I can do two days, if you need them back sooner, but it would have to be at the very end of the day, Tuesday,” he replied helpfully. It was at that moment that it clicked. I thanked Tim and told him Wednesday was fine. I had what I needed.
The answer to the cultural prohibition against saying “no” is the ability to ask “when?” as in, “I can have this done in three days. Is that okay?” With this small breakthrough, we had the start of a plan.
Visibility is essential
Making the work visible was the first step in establishing and communicating priority. We did this by creating a simple Kanban board using painter’s tape on the wall directly behind the desks of the team members. As customers came by, they asked questions regarding the Kanban boards. They were somewhat surprised to see the amount of work waiting to be pulled into “production” and one asked about how priority was established. We responded that priority was determined by the order of task arrival.
We had three columns: “To Do, Doing, and Done.” When a task was completed, the individual performing the task would move the note from the “Doing” column to the “Done” column, freeing up space in the “Doing” column. The individual would then take a note from the top of the “To Do” column and move it into the “Doing” column, “pulling” the work through the Kanban board. At the end of each day, we had each team member track the rate at which they were able to move tasks through their Kanban board and had them use that rate as their estimated throughput for the next day. Over time, they got very good at sizing tasks and estimating their throughput.
The best part was when I heard one of the team members respond to a customer’s request with, “I can have that done in four days. Does that work for you?" The customer replied. “I don’t need it until next Friday (ten days). I see you have a long list of things to do.” The culture of “nice” was working for everyone now. There were some hurdles to overcome as we progressed along the path (“emergencies” and attempts to cut in line), but the basic system was in place and working.
Countermeasures to the Peanut Butter Peter Principle start with making work visible. If folks can’t see it, they assume it doesn’t exist. Next, be clear regarding priorities. If you lack the authority to set priorities, don’t accept the responsibility for setting priorities. Just commit to doing the work in order of arrival and leave the prioritization to those with the authority (and responsibility) to do so. Finally, limit work in process. Take control of your estimates and your throughput, being as clear with your customers about “when” you will deliver as you are about “what” you will deliver.
Several weeks later, when visiting the dry cleaner, I thanked Tim for his help, explaining how his asking me “when” helped me solve a problem with my team at work. He told me he was happy he could help and then got down to business, pointing out a stain on one of my shirts. “I will pre-spot this for you,” he informed me as he set the shirt aside on the counter. As I mulled potential causes for the stain, I concluded that it was most likely peanut butter.
From the Desk of Sean Jackson: The Peanut Butter Peter Principle
Sean updating the Ufirst Project kanban board
As my family’s designated chef de cuisine, I was once assigned the formidable task of providing my daughter, a ravenous toddler, with a peanut butter and jelly sandwich. She ate the sandwich with all the reserve and discerning wisdom of a budding connoisseur and, at the conclusion of her meal, with a radiant smile she declared, “You make the best peanut butter and jelly sandwiches in the world!” Flattered of course, and wanting to duplicate the experience, I could not resist inquiring, “Why is it so tasty?” She said, “There’s always peanut butter and jelly in every bite. You spread it right to the edge.” Rewarded by her exuberance and sincere praise, over the years, I have worked to refine and expand my cooking skills. This cherished memory has often informed my lean journey in different ways as well. We will explore one of those ways here.
In the 1960s, education professor Dr. Laurence J. Peter observed employees being promoted based upon their success in their current job until reaching a level in the organization where they were no longer competent. The individuals then spent the remainder of their careers in that organization stuck on what he called “Peter’s Plateau.” His resulting principle, that "In a hierarchy every employee tends to rise to his level of incompetence...” was memorialized in a 1969 book he co-authored with Raymond Hull titled “The Peter Principle: Why Things Always Go Wrong.” The book is still in print and contains many useful and relevant insights delivered with a healthy degree of humor. It is well worth reading.
How does this connect with a peanut butter sandwich? For that, we will need one more ingredient, from a time when I observed an organization that was struggling with innovation.
The organization had a flat structure (three levels) and the culture encouraged employees to “just do it.” Employees who just did it were recognized as “valuable team players” while those who struggled were politely marginalized. The organization also prided itself on being “nice.” In the preserve of the culture, saying “no” to a request from a leader was out of the question (“it’s not nice”). I learned that nobody, including the leaders, ever said “no.”
Being spread too thin
Success in this paradigm channeled more assignments and more work to the valuable team players. Yes, the “reward” for success was more work. Given the organization’s flat structure, instead of being promoted based on their past success, employees were being tasked based upon their past success. As with the Peter Principle, an employee’s past success undermined their long-term success and value to their organization and its customers.
Dedicated, hard-working employees were “just doing it” and spreading themselves too thin.
The employees were in effect spreading their peanut butter and jelly all the way out to the edge of the bread. Unfortunately, unlike a piece of bread, this edge was infinite, receding forever into the horizon, due to the organization’s insatiable appetite for more. When I reflected on how this particular organization was spreading people out to the level of their incompetence, I conceived my Peanut Butter Peter Principle: “In a flat hierarchy, every employee will be tasked to their level of incompetence.”
Now that I had the problem defined, the question was what could be done to change this culture? We will look at that, and how that experience has helped inform our Ufirst project, in next month’s post.
From the Desk of Sean Jackson: Watching the ‘BLIP’ on Our Radar
Sean updating the Ufirst Project kanban board
Last month, I wrote about a Lean game that I designed to teach teams how to learn from work. To win the game, team members needed to observe work with an eye toward maximizing value. This month, we will look at how we have applied this principle to our testing activities.
Our transformation project combined three separate HR and payroll organizations and the result is an exceptionally complicated Workday configuration. This complexity informs the integration and analysis of our testing. While there is significantly more detail regarding the resulting Workday configuration, it is beyond this discussion.
Testing, with an eye on our customers’ needs
Taking the perspective of our customers, we decided to give the highest priority to our Benefits, Leave, Payroll, and Integrations areas. Defects or complications in these areas could cause the most significant harm to the largest number of people. The flow from Benefits and Leave into Payroll and out to Integrations (the HR data we share with others) formed the nexus of our strategy. To facilitate communication and avoid team confusion we took the liberty to modify the order of the flow to Benefits, Leave, Integrations, and Payroll. Thus the acronym: BLIP.
The structure needed to test the control of the flow of information across these four areas. Some might suggest that End-to-End testing would be the place to test these flows. Under normal circumstances that would be correct; however, End-to-End testing also captures system functions that could mask specificity in an abundance of detail. Resolution of this problem required us to focus solely on the BLIP flow. Therefore, we created an additional round of testing to do just that.
We created scenarios for each of our numerous employee types that ran each test employee from hire, to benefits election, through to payroll. We developed scenarios to test paid and unpaid leave for a subset of each cohort, and we evaluated the quality of the data that appeared in our integration files at the end of each scenario. The team strategy was to test areas where failure would create an unacceptable user experience. Thus, testing a mock payroll for each employee type was at the top of our list of priorities.
Instead of triggering events artificially, we advanced the payroll, period by period, over the course of the entire upcoming year, taking each test employee from their first paycheck to the last, culminating with the generation of a W-2 at the end of the year for each test employee in the cohort.
Lessons learned that set us up for success
These tests did unearth defects. We were able to correct them before commencing End-to-End testing. Our testing also confirmed the (high) level of quality that we have built into the system. Engaging the team, we earned a welcome side effect: the payroll testing scenarios helped to train the new Payroll team as they ran successful mock-payroll cycles over the course of an entire year. As we enter End-to-End testing, a deeper understanding of this critical work enhances our ability to execute successfully the remaining testing and validation tasks.
From the Desk of Sean Jackson: Let the Work Teach You
Sean updating the Ufirst Project kanban board
Several years ago, I created a Lean game to illustrate how to learn from work. The game has four timed rounds. In the first round, the method of the work emphasizes waste. In the next, the method of the work changes to emphasize the relationship between the customers and the worker. After the second round, with their focus now on their customers, I ask the teams to consider how they can improve their cycle times before beginning the third round. In the fourth round, we introduce another significant change that challenges the team’s quest to reduce their cycle times. The only thing that changes over the four rounds is how the work is done.
When the teams form, they have no idea what the work is. By design, they do not have the ability to change anything for the first two rounds so they can focus their attention on the work and experience the power of waste and how it inhibits flow. Appearances are deceptive, however, and teams that look beyond them are rewarded.
For example, teams often fail to recognize that the novelty of the situation precludes any single team member from being an expert capable of offering a “solution.” Nonetheless, between rounds two and three team members engage in wasteful behaviors centered on status seeking and influencing each other rather than sharing and analyzing their observations and developing hypotheses. This approach frequently results in the emergence of a dominant team member who takes on the role of “teacher” often promoting some clever idea aimed at outsmarting the game rather than letting the work teach them.
What does it mean to let the work teach you?
It means that you learn by observing the work from the customer’s perspective. You develop an understanding and appreciation of what is valuable, and what is not. You recognize that there is nothing clever about empirical observation, and you realize that while a guide can help direct and focus attention, there are no shortcuts to insight. Most importantly, you understand that a “solution” is an emergent property of a system rather than its goal.
Letting the work teach you means that you hypothesize and experiment based on what you have observed. By putting insights into action, teams can observe and learn what is effective and what is not.
Life is inherently a process of transformation and growth. In the workplace, Lean’s concern is to make these processes deliberate, conscious, and aimed in a particular direction. Over time, we learn through our experiences that inner transformation precedes outer transformation. Once we apprehend that the process of transformation resides firmly at the center of our lives, all of the surrounding circumstances likewise transform into pathways for our growth. We can observe and experiment our way along these paths, reminding ourselves to let the work teach us so that we may cease to be “governed by epistemologies that we know to be wrong.”
Let the work teach you. Don’t be clever. Act on what you learn.
Next month we will look at how we have put this into practice.
From the Desk of Sean Jackson: The Art of Imperfection
Sean updating the Ufirst Project kanban board
In February, we uncovered a technology issue on our project that required more time to resolve than we had available. This compelled us to reschedule our system launch date from July 2018 to January 2019. Our project plan was broken and we needed to repair it. In doing so, we resolved not to hide our repairs but to emphasize them so that we might continue to learn from the spots where we rejoined the pieces. This reminded me of Kintsugi.
According to legend, the Japanese shogun Ashikaga Yoshimasa (1436-1490) once broke his favorite ceramic teacup. He sent it to China for repair and it returned mended, but covered with ugly metal staples. Dissatisfied with the inelegance of the repair, the shogun turned to Japanese artisans who removed the previous repair work and used lacquer coated with gold to repair the cup. The shogun was satisfied and thus was born the art and craft of Kintsugi, which translates as “golden joinery.”
An outgrowth of the Japanese philosophy of wabi sabi, the belief that posits and encourages us to see the beauty in the flawed and imperfect, kintsugi repairs broken objects in a manner that highlights the damage, rather than trying to hide it. The scars become important not only aesthetically, but also emotionally as they help us work through our regret for our loss and the recognition and acceptance of change as we interact with the transformed object. From a planning and execution perspective there is also the pragmatic benefit of understanding how historical risk factors have combined to influence the whole.
Our project includes a functional transformation in addition to a system implementation. The rescheduled system launch date means that we have the challenge of ensuring that we meet operational demands between now and January, extending our period of service stabilization. Our planning effort encompasses all of these areas and our team members and stakeholders have identified places of stress, strain, and things broken that require attention and mending. At each encounter, we ask why until we understand the root cause. Then we mend.
It has been difficult and challenging to develop a new plan that takes into account the myriad details that cut across our complex landscape. However, we have received a great deal of encouragement and support from our stakeholders, a reaffirmation of the importance of our work along with expressions of gratitude for our decision to maintain our commitment to quality by rescheduling our system launch. The engagement of and with our stakeholders has always been a point of strength on this project, and it remains so.
As we face together the challenge of stabilizing the delivery of our HR services using the current collection of technologies, we are bonding our relationships with confidence, respect, and grace, the golden joinery that will transform our broken project plan into one of imperfect beauty and lasting value.
As I mentioned in my post last month, trust is a vital component of our collective ability to overcome obstacles. Trust is also at the heart of continuous improvement.
A commitment to continuous improvement helps to nurture trust by instilling confidence that a person or process is behaving in a predictable and appropriate manner. It is a commitment among all participants to be focused, transparent, and observant regarding what needs to be done and how we plan to do it. Inevitably, gaps emerge between what we expect and what we receive, either in terms of the result or in terms of the experience. We improve by resolving the gaps between expectations and results.
How do we do this?
We wonder why.
When we wonder why we catalyze our observations with our natural curiosity. To wonder why means that we trust enough to invite others to participate with us in challenging our collective assumptions to their very roots. We have to wonder, however, and not just ask why. Think about the difference between saying, “Why did they do that?” versus “I wonder why they did that?” While the difference may seem subtle, it is extremely important.
When we ask only “why?” we cease to wonder. When we cease wonder, fear steps in and begins to erode trust.
When we cease to wonder, we abandon truth for judgment.
When we are committed to continuous improvement, whenever results fail to match expectations, we wonder why, and experiment until we are able to produce the desired results in a manner that delights the participants in the process.
Trust, but verify. If there is a gap, wonder why. Experiment and change until all are delighted.
From the Desk of Sean Jackson: Welcome to the Blog!
Sean updating the Ufirst Project kanban board
Welcome to the blog! During the next few months we will be exploring topics regarding Workday and our HR Transformation. I hope to share with you things that we have learned during the last several months that will be helpful in navigating successfully the upcoming changes. As we complete the launch of our new UVA HR and Payroll organizations in parallel with the deployment of the Workday system, we will be bringing to culmination nearly three years of work that has touched every area of the University.
Perhaps the most important lesson that we have learned through this time is that we are more alike than we are different. While there is comfort and solace in the recognition of our similarities, the real treasure is to be found through the respectful exploration of those areas where we differ. This type of exploration can be difficult to establish and maintain, however, especially when there are risks, constraints and uncertainty in play. Trust is critical to overcoming these obstacles and this is why we have worked hard to establish and build trust during our journey with you. Have we always been successful? Not always. Trust can be hard to come by in our culture here at UVA. Please know that we remain committed to building trust because it is so vital to our collective success—both in terms of the Ufirst program but also, and more importantly, beyond it.
I would suggest that any meaningful journey of change proceeds by means of reasoned trust, not blind faith. In fact, I have been reminded by several colleagues on different occasions of the old Russian proverb, “Trust but verify.” Next month, we will consider how a commitment to continuous improvement will enable us to bring life to this proverb.