Most managers want their team members to do more on their own, to be more proactive when it comes to making decisions and taking action, rather than always waiting for direction. If you're a manager seeking such results, you can use the "Tree Decision Rights" model, a simple tool based on the four parts of a growing tree.
There are two benefits to using a simple decision rights model. One is to connect people with the power they have to be able to do everything they should be able to do within their roles. The second is to clarify for everyone, "who is responsible for what", or who has authority to make what form of decisions.
Another decision rights model called RACI, stands for the four core roles in a process-based model, Responsible, Accountable, Consulted and Informed. When dealing with decision rights around processes, the RACI framework is very useful. When talking about decision rights around people, however, something simpler that takes a look at the impact of the decision, and the potential to revise the decision, gives us a more useful framework.
The Decision 'Type' Framework
One metaphor for this framework is to think of a tree as having a set of roots that anchor it, a trunk that supports it, branches that are ancillary structures, and leaves on those branches. So we have roots, trunk, branches and leaves.
In terms of impact, if a tree loses its leaves, that's generally a minor impact. So what kinds of decisions or choices might you equate to the leaves on a tree, in that if someone makes a decision that is either wrong or not optimal, the impact is relatively minor or neutral?
A tree can frequently lose many branches with relatively minor impact. There is the trunk, which could arguably include major branches. If a major branch was to split or the trunk were to split, that could be catastrophic for the health of the tree. Finally, there are the roots, which are the fundamental anchor for the tree itself. Anything that compromises the integrity of the roots results in the death of the tree.
In terms of practical application, first look at the kinds of roles and responsibilities that your people have. Look at your security lead, your applications lead, your infrastructure lead and so on.
Within each one of those domains, there are going to be types of decisions that are foundational, meaning that they are roots where you cannot tolerate an error. And then there are trunk and major branch-type decisions where you might be able to tolerate one or two errors, but the impact would be significant and take time from which to recover.
Then there are decisions that relate to branches, where you can give people much more latitude. And then there are decisions that are like leaves, which you really don't even need to know about.
Decisions that are at the branch level, you probably want to know about, but you don't need to approve. Trunk decisions, you need to know about and approve, but you might not need a lot of time to deliberate or address. Decisions on the root level are often the decisions you need to make yourself, or in which you need to be deeply involved in deliberation.
The Impact of Different 'Levels' of Decisions
This is a simple way to look at the kinds of decisions that each of your folks has an opportunity to make, based upon the level of impact of the decision. The other consideration is the ease with which such decisions can be revised, or even reversed.
Decisions that are at the level of leaves are generally quite revisable, because their impact is relatively minor. Branches, where you want to know about them but you don't need to approve them, typically are also revisable or reversible.
Examples would be a program design decision or a functional position taken in an internal meeting. Most decisions like these are made internally working with peers. If you were to find out about them within a couple of days, and if you had any issue or concerns about such a decision, it wouldn't be difficult to reconvene the group involved and to re-explore and maybe even reverse the decision.
Contrast that with when your folks are working outside of the IT organization, perhaps with senior people in a business unit. Here, if you learn of a decision a several days later that you are concerned about, reversing that would be more difficult or challenging based upon the strength of the relationship, or because of any follow up actions that the business unit might have already taken.
Looking at examples like these, we could say that internal decisions, unless they commit significant resources irreversibly, would be branch-level decisions. Internal decisions that commit significant resources that are not reversible, say a vendor contract, would be trunk-level decisions.
Decisions or positions taken outside of the organization with other key stakeholders would also be trunk level. And long-term contracts, major purchases, commitments to strategy, would be examples of root-type decisions that you would want to reserve for yourself.
Determing a Decision Approval, Notification Policy
When it comes to branch-level decisions, though you don't need to approve, you do need to know about them at the time that they are made, and your staff needs ensure that you know about them. This is a critical follow up point.
Emails from staff about branch-level decisions may get lost in piles of other emails and maybe not seen by your manager in a timely manner. Therefore, it is essential to follow up by sending another email for confirmation that the first was seen, or marking the initial email as a priority, or swinging by your manager's office to let them know you sent them a detailed email regarding a recent decision that you'd like them to review in case there are any questions or concerns so they can be addressed as soon as possible and before reversing it could be a real issue.
Once you decide to apply a model like this, the next step is to engage your staff in interpreting it and customizing it to their environment. That might start with asking each of your direct reports to define what they believe are the four different levels of decisions that they make, including examples. You collectively begin to see what the model really looks like, and can collaborate to make changes or edits from there.
That gives you a starting framework within which to operate. Assume that working this through and making it effective is an iterative process, and that people will interpret things differently and will make some mistakes.
For example, one of your people makes a decision, and they assume it's a leaf decision and they don't inform you. You find out about it a few days later, and say "Hmmm, I really would have liked to have known about this." You and he can sit down and he might say "Well, here I thought it was a leaf decision because...". You could then say "Well, in this particular case, even though I didn't need to approve it, this is the kind of thing I would like to know about fairly quickly," and you can discuss the reasons why. With this framework and process, you learn from each other, and you align yourselves around what these decisions rights actually mean.
This can also become a communications framework for your staff meetings. It's a way for your team members to decide what information should be shared in these meetings, and in which issues or decisions the rest of the team needs to be engaged.
Decisions that you need to make collectively might be trunk decisions. Decisions that you don't need to make collectively but everyone needs to be aware of might be branch decisions. And then leaf decisions wouldn't come up in these meetings at all, as they are day to day operational decisions that would normally stay within each department.
Using IT Operations as an illustration: Standards tend to be either root or trunk decisions, in that you either need to make them, or you need to approve them. All of your directs need to be involved in the decision-making process, because setting standards impacts everyone on a fundamental level.
Whereas product selection, as long as product selection is based upon those standards, might be considered as a branch decision. Everyone needs to know about it but they don't necessarily need to all be involved in the approval process or the decision, unless it turns out to be a tool that is going to be used across all departments.
Using IT Applications Development as an illustration: If you're buying tools for maintenance and development of source code, you probably don't need the approval of colleagues in operations. If, on the other hand, you're selecting a tool that's going to be used for performance monitoring, and want every function to use the same tool for performance monitoring, then that probably looks more like a trunk decision where everyone needs to approve.
Most of the above discussion and examples have been aimed at the top levels of the IT organization. However this same model readily cascades down to all levels of the organization. Team leaders at any level can identify their own Root, Trunk, Branch and Leaf types of decisions. They can then work with their team members to agree on who owns which decision rights, to empower them to take on more decision-making responsibly.
Bob Kantor is an IT management coach and consultant, specializing in improving IT leadership effectiveness. He welcomes your comments and suggestions. Reach him at KantorConsultingGroup.com.
Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Read more about careers in CIO's Careers Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.