The 4 Principles Of Effective Teams
The following is an edited excerpt from the book, Risk Up Front, by Adam Josephs and Brad Rubenstein.
Let’s outline about the core principles underlying Risk Up Front (RUF)—our methodology to accelerate product development and organizational change—and dive into how these concepts can upgrade your team’s behavior, results, and narrative.
1. Accountability
Let’s start by making the connection between accountability and results. It should be obvious it’s more likely something will get done if someone has agreed to get it done.
Yet, it’s surprising how often we hear teams say, “Someone really needs to do X,” and then they let it drop. Team members get shy about forcing the team to make sure there is a name attached to any activity that the project wants to get done.
Assigning a task to a department is inadequate. Things change when teams root themselves in accountability as a core principle, in language and in practice.
Of course, all teams realize it takes more than just assigning people to do stuff. We hold a specific definition of accountability — singular ownership of a result. This requires that everything that needs to get done has an accountable owner, and every accountable owner is committed to doing what she said she will do.
Risk Up Front has a specific technique for establishing individual accountabilities on a project. By engaging each team member in generating her own individual accountabilities, the team will reduce the risk that responsibilities will be attached to people without their being aware of it (no more “I didn’t know that was my problem”). Observe that the process for generating and approving each member’s individual accountabilities is a practice, triggered by the start of the project, or when a team member joins. It’s a “just do it” ritual. It works when kept in integrity.
In RUF, we insist the assignment of owners be complete — no unowned action items. Before writing down the name of a team member as owning an action item, that individual must agree to take responsibility for it. Do not assign an item to a person who is not in the room. Only an individual can accept accountability, not a functional group. Assign accountability to people by name, not by their job titles. The process of asking for consent when assigning ownership and handling the resulting yes or no is an important part of any meeting.
Just because you are accountable for a result does not necessarily imply that you will do any of the work (although you might). You’re accountable for causing it. That means, for example, if you can’t do it, you’re on the hook to find someone who can. If you are on the hook to solve a problem, and that requires a meeting, you will cause the meeting to be scheduled where people come together to solve the problem.
Avoiding “Project Democracy”
We don’t want decisions on a project to be made by consensus. When we see this “project democracy,” we suspect the team is unwilling to hold individuals accountable or doesn’t trust individuals to make good decisions. This slows projects down and often makes them unworkable.
If the team doesn’t trust an accountable owner to make the right decision in their area of accountability — drawing on whatever expertise, research, stakeholder feedback, and team wisdom that the owner feels they need to gather to make the decision properly — then that owner is the wrong person for the job.
Of course, a project leader can set ground rules that constrain what decisions team members make. For example, the system architect on your team may be accountable for deciding on the system architecture, but that doesn’t mean the organization can’t require sign-off from a review committee before making their decision.
It’s critical to decouple the question of who should make the decision from the decision itself. Settle accountability early in the commitment phase so you’re not fighting over “Whose call is it?” and “What should the decision be?” in the heat of mid-project decision making.
2. Transparency
The moment an individual speaks up and says she will be accountable for a result, she has a problem.
How does she know what the result should be? What if the result she agrees to is not the result that’s needed? What if the result she agrees to isn’t the result the team asked for?
These misunderstandings are common and often fatal to the success of projects. To address this, RUF insists that teams get rigorous about noticing failures of transparency.
Transparent Measures
We need to be rigorous about our language in the project documents. For example, in the project statement, each of the customer measures of success must be necessary and sufficient for the success of the project. The fact that they are in the project statement means the team has made that decision. In addition, at the end of the project, the team must demonstrate those measures were achieved.
Consider the practice of the definition meeting. During that meeting, the team does a ritualized read-through of the items in the project statement. Team members are asked if the language expressing each item is clear enough that members really do agree on what that item means. By forcing these questions to be addressed during the commitment phase, the team is less likely to be blindsided by risks stemming from ambiguous language late in the project.
Conversations Disappear: Write Things Down
The most common improvement we see teams make in their behavior, in the name of transparency, is they write down their decisions on documents that are actively reviewed. Only then will teams notice and fix the descriptions of the results they need, wherever they are ambiguous and unclear. They’ll do so early in the project, while team members are making tradeoffs to arrive at commitment, rather than later during the delivery phase when the ambiguity resurfaces in the form of a disaster.
When teams first insist on this level of transparency, there is a lot of erasing in their meetings as they notice where they lack clarity and what they need to fix. But after a short time, team members become competent at describing their deliverables clearly from the start. In addition to reducing project risk, they find that recording high-quality, transparent action items goes much faster.
3. Integrity
While transparency obligates the team to make a reliable connection between what is meant with what is said, integrity insists the team draw the connection between what is said and what is done. In fact, reducing the amount of time wasted on confusion about what is done and what is not done is an important consequence of a rigorous commitment to integrity.
You Get What You Measure
“Knowing where you are” is critical to achieve a goal. It has been shown that starting to measure a given activity will often improve results.
It is lunchtime at a Risk Up Front workshop in the Netherlands. We let the thirty participants know the break will be an hour long and ask, “Will everyone be back in their seats by 1:30 p.m.?” Everyone nods. We then ask explicitly if anyone will not be back in one hour. No one raises their hand. Clearly, everyone is on board with the time and schedule.
At 1:31 p.m., we count the participants who are back in the room. There are twenty-one of the thirty participants ready to go, and we note this on the whiteboard: 21 delivered out of the 30 who committed. In the workshop, we spent considerable time discussing integrity, yet only 70 percent of those who committed to return did what they said they were going to do.
The participants weren’t happy that we were counting. It took time and discussion to become comfortable with the fact that when they said something would happen, we would account for whether it happened or not, transparently. Counting measured the integrity. At the end of the day, we asked if anyone was unable to be in their seats in the morning at 9:00 a.m., and at 9:00 a.m. the next day, we counted. Every seat was filled, and we recorded 100 percent integrity between what the group committed to be so and what was so.
We see this all the time. The simple act of transparently accounting for results improves results.
Apply Integrity to Commitments, Not People
People may race to the judgment, “Having integrity is good; not having integrity is bad.” In fact, you may be used to saying things like, “This person has integrity; that other one, not so much.” That isn’t RUF. For our purposes, integrity is not about an individual; it’s about specific instances of language and results. Was a commitment made, and was it kept?
RUF fully expects that the project documents, at the early stages of the commitment phase, will be full of statements that are placeholders, untested hypotheses, misunderstandings, and outright mistakes. This is normal. As you are reviewing and clarifying those statements, ask yourself if you will be able to test whether they are so. If your commitments are unclear or untestable, then the team will find itself arguing later about whether stuff is done or not.
4. Commitment
Upgrading a team’s conversations around commitment can improve the reliability of its projects. It causes teams to communicate and get into action on the things that stand in their way. Instead of simply saying “I’ll try” or “I’ll do my best”, they can confidently feel and assure that “It will be so!”
The Paradox of Commitment
A paradox has two sides that contradict each other. On the one side of the commitment paradox, we are asking you to use this upgraded definition of commitment: “It will be so!” On the other side, the simple reality is that you will not keep every commitment you make in your life.
We are advocating, even in the face of this paradox, that you use the upgraded definition of commitment.
We staunchly believe in this approach for two reasons. First, making high-quality commitments yields real results, even if some commitments are not met. Second, creating a culture of upgraded commitments leads to earlier risk identification. In practice, when teams take their commitments seriously, they will be more judicious in what they commit to and will be more communicative and proactive in identifying and mitigating risks.
When we ask team members to commit to deliver a result, they often say, “How can I possibly commit? There are surely things that might happen that I can’t handle. What if there’s an earthquake? What if I break my leg?” But consider you do this all the time.
The point is, when it really matters, you do make commitments. If something arises that gets in your way, you immediately respond to it with seriousness and the expectation that you’ll work to figure out the best way to respond. That’s how you want your team to behave.
Human beings make promises. Sometimes they keep their word; sometimes they break their word. That’s what humans do. But teams that make commitments with seriousness and rigor, even knowing the universe is cruel and sometimes they’ll fail, make them anyway knowing they’ll improve their results by doing so. This is a muscle you want your teams to develop.
Managing for Commitment
If you are a manager or project leader, and you need something to happen, be sure to identify an accountable owner on your team to cause it to happen. Then explicitly ask her for her commitment to get it done by a deadline. This is true for both big things and small things
Accountable owners may want to say yes and say it immediately. Don’t let them. Remind them you want the commitment to mean it will be handled, regardless of circumstances, and then ask questions like these:
Do we agree what “done” means? What can we do now to avoid arguing on the deadline date, whether it’s done or not? What would we be arguing about?
What might prevent the result from being delivered completely by the deadline?
Does the result depend on anything that’s not currently under your control?
Is there anyone you need to check with to confirm that it will be so?
Is there anything you need me to get out of your way for you to deliver the result by the deadline date?
Things to Remember
Use Risk Up Front language with precision. It allows your team to establish accountability, transparency, integrity, and commitment with rigor and consistency from the beginning.
There can be only one accountable owner for any given result or decision.
Transparency requires overcommunicating information and decisions on your projects.
You must be able to measure integrity for it to be useful.
When asking for commitment, if there is no room for “no,” then “yes” is meaningless.
To learn more about how to accelerate product development and organizational change, read Risk Up Front by Adam Josephs and Brad Rubenstein.