There should be a correct balance between authority, responsibility, and accountability. Learn how to strike this balance and potential pitfalls. Find out about the Railsware approach to the authority-responsibility-accountability concept.

Why can’t you delegate responsibility?

Think back to a situation when your business needed expert help, and you hired a consultant who seemed to be knowledgeable and up to the job. You expected them to take care of the problem, but in the end they just used up the budget, didn’t fix the problem, and placed responsibility on you on top of that.

Remember back to another time when you provided detailed requirements for your team. You were confident that everyone was on the same page,only to find out two months later that the implementation was a disaster. Your team on the other hand were convinced they did everything right.

These things happen because of an imbalance between three major aspects of management: authority, responsibility, and accountability.

To put it plainly, a good leader should always:

1) Delegate their work and

2) Stay responsible for the outcome

Let’s have a look at what this entails.

I’ll also explain why the joke “product managers have all the responsibility but none of the authority” is not technically correct, although we all know that feeling.

Explanation of the theory – authority, responsibility, and accountability in management

These are the three main components of all managed processes.

Authority means

• making decisions;
• telling people what has to be done;
• clearly defining the task that is assigned.

Responsibility means

• obligation to perform assigned tasks

Accountability means

• accepting responsibility, in relation to job completion;
• taking personal answerability for results.

These components are interrelated. Authority is the granting of power. Responsibility is the fulfilment of obligation, and accountability is answering for one’s work.

Authority can be delegated. Responsibility can be shared but cannot be delegated. Accountability can neither be shared or delegated. One has to answer for their work.

Delegating is handing off a part of something that you have. Once you delegate, you should no longer deal with that piece. Sharing is working together on something that you have. Once you share, you are still involved in that piece of work.

When you delegate the authority, you give it to another person to perform specific activities. This implicates managers in deciding which work they do themselves and which work they delegate to others (and explaining clearly what has to be done). The opposite of efficient delegation is micromanagement

An example of delegation would be a CFO who needs to make a bank transfer, for which they need a new bank account. The CFO delegates opening a bank account and empowers a member of their team to contact the bank, decide which type of account to open, sign the agreement, and pay the fee.

When you share responsibility, you share the workload with your teammates, or peers. You decide together how you share it. For example, the nominated employee has to look into 10 different offers provided by the bank, and see if they meet the appropriate criteria. They decide to look into the first 5 accounts, and get a colleague to the other 5 options.

Getting back to the joke that “product managers have all the responsibility but none of the authority”, this is not necessarily true. Unless you work in an imbalanced process, all managers have enough authority to get things done.

This perception arises because lately more processes are shifting to horizontal(or flat) organization, and authority is no longer “ordering someone to do something” but rather motivating and leading co-workers by sharing the same goals.

Practical examples – Authority, Responsibility and Accountability Dos and Don’ts

❌ Authority is not delegated

Delegating authority is harder than it seems. Responsible people have “who else but me?” thoughts and the desire to constantly check progress. But you can achieve the right outcomes without being the “hero” who does everything themselves or controls everyone. It’s also crucial to have
the right people on the team.

Inability to delegate authority comes in two categories:

👉 Not delegating the power to others

You’re the CEO of a company and you face high staff turnover. You hire the HR team to solve this problem.

Since having an HR team is new for the company, the risk is they can make things even worse, so you want to keep things under control by:

• checking the wording of their emails;
• interviewing every candidate they approve;
• having the final word in the staff performance review;
• directly managing the staff when you feel it’s necessary.

Thus you don’t give HR the authority they need, limit what they can do, and influence their decision-making process.

The staff turnover problem won’t be fixed because the process will not change under such circumstances. From your CEO’s point of view, hiring an HR dept turned out to be a wrong decision, because they didn’t fix the problem and they failed to fulfill their responsibilities.

In reality, they were not granted enough authority to fulfill their responsibilities. As for the team’s attitude, they would either feel guilty, not understand what was their fault, or won’t agree to be responsible for the outcome.

How to delegate authority

Instead of controlling the issues, communicate all the risks that you know to the HR team:

• poor wording in emails may damage the company’s reputation;
• the candidates may not find a common language with you personally;
• recent performance reviews were too subjective;
• certain people have peculiarities when working with them.

Agree with them how you mitigate those risks, and in which cases they should ask for your approval. Thus you’ll have all the risks covered, and the team will have enough authority to fulfill their responsibilities.

👉 Not clearly explaining what should be done

You are the head of the department. Customer orders are taking too long to complete. Your peers said that they did some process optimization, and it helped them to speed up the order completion.

