Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

We then got talking about Peter Weir’s 1989 movie, Dead Poets Society, starring Robin Williams and Ethan Hawke. In the movie, Robin Williams plays an English teacher who fosters a love of poetry in his students and encourages them to demonstrate freedom of expression and a willingness to go against expected norms. The movie takes an unexpected turn when one of the students commits suicide. The kid wasn’t free to live his own life but was being forced to live up to his father’s expectations and dreams. The father wanted his son to become a doctor and viewed poetry and drama as frivolous activities keeping his son from the real matter at hand — preparing for a future in medicine at Harvard. The son, in frustration shoots himself with his father’s gun.

So, the question is, whose fault was it — the dads for forcing his expectations on and disregarding his son’s feelings, or the teacher’s for introducing the concept that when faced with conformity, it is your responsibility to stand up for what you believe is right and to not blindly do what others tell you is just.

Recently I ran into Joe, a tech lead on a big Agile project I had coached. Joe is easily one of the best senior developers at the company, is enormously respected by the other developers and by the business stakeholders he interacts with. Joe has also done a stellar job on the Agile project and has been crucial in keeping multiple project teams functioning smoothly.  However, Joe got dinged on his just concluded annual review. IT management expressed dismay at Joe’s “lack of communication” and “poor planning.” What was actually meant was that IT management was not happy with Agile, was not happy with the business being part of the team, and was not happy with their inability to get ahead of any bad news and spin the message to the business — Joe’s superiors considered transparency to be a very very bad thing.

In this company, the C-level folks have utterly failed in convincing their subordinates that they truly believe in what they are espousing and have failed to create an environment that values and rewards openness. Thus far, senior IT managers have only paid lip service to changing the existing assessments, metrics, and reward systems that encourage lying and hiding material information. Employees believe that to be successful in this organization you need to keep a low profile, not stick your neck out, and to lie and shift the blame to someone else anytime something goes wrong. Senior IT managers have also failed to create any new experiences that would cause people to question and challenge their existing beliefs. Senior managers take their cue from C-level managers and try to do what they think their bosses actually want. I don’t blame them for simply going through the motions; after all, past experience has taught them that there is no benefit in doing something counter to what your boss expects (irrespective of what he/she says).

So, once again, the question facing me is: is it right for us to coach teams and get them dreaming about possibilities knowing fully well that they are not going to get real support and encouragement from their bosses, who say one thing to their business counterparts but do the exact opposite and have no interest in changing their modus operandi? Is it ethical for us to show people the great things that are possible and then have them penalized for their good work?

Have you faced a similar situation before? What did you do? What do you think is the right thing to do — call people out on their hypocrisy? Part ways with the client because long-lasting meaningful change is not a possibility at this time? Spend even more time on educating management and executives?

• Leadership is crucial for defining a shared vision and generating buy-in from employees.
• C-level managers are responsible for creating a learning organization that values systems thinking, craftsmanship, and team learning.
• C-level managers must design an organization whose structure, processes, metrics, rewards, and talent align with the organization’s mission.
• Managers are responsible for creating a well-trained, well-organized, well-managed company. If people require constant supervision then management has failed to do its job.

Last year, the new CEO at a client decided to leapfrog existing competitors by creating an innovative product; a product that would attract customers and cause competitors to play catch-up. A team that included the best developers, in the company, was hand-picked; the business was told that cost was not a concern; and the group was secluded from the day-to-day madness and allowed to focus on getting the job done. Despite this the program was a failure and ultimately the task of innovation was “outsourced.” What happened?

A number of major shortcomings inherent in the existing culture doomed the endeavor from the start; these shortcomings were very visible to outsiders but not to long-term employees. Not all organizations face all of these shortcomings — based on my experience, these are more prevalent in larger organizations.

• C-level managers not creating a learning organization
• Lack of a compelling vision
• Lack of prioritization and understanding of what is truly valuable
• Org structures and policies that stifle collaboration and communication of ideas, information, and feelings
• Reward/merit system that punishes innovation and risk taking
• Overly focusing on utilization
• Perception that senior management does not walk their talk

C-level managers not creating a learning organization

A belief that there is one right way and one right answer coupled with the allure of doing it right the first time makes it hazardous for employees to experiment, learn from mistakes, and to try novel approaches. Most command-and-control cultures penalize mistakes and those who have the temerity to try something new quickly learn that it is wiser to dutifully follow every rule and guideline — it’s safer to claim that any failure was due to a shortcoming in the process.

Over time, existent unwanted company behaviors, norms, and values supress any creative desire and motivation that employees may harbor about building a culture that encourages inquiry and trust. The job becomes a 9-5 grind and people stop offering ideas for improvement.

Lack of a compelling vision

Executives sometimes think that what ought to be done will get done without them getting personally involved. They tell what they want but fail to explain how to achieve what they want and why the want is even important. People lower in the organization hierachy are left to wonder, “Why should I/we ___?”

A non-existent vision or one that doesn’t align with what employees value and is imposed top-down guarantees lack of buy-in. As Patrick Lencioni so succinctly stated, “Trust and ability to speak freely are the building blocks for eventual results.”

