Ok, stop. I mean it. Stop this moment.
Is a manager supposed to manage people? NO.
You, dear manager, are supposed to focus on creating an environment that enables people to excel at their job. I’m not making this up. Take some time to read the work of Deming and Senge, you’ll see that I’m not off my rocker. Then again, as a manager, how come you haven’t read their work? Oh, that’s right, you were probably just promoted into a management position and asked to figure it out on your own. Don’t worry, that’s what happened to me as well. There is hope for us.
I’m sorry you’ve been misled and that the prevailing management theory in use is still from the Stone Ages. I’m sorry, very sorry. I have a confession. I was also brought up (or is it brainwashed) to think and act that way as well. Yes, I do find myself at war with myself at times as the flesh wants to revert back to “old way”. So no, I am not judging you. I’m challenging myself as I challenge you.
Trust me, there is a better way. A way that makes work more enjoyable for everyone. I’ve experienced it. I need for others to experience it. While we’re at it, let’s stop talking about “empowering people” as well. I think we can do better. It doesn’t reflect well on us. It suggests we have power to give others power. What’s that? Hubris? I used to use that word all the time. I’ve stopped. I think we all need to stop. And since we’re stopping the use of words, why don’t we quickly add “resource” to that list. But this could all be wishful thinking on my part. Old habits die hard, don’t they?
But I got sidetracked there, the point of this post is to remind us (managers) of what our focus should be on if we really want to make a difference in our organizations. Focus on the system.
I’m a Theory Y guy. I may be näive in my outlook but I’m just a Theory Y guy. I believe that most (not many) people want to do a good job wherever they are. So what do we do when we observe that someon is not doing a good job?
Let’s say that Chidi (a guy I know) is having a difficult time at work, he’s struggling to meet expectations of his co-workers. Even though it seems his trying really hard, he’s struggling to deliver. What could be the problem? How can we help him? Well if we view his performance through the lens of Theory Y, could we identify the reasons why he is not doing so? I can think of at least 3 (I’m sure you can add more):
- Chidi doesn’t know HOW to do a good job – competence.
- Chidi doesn’t know WHAT a good job is – understanding.
- Chidi knows how to do a good job but the environment is preventing him from doing so – system.
Let’s explore these a bit.
Competence means the ability to do something successfully. Does Chidi have the right skill for the job? Was he given the appropriate education to allow to be competent at the job? If this is a new position, is a competent mentor mentoring him? How is the organization taking deliberate steps in improving his competence?
Does Chidi understand the expectations of the job that the organization has given him? Have they been made clear to him? Was it discussed with anyone? Who is available to answer his questions if he has any? Was he told to “figure it out on his own”? Have the outcomes expected from him been connected to the strategic vision of the organization? Does he understand the strategic vision?
Do the structures (Senge) in place enable Chidi to succeed? Is the system working in his favor or against him? Is he doing his best in a poorly designed system? Have problems with the system been identified? Is anyone (management) fixing the system? Is management tampering (Deming) with the system e.g. adding more process? Does management even know and understand the system?
In my experience as a “manager”, competence and understanding often prevent people from excelling at their jobs. However, I have found that the system is the biggest inhibitor to people’s success. It was Dr. Deming, who suggested that 85% of a workers effectiveness is determined by the system. In addition, Lewin’s formula reminds us that the behavior of an individual is dependent on the person AND their environment. This is another reason why performance appraisals can be largely ineffective.
At the beginning of this post, you may have identified yourself as a Theory Y type person. Is your espoused theory the same as your theory-in-use? When people or teams have challenges, how do you look to help them? How does your ladder of inference inform you? Do you just see the tip of the iceberg and act on it or do you go deeper to truly understand why an individual or team is challenged?
At the end of the day, it’s very likely that Chidi is really not the problem, after all, he really wants to do a good job. You see my friends, appearances can be deceiving.
Well depending on what type of organization you are trying to help create, that could be a problem.
For business agility via Agile or Lean methods (remember methods are NOT the goal) to be highly successful in an organization, the organization must promote the concept of the self-organizing team. This runs counter to the traditional hierarchical philosophy that is found in many (maybe most) organizations and often prevents organizations from having their teams perform at their highest levels possible. In the traditional approach, the organization is largely dependent on managers directing their reports and solving the teams problems. Annual goals (and you know my thoughts on performance appraisals) are built around such an approach. I find it interesting when a manager suggests to me how “Agile” they are and then begin to rattle off how many people they have reporting to them or how often they looked at the teams’ burn down chart or inspected their card wall to see how long things were taking or solved all the problems that the team had. They are yet to realize that their behavior is not what is desired in the age of the knowledge worker. The manager who “fixes all the problem” is not a plus in an Agile environment. They don’t realize that they are possibly the biggest reason why their teams will not become high-performing. To quote Drucker on the knowledge worker:
For, once beyond the apprentice stage, knowledge workers must know more about their job than their boss does–or else they are no good at all.
But the fact is that many organizations that are engaged in an Agile or Lean journey have a good number of good people in managerial positions. So what are they supposed to do if not manage team members and fix team problems? I have a suggestion: focus on the system. What is the system you may ask? Read this and this for starters. Can you now identify the system you are a part of?
Management (hence managers) need to focus on creating an environment (system) in which their teams can excel. This is also known as leadership. If you are in management and consider your responsibility to be the “management of people” then, from a knowledge worker perspective, you’ve (unfortunately) totally missed it. If you want to get into to management for the aforementioned reason i.e. fix the teams, please do us a favor and reconsider. Don’t rob the team of it’s ability to learn and self-organize. Your focus and attention needs to lie elsewhere. As a manager, you need to help design a system that allows the teams in your organization to perform an excellent job. A job that people want to do. This unfortunately, is quite different from our classical view, understanding and training on management and requires a complete paradigm shift of our mental models. This transition is not easy in organizations that reward managers for behaving in a completely different way. So once it again, leadership is required to change the system. Quoting Deming:
Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
Even though many workers are now salaried, the guidance is still relevant. No Agile (or Lean) based transformation is complete without a transformation in the way managers conduct their behavior. Beware of consultants who peddle solutions that don’t require such a paradigm shift. Be sure of what you want. Beware of Agile managers who are fixated on jumping into the team and solving their problems. They are probably getting in the way.
Dear manager, focus on the system. Fix problems outside the control of the team. Design an environment that allows the teams in your organization to be successful.
I feel like I may get some pushback for what follows but here it goes….
(You can apply the following to Lean, Kanban, Theory Of Constraints etc etc).
You don’t have embrace the Agile approach to software development. I’m yet to find a mandate that suggests so. Please share with me if you have one. You don’t have to agree with the Agile Manifesto as well. If any of these things has been forced upon you and you disagree with them, make a change. You deserve it. It’s your life after all and life is just to short to be stuck doing what you don’t want to do. Take care of it.
But if you decide to do the Agile thing, please spare me (yes me) from trying to rewrite the manifesto to suit your own agenda. Let’s stop giving people a pass on calling anything they are doing Agile. I’m talking about big A Agile here. The one guided by the Agile Manifesto. I’m not suggesting we be judgmental and all high and mighty about this but we need to be truthful to ourselves. It’s ok to be on your way to embracing the values and living the principles as it’s a journey but be explicit about that fact and stop trying to redefine Agile to suit your situation and instead focus on moving your situation along. Trying to fit Agile to your situation is sort of like saying you are a vegan but you only eat meat on Sunday. Really? That just doesn’t work and you can do better than that. Either you are a vegan, working on becoming a vegan or have no intention of being vegan. All three things are fine, but let’s not be deceptive about it.
It is a curious thing that the authors did not specify a bunch of practices that must be followed. I imagine they wouldn’t have reached consensus because practices can be a tricky thing. That’s ok, a number of methods/frameworks/practices that existed before and after the Agile Manifesto are available to choose from. You can evaluate how well these practices tie back to the values and principles outlined by the Agile Manifesto and how well they will work in your organization. The body of practices continues to grow as we identify additional ways to effectively deliver software.
Agile is not an exclusive choice. You can do other things in addition to it if you please. You can evolve beyond Agile to something else if that’s what you think you are doing. You have many options here. Just be clear about what it is you are doing.
Is Agile THE goal? No. It is one of several ways to the goal. If you choose it, then do it. Don’t redefine it.
I tweeted the following on Twitter last night.
One of the things that grinds my gears is the lip service that organizations pay to “autonomy” when in practice they do the exact opposite. A classic example of this (and I’ve seen it in multiple places) is the selection of tools for use by the team. The organization creates a group (or even worse brings in a set of consultants) that is supposed to standardize the set of tools that are used within the organization. In many instances, the people chosen to set the direction are not going to be using the tools day in and day out and may not have a proper appreciation for effective knowledge work management (but that’s a completely separate topic).
The response to this that I often receive is generally one of the following “we need to have some control”, “we can’t let people get whatever they want”, “we need to standardize on something”, “we need to manage costs” etc etc. This suggests that we know more about the work than the people actually doing the work or we don’t trust our people to make good decisions. If either of these points are true in your organization, then you are in deep trouble. Get out now.
Let me cut to chase and simplify things for us by suggesting an alternative approach. Instead of specifying the tool, let the teams choose. Let those doing the work decide what tools work best for the work they are actually doing. Provide an explicit decision making framework that the teams can use to choose their own tools if you actually need to constrain a particular variable such as cost. Examples of guidelines that can be in a decision making framework could include:
- Tool should be cloud-based
- Annual subscription/license fee should not exceed $5,000 a year
- Teams should be able to report with ease certain measures
- Needs to integrate with a certain third party solution
- Etc etc
I know I’ve probably upset the sensibilities of a few people. I think that’s ok. I hope we’ll all be better for it.
In honor of Doctor Who being back on, I thought we should talk about a town called commitment. This is a town where everyone goes around making commitments to one another. One day, Madame Mayor called for a town meeting. At the beginning to the meeting, she said, “I commit that we will get through all the agenda items we have today…”. Just as she finished speaking a blue telephone box with the words Police Box began to materialize in the middle room…..
Recently, I suggested that estimates are not commitments and advised that when teams are asked for estimates, they should make an effort to understand if they are truly being asked for a commitment. Simple, right? Well, not so fast my friends. Commitments are an interesting thing with implications and ramifications on both individual and team behavior.
I once heard the story of a man who made the commitment to his dying wife that he would never remarry because he loved her so much. Years later, he met someone he feel madly in love with. What do you think happened to his commitment? If you make a commitment to attend a friends wedding, you are pledging to be at that friends wedding. You have made a promise (yes a promise) that you will do whatever you can do to be at your friends wedding. That’s a commitment. When we make commitments, we are implying that we have a lot of control over the final outcome. Some of you reading this are probably thinking that I’m taking this commitment thing a bit too far. Um, I don’t think so. My experience in life would suggest to me that when people say they are making a commitment to something, those who hear the commitment are largely interpreting it as a promise for the individual to do what they have said. This is why there is disappointment and frustration when commitments are not met.
Others may read this and say that anyone who sees a commitment as a promise (or something similar) is making a mistake and shouldn’t. But why shouldn’t they? Isn’t that at the end of the day what a commitment really is? Why would we attempt to redefine commitment in certain contexts?
Commitments inherently runs the risk of not being met. That is just a fact of life. Inclement weather can hit your town grounding all the flights and making it impossible to get to your best friends wedding. You can meet someone you fall madly in love with and remarry. What you thought would be a few lines of code changes turns out to be something much more involved. Things happen. Things happen every day. It’s important to realize that the more people that are involved in making a shared commitment, the larger the risk of it not being met. (This is another reason for small(er) teams in software development but I digress). After playing team sports for most of my life at a pretty competitive level, I learned that lesson the hard way. This is why you’ll rarely see a coach commit to wining a game (outcome) and most players would hedge on doing so. I mean we all saw how it ended for LeBron and Heat after promising “…not one, not two, not three…”.
Commitments also come in conflict with one another. Making a commitment to one thing very often impacts commitments to something else. Daily, I have to excuse myself from one meeting I committed to in order to attend another. Its not uncommon to ask a team to be committed to quality but then also ask them to commit to delivering X number of stories in an iteration – which commitment do you expect them to honor when there is conflict (and there will be a conflict)? The quality commitment or the number of stories commitment?
Commitments made too early can also lock us into a solution prematurely and prevent us from exercising other options that we may have had. We see this when teams make a wholesale investment in a particular solution to a problem making impossible to leverage any of the other options on the table. (Yes enterprise/solution architects, I am talking to us).
This is the very reason why we should be careful what we make commitments on and when we make those commitments. In knowledge work (and software development in particular), I suggest considering the following when thinking/talking about commitments:
- Do not make goals, commitments
- Have (and understand your) options
- When (and if) you have to make commitments, make them at the last responsible moment
- Choose commitments to behaviors and causes over commitments to particular outcomes
- Consult people before committing them to a cause or outcome
- Don’t make a commitment you don’t think you can keep
- When you make commitments, do your best to honor them
I had started this blog post before I read http://commitment-thebook.com/ but I would encourage anyone who hasn’t read the book to do so. Some insightful nuggets are contained within it.
Commitments are valuable and precious, use them wisely. Now that sounds like something the good Doctor would say.
Photo of Tardis: By Rept0n1x (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia Commons”
Unfortunately, they very often are. Recently, during an interview, I asked the candidate what they thought about the notion that “estimates are not commitments“. The candidates answer was:
Once an estimate is put down on paper, it unfortunately becomes a commitment.
Performing a search for estimates are not commitments returns a good number of results so this is not really a new subject. Yet, to be fair, it’s important to realize that many of the articles are authored by individuals in the Agile software development delivery space so do we have an agenda?
In previous articles, I’ve tried to define what an estimate is, so I won’t repeat that here but suffice it to say, that an estimate is an approximation of a measure. On the other hand, a commitment is defined as the following:
- an act of committing to a charge or trust
- an agreement or pledge to do something in the future
So its very clear that estimate and commitment are not one and the same thing. How is it then, that estimates are very often interpreted and/or immediately translated to commitments? I’m not sure I have a good answer for that yet, but I’d love to your feedback!
What I do think is important is understanding what the the requestor of an estimate is looking for. An estimate? A commitment? The response for each could be remarkably different. So when you are being asked for an estimate (and let’s just assume for a second that one is truly needed), make sure you understand what you are really being asked for.
Estimates are not commitments.