Stakeholder anti-patterns

The best stakeholders tend to be product oriented people who have regular contact with customers.

Unfortunately in many organisations stakeholders have organisational authority but relative to the delivery team exhibit ‘junior’ behaviours that impede the chances of creating great products.

Building digital products involves many moving parts — design, technical architecture, development, devops, QA, 24/7 operations.

Unfortunately stakeholders can make a difficult job harder.

I’ve been collecting a list of anti-patterns that I sometimes see from stakeholders:

• Changing Priorities
• Unplanned Work
• Lack of Engagement
• Micro Managing
• Company vs Customer Focus
• Personal Agendas
• Responsibility without Authority

I would love to offer you all a guide for dealing with these anti-patterns. However at Snapp, we prefer to focus on engineering challenges and accept that there are people who are much more adept at managing stakeholders. If anyone reading this wants to propose some strategies for managing stakeholders, we are happy to have guest posts.

Changing Priorities

This could also be called lack of focus. In this anti-pattern, stakeholders continually disrupt the flow of work by changing priorities for the team.

At it’s worst, these priority changes start to impede the delivery of sprints. Other times it means delays to shipping product. It can often lead to disjointed products that dilute the customer experience.

Under these circumstances delivery teams lose focus and become less effective. This inevitable degrading of a team’s performance typically results in other anti-patterns being used such as micro-managing, lack of trust etc.

Most often I see the cause of changing priorities as an indicator that the stakeholder in question is not the decision maker and they are mirroring demands made by others higher-up in the organisation — i.e. people with more ‘authority’. Other time, a stakeholder does not have the requisite experience to hold ground and they are influenced by those who ‘shout loudest’.

Irrespective of the cause, the stakeholder fails to set a true north for the product and the team.

Unplanned Work

This is a close cousin to Changing Priorities but can have different causes. Unplanned work come in the form of requests made to a delivery team which disrupts their focus. For example, a team that is focused on delivering a feature over the course of several sprints will be disrupted by demands to work on unrelated items.

Unplanned work comes in many different forms. Bug fixing, design changes, support of release processes, preparation of a demo, and more. However it is not the nature or even the importance of the work that is problematic, it is that it disrupts the team’s flow and delivery focus.

The stakeholder is not always the source of unplanned work. When they are it is often because they exert influence on the product or ux design late in the day (see Lack of Engagement), they set artificial deadlines that are not customer-focused (see Company vs customer focus) or they demand must-have or hero features that were not part of the roadmap (see Changing Priorities).

The impact on delivery teams is the same as with Changing Priorities. Lack of focus and reduced output.

An alternative behaviour by stakeholders would be to recognise that the newly requested work is unplanned and then batching this work to be done after the planned work.

Lack of Engagement

A very common challenge for delivery teams is that key stakeholders are only part-time participants in the delivery. Stakeholders will suddenly parachute into a delivery and disrupt — not intentionally, but because this behaviour is almost always accompanied by other anti-patters — Changing Priorities, Unplanned Work, Personal Agendas and Micro Managing.

Unengaged stakeholders typically fail to give timely input into product decisions. They make demands that disrupt team activities and dive into details on some topics whilst remaining high-level and vague on others. They often tug at the edges by doing things like questioning UI/UX, prioritisations and planning.

A common facet of this anti-pattern is that the stakeholder isn’t viewed part of the team but some remote figure. However, for stakeholders to be effective, they must be very close to the delivery team and provide feedback, guidance and encouragement. It is sometimes surprising when stakeholders remain aloof although have a reputational stake in the outcome.

When a stakeholder is absent from the delivery, the team must make extraordinary efforts to ensure his/her involvement. Regular builds of the product must be available and maybe even time alloted to sit with the stakeholder to review these builds. Clearly this distracts from the actual work of delivery. (On a recent project, a stakeholder had not even installed the app version that was going live — a receipie for mismatched expectations.)

Others in the project might find that they have to work extra hard to protect the delivery team from the stakeholder. However, this shouldn’t be done without a parallel activity to foster more engagement and participation — otherwise it leads to stakeholders becoming disenfranchised.

Micro Managing

It might be that some stakeholders are highly technical and therefore want to be more hands on — however this anti-pattern isn’t about them. The scenario here is about the of lack of trust in the delivery team.

Often coupled with a lack of engagement, micro management is usually a knee-jerk reaction by a stakeholder who suddenly feels the need to course correct or exert control.

