We're all in this together: shared responsibility and incentive alignment in software development

Future-Proofing Nov 23, 2021

At any business where software is built, strategic decision-makers need to have a basic competence with technology and understand the principles of software development. This knowledge and understanding must be used by all decision-makers as they take an active role in software planning and development, not just those who write the software.

Despite how important this approach is, many companies that develop software for internal use are accustomed to separating “INFORMATION TECHNOLOGY” and “THE BUSINESS”, to the detriment of the company.

Dissolving these barriers and helping everyone actively participate in the development process can be the single biggest competitive advantage most companies have available to them. Producing value with software is hard, so being one of the rare companies that can do it will put you way ahead.

Leveling up, from communication to engagement

At companies where developers, system administrators, and their leaders are siloed from the rest of the company, various roles are put in place to assist in communication between these siloes. The titles for these roles differ from company to company, but you will recognize them as product managers, product owners, business analysts, project managers, etc.

While there can be some value in those roles, they often aren’t implemented effectively. When a project manager is responsible for a project being completed on time and under budget, they need to have the authority to make sure it happens. If a business analyst is responsible for software having the right features, they must be in a position to sufficiently influence what is being built. When leaders delegate responsibility to project managers and business analysts who don’t have the authority to execute, it hints at organizational problems that lead to inferior results.

Leadership across all departments and up to the highest levels of the company must be engaged in the delivery of effective, valuable software. If a company produces software expecting to bring value to different departments, the leaders of those departments must share responsibility for that value being delivered. They must be engaged during the planning and building processes; when value is delivered they share the credit, and when the software misses they share the blame.

For a company to build effective software, the finance department must be having conversations about the financial state of the company with software development leadership present. In a team setting that includes leadership from the software development team, operations must be discussing their key metrics and the challenges with achieving them. The software development team must be discussing their roadmap and communicating about upcoming releases with the entire company leadership. Any other departments must be similarly involved.

Here is where engagement comes in: when the finance team is talking about the financial state of the company everybody else needs to be tuned in, actively listening and considering what is being said. The software development team isn’t made up of finance experts, but the more they know about what is happening financially at the company the better they will be able to direct the software in a way that supports the finance team, even if that support is indirect. The finance team probably has never written a line of code, but as the software team talks through the roadmap the finance team will have context for important contributions to the discussion.

If an operations team isn’t ready to execute on the opportunities the sales team is bringing in, it won’t be a surprise to anyone when those opportunities go poorly. Nobody questions the need to have sales and operations aligned, but communication and effort around software development often receives less focus.

Everyone must work together to ensure that software is providing value, or at best there will be a lot of wasted time and effort building the wrong thing. At worst, opportunities and customers can be lost and a company fades to irrelevance while competitors execute.

Aligning capability, responsibility, and authority

In my experience, a misalignment between capability, responsibility, and authority is the single biggest cultural failing that leads to poor outcomes in software development. This misalignment certainly isn’t unique to software-producing departments and organizations, but problems seem more common here.

Capability – leaders need to be able to guide the company and its various departments to success, using a wide range of skills. A COO, for example, needs to understand basic accounting principles to build and follow a budget. A COO who refuses by saying “I never learned how to do that stuff” will be laughed right out of the position and out of the company. Saying “The developers never build what I need” indicates just as big a problem as not knowing (and not learning) how to use a budget for the department.
Responsibility – If something needs to be done, somebody needs to be in charge of doing it. That is responsibility, plain and simple. Responsibility can be (and often is) divided up, but it must be clear who is responsible for desired outcomes. Shared responsibility should mean that different people are responsible for different parts of a project, NOT that they are all responsible for the same thing.
Authority – The concept of authority is a bit different between organizations, but it generally means the power to dictate what is done, and who works on it. Authority can be shared too but is most effective when it lines up with responsibility. If you have ever felt like you have had multiple bosses, the scenario was one where authority probably hadn’t been fully figured out.

Let’s dig into these different attributes just a bit.

Capability