Lack of prioritization and understanding of what is truly valuable

Some companies lose their ability to probe, sense, and respond to market conditions. They inadvertently fail (or purposely ignore) to ask existing and potential customers what they want and what they are willing to actually purchase. Assumptions are made by marketing heads or business owners based on their beliefs, prejudices, and opinions. These unvalidated assumptions often prove to be untrue and result in products being developed that no one wants to buy.

The problem is exacerbated when teams are not provided proper guidance on what is truly important. If everything is deemed a high priority (happens in cultures where IT is unable to say “No” to any business customer) then people end up multitasking, which leads to a loss of focus, more defects, delays, and no time for learning and self-improvement.

Org structures and policies that stifle collaboration and communication of ideas, information, and feelings

A command-and-control culture combined with a fractured (silo) organization causes an “us” versus “them” mentality to take root. Looking good, hiding bad news, shifting blame, and painting an overly rosy picture soon follow. A greater need for written communication (used for CYA) further dampens progress. When silos are present you often hear statements like, “that’s not my job” or ” I don’t care about the rest, I did my part.” Eventually we also lose the concept of teams and end up with a group of individuals working on a project. We also lose any understanding of a system-wide value chain. Incentive systems that reward local optimization worsen the situation by encouraging groups to make locally optimized self-serving decisions that negatively affect the whole. (See the Robbers Cave Experiment for how easy it is for such a mentality to spring up.)

Reward/merit system that punishes innovation and risk taking

When being right, making no mistakes, and doing what you are told is valued, people stop trying new approaches. They stop taking risks when their annual merit increases and bonuses are tied to metrics (often vanity ones) that aren’t aligned with the company’s goals. When meeting project time, scope, and budget constraints is how people are evaluated and compensated then it is not surprising to see them disregarding the concept of providing value; its more common to see fudged reports and gamed metrics. (Also see Jim Highsmith’s article, “Can-do Thinking Makes Risk Management Impossible.”)

Managers who don’t understand the difference between common and special causes only create additional rules and policies that further burden teams. Most managers also don’t understand that artificial targets and incentives don’t help if the process itself has problems. (For additional information search for Dr. Deming’s red bead game on YouTube.)

Overly focusing on utilization

An unhealthy stress on maintaining high utilization leaves no time for learning, thinking, improving. Departments want to show that they are very conscientious in how they spend scarce dollars; pushing employees to book all their time to specific projects helps show that employees are valuable and busy. Batching large chunks of work and getting people to be as efficient as possible at each step defeats the goal of making work flow so as to provide value to customers early and often.

Utilization goals of close to 100% are counter-productive as they encourage multitasking and creation of busy work, cause employee burnout, increase defect rates, slow down throughput, increase focus on activities instead of on outcomes, and leave no time for self-improvement. Without time to learn new technologies and keep with with new trends employees cannot be expected to come up with creative ways of getting things done.

Perception that senior management does not walk their talk

People quickly see through any political maneuvering or chicanery that senior managers might employ in order to look good. They lose faith and respect for managers who are more interested in playing the political game and not in doing what is right for the company or for the team. Such managers lose moral authority and have to resort to organizational power to get anything done. At best they get compliance; not the passion and creativity that an engaged employee brings to the table.

Other managers talk a great game but fall short on execution. Ultimately, actions speak louder than words and when there is a disconnect between what is said and what is done, people begin to disregard the spoken word. If managers and executives really believe in something, they should take every opportunity to demonstrate its importance. When employees don’t see the passion and don’t hear the message communicated over-and-over again they rightly assume that the new thing is just another passing fad. It isn’t the emloyees’ fault that they don’t belive; it is management’s responsibility to create new experiences that permit employees to question their existing beliefs and to try new actions in the hope of getting better results.

In conclusion

So, why did this company fail to innovate? The group had shortlisted 8 possible things they could work on but they dithered for months about which of these to work on first. They failed to quickly validate their assumptions on whether the market really wanted any of the things being proposed. The group continued to rely on tried-and-true methods and constantly referred to what had worked in the past; they failed to realize that new approaches to development were called for. They lacked managers unfraid of making decisions that were not guaranteed to succeed. They lacked executives who could provide the group with a clear direction or a challenging vision. A political struggle between the CEO and CFO worsened the situation and neither wanted to compromise on his agenda.

This company had over the years deemphasized systems thinking, personal mastery, shared vision, and team learning. Was it then any surprise that their ability to innovate had withered and disappeared? Losing the innovative edge makes it harder to keep up with faster nimbler competitors who aren’t resting on their laurels and are actively looking for ways to leave you in the dust. Ultimately, being nimble and agile is not a choice — it’s a necessity for survival and growth.

• What went well this year, or what did I do well this year that contributed to my personal, professional and company’s success in 2011?  Celebrate these successes and consider ways to leverage them in 2012.
• What wasn’t successful and I should try to stop doing or do differently?  Celebrate these attempts, laugh where possible and leverage what you learned in 2012.
• What changes am I going to make or try in 2012 to improve my results?  Focus on one or two things that you believe are important to try.

