How fun is it to work in an environment where you constantly try to do your job, but too often encounter situations where someone else in the organisation overrules your decisions? Most of us have encountered these situations now and then and we all know how demotivating a single experience like this can be. A long series of similar experiences can even be devastating to your effectiveness and feeling of invincibility at work. It is an established fact that an important part of feeling motivated is your level of autonomy to solve your problems and thus enabling you to reach business goals. We want to be proud of what we do and without the authority to act as we see fit we end up in an environment that gradually breaks your self-esteem down. If you don’t have the authority, someone must think that you are not capable of performing these decisions.
In the following description of a workshop I have tried to solve one of the firsts steps towards autonomy, i.e. knowing what you have authority to decide upon and define actions to improve your ownership of decisions step by step in areas where it hurts the most. It is not designed for finding all improvements and change them all at once, instead try to find the most hurtful problem and solve that, then redo the workshop later when time allows and pain is too high.
The first step of the exercise is to define important organisational stakeholders. Start with a prepared box-chart showing the organisational levels.
Figure 1. Organizational view, hierarchy.
With this overall description of the hierarchy at the organization under investigation it is time to start defining roles that have an impact for your teams. You might have a central QA department, head architect, subsystem architect, managers, DevOps, Infrastructure architects, DBAs, CIO, CEO, … Don’t overdo this phase, instead add roles later on if there is a certain decision that requires ok from a certain role you forgot to add in this phase of the workshop. When you are done the view could be something like this.
Figure 2. Including your defined roles important to you in the organization.
I personally like this view since it really reflects the complexity that you have chosen for your organization. And I want to make this clear , it is a choice and not just a mandatory situation you were forced into. If you don’t like it, step up to the responsibility to your own believes and change it.
Defining key decisions that matter to you
What is power? Jurgen Appelo defines 7 levels of authority in his book Management 3.0. You could go deep and define what level you are talking about in this workshop, but I usually just keep it to the level when a team feel empowered to take a decision themselves we are fine. Usually this means informing a certain role or instance in the organization, but that the team is not dependent on their approval.
When you now together define different decisions or responsibility areas make sure you spend just enough time to cover the most painful or important areas. I recommend doing this by splitting up your team in groups three-by-threes and then brainstorm areas and just quickly type them on a sticker. Do this for 10 minutes or until the members of the workshop feels that the most critical items are defined enough. Try to keep a note on what authority you are defining and also preferably what problems you currently see. E.g.
- Heading: Approval to release software.
- Reasoning: The team loses motivation and speed when waiting for formal release approval from CIO. Yeah it’s a silly example, but hey it could happen!
Placing an item in an area of responsibility
Each team should now place their notes to a certain role or organizational level using the rule definition above. This would lead us to place the note on the role where the decision can be taken without any other approval, however some other roles might need to be informed about the decision. Each team place note by note where they think it fits and explain why they chose that place. At this point place the notes where the decision currently is thought to be taken note where you would like it to be.
When doing this exercise it is often very common to realize that ownership for many decisions are unclear. When uncertain move the item to the higher end of the hierarchy and possibly note that it is unclear where authority currently is. Keep in mind that it is a good idea to redo this workshop continuously over time as often as you see fit.
For each note being placed, try to continuously place them in groups or just skip redundant notes. When having a larger group of people there will be much more redundant notes stating the same type of decision. Similar decision can just be grouped.
Figure 3. The look of the board after placing notes.
Note; already now you have reached a part of the goal, awareness of your boundaries. Much less frustration occurs when you know your level of authority. You can choose to end the workshop here and leave, still with added value to your team(s). A greater value comes with next phase which I highly recommend.
Defining the wanted position — Change definition
Even with limited time there are usually much more actionable items than you have the time or energy to act on at the same time. Also, finishing one improvement is for obvious reasons better than starting many that never finish.
Select the key pain points where the motivation is high to finish a change. Never estimate how hard things are to change, just make sure there is a strong will to adjust. There are many methods for voting or selecting from a bunch of alternatives. Use freely among any of those methods. A simple solution is to give each member in the workshop three votes to distribute freely among the items or group of items on the board. Select the items with top three number of votes.
Now you have three areas or items that you would like to change. E.g. a delivery decision might be on central CIO and you wish to move this authority to the team. Illustrate this simply by drawing an arrow from the group of notes or single item to the wanted role or organizational position, see figure below. Since this workshop is about autonomy and how to move into more autonomous solutions and by this improve motivation and performance the arrows should preferably point inwards towards the team or individual.
Figure 4. Moving power is as easy as drawing an arrow.
Some changes can result in several levels of authority moves. I.e. from CEO to team through entire org. This might require breakdown and start with actions to move the decision closer to team, even this empowers the team since the team will most likely have an easier interface to a closer role or entity in the organization and more power to influence the decisions.
Moving an authority for a decision will require some action and depending on numbers of participants on the workshop you can choose how to proceed. With a smaller set of people you can just have a broad discussion with all involved to define these actions. Simple checklist to cover when defining actions:
- Define the definition of done for the change. When are we done? What has then happened? How do we know we are done?
- Define what actors there are for a certain change.
- Define what change you expect from each actor.
- Define what final steps you need to do to make the change official and done.
- Define who drives what action!
So we are all fine. We have defined the change we wish to see, we have defined actions to reach them and who should drive each action.
Some adjustments suggested as an outcome of this workshop might be painful for people in the organization. Some roles are all about taking decisions for others and by moving these decisions inwards to the teams these persons situation at work might be heavily impacted. This should not stop us from improving, but it is good to keep in mind when expressing the wanted changes.
It doesn’t take a genius to realize that a complex chart with many roles and organizational level is hard to understand and slow in making decisions. In an age when scaling agile is a key word in your cv, roles pop-up faster than mushrooms a rainy summer. Be aware what organizations you build.
Usually a complex picture also leads to less clarity on who actually needs to take a decision and how to get the approvals you need to deliver the business values you are trying to accomplish. How motivating is this? It can be well spent time just to draw the chart with roles and levels which really visualizes your organizational dependencies and will in many cases generate aha moments.
Looking just at the team level it is clear that teams with many defined strict roles, such as PO, Tech leads, QA, DevOps within a single team, are less dynamic and slower. So much for team dynamics. Too many roles leads to a rigid, slow and unmotivated team in the long run, but that is another topic that interest me a lot. Self-organizing teams…
Email me when Agile leadership publishes stories