Capability is usually the least straightforward of these leadership requirements. Let’s start our discussion by talking about the software development team first, even though all leaders across the company need these attributes.

It’s not necessary to have software development leaders writing code themselves, and it’s not necessary that they have direct experience with whatever combination of languages, frameworks, and technologies are in place – although it sure helps! What IS critical is that individuals in these positions are able to effectively lead the teams and people who are writing the code, and those leaders must have an intimate understanding of how software is built and run.

A capable leader is trusted by their team. Software development teams with capable leaders know they won’t be over-committed to work that requires a series of death sprints to finish, for example. The rest of the company knows that the leader can execute on delivering software that is well-architected and stable, and which consistently delivers value to the users.

This question of capability applies to non-technical positions as well. If the software is regularly delivered to comments of “That’s not what I needed it to do!”, there may be problems with the capability of the team who is requesting features. Software developers need to be able to ask the right questions and make sure they understand what problem they are being asked to solve, but the stakeholders using and requesting the software must also be able to present the problem in a way that it can be solved accurately.

A leader with #3 (authority) and #2 (responsibility) who is deficient in #1 (capability) will spend a lot of time and money on software building things that never deliver value. Under this type of leadership, software development teams and stakeholders alike will experience never-ending frustration. The symptoms surrounding a lack of capability can vary, simply because there are unlimited problems that come up during the development of software and incapable leaders won’t have the knowledge and experience to help the team resolve them.

One unique point about capability is that it can be collaborative in nature. No leader knows everything, and nobody in the software industry has experience in every single area and with every single technology. Capable leaders rely on trusted team members who can help them make the right decisions; capable leaders regularly seek advice from (and defer to) others with more expertise.

While responsibility or authority without capability is harmful, the opposite isn’t ideal either. Not giving responsibility and authority to somebody capable means that the team is less likely to achieve the full potential of what they might otherwise accomplish.

Responsibility

The concept of responsibility is reasonably straightforward – making sure that it is properly distributed can be more tricky.

It’s not difficult to assign responsibility. If anything, responsibility is too easy to hand out, to the point that it can be distributed for the wrong reasons. Leaders will often make people responsible for things without making sure that they are capable, or without giving them the proper authority. This may be done in an attempt to unload responsibilities from the leaders themselves, or it may be done in a misguided attempt to help that person “grow”.

If responsibility is given without the requisite authority, the person “responsible” will be unable to carry out what needs to be done – and being responsible for something without the ability to accomplish it is frustrating to the point of being demoralizing.

Authority

Authority should belong to those who are capable of leading a team to execute and deliver value. Those same people should also be responsible for the success of that team.

Authority without responsibility is chaotic – when leaders can make changes and direct people’s actions without being responsible for the results, the results often won’t be in alignment with the best interest of the company. Authority and responsibility are almost always naturally paired together, and a leader acting with authority but no responsibility is usually abusing their authority.

A classic example is when a high-level leader tells you to do something, but they aren’t your boss (or anywhere in your chain of command). Not complying risks problems because of their authority, but doing what is asked can also cause trouble if the request isn’t in alignment with what you are supposed to be working on. That leader will rarely answer for any problems caused when you fulfill their request, simply because they aren’t responsible for it.

Real-world examples of misalignment

Developers like to talk about “code smells“, or patterns in a codebase that indicate that there might be bigger underlying problems. In that same way, there can be “organizational smells” that point to underlying problems with how responsibilities, capability, and authority are aligned.

Here are a few warning signs worth watching for (although there are many more):