Now consider what you’ve done, learned and will try relative to the challenges you know are ahead in 2012.  Planning or strategizing for the nearest challenges in the New Year relative to what you accomplished and learned in 2011 will provide some guidance on the first steps you should take.  Additionally, here are three things for you to consider as you begin to think about the work ahead:

Alignment – Is there alignment between your customers needs and what you are delivering?  Is there alignment or agreement on goals?  Is there alignment between your personal and professional goals and what the company needs to be successful?

Transparency – Be open, honest and respectful in communicating and delivering what needs to be accomplished, why it is important to accomplish and how it will be accomplished.  Alignment is not possible without transparency.

Success – What does success look and feel like to you?  Create your vision of what success feels like and work with your team, your management and your peers to create a shared vision of success to help guide the organization.

I have often found that creating a shared vision of success for a team provides a compass for a team as well bringing the team together to work collaboratively towards a goal.  Understanding the organization and your client’s needs begins the necessary step of aligning priorities, and determining how best to meet the challenges.  Finally supporting and enabling transparency helps create an environment where the team can self-organize, where the learning process is valued in determining how best to solve a problem and collaboration can be improved, ultimately improving delivery.

Edgar Schein is a former MIT professor at the Sloan School of Management and author of numerous books on organizational development, the consulting process as well as other subjects. Schein’s work is based on over forty years of consulting experience. He is also generally regarded as the originator of the term ‘organizational culture’.

Schein views the consulting process as essentially a ‘helping’ relationship between the consultant and the client. He gauged each interaction with a client by the degree that the relationship had been helpful and whether or not the client felt helped.

I found Schein’s list of ten tips on creating and maintaining a helpful client relationship to be directly applicable to our work as coaches and essential to helping us create and maintain great relationships with our clients. I have included Schein’s list below along with one additional tip and a bit of personal commentary.

1. Always try to be helpful – Coaches have to know when to help, how to help and learn to see what the client is really asking.
2. Always stay in touch with the current reality – this could be the most important principle because it is really about being mindful. Staying present and aware of what is happening here and now is one of the most fundamental skills that a coach should develop and the key to performing well with all of the other principles listed here.
3. Access your ignorance – asking ourselves what we really know vs. what we think we know is an important exercise for coaches and one that can help keep us grounded and in touch with what is happening now. In other words, question your assumptions.
4. Everything you do is an intervention
5. It is the client who owns the problem and the solution
6. Go with the flow – if you remember principles one through three you should have not trouble with this one
7. Timing is crucial –Finding the proper moment to bring up a sensitive subject is crucial to building and maintaining a helpful relationship with your client.
8. Be constructively opportunistic with confrontational interventions – there are times when clients are more likely to respond to intervention. Be patient and wait for the right time. Any questions see principles two and seven.
9. Everything is a source of data; errors are inevitable – as Schein says, we all make mistakes. We, as coaches, have to accept the fact that we make mistakes and do what we tell our clients to do – learn from them.
10.  When in doubt share the problem – this one is about coaches helping each other, which is something that we do continuously at Big Visible.

I really like this list and find it helpful to refer back to it occasionally. However, I would like to add one of my own…

11) Set expectations up-front and adjust as necessary – your personal preferences and coaching style and that of your client’s will contribute to the specifics of this conversation, but suffice it to say that open, authentic, conversation about expectations is essential at startup and throughout the process.

Step 1. Lead from the front using the leader part of servant leader. Use this when the team is lost, going off the rails or about to run back into the burning barn of traditional project management.  As soon as the team gets their bearings, starts being honest with themselves, or chooses not to get burned again, move immediately one step back and to the side.

Step 2. Coach from the side. Be there on the sideline giving support, offering suggestions and providing guidance. Shift to Socratic method.  Once the team gets their confidence back, take another step back, moving behind the team.

Step 3.  Mentor from the rear.  look for patterns, learn how the team(s) are moving ahead through their challenges so you can lead them when they ask for help.  Remember you are now a firemen always ready to go when the team rings the bell.  When you get to the fire you’ll know which steps to take.

Archetypes of Product Owners

I don’t mean to imply that every product owner I’ve worked with could fall into one of a series of buckets, nor that alignment with a single archetype would imply someone can not behave according to another. In fact, as I look at the people I have had the privilege to coach and work with, I see the archetypes representing a couple progressions individuals move through towards becoming truly effective agile product owners. These categories capture the essence of different roles I have seen people play. Some are good, some are bad, and some are somewhere in between. The most hopeful thing is that I have seen people successfully progress from one to another and to another as they learned and grew in their role. Thus, these don’t imply a fixed classification, but rather a step in a journey.

The Stenographer

This is a place where many people find themselves – including yours truly – at some point early in their career as analysts. Whether they are an analyst or a product owner, they are simply expected to ask the customer what they want, and to write it down. Unfortunately, my experience was that my customers were notorious for asking for a solution they thought would solve their problems without actually articulating what they were really trying to do. Indeed, my own journey beyond this archetype really began when I was able to eliminate a six month development project by talking through with our business partner in response to a request they submitted for some new functionality. Low and behold, we were able to offer that capability to them with the current system by using a few tricks!

