Decision Point: Roles or Jobs

Article no. 1: “For 364 days out of the year most of the world lives and works in monarchies not democracies, because we don’t know the difference.”

Article no. 2: 

• Monarchy Thinking – Choosing one person to make the final decisions. 

• Democracy Thinking – A group of people collaborating to solve problems.

Article no. 3: Definitions of historical versions of democracy.

• Democracy 2.1 – British House of Commons under monarchy leadership

• Democracy 2.5 – US Constitutional Democracy w/ Checks & Balances and career leadership

• Democracy 2.9 – Haudenosaunee (Iroquois) Democracy w/ Checks & Balances

The first five Decision Points of democracy or monarchy:

1. Listen or Win

2. Prioritize or Plan

3. Wrong or Right

4. Multiple or Single

5. Roles or Jobs

Decision Points: Democracy or Monarchy Thinking

The ideas of monarchy thinking do have their place, and it’s here at decision point 5. We do need leaders. It is important to know how to form coalitions, build a following, and make allies. We do need to stick to plans. Sometimes we are right, and other people won’t be able to see it until the work is done because it is so different from the norm.

The big historical learning was to have democracy thinking as the higher authority, and monarchy thinking as subject to checks and balances of democracy, instead of the other way around. 

Giving Monarchy Its Due

The lesson that humans learned under Monarchy is that when there are too many “leaders”, even the best plans can come to a screeching halt. I still remember the first time I had a “failed” project. I had successfully completed a project for a military client of which I was very proud. It was one of the fastest projects the client had seen, with high quality and high user satisfaction. So they doubled my budget, added a team of requirements writers, a quality manager, and a project manager.

I never had team members who only wrote requirements before, and I had never had a project manager. I later learned that most projects in the world are run this way, but it was new for me. We had always been a team who talked directly with the customers, documented our own work, and made decisions as a group.

Is the phrase “too many cooks in the kitchen” a world-wide phrase? The Project Manager owned the personnel decisions, the Quality Manager the quality process, the Requirements Manager communication with the client, and I owned technology as Engineering Manager. To my unfolding horror, the project manager also brought with him a chain of command, claimed the right to make all final decisions, blocked us from talking to customers, and fired some of my best workers. 

In the end, we took twice as long, were way over budget, and the client was not happy. I’ll also admit that it was a blow to my ego. I spent years trying to understand how to bring back the “glory” of my earlier projects, but this failure did help me understand the goal of “ideal monarchy”. It is extremely hard to get any project to completion when your peers are constantly undermining your decisions, reversing course, and blocking your ability to get things done. 

Democracy Thinking versus Monarchy Thinking

In previous articles I went deeper into monarchy thinking’s use of the hierarchy to keep everyone focused, and resolve disputes. Its tragic flaw, however, is that hierarchical decision making solves the problem of disunity through blocking collaboration. 

Its tragic flaw, however, is that hierarchical decision making solves the problem of disunity through blocking collaboration. 

One thing I do know from the two projects above was that in the successful project, when we had a problem, we addressed and adjusted requirements, engineering, quality, and process at the same time. In the second project they were addressed separately. A problem in requirements was solved by requirements but created a problem for engineering, which was solved by engineering in a way that created a problem for quality, which was solved by quality in a way that created a change in process.

To say that another way, in project two we solved our problems one after another. The requirements problem took a week to solve, but it caused the engineering problem. That took a week to solve, but it caused the quality problem. The quality problem took a week to solve but caused the process problem which then took another week to solve. A total of 4 problems and 4 weeks. In project one we took the one problem, looked at it simultaneously from 4 perspectives, and solved the combined problem in one week, in a quarter of the time. This is another way democracy gets to be 2x, then 4x, then 8x more productive.

So here is my advice at decision point 5: It is way better to have advocates for the various roles in a project, rather than having deciders for each. This shift also repositions the “monarch” leader as mentor and facilitator between the advocates instead of serving as the final “decider”. But before I get there, I should define what I mean by “advocate”. 

Jobs versus Roles

There is another unrecognized convention of monarchy thinking that blocks this transition from decider to advocate: jobs. When we think of the multiple options from decision point 4 as experiments, the best leader to run an experiment is the one who knows that option well. But when we run multiple options in parallel, it makes less sense for the same person to lead all experiments.

This exposes the disconnect of a “job”. The idea that we should hire one person to execute the same role for all experiments is another leftover from monarchy thinking. Jobs evolved from delegates, where keeping trustworthy allies by your side solidified the power structure.

