Silos, Politics and Delivering Software Products

Technical teams tend to be unprepared for politics. This leads to political problems being either accepted as tragically inevitable or written off as due to the incompetence of others. But politics is not inevitable and is not caused by incompetence.

Politics in business emerges when direction is not set with sufficient clarity. This can be best understood through the work of Patrick Lencioni, which will be explored in the next section. When armed with this understanding we’ll then move on to politics in the world of software development. Making software is a complex undertaking that poses special challenges. Nonetheless, the basic principle of setting direction with clarity is applicable. Better understanding the causes of politics will help us understand how best to either resolve or at least navigate politics in software projects.

Politics in the Business World

Some companies have a clear focus, well-defined objectives and a strategy for achieving them. Others have come to be what they are through historic acquisitions and growth, resulting in a confusing structure and unclear direction. Focused companies experience much less internal division and politics than sprawling, confusing companies.

Focused companies are less political because they are focused. If the course of action is set clearly and leadership make it clear that they are behind it, then departments will work towards it. Politics happens when there is ambiguity about direction. That leaves room for factions to push their own interpretation or fight for their particular turf.

Some companies, especially large companies, have organisational structures that breed politics. This can even happen as a side-effect of success. A company starts out as a small challenger with a specific strategy for taking market share from the big incumbent. As it gets more successful it grows and expands its business model to sell more related products and services. Perhaps it also acquires other companies, some of which might only partially fit into the original business model. Eventually the focus of the company becomes obscured and departments find themselves battling for status and budget, each making the case that what they do is core to the business.

Lencioni suggests to reduce politics by setting a thematic goal for the organisation and sub-goals beneath that. A similar approach is taken by the Objectives and Key Results framework, where top-level goals are linked with lower-level objectives throughout the organisation. Lencioni cautions that simply producing goals and objectives will not resolve politics unless the direction set is very specific and actionable and has a unifying rationale behind it. Teams need to understand the direction being set by their leadership and what part they can best play within that. Otherwise there will be misalignments that will develop into conflicts.

Politics in the Software World

Misalignments can very easily emerge within software projects. Software is complex and the process of building it is complex. A project might have a clear guiding objective at a high level but could still become political as individual sub-teams might have misaligned interests or interpretations of their part in reaching the objectives.

Misalignments between teams can focus on priorities, scope or direction. Imagine that a team finds itself blocked as it is unable to finish a piece of work until work is completed by another team. The other team might not consider this a high priority item for them, in which case there is a misalignment of priorities. Or the other team might consider the work outside of their scope, in which case it needs to be resolved who should deliver the work. Or more seriously it could be a disagreement about direction - the other team might understand the request but consider it a bad request that they do not want to see fulfilled (e.g. the proposed change would undermine the design).

The complexity and specialisation required to tackle large projects can give rise to various kinds of silos. One might find misaligned interests between any of:

• Scrum teams within a large Scrum project.
• Particular roles such as DevOps, Quality Assurance or Product.
• Different stakeholder/user groups within the business.
• Hierarchical arrangements such as different levels of management.

Ultimately disagreements must be played out and resolved in order to deliver the project. A key challenge for project leaders is how best to organise projects to minimise the effort lost on political battles.   

Organising to Combat Politics

Larger projects can benefit from putting in place a framework so that working practices can be shared across the project. For projects involving multiple development teams, popular frameworks are LeSS (Large Scale Scrum) and SAFe (Scaled Agile Framework), as well as DAD (Disciplined Agile Delivery). There is a temptation throughout the software industry to look for stock answers to specific problems. Using solutions that others have arrived at has much to recommend it and often saves programming effort. But the devil is in the details. When it comes to arriving at an optimal way of organising for a project, there needs to be sensitivity to the specifics of the project.

A common practice is to dedicate teams to particular features with an intended system. Each team has members with different specialisations and is intended to be able to build a ‘vertical slice’ of functionality that could be delivered to users. For example, the team wouldn’t contain only frontend developers so that they would have to wait for backend developers from another team in order to progress. Teams that provide outputs for other software teams rather than for users are called component teams rather than feature teams.