As a product owner, the stenographer finds themselves – by choice or organizational imposition – in a role where they are unable to influence and not expected to add much expertise or knowledge to the problem domain. Product owners in this role may feel more like order takers from higher up executives who are looking to use them as interlocutors to relay requirements to the development team. Unfortunately, this is a self-defeating position for a product owner. They are unable to articulate a clear direction for the team to execute against, because they must continually go back to get questions answered.

Ultimately, product owners must outgrow this limited model and become masters of their own destiny if they are to help guide their teams in a coherent direction. In fact, many organizations embarking on an Agile transformation are open enough to change that this provide an opportunity for an un-empowered analyst to grab the opportunity and find a voice nobody knew they had. They begin to show leadership and vision, at least enough for the team they work with to execute effectively.

The Decider

Offering confident message and vision forward, we see product owners in the decider archetype offering a clarion call to their team about what must be done, what order and to what end. The key benefit they offer the team is decisiveness and a vision to execute against. No longer must the team troll through enormous document to glean a possible answer to a question. No more must they wait weeks to float questions in order to get simple answers. The decider short circuits these anti-patterns and provides consistent and timely information to the team so that it can continue to do what it does best: deliver software.

This is not to say that the decider has no product expertise, as some are quite experienced in their domains, but rather that their primary locus of control is in the stated role of product owner being the “single wring-able neck” who owns the product backlog for a team. They cut through the ambiguity and uncertainty so that the team doesn’t have to. At their best, they are able to set both “big hairy goals” for the project and tactical goals for the team. One precocious product owner I worked with really took to this concept. I recall working through a story map with her when we were identifying their first release. Working with some key people on her team, they decided that the priority for the first release was to confront product and technical risk. Once she clarified that goal, she quickly move through the backlog and de-prioritized anything not meeting that criteria. I recall her looking at each piece of work and simply stating things like, “well that doesn’t move us any closer to our goal, so let’s put it off until later”.

She provided a consistency that allowed the team to focus on a goal and not get bogged down in changing scope or a morass of requirements for the project that were not terribly important but threatened to distract the team.

Unfortunately, this archetype is not without it’s downside, and I would describe this as a transitionary place for product owners. While they cut through ambiguity and provide clarity of purpose, this is not always informed by deep product knowledge. Product owners working in this model run the risk of sending their teams off a cliff. Fortunately, the nature of Agile projects is designed to accommodate this, by allowing for false starts and early failure. The impact of a lost two week iteration is usually not profound for a large project that is being properly managed. This is also the opportunity facing these product owners, namely to learn more about the domain. The iterative nature of Agile projects provides ample opportunity for individuals to test a hypothesis, experiment, and learn. This opportunity is not lost on good product owners, and we frequently see them become veritable authorities within their product domains moving them into the next archetype, the genius.

The Genius

Product owners in this archetype are generally coming from one of two paths. Either they have been playing the role of product owner for some time and have used that opportunity to accumulate experience, or they are credible subject matter experts within their domain already and have now been put into the role of product owner to lead an Agile team. These individuals frequently retain the confidence and decisiveness of the decider archetype, but they can back up that clarity of purpose with a significant amount of expertise. A general difference I see between geniuses and deciders is that deciders are generally more focused on the tactical decisions. They lay out the next release or prioritize the next set of features. Geniuses will focus more energy and time articulating the big picture and crafting a bold and ambitious vision for the product overall.

This depth of personal knowledge about a product domain can be incredibly valuable to a team. It allows the product owner to better educate the team about the nature of the domain, answer difficult questions, and in general set context very well. This in turn allows the team to be more responsive and creative in their own solutions. Unfortunately, this expertise comes with a couple of risks. While a product owner with this level of expertise can be quite effective, if they do not share their understanding and help to explain their vision clearly to those around them, their expertise can effectively be wasted. Indeed, it may be quite a difficult situation for a product owner in this position, as the “curse of expertise” can even undermine their ability to communicate effectively. A critical success factor for product owners in this model is to be able to clearly articulate complex ideas. Even if they do share their expertise, they are still prone to the risks that face any expert in that their own past experiences may actually become liabilities. As the economist Kenneth Boulding once famously said, “Nothing Fails Like Success.”

Namely, patterns and approaches that have served us well in the past will invariably be used again in the future, until they fail. If an expert has used a limited set of techniques or perspectives to great success, they may be unable to let them go and move on to new ideas and concepts. Similarly, the genius archetype must avoid leaning on their own expertise too much and not exploiting the empirical feedback loop available to them inherent in any iterative and incremental project.

The other major trap that I have seen product owners in this role fall into is what Fred Brooks dubbed the “second system effect“, where they have the opportunity to build a newer version of a system they are already familiar with and become seduced by progressively more and more advanced capabilities until they have conceived of a system that is unnecessarily complex and expensive. This risk can even be amplified within an Agile project, as there are less constraints upon the scope that a product owner can request. The best way I have seen to guard against this type of dynamic is by laser like focus on tactical goals when prioritizing work for each iteration. Ironically, these are the skills that the decider archetype most embodies. Thus, some people may begin their journey as a budding product owner who is able to cut through the fog of complexity, but then later succumb to it as they learn more and more about the very system or product they are guiding.