An IT department strictly controls access to data, denying people the ability to access data that is needed for their jobs. An IT department is often responsible for security, access control, and operational impact surrounding data. Since they have authority over access to the data, and a responsibility to keep it secure, they exert a lot of control. However, the IT department generally isn’t responsible for the operational success of a company – and when operational departments can’t perform because they don’t have the data they need, IT can just do a handwavy claim of “The data has PII in it”, or “That will affect the operational database”. The operational database obviously can’t be impacted, and PII of course has to be protected, but these are the types of problems where well-defined best practices and solutions have been in place across the industry for decades. Because the IT department has authority over the data but no responsibility for the success of teams that rely on it, incentives are misaligned and effort isn’t made to make data properly available.
Software features are regularly rolled out but stakeholders and end-users aren’t aware of the new features. In a situation like this, any or all of the 3 attributes could be lacking in alignment. Perhaps nobody is responsible for distributing the information about new features. Or maybe the people who have the information don’t have the authority to communicate with stakeholders and publish release notes to those who need them. Perhaps it is a question of capability, and nobody is aware of the need to distribute this kind of information or nobody knows how to go about it.
New sales deals close, but the software isn’t ready for implementation when needed. This is often a case of a lack of capability. The individuals with the responsibility and authority to communicate about what needs to be incorporated into the software often don’t have the experience and knowledge to involve the right people at the right time. Or, the individuals with the capability to guide the software to be ready as needed can’t be bothered to participate in the sales process as they should. It is also possible that nobody has the responsibility to make sure this communication is happening, or that the sales and software teams are so siloed that they don’t even have the authority to talk to each other.
Released software misses the mark, and doesn’t provide the expected value. This is another example that could have any number of root causes or misalignments. It could be that the stakeholders don’t have the capability to convey what is needed. Or, the software team doesn’t know how to properly build something that addresses the problem. It could simply be that those with the capability to build software that delivers software don’t have the authority to make that happen. The most common root cause in this type of scenario is that nobody is responsible for ensuring that software is producing value. People are responsible for software sprints being completed, or for cards being moved across a board, or for lines of code being written, but nobody holds any responsibility for the actual value of the software.
Regularly hearing “I will have to check with somebody to get that done” when working with a project leader. When status meetings are nothing more than constantly hearing why things couldn’t get accomplished, there are problems with alignment. A lack of capability, responsibility, or authority could be at the core – but the only way execution goes well is when capable people are responsible for results, and they have the authority to get things done.

Building a culture of engagement and alignment

If you want your company to have an attitude of “We are all in this together; successful software development is a key part of our strategy”, here are some concrete steps that you can take to develop this culture. You might think these steps are obvious, and they apply to any organization that wants to function at a high level – whether they build software or not. and you would be right! Still, stepping back and analyzing whether you are doing everything possible to encourage engagement across different departments is an exercise worth performing periodically.

At all strategy and leadership meetings, ensure that members of your software development team are present and engaged.
Software development leaders should know as much about the sales pipeline and expected deals as your operations leadership. Leaders from both departments must execute on sales deals when they land, so the information they have should be similar.
Company leadership must understand what is on the software development roadmap, and everyone must actively contribute to its planning and direction. The software team must regularly communicate the contents of the roadmap, and the different departments must understand the roadmap and its impact on them.
The software team should understand the KPIs used by each department, and what challenges there are in achieving them.
Non-software departments must understand what software development methodologies are used at the company, and how software is released.
A system for receiving bug reports and feature requests must be in place. Stakeholders must be able to submit these features and bugs, track their resolution, and be involved in the conversation as solutions are discussed and implemented.

Every company has a culture – but building a specific, desired culture is difficult. Changing a bad culture to a good one is even more challenging, but possible with effort and a lot of persistence.

Bringing it all together

For companies that build software to sell, their software unquestionably is their business, so incentives are naturally aligned. Organizations that rely heavily on internally-developed software to support the parts of their business that generate revenue can find it challenging to align their software development with their organizational goals. The connection between software produced and dollars earned is usually less apparent, which is why producing software of value has these challenges.

Producing value with internally-developed software requires having everyone engaged in defining the goals of the company, knowing what is on the roadmap, and understanding how the roadmap supports those goals.

Leaders must have the proper capability, responsibility, and authority to deliver on building valuable software. This applies to everyone building software, but it applies equally to leadership from every department in the company.

Like most things worth having, achieving these goals is far from easy – but the results will make the value of the effort readily apparent.