So you ask your team to optimize the process too. The team agrees it is an excellent idea and they like it. But in a few weeks you still see no results. You explain again that the order completion time is a problem to fix, everyone agrees, but things are still not improving. You are disappointed and ask them what they tried to do. They tried several strategies such as staying later hours, filling out order forms in parallel, and asking more people to help them. These measures didn’t help, and you tell the team that they didn’t do well with the optimization task. The team is confused and disappointed.

The problem is that they didn’t know what to do, they didn’t have anyone to consult or support them, and they didn’t know what the expected result should look like. The team has limited information about how the process works, and only the head of the department has the big picture. And without having the big picture, it’s hard to deduce missing parts on your own. They couldn’t know that filing order forms in parallel wouldn’t help because each order has to be processed by the security team, and their throughput is limited.

Part of delegating authority is explaining what has to be done, and if this part is skipped, the whole process may fail.

How to explain what has to be done

• Be specific and illustrate what success should look like.
• Describe what the implications of the current problem are. You have a meeting where you mention that order processing time is a problem? Explain why: your competitors do it twice as fast, and you lose clients, or you noticed that it became twice as slow, and the revenue dropped.
• If you don’t have a detailed plan yourself, delegate that too. Once they have the results, work with them on the actionable items that can be implemented.
• Agree with the team to do the analysis: decide what to measure and how. Define the goal as something measurable: before optimization it was X, you aim for Y.
• Give them authority to contact other departments to get domain knowledge.

Et voilà! You are on the same page, the team knows what to do, and the expectations are set.

❌ Responsibility is delegated

You are a busy project manager. The client sends you a piece of documentation that is complex, contradictory and ambiguous, and asks to implement it.

Since you are busy with other things, you pass the documentation to your team without reading it and ask them to figure it out. They send you a 20-page report on the implementation plan, specifying how they understood the requirements and expectations. You read it very briefly, there are things that don’t seem okay, but you decide it’s no big deal. You return the report, commenting, “Okay, don’t screw this project up!” The team feels scared and does not tell you about any more unpleasant details they find.

As a result, the client is not satisfied with the outcome, they are furious, and you are the person to handle the situation. You can’t fix things quickly now because you need time to learn all the details, and the client knows that you were not involved deeply, so they no longer trust you. When you report the situation to your CEO, you explain the failure by the team’s incompetence, and you say they didn’t cope with the task. This spoils your relationship with the team because they feel betrayed.

In this example, the responsibility was delegated. You expected that the team would do everything on their own. But as the responsible one, you can’t step out of the picture. However, the responsibility can be shared, meaning if you are responsible, you should participate in doing things, but you shouldn’t do everything on your own.

How to stay responsible

• Given you are busy with other things, ask someone to sort the problem out and prepare a summary for you. If a 20 page report is too much, ask them to shorten it.
• Dedicate some time to studying it, listen to the summary carefully, and adjust the strategy they present if you feel something is not right.
• Ask for a short catch-up weekly, and approve the decisions explicitly.

If the client didn’t like the outcome anyway, you can quickly adjust the plan and deliver it because you have the necessary context, and you have a high-performing team because people feel protected and supported.

❌ The wrong person is held accountable.

You are the business owner, and you run an international excursion booking agency. When COVID-19 hits the world, you face new challenges because travel requirements start to change daily. You need to keep an eye on them, and you decide to launch a project that automates this for you, and potentially for millions of other users who face the same problem. You have a great idea, and you find a team to make it a reality. You are pretty busy with your main travel business, so you don’t dig into all the details – you trust the team, and you know they are qualified enough.

You catch up once in a while with someone from the team, and they bring you up to speed. You are not into the details and you don’t know which sources the team uses to get the latest updates. One day they mention that they’ll pull info from the EU official website, and your gut feeling tells you that it’s risky, but because you don’t know the low-level details, you let this feeling go. You constantly see how the team makes the decisions about which data source to use, they keep you in the loop, but you choose not to be part of this decision-making process because it requires more time and more involvement from you.

In the end, when the result is not what you expected, and the app doesn’t work correctly for half of the locations, you blame the team and hold them accountable for the outcome. Technically, you are in charge, but it looks like you are not part of this failure. You didn’t do anything wrong because, well, you didn’t do anything. The team is demotivated, and it takes forever to fix the consequences.

How to be accountable