Ultimately, the genius archetype faces the challenge of growing by increasing feedback channels available to them. The specifics for these sources are numerous and vary based on the context of the project.  It may be reaching out to less vocal stakeholders, like support or operations, in order to broaden perspectives available to the team. It could be building stronger relationships  with product development and finance in order to keep things like scope and budget within agreed upon constraints. It may also take the form of continuing to exploit iterative work in order to get empirical feedback and conduct testing and validation of concepts with the project team. Regardless of the details, experts need to ensure that they never allow their perspective become hermetically sealed within the world of their own personal experience. Having learned a significant amount about their problem domain, their journey is to continue deepening that knowledge as well as expanding the horizons into adjacent areas.

The Diplomat

The first two archetypes discussed rest upon one major assertion: that the product owner truly has the authority to articulate and prioritize work. If you read the Scrum Guide or just about any text book on Agile Software development, you will see that this is a requirement for an effective product owner. Unfortunately, I have seen too many projects where this is simply not the reality. In some cases, organizational policy, where the development team and their customer proxy are simply not empowered to make product decisions. More than anything else, this explains how people find themselves within the role of stenographer.

We explored the concept of product owners being given the authority to make decisions, as well as in some cases them simply grabbing it. But there is another path forward where product owners exert influence over their product with limited authority. This is the archetype I call the diplomat, where savvy product owners without formal authority are able to clearly and strategically work in environments to establish clarity of purpose and get questions answered so that the team can work effectively.

While the diplomat’s ownership of the product backlog may be limited, when played effectively, they can confront problems by bringing the various stakeholders together and getting them to work through their own differences. In fact, establishing a consistent vision across numerous project stakeholders is probably one of the most effective things that a product owner can do in many organizations. I have seen numerous companies where their software development process has become so fragmented and slow that no clear vision or priority exists between the business and technology partners; in some cases a consistent vision doesn’t even exist within the technical or business silos! In these situations, a thoughtful product owner can deliver immense value to their organization by bringing the different stakeholders to a table and helping them see how their inability to resolve differing priorities undermines the success of the very projects that they all depend upon.

At their best, diplomats are able to use organizational jujitsu so that people with various conflicting priorities are able to come fact to face with each other, discuss their interests, and make a decision in the best interest of the project, program and company. This is obviously much easier said than done, and I could probably write a series of blog posts discussing different techniques available to product owners in this archetype. I have seen product owners use very simple techniques to great effect, like insisting that all stakeholders agree on what to work on next, anything the group can’t agree on, doesn’t get done. This can provide powerful motivation for people to interact and work together.

While the diplomat can be quite effective and valuable in organizations where there are numerous stakeholders who wield immense influence and aren’t always in alignment, there are some limits to what someone operating in this model can achieve. Their contribution is basically limited by the ideas brought into the common pool of discussion between stakeholders. Much like the decider, they are not so much adding expertise, rather than simply cutting through conflict and indecision. In order to grow, diplomats must grow their own expertise and offer more value than simply bringing parties to the table and helping mediate differences.

The Catalyst

Moving beyond simple positional negotiations, experienced diplomat product owners move into another category I call the catalyst. In this archetype, they have accumulated considerable experience in their own right both in the problem domain, as well as in negotiation, communication and collaboration. Superficially, it may appear that they are operating in a similar model to the diplomat, but there are two key differences. They are strategic in who they engage and they are able to engage people in a way that allows new solutions to emerge.

As the name implies, catalysts play a critical role in helping get elements already within the system to react in ways that release energy or cause other valuable changes. In the case of Agile software development, this may be bringing to seemingly irreconcilable groups together to craft a shared vision allowing them to see how their interests can positively intersect. It may be pursuing other stakeholders in order to better balance the vision for a product. For example, one product owner I worked with brought several of the people from the business unit he represented to meet with the team periodically. They would show the team the type of work they did and how the project was going to benefit them. Incidentally, in one of these discussions, the lead architect happened to key into one pain point they mentioned about compiling reports – the point of this entire project was to streamline operations for this group – and he began to explore an entirely different solution to help solve that problem. In the end, his side investigation identified a novel way to use some of the systems they were developing to deliver automation to this business unit significantly faster, also meeting the ROI target of the project before they had completed the primary deliverable.

The catalyst is comfortable with problems with no apparent solution and invites as many perspectives as possible when confronting the problem, even if they have amassed sufficient authority that a decision rests solely within their domain. They understand that a shared vision not only fosters more solutions, but increases follow through on the actual execution. The challenge facing the catalyst is that regardless of the number of feedback loops they develop and their ability to engage different stakeholders, sometimes product require breakthrough innovation and different thinking. Apple offers a striking example of apparently counter-intuitive thinking including intentionally designing products they think are cool rather than doing market research. In the end, we see the catalyst growing by building up product expertise from unique sources of feedback and eventually converging towards the path of the genius.

Two Different Paths