A challenge to the delivery team is that micro managing stakeholders aren’t able to get into the detail of the delivery because it is too technical or specialist in nature. You often hear phrases such as “I don’t understand why…” or “Isn’t is simply a matter of…” or “Why does this have to be complicated”. The upshot is that considerable effort is expended explaining things to stakeholders.

The impact of micro management is once again a lack of focus for delivery teams. Other disruption can be changing team composition, bringing new people into the team or exerting a different delivery style or overlaying another methodology (usually waterfall).

Delivery management becomes consumed with managing stakeholders rather than managing delivery which only goes to exaccerbate the perception by the stakeholder that they must get more hands-on. In other words, it becomes a downward spiral.

Company vs Customer Focus

This anti-pattern is possibly the one I see the most often. In many companies, stakeholders must be adept at organisational politics, positioning and maneuvering. The delivery team becomes co-opted to feed internal company “needs” rather than those of the company’s customers.

Unplanned features can be introduced, the product roadmap can get distorted and the underlying vision of the product can become ignored.

In one organisation I worked with, the project was battling to deliver a complex set of features that were entirely unrelated to the goals set out in the project initiation. In fact, the features that customers had articulated as being critical were not even on the product roadmap for the next 12 months. Nobody in the delivery team talked about customers, however satisfying the senior stakeholder who forced the change of focus was mentioned regularly in the context of satisfying his needs.

The impact on the delivery team is that they start to forget the reason for doing the work in the first place. Developers can get caught up in focusing on technology for technology’s sake. Designers start to drift into prematurely creating toolkits and design systems instead of addressing customer needs. Product and project managers set priorities according to internal stakeholder wishes.

The result is a lot of human effort expended on a delivery that is not focused on customer needs. Apart from the financial cost, I have seen a human cost for people who become disillusioned but at the same time are programmed not to give up. The whole endevor becomes an endurance exercise.

Anti-patterns that often accompany this one are Changing Priorities, Unplanned Work and Personal Agendas.

Personal Agendas

This anti-pattern resembles Company vs Customer Focus however it is the individual’s personal agenda that needs to be served. Often the stakeholder’s agenda is part of his/her personal career advancement or some political positioning.

Stakeholders who prioritize their personal agendas do so at the cost of serving customer needs. The customer becomes less important than the stakeholder.

An example I have seen is a stakeholder grafting a feature on to a product that he failed to deliver on a different project for the company.

The impact on the delivery team is the same as for Company vs Customer Focus, namely the team can lose direction and it becomes unclear why effort is expended on certain features vs others. There is also additional effort expended by product and project managers as they juggle satisfying multiple audiences, namely stakeholders and customers.

Responsibility without Authority

Stakeholders who tend to micro-manage usually bring a management style where they wish to tightly control the activities of the delivery team, but do not want responsibility for impacts or outcomes.

In this setting a stakeholder will look to exert his/her will on the delivery team, but withdraw from getting into specific delivery details or impacts of their requests. The attitude tends to be — “Do as I command, but don’t worry me with the details of how.”.

The effect is that the authority of a delivery team to determine how to deliver is undermined and sometimes removed entirely.

The impact is that a delivery team quickly becomes less effective as they try to bend themselves around the will of the stakeholder. The team become drawn into taking actions that they would otherwise not make. The natural consequence is that the resulting poor execution is seen as a deficiency of the team rather than a direct result of inappropriate stakeholder influence. In extreme cases a delivery team stops taking initiative and become purely reactive to the stakeholder.

Delivery teams often start to lose individuals who are key decision makers — either because they leave the project or they withdraw and avoid taking responsibility. Product and project managers spend an increasing amount of time justifying decisions to the delivery team and demonstrating compliance to the stakeholder — this is instead of focusing on solving customer needs.

A term that I have come across that is related to this anti-pattern is “Servant Manager”. It’s a fantastic way to articulate the challenge of anyone in this situation. I will write about this some more in another post.

TL;DR

The best stakeholders tend to be product oriented people who have regular contact with customers.

Unfortunately in many organisations stakeholders have organisational authority but relative to the delivery team exhibit ‘junior’ behaviours that impede the chances of creating great products.

Patterns of unhelpful behaviour by stakeholders can be found across different organisations, cultures and personalities. Some common anti-patterns we come across are Changing Priorities, Unplanned Work, Lack of Engagement, Micro Managing, Company vs Customer Focus, Personal Agendas, Responsibility without Authority.