• Talk about all the risks that you or the team notice. Assess these risks and either suggest changing the strategy or confirm that you are willing to take the risk.
• Take part in the decision-making. And although you are not aware of all the implementation’s low-level details, jump in if something doesn’t seem right, and use your network and expertise if specific knowledge is needed. Ask your lawyer if you can use the EU’s official data in your commercial app, and check with other business owners which data sources they used for similar problems.

In the end, if something is wrong with the project, you are not that surprised, – you know how to help because you understand the context, and the team is motivated because they know you support them. In this scenario, you are accountable for the outcome.

Railsware experience

Although the authority-responsibility-accountability are well-known terms, they are still a part of the management theory, and no one actively uses them in practice to organize the processes. For example, the manager won’t say, “I delegate you the authority to choose a new vendor,” or you won’t tell your co-worker, “I now share this responsibility with you.”In reality, things happen more naturally.

In hierarchical (or “vertical”) organizations, you know who’s in charge and who’s subordinate from the person’s position in the company (Junior, Middle, Senior, Team Lead, Manager, etc.) In horizontal organizations, this depends on the project, as there is no single person accountable for all the projects in a certain area (marketing, legal, devops, etc.), but accountability is instead assigned on a project base. It is common for one person to have authority in one project and responsibility in another. The teams agree on how they should organize their work.

Let’s take a look at how we manage work within the company, be it product development, HR and recruitment, finance, or operations.

RW RASCI

At Railsware, we use horizontal processes and an extended RASCI model: RAtSCIur. Let’s check what the roles are and how this ties together with the management theory.

The RASCI/RAtSCIur model and authority-responsibility-accountability theory map into each other. Not every role possesses the same managerial components.

Let’s run an example. People start giving feedback that the current issue tracker does not meet their needs anymore. And the solution is to move to another one that has all the required features.

• The Managing Director is the Approver. He will approve the decisions, and he’s accountable for the whole transition.
• The Product Manager is the Responsible. He drives the process and organizes the work to be done.
• The team is the lead engineer and QA who make the transition along with the Product Manager. They configure the automation and make sure the data is transferred correctly.
• Supportive are Project Manager and Engineer who help to make data consistent whenever they have time.
• Consulted is a Product Manager from another team who shares knowledge of how they set up the issue tracker.
• If No one else is another Product Manager who volunteered to lead the transition from the start if there were no other volunteers.
• Informed are all the team members plus people from other teams who are interested in project management strategies.
• Users are the team members.
• The occasional (rare) users are third-party freelancers who’ll be invited to the project from time to time.

As you can see, all the roles fill in naturally. The Approver, Responsible, and the team are usually defined explicitly at the stage when the problem has been confirmed and prioritized.

At Railsware, the roles are taken rather than assigned, meaning that people have a choice of which role they want to take and in which project. This self-organization is possible thanks to the holacratic methods that we use.

Holacracy

Holacracy is a type of flat organization where authority and decision- making is distributed through the
holarchy of self-organizing teams rather than being handled by the management hierarchy. The core structure is a role, which is not associated with a single person, and a person can have multiple roles in different projects at the same time.

The teams are aligned according to the operational needs, and they have enough authority to self-organize internally and define the roles. This is an ongoing process, and the roles are revised and updated regularly.

Both RAtSCIur and Holacracy create and support the systems with distributed authority, and thus the leaders do not have the burden of having to make every decision on their own. This also improves the quality and objectiveness of decisions made because more expertise is involved. And since each specialist is engaged in different projects and domains, they contribute with opinions based on the data from various business aspects, which improves the quality even more.

BRIDGeS 

BRIDGeS is a flexible ideation and decision-making framework designed by Railsware. When we run BRIDGeS sessions, we invite several knowledge-holders/stakeholders to come together and explore the solutions to a problem. Participants begin in the Problem Space by examining the Benefits, Risks, Issues, and Goals of a Subject, and end in the Solution Space, where solutions are formulated and screened.

Following the Solution Breakdown, participants enter the roadmap phase. This is where we integrate the components of RAtSCIur and define who will execute the solution. Roles are assigned to epics and tasks, which members of relevant teams will select after the BRIDGeS process. We find this approach helpful for clarifying authority, responsibility, and accountability in a variety of situations. 

See BRIDGeS in action on our article about decision-making frameworks for multi-context problems.

Conclusion

If this sounds like too much work, you are not far away from the truth. Building a process that properly balances authority, responsibility and accountability is hard, and so is staying in the loop and taking risks. But there is no silver bullet, and the problems are not solved properly by just handing them off. Hopefully, this article has helped to define the right type and amount of your engagement in the processes.