These archetypes present more like a series of logical stepping stones for someone to make as they progress towards being an increasingly capable product owner. Some product owners focusing on exerting authority in the decider archetype. From there they build expertise and eventually move into a genius role. Others do not have the opportunity up front to be authoritative and must opt for a diplomat archetype. The growth opportunity for them is to build authority and decision making capabilities through their growing ability to influence without explicit power, allowing them to grow into the catalyst change. When first laying this out, I didn’t mean to show a progression, nor did mean to have the two paths diverge and then converge. Is there a sixth archetype that sits between the genius and the catalyst? Is there some ideal mastery of both influence and expertise that all product owners are striving to achieve? While I certainly agree that there are always further opportunities for growth, I’m not sure I can identify an idealized end state for this journey, so for the time being I have left this spot open. It seems identifying a terminus for some perfect product owner would undermine the concept of continual learning and growth that is one of the most important things I see in successful product owners. So let me just conclude on a note that there is no one pre-ordained journey. By enumerating these archetypes I hope others in those situations can help identify their circumstances and use that awareness to their advantage.

“Hey, man! One week down, two weeks behind…” -Kirk Lazarous, Tropic Thunder (2008)

While not a terribly serious movie, I have always enjoyed this quote from the comedy movie about the ill fated making of a war movie. The concept of being only one week into a project, and yet somehow already two weeks behind seems so absurd as to be impossible, and yet it has been the reality for a lot of projects encountered. Invariably, ambitions around projects can get so high, with so many stakeholders that our definition of success rapidly becomes so great we watch the possibility of completing our project recede into the horizon. Properly defining and then managing project success is a critical activity in any project. There are a number of excellent resources I’ve drawn upon over the years to do this. This blog post is more a compilation of my thinking on this topic threading through some of these techniques.

The Iron Triangle of Project Management

Fig 1 - The Triple Constraint

The first concept I encountered on this topic was introduced to me as a project manager. I was told to manage the triple constraint of scope, schedule, and budget. The concept is simple and quite effective. On any given project, there are fundamentally three constraints, the amount of work you’re going to deliver, the amount of money you’re willing to spend, and how long the project can run. As the name implies, these are constraints imposed upon a project, “you must finish by 12/31/12″ that will be used to determine if a project was successful or not. As the triangle image demonstrates, you can constrain on up to two dimensions, but not all three. Thus, you could engage with a project sponsor in an earnest discussion about where you would put the prioritizing focus for a given project. Let’s look at some examples to better illustrate this point.

Fig 2 - Triple Constraint Examples

The first example is a pretty straightforward single constraint where the delivery of a set number of features is most important, while schedule & budget being less important. My favorite example of this would be Blizzard entertainment, who explicitly refuses to announce release dates in advance for their games, rather insisting they build them properly and that it’s “done when it’s done“. The next example we see is a double constraint. In this case, we are prioritizing one of the two constraints over the other. A colleague working with an entertainment company offered a great example for a project like this. He had a specific team (fixed budget) and was building a new application for an upcoming sporting event. Thus, if they didn’t release by a given date, the application was worthless. In this case, the scope of what they release was actually the least important thing. Lastly we come to one of the failure models for this approach, which I would call the cop out. In this case, the sponsor basically puts the focus exactly in the middle, saying that everything is important. As you can imagine, this does not set up a project for success, as we have no flexibility along any dimensions.

From a project management point of view, I can see the value of this tool. However it leaves many questions unanswered. How important is it that we build something which is reusable and can be built upon in the future? How important is it that we invest in the team? Are there specific ROI figures that are required for this project to be viable? These are all left unanswered by such a tool. These limitations were clearly articulated when I managed to deliver a project on time, on budget, and to scope but it delivered zero business value.

Success Sliders

Rob Thomsett introduced the concept of Success Sliders as a means of exploring more than just three dimensions when considering the success of a project. This technique offer the ability to break apart that ambiguous concept called “scope”, or prioritize other dimensions like quality and team experience. Indeed, you can use this type of model to prioritize along a virtually infinite number of criteria.

Fig 3 - Success Sliders with a force ranking

Figure 4 - Score based Success Sliders

There are two common implementations I’ve seen of this technique. The first, demonstrated in Figure 3, is a force ranking. In this example, a number of stakeholders each individually had to force rank the priority of a number of different criteria such as “realize ROI”, “High Quality”, and “Deliver Project on Time”. Each individual stakeholder’s values are represented with a different color. The precise list may vary from project to project. In fact, eliciting and elaborating specific criteria can be an art in its own right. This example shows how different stakeholders show their perspective of priorities so that discrepancies can be discussed and reconciled before a project falls into duress. The ultimate goal is a single prioritization, as demonstrated in Figure 4. This is a screen shot from a tool made available by Mike Cohn on his website. This example is different in two counts. First, it represents a single set of agreed upon values. Second, it is not force ranked, but rather a budget. You can only increase the priority of one dimension by lowering the priority of another. This sort of tool, especially when used with a number of stakeholders, can be an excellent way to work through different expectations and amongst different stakeholders. However, this technique also introduces some limitations. While it does allow us to prioritize, it can’t quite distinguish what the absolute criteria is. We can focus on dimensions, but are the top 3 deal breakers? What about the top 4? There still is some ambiguity we need to cut through.

