The reason I picked that title for my book “It’s All Upside Down” is because so much of what I recommend to my clients today seems completely opposite to what I was taught. The reason I wrote the book is because too many people continue to believe these upside down ideas today, and I wanted to set the record straight.
Welcome to our interview with Paul E. McMahon. Paul is an Author and Principal Consultant at PEM Systems. Paul helps large and small organizations as they move toward increased agility and process maturity. He is the author of several books including 15 Fundamentals for Higher Performance in Software Development, Integrating CMMI and Agile Development, and his latest book is It’s All Upside Down.
Welcome Paul, and thank you for contributing to the questions that are at the heart of Container13.
Let me start by addressing how I handle the “every voice matters” side of the question in my own work and then I will explain how this idea could be applied to the workplace. In the past, I often conducted 3-4 day workshops for my clients using literally hundred’s of powerpoint slides. Over the years I gradually weaned myself from this poor practice. One technique that helped was starting each workshop with a go-around where I ask each participant to share with the class what would make the workshop a success for them.The reason I picked that title for my book “It’s All Upside Down” is because so much of what I recommend to my clients today seems completely opposite to what I was taught. Click To Tweet
As each participant speaks I then jot down on a big white pad keywords or phrases I hear them voice, and those sheets all go up on the wall where they stay visible to everyone. Then, throughout the workshop at appropriate times, I refer back to as many of those keywords or phrases explaining how what we are currently discussing can address the issue that was articulated by the participant at the start of the workshop. In this way, I make sure the voice of every participant matters and remains a key focus item of the workshop. Now—getting back to the workplace—I believe this same idea could be applied by team leaders to create workplaces where every voice matters. As a simple example, if leaders started each team meeting by asking the team members if they had topics or issues they would like to discuss at this meeting, this simple technique could send an important message to everyone that the voice of every team member counts.If leaders started each team meeting by asking the team members if they had topics or issues they would like to discuss at this meeting, this simple technique could send an important message to everyone that the voice of every team member counts.Click To Tweet
Now let me address the “change happens naturally” part of the question. I’ll get to the “innovation” and “everyone thrives and finds meaning” parts later.
I have made a further change in how I help my clients where I use no powerpoint slides at all. I have modified my services to where I spend far less time in the classroom, and significantly more time conducting direct on-the-job coaching. One great advantage I find to on-the-job coaching is that I get to see if concepts I thought I was communicating in the classroom were really understood by the students. More importantly, on-the-job coaching gives me an opportunity to clarify points when I observe areas where important points were missed.
Let me give you an example and I’ll explain afterward how it relates to change happening naturally in organizations and how team leaders can use these lessons in their own organizations.
At a sprint retrospective, I observed a tester sitting quietly and not participating. So I suggested to the Scrum Master that he ask the tester how his testing was coming along.
The tester replied,
“The tickets I get from developers are often vague and don’t have all the information I need to test.”
One of the developers quickly replied,
“We’re always under pressure to get more work done. We don’t have time to put extra information on the ticket.”
When I heard this I reminded the team that we had discussed this issue and agreed in the classroom training to improve the communication between developers and testers. Poor communication between developers and testers had previously been identified as one of the causes of breaking critical functionality in the product.
I then suggested that everyone take a few minutes to brainstorm what they could do in the next sprint to help the tester with this particular problem. After just a few minutes of discussion, all the developers agreed it wouldn’t take them long to provide some additional information in the ticket to help the tester understand exactly what needed to be tested.
In this situation, the team needed additional coaching beyond the basics of how to run a retrospective to help them learn how to get the intended value out of the meeting.
Now, let me get back to what this example has to do with “change happening naturally” in an organization and how team leaders can use this lesson.
My simple point is that, in my experience, when it comes to the kinds of changes that really improve performance, often they don’t just happen naturally.
I view classroom training as just a first step because the kind of changes that are needed to gain real performance improvement are rarely learned in a classroom.
This is where on-the-job coaching after classroom activities is critical to help point out situations where what was discussed in the classroom needs to be converted to a behavior change. And, to be honest, in my experience, these simple situations often need to be pointed out multiple times before new behaviors take hold.
My grandfather had a saying,
“Education is like throwing mud against a wall. Some of it sticks, but most of it falls to the ground. But if you keep picking up the pieces that fall to the ground and throw them back again, eventually more and more of the mud will stick.”
So, what can team leaders learn from this lesson?
If more team leaders viewed themselves as coaches watching for similar simple situations where team members need just a few reminders or a little extra guidance, I believe that would be the best path to change happening as naturally as we could hope for in the workplace.If more team leaders viewed themselves as coaches watching for similar simple situations where team members need just a few reminders or a little extra guidance, I believe that would be the best path to change happening as naturally as we could hope for in the workplace.Click To Tweet
Simply put, first, they have to care. That is, they have to be interested in the job they do. Now, I have heard some managers respond to this line of thinking by saying,
“The job is what it is. I can’t make it more interesting.”
But this isn’t always true.
Let me give you an example. One problem I have seen more than once recently is IT professionals becoming frustrated due to new rules and regulations stemming from cybersecurity threats. These new rules restrict IT professionals from making many quick changes they used to make routinely to fix common IT problems on the spot. Because these rules slow them down, or even stop them from making certain kinds of changes, many IT professionals feel they can’t be as productive and they start to lose interest in their job. This can lead to performance issues.
So what could a manager do about this situation which is becoming more common in today’s world?
I was recently giving some training to a group of IT professionals facing this exact problem and I quickly sensed the low morale of the group due to this problem. The first thing I did was to highlight the positives of their job that many of these professionals had started to forget.
This was an exceptional team that was used to getting great customer reviews for their ability to rapidly solve most any problem the customer brought to their attention. I reminded the team that the reason most of them love what they do is because they love the challenge of troubleshooting and solving hard problems.
I then suggested that they look at these new cybersecurity regulations as just the latest challenge they need to solve. Then I told them I was certain they could come up with an innovative way to solve the problem.
Furthermore, I pointed out that they were not alone in this challenge, as the whole world was facing a similar issue. I also told them that if they came up with an innovative solution they could potentially publish it and become famous.
In other words, the approach I took was to show them how the problem they were letting get them down, was really a great opportunity in disguise. It wasn’t long before the low morale turned around and the hung heads started popping up as one team member after the next started chiming in with different possible creative approaches to solving the challenge.
As it turned out, they worked in a classified environment, but a lot of the tasks the IT people worked on had nothing to do with classified information. So they quickly figured out how they could do a great deal of their work in an unclassified environment where the policies were much more lenient. This was just the start of their creative thinking on the problem.
They figured out an initial good solution, but to do this we had to first get them to look at the problem differently. We had to get them to see the problem in a different light and recognize they had the expertise to solve the problem, just like any other challenge they faced every day on the job.
Now, let me give you another quick example related to this question. When employees are struggling because their job priorities are unclear it may appear you don’t have the employees’ full attention. But it may be their attention is just in the wrong place.
This often happens when employees are given a new role and they aren’t fully relieved from their last role—either because they still want to do the last job, or because they actually now have been given two jobs. In either case, managers need to recognize such situations and guide the employee in focusing their attention appropriately.
I often see this problem when programmers are asked to take on technical leadership roles. It is worth point out that I am not suggesting that technical leads should always be forced to give up programming. Allowing employees some time each day to do other activities, especially ones they enjoy and want to do can be an effective way to help keep them motivated and caring about the job you want them to do.
I live just 6 miles from Endwell, NY, the home of the 2016 Little League Baseball World Series Champions. When I was young and playing sports it was common for coaches—when they saw a talented youth—to push them to drop other sports and just focus all their attention on that single sport. The thinking was this would give them the best chance to raise their performance.
But in many cases, the result was burn-out and loss of interest by the youth. The coaches at Maine-Endwell encourage all their young little leaguers to play other sports and forget about baseball in the off season. This is a great way to gain their full attention and best performance. It may seem backwards—or upside down—because we are suggesting they do other things to get their full attention and best performance.Show your worker that you are willing to support them in learning things they want to learn even if those things do not appear to be directly related to the current job you want them to do.Click To Tweet
But it can be an effective technique. Show your worker that you are willing to support them in learning things they want to learn even if those things do not appear to be directly related to the current job you want them to do, and you might be surprised at how it helps to gain that employees full attention and best performance.
I believe it is an environment where the employee feels it is ok to try something new, and an environment where it is even ok to fail.
Now you might be thinking,
“Sure, but do such companies really exist?”
The answer is absolutely YES and I will give you an example.
In 2015 I visited South Africa for the first time in my life when I was invited to speak at the Agile Africa Conference in Johannesburg. One of my favorite memories of the trip was getting to meet Kent Beck and listen to him talk in his keynote address. I had previously been familiar with Kent’s work on Extreme Programming and Test Driven Development.
In his keynote, Kent talked about what it is like to work at Facebook. In the talk, he focused on policies at Facebook that had come from the vision of Mark Zuckerberg. One of those policies Kent referred to as “personal ownership”.
Now let me give you an example of personal ownership. At Facebook, when a new software developer comes into the company they are expected to affect the released product within 2 weeks. And at Facebook you are encouraged to try out new and innovative ideas. In fact, when your performance is measured the focus of your performance review is on the “impact” of your work related to changing the world of social media.
So wouldn’t you think—working in an environment where the product you are affecting is used by millions of people every day and you are expected to make significant changes—that the managers would be monitoring the employees closely to make sure they didn’t make mistakes?
Well, at Facebook nothing could be further from the way they work.
If you make a mistake at Facebook, don’t expect to get yelled at by a manager or anyone else. Someone will just fix it and that someone won’t be wasting any time playing the blame game. In fact, if you like to blame people for mistakes, Kent said,
“Don’t expect to be working at Facebook long.”
Now, let me give you another example that further exemplifies a culture where failing is not only not punished but is actually encouraged.
At Facebook no one is expected to meet all their yearly goals. In fact, Kent said—
“It is expected that you don’t meet about 50% of your goals.”
At Facebook, the thinking is,
“if you meet all your goals then you set the bar too low.”
And this probably means you aren’t making a significant impact to the world of social media.
Now, I know that all companies can’t operate like Facebook, but I do believe there is something in this story that all companies can learn. I believe all companies should strive to create a culture where it is encouraged and safe for all employees to stretch themselves. That is, we all should be life-long learners and all workplaces should support that goal for every one of its employees.
And getting back to your first question for a moment, this is one-way organizations can create workplaces where everyone thrives and finds meaning.
When you are constantly stretching yourself you need to accept that mistakes will be made. And yes, I know, this sounds “upside down” from the culture of many organizations today.
When I first heard this question, it caused me to ask a different question:
Who is management?
I think most of us have a good idea what is meant by “management”. It’s the people way above our paygrade who are running the company and telling everyone what to do. Right?
But is that really the best way to think about management—especially in today’s fast-paced rapidly changing high technology world?
Let me explain my thinking here, and then I will get back to your question. First, I believe a lot of people confuse management and leadership. This may be ok in certain situations, but it is important to keep the distinction clear.
Simply put, we manage “stuff”, and we lead people. By stuff, I mean artifacts like requirements, test procedures, design documents, code, user guides and so on…
One reason it is important to know the difference is because the best solutions to people problems are different from the best solutions to “stuff” problems.
Now, let me get back to your question.
If you accept my distinction on management and leadership, the most important question “management” should be asking employees is something like,
“What’s getting in your way keeping you from getting your “stuff” done?”
This question is clearly getting right to the point because “management” is about getting “stuff” done.
But now let me share with you a story to put this in perspective.
At one of my recent client engagements, the president of the company hired me to teach his software developers Scrum because he knew they needed help getting their “stuff” done on time. But he also did something else. He attended the training himself, which I found unusual because I don’t often have presidents of companies sitting in my Scrum training sessions.
Before this training the company was operating in a very chaotic fashion, completely interrupt driven. But within just a few short weeks the chaotic/interrupt-driven culture had virtually vanished.
At a retrospective, the team discussed why this had happened. We asked,
Was it just the power of the Scrum practices at getting “stuff done” that made this organizational transformation happen?
What the team realized was the real reason the interrupt culture vanished was because the president—not only learned Scrum himself—but he was also coaching his entire staff in the new process. And he was making it clear to everyone that this was now the expected behavior in the organization.
Change happened dramatically and quickly in the company, not just because of Scrum helping the team to manage their “stuff”, but because the president realized that if he really wanted the organization to change, it had to start with himself and his own staff.
So I would still say that the most important question management should be asking employees is,
“What’s getting in your way keeping you from getting your “stuff” done?”
However, I would add that asking this question isn’t enough. Management needs to also ask another question and that is:
“How am I going to respond when I hear the employees’ answer?”
And at least part of the response should take into consideration the power of leading by example. Management is not the same as leadership, but one of the best ways to achieve effective management is to lead by example.
I learned the answer I am going to give you to this question the hard way when I was an employee and I didn’t know enough to ask this question.
This goes back to when I was a young programmer just a few years out of college. I came into work one weekend to rewrite a large part of my code on my current assignment because I realized I had made a large mistake with my design. I was afraid to tell my manager because I didn’t want him to know I made that mistake. So I never let him know.
Since that time I have heard similar stories from other junior programmers. I have also heard stories about new software developers who did ask for help when they thought they needed it, but no one was available to help them.
So, from my experience, the most important question employees should be asking management is any question related to getting help when they feel they need it. But it is equally important for management to be ready for that question—and to recognize it in whatever form it comes—so they can ensure the right kind of help is available when needed.
And I would add that this doesn’t mean just “assigning a mentor”—which I often hear as the response—unless that mentor accepts the role of mentor, wants to be a mentor, and—most important—has been given the time to be a mentor.
I believe the answer to that question is:
What are my responsibilities and how do those responsibilities align with my competencies, and what I am actually doing each day?
Now, let me explain why I believe this is the most important question we can ask ourselves.
When I go into client organizations to coach them with respect to some problem they have, and when we dig deep trying to uncover the root cause, I all too frequently find that the root of the problem can be traced to the lack of clear understanding and ownership of responsibilities and competency to carry out those responsibilities.
Interestingly, one of the key competencies we all need that people don’t think about is the competency to observe each day on the job where one’s responsibilities come into play. We can be given a list of responsibilities, read them on a piece of paper, and think we know what the words mean, but then completely miss common situations that occur on the job where those responsibilities come into play.
One quick example goes back to a technical lead I was coaching who viewed situations where his responsibilities came into play as interrupts to what he was doing. This related to mentoring junior software developers.
In this case, part of the root of the problem was tied to the fact that the technical lead had taken on too much responsibility for software development tasks given his technical leadership responsibilities. Many of these situations just require a reminder at the right time which is what an on-the-job coach can provide. This is often the best way to help practitioners who have been given new responsibilities improve their competency at actually carrying out those responsibilities. You can’t get this kind of guidance from classroom training alone.
Let me answer the second part of that question first. Yes. The book is a collection of true stories, about my recent on-the-job coaching experiences. All of the stories occurred in 2015 or 2016. I also explain in the book what motivated me to move toward doing less traditional classroom training and more direct on-the-job coaching.
But please don’t think I am saying we don’t need classroom training. There is still a place for classroom training although much of it can now be replaced with webinars allowing us to save on travel time and allowing us to provide that form of training to larger audiences in less time. This should drive the cost of the formal classroom type training down, which in turn should allow us to spend more of our training dollars where it can do the most good and I strongly believe that is in direct on-the-job team and individual coaching.
Now back to the first part of your question.
The reason I picked that title for my book is because so much of what I recommend to my clients today seems completely opposite to what I was taught. The reason I wrote the book is because too many people continue to believe these upside down ideas today, and I wanted to set the record straight.
As I mentioned, the stories in the book are all true and I picked them to demonstrate what really works in software development today–despite the fact that many may appear to be completely “upside down.”