Jobs evolved from delegates, where keeping trustworthy allies by your side solidified the power structure.

I was introduced to an alternate approach early in my career by a recruiting mentor. Unfortunately, I cannot remember her name, but she had a technique called “Job Boxes”. To this day it is still one of the most effective ways I have found to negotiate disputes between team members. I have also found it a perfect alternative to “jobs” within democracy thinking, so I changed the name from “Job Boxes” to “Role Boxes”.

Technique: Role Boxes

To prepare for this technique we literally draw boxes. Above each box we write the name of a role. We then subdivide each box into three subareas. The first area is “Responsible”. The other two subareas are “Approval” and “Advice”.

Role Boxes

Round one starts by making a list of known tasks. Each task is then placed into a box. The unbreakable rule, however, is that we can only place a task in one Role Box. If there is debate, we have to figure out which role is ultimately responsible. Roles can collaborate, but if the task is in a Role Box, it is the responsibility of that role to make sure that the task gets done correctly.

Round two is about autonomy. Some tasks are so impactful on other roles that those roles must agree with our decision. These tasks are placed in the “Approval” subarea. Other tasks may affect other roles but we only need to alert that role and consult with them before making our decision. These tasks are placed in the “Advice” subarea. All other tasks that don’t affect other roles stay in the “Responsible” subarea.

Role Boxes with Consultation

Round three then customizes the Role Box for a specific employee. If the employee is new to a role, we might move tasks out of their box until they have learned that skill. Alternatively, we might move a task to the “Advice” or “Approval” subareas so they are required to get input from a mentor. It provides clarity of what is or is not within the decision authority of the new employee, as well as what skills they are expected to acquire. (It is also a great way to map out new career paths with limited responsibility under mentorship.)

Role Boxes give us the freedom to assign different people as advocates for different roles across multiple experiments. It also makes roles aware of how their actions affect each other, before conflicts occur. This provides the security and flexibility necessary to allow employees to develop new skills, change career paths, or get closer to utilizing 100% of their existing skills with the least disruption.

From Deciders to Mentors

With a more-flexible role structure, leaders now have multiple facilitation tools for cultivating both collaboration and unity based on the 5 decision points:

1. Listen: If anyone believes that new information has been discovered, they can bring it to the facilitator’s awareness. If it is within the Role Box of the person, they are authorized to act on it. If it is outside their Role Box, the facilitator can identify the appropriate role and get the new information prioritized.

2. Prioritize: If anyone believes that someone else is violating the list of prioritized problems, people can be reminded of the agreed upon order, or a new debate can be scheduled if reprioritization can be justified. If the dispute is a matter of problem order and not a matter of role responsibilities, usually the dispute can be handled by a vote.

3. Wrong: If the lagging problem metrics or the leading solution metrics are moving in the wrong direction, the metrics themselves alert the team as the project unfolds. If the problems are outside the team, the experiment can be submitted to a review board for further guidance.

4. Multiple: If anyone has a new idea, depending on the severity of the proposed change, the current experiment can be prematurely halted, or the new idea can be scheduled for future exploration.

5. Role: If the choices made by one role are causing problems for another role, the Role Boxes help make sure that the people who understand the task have appropriate authority over how to complete that task.

This is how I use the decision points to act as checks and balances and remove the need for an all-powerful decider. The mentor facilitator mainly has to remind people of the rules of the experiment, the problems to be solved, and the definitions of the role boxes in order to resolve the vast majority of disputes. The remaining decisions can be resolved by voting, either by the team itself, or by a skilled review board. The result is a fairer outcome which is more widely accepted. And if there is any leftover discontentment, there will be a chance to change roles in a short period of time when an experiment enters its next cycle.

What’s Next

If I have not yet made it obvious, let me say now that democracies are not always auto-magically good. Democracies can also make bad choices, fail, and be woefully inefficient.

Democracies are not always auto-magically good. Democracies can also make bad choices, fail, and be woefully inefficient.

My intent in this series is to capture the decision points through which democracy thinking can be used in both formal Democracies and Monarchies to self-correct by giving equal consideration to multiple perspectives. Leveraging as many of these decision points as possible, I am able to recreate environments of guaranteed success, regardless of the size of the project, industry, skill levels, and culture.

Our next – and final – decision point is “Reality or Opponents”. 

If you like where this is going or you're also fascinated with how to build a better future, subscribe, and please share this with others who you think should join the discussion.