Project Constraints

Jim Highsmith proposed the use of identifying project constraints to as a way of reinventing the triple constraint. His argument is that those dimensions can be prioritized into “Fixed”, “Flexible”, and “Accept”, but those can additionally be illustrated with threshold criteria. Let’s illustrate that tool with the case of the sports application.

In this example we see that the primary constraint is schedule. The application must launch by 3/1/11. The flexible constraint is budget. In this case there is an existing team, so while there is a little bit of flexibility with the budget, this dimension shouldn’t move too much. The final constraint is that they can generally accept an application that can provide scores and game highlights. Thus we see the project team must deliver the application by the specified date while adhering to the general burn rate it currently has in order to opportunistically deliver whatever functionality it can within those constraints. As you can see with this model, whave a more precise conversation around the precise criteria.

The concept of a fixed constraint compared to a flexible constraint can be applied to the broader set of criteria identified in our earlier exercise. Let’s take a look at the situation illustrated in figure 4 using a constraint table.

What Do You Mean, “All Scope”?

Regardless of which of these more detailed techniques you may use, clearly breaking apart the “scope” dimension is critical. I have participated on too many projects that have blindly said something like, “our new system should deliver all the scope of the old system”, without really doing any analysis of exactly what that is. Indeed, I find that the question of scope can usually be broken into smaller pieces. Let’s look at some examples.

• Break by users: some applications have either a wide array of user times or clients who use an application differently. In this case, you may want to identify different dimensions to prioritize. For example, you could take an online book store and break it apart by the different roles and say something like the functionality for an online book shopper is the highest priority, as they are the ones actually buying the books. Support for wholesalers providing the books and your administrative support staff may be lower priorities for your first release.
• Break by business objectives: many projects have hard interdependencies or down stream processes that require time in order to deliver their own functionality. For example, imagine you have a web service that a customer must interface with. You may have priorities by date, based on the delivery schedule of your partner. Let’s say that you and your hypothetical partner plan to launch a new service for the holiday season, which must be live by 12/1/12 in order to take advantage of the holiday season. However, your project is not responsible for integration with the vendor. Rather you, must simply provide them with a usable web messaging interface by 11/1/12 so that they have 1 month to tie it together an test. That delivery of a usable service may be a more important criteria for the team than the actual 12/1/12 implementation date.

Let’s take one last look at a hypothetical project book store project and see how this whole thing plays out

This is More That Just Mechanics

While these exercises might seem pretty straightforward and simple, sometimes they can be quite contentious. I have encountered a number of anti-patterns when trying to use these types of techniques

• “We already know what the priority is” - frequently a project manager or sponsor may state quite simply that this level of detail is not important, because they already agree on it. In these cases, sometimes the easiest thing is to ask them simply to write it down and compare it to what some other major stakeholders think. Frequently, this will reveal enough inconsistency that they realize they need to entertain a more detailed discussion about criteria
• “But I’m the sponsor, Isn’t this simply my decision?” – sometimes project sponsors may feel offended that you are trying to democratize what they see as their decision to make. It’s very important to be clear about the point of this type of exercise and how you will use it to make decisions. Chances are, a project sponsor funding the project will ultimately make the prioritization decisions and define the final criteria. The point of an exercise like success sliders or constraints isn’t to do that for them, but rather to surface the expectations and perspectives of other stakeholders so that the sponsor can make the best informed decision. If the dev manager says that reusability is very important for the success of this project, that very well may at least be worth entertaining the discussion to understand why. There’s a chance they may know something the sponsor doesn’t and the discussion will help lead the group to a better decision.
• “This is ALL important” – some groups of stakeholders may be unable to parse more detailed criteria like in some of our later examples in this article. Rather, they may have a very hard time saying precisely what is or isn’t critical for success. This is usually where a force ranking, like in FIgure 3, can be most valuable. Before even engaging in a discussion about which dimensions are truly must have, or even the precise dimensions, stakeholders must simply prioritize in a force ranked order.
• “We don’t want to preemptively surrender scope” – when engaging in this exercise with groups that have little trust, its quite possible the business may reject this type of exercise feeling like the development team is simply trying to get them to give up scope or lower expectations. The point of this exercise isn’t so much to surround things; ideally, we’d like all dimensions. The point of the prioritization is to do responsible project management. We want to know what’s truly important before we start the project so that people can make informed decisions along the way ad new can manage risk so that if things do go wrong, we are able to maximize the chance it won’t impact our primary success criteria.

When someone leaves, seemingly out of the blue, teammates and managers are often left confused and surprised. It’s easy to spot unhappy individuals when they complain, bicker, or exhibit clear signs of discontent. But what about those who are quietly unhappy? Without conflict, outbursts, or other overt signs of dissatisfaction, how can we spot those who are silently seething so that we can address their issues before they damage team morale or leave the organization?

Apathetic employees do exhibit subtle warning signs, if you know what to look for. Symptoms include disengagement, suboptimal performance, and a lack of meaningful communication.

Failure to Engage