Frameworks can help by providing guidance on structuring teams. LeSS recommends preferring feature teams, so as to reduce inter-team dependency. But how you break down which features are managed by which teams is up to you. It’s also very likely that you will have inter-team dependencies no matter how you organise as complex systems have interwoven features. Moreover, there will be cross-cutting concerns such as design principles that will need to be aligned across teams.

On larger projects not everyone can realistically be part of the core high-level vision setting. Instead, that vision needs to be communicated effectively. Visions evolve over time and projects need to regularly set specific goals for particular phases. Keeping teams in alignment tends to require time from team members. Time spent on this can be reduced by using representatives but using intermediaries can lead to misunderstandings.

The fact that there are competing frameworks is further indication that there’s no single right answer when it comes to project organisation or practices. Much as OKRs alone do not produce company alignment, project frameworks alone will not produce alignment in software projects. At best they provide tools for getting to alignment. It is up to the projects to apply those tools in a way that makes sense for them. Regular messaging about priorities and direction can be key to alignment. The more specific and focused, the better.

Navigating Politics as a Team

What if one finds oneself in a delivery team within a larger and politicised programme? Navigating inter-team politics can be a key challenge for a software team. Even for teams that are not part of larger programmes, there can still be big challenges in dealing with external teams (e.g. infrastructure teams) or stakeholders.

Politics can be a lot easier to navigate if one anticipates it. Teams can be much better prepared for political challenges if they anticipate potential issues early in the project. A useful technique is to map out what could potentially be an issue, how big the impact of it would be and who would be able to help with it. This is called an Impediment Impact Diagram:

 
Image source: Impediment Busting: Designing an Impediment Removal Process for Your Organization

These diagrams and more are discussed in Ken Power’s article Impediment Busting. If used early on, as a kind of pre-mortem, it can be used to cultivate relationships with key stakeholders. It can be especially helpful to establish early with senior stakeholders that they will act as a route of escalation. This way if their help is needed then it won’t come as a surprise to them. It might also be possible to call on these senior figures to deliver key messages to help align teams and ward off conflict before it happens.

Stakeholders and other teams naturally have their own priorities and need to be approached sensitively. Appreciating the priorities of others helps to phrase your approaches in a way that is more palatable to them. It can also make more apparent possibilities for negotiation. For example, perhaps you need another team to make a service available for your project but they’re currently swamped with other work. If you’re able to negotiate on timing of delivery then this can show understanding and help to build empathy.

Sometimes negotiation fails or isn’t possible without more senior representation. In some environments bringing in more senior managers can be a smooth step towards aligning priorities. In adversarial environments any escalation can be a delicate matter. Escalation can be seen as highlighting that expectations are not being met and might involve singling out a certain team’s course of action as presenting an obstacle for another team. Naturally this makes things delicate as people tend to be sensitive about how their managers see them and managers can become defensive when their team’s actions are challenged. One has to be sensitive to how the escalation is likely to play out if and if it will be further escalated up the chain. It can be valuable at any points of escalation to emphasise the bigger picture for the organisation and to find common ground or pointers toward resolution. This can help move the focus on to paths of action and the wider business impacts.

Resolving differences takes time and energy and not all battles are winnable. Building relationships can greatly increase influence but only within limitations and can be especially challenging in an environment which is already politicised. Sometimes compromises and workarounds are the best realistic options. It is important not to overestimate one’s range of influence. In politicised environments a key to success can be picking one’s battles carefully.  

About the Authors

Ryan Dawson is a passionate developer with an interest in software cultures and open source. He currently works at Seldon, providing tooling for machine learning deployments to Kubernetes. Ryan has been working in the Development scene in London across a variety of industries since 2007.

Laura Edwards is a Senior Product Manager at hotels.com and has been working in e-commerce and finance since 2009. Laura mixes strategy, detail and empathy to create customer-centric products & features.