The first sign of a pending retreat to apathy is disengagement. Warning behaviors might be subtle, and often include showing up late for (or even skipping) team meetings and being distracted or unresponsive when other team members are talking. Often, these outward signs of disengagement are attributed to a bad mood or a short-term personal problem. To make matters worse, by the time a person’s teammates start to suspect that there might be a deeper issue, the employee’s feelings of withdrawal have deepened. As a consequence, the disruptive behavior actually wanes instead of worsening. Because the inappropriate behavior has stopped, an individual’s co-workers might mistakenly assume that any issues at play are now resolved, and chalk up the incident to unrelated events. In actuality, the cessation of overt discontent is only masking the individual’s true feelings, which now include a growing resentment at not being understood.

As the employee’s discontent festers beneath the surface, it begins to affect how that employee relates to other team members, and also how team members relate to one another. As Katzenbach and Smith interpret in their Harvard Business Review article, “Teams develop direction, momentum, and commitment by working to shape a meaningful purpose” (Katzenbach, 4). When one member is segregated from the common goals of the group, it affects the group’s ability to collaborate. Conflicts that endanger that sense of team-ship, the “broader purpose which supplies meaning and emotional energy” will eventually affect group performance and drive (Katzenbach, 6). The team degrades into a group of individuals as socialization slows down and ultimately stops altogether.

To stop this dynamic, managers and team members must act at the first signs of disengagement, drawing the person into meaningful conversations to uncover the root cause of the individual’s unhappiness before it can infect the team. Don’t wait and assume the problem will fix itself. It won’t. Intervene before disruptive behavior becomes a more silent, and deadly, destructive force. It is every team member’s responsibility to hold teammates accountable for being a part of the team.

Failure to Perform

Another early behavior that can signal apathy is a gradual decrease in efficiency. As someone’s distracted behavior begins to permeate the work routine, tasks might take longer or decrease in quality.  Examples of low quality include a lack of detail or completeness. This might not be metric-quantifiable, as deliverables might not be materially impacted, but the gradual loss should be palpable by other team members. Like the disruptive behavior at team meetings, a failure to perform will eventually stop as the individual’s work ethic overtakes his discontent. The fact that the behavior flew under the radar, however, will only serve to fuel the employee’s dissatisfaction, causing the rift to expand.

One can find clues that might signal employee apathy in the work patterns found in sprint or release burndowns. Using metrics to look for performance problems can be a very dangerous slippery slope to undertake; however, if a burndown shows a marked change in a team, it should be a red flag to the team that a conversation is in order. The problem could be some impediment that the team or ScrumMaster can resolve. It could also just be a difficult task that is just bogging the team member down and that the team could help solve. Occasionally, however, it could be a signal that an employee is quietly unhappy.

No matter what the reason for the anomaly, the team should initiate a conversation as part of actively keeping all team members accountable for what they promise to deliver to the team. It is essential to demonstrate concern, interest and build a positive, supportive environment while the channels of communication are open—and before the employee shuts down, stops trying, and starts transference of his displeasure to his teammates. Team working agreements help foster an environment where conversations of this nature are common, and indeed expected of each member. When well facilitated and executed, they create strong bonds among team members, which is a key step in the building of any team, but is especially crucial for an agile one.

Failure to Communicate

As bad as disengagement and sub-optimal performance are, degradation in communication among team members is the most destructive, and ultimately lethal, symptom of employee apathy. As Weiss and Hughes indicate, to build “truly effective collaboration” among the individuals of the team, teams have to “realize that conflict is natural and necessary” (Weiss, 1).  The lack of conflict in team interactions is an artificial form of harmony that does not help a team perform, or truly collaborate towards high performance.

If a team environment does not have conflict, they are not going deep enough in their conversations, and therefore not getting the most out of their interactions. A false sense of harmony should not be allowed to persist. Don’t be afraid to be the one to bring attention to this.

Rock the Boat

While it might seem harmless compared to more overt disruptions, apathy is a silent disease, creeping along the living spirit of the team. If left unchecked, apathy can spread far beyond one individual and disturb the inner workings of the team, disassembling a highly-productive group of individuals into just a group of people working together, diffusing their group identity, and blurring their common goals. The best cure for apathy is prevention.

Engaging someone who seems a little restless or is performing a bit below normal can be difficult to do. Forcing conflict into the light of day can be equally unsettling. In the absence of overt signs of discontent, many people attribute what can seem like small blips in behavior and productivity to a transient problem or personal issue that can likely resolve itself, and don’t dig further. Don’t assume. Don’t accuse. Don’t let it go! Ask! As uncomfortable as it might be, take early action at the first sign of trouble, uncovering root causes and forcing problems into the light. 

Don’t be afraid to rock the boat! It might be the best, and possibly only way, to keep it afloat!

Works Cited

Katzenbach, Jon R., and Smith, Douglas K., “The Discipline of Teams”, Harvard Business Review, Boston, Massachusetts, March-April 1993 (HBR Reprint 93207,  p.4).

Weiss, Jeff, and Hughes, Jonathan, “Want Collaboration? Accept – and Actively Manage – Conflict”, Harvard Business Review, Boston, Massachusetts, March 2005 (HBR Reprint R0503F, p.1).