Everybody's priorities

Outcomes-orientation

Outcomes-orientation

What's this about?

Priorities. We all have them. But are they all aligned? In this lesson, we'll learn what to look for when asking individual team memebers about their roles and current priorities.

Lesson outline

• Conceptual: Setting the priorities (20m, solo)
• Everybody in the room (30m, solo)
• Sharing experience (30m, small group)
• Roleplay and discuss in community (1h, group)

It can be difficult to determine priorities in a team setting, but it’s important that all team members share the same sense of what’s important to the project. One of the top priorities in the outcomes orientation primary indicator is the roadmap, because building alignment and a shared vision helps a team set their priorities and next steps. While looking at a team’s roadmap can give you the big picture vision, asking a team members about their roles, priorities, and how they stay on track can give you more insight into their day-to-day work. In this lesson, we’ll take a bit of a deeper dive into what it means for a team to speak to their priorities and be aligned on them.

As always, remember to make note of questions that you have about the material as you go through this lesson.

Conceptual: Setting the priorities (20m, solo)

There’s a lot of different ways for a team to set priorities. If you start asking questions about how a team sets their priorities, you may hear a lot of terms and methods. To avoid going into depth about all of the different techniques used to set a team’s priorities, let’s take a look at a very simple method:

In this video, Angie Li shows a super simple sorting technique that works for her individually, but is also robust enough to use as a good starting point for a team. A product manager could use a technique like this with in a meeting with stakeholders to decide on the next feature or step to prioritize. No matter what technique is used, a team needs to set priorities in a way that gets every team member on board – whether that’s the people actually writing the code, the IT people, or the product owner or top-level administrator.

When you speak to team members, ask how they set their priorities. Then listen less to the method they use and more to who they mention is in the room and who you think may be missing.

Consider one of your state’s projects and answer the following question in your notebook:

1. How does the team set their priorities?
2. Does the team set their priorities based on consideration of user outcomes? What indicators of that are there? If you don’t think they set them based on users, what factors are in competition with that goal? What priorities seem more pressing to them?
3. Who was in the room when they made these priorities? How do they make sure everyone on the team knows what they are?

Everybody in the room (30m, solo)

To gain a bit more insight into the prioritization process, we’ll take a look at the following video. It’s a bit of a plug for this company’s product managment tool so it’s a little business-y. But the speaker gives a good overview of the steps toward a good product prioritization process. As you watch the video, think about who would be involved in each of these steps.

Below are the steps outlined in the video:

1. Define strategic value and cost drivers.
2. Rate your projects, initiatives, or features.
3. Discuss your priorities and decide on next steps.
4. Communicate your priorities.

Since priorities can change quickly, “real-time roadmapping” is a concept from the video that shows how a good process is flexible and adaptable, as well as inclusive of team members at many levels in the organization.

All of these steps require a person who will drive them and stakeholders to help define the priorities. The last step, communicate your priorities, needs the largest amount of people on the team to be involved – everyone has to be able to know what the priorities are so they can work effectively. That’s where shared documentation comes in.

Questions to answer in your notebook about your state’s project:

1. Who’s involved in setting the priorities on your project? Is it a product manager? Product owner? The whole team? List them.
2. What’s their official role on the project?
3. How does this person (or persons) communicate the set priorities to the whole team?
4. How often do they check with team members to make sure everyone knows what the priorities are?
5. How does the team pivot or change priorities? How are changes in priorities communicated?

Everybody on the same page

Communicating team priorities can happen in team meetings or check-ins, especially when things pivot quickly. But ideally, meetings should be paired with shared documentation that is kept updated with the latest issues. When thinking about your team, think about whether they use some sort of shared document to keep track of priorities, whether it’s a speadsheet, github, or a kanban board system like Trello. Just like there are different methods for settting priorities, there are also different methods for keeping track of them. Look for something that everyone at all levels on the team can see and agree upon. This document shouldn’t only be visible to senior leadership. It’s important that people actually doing the work can reference it too.

Some things you might ponder here (again, write down answers for your project):

• Does the team use shared documentation? Who can access it?
• Is the shared document kept current? Or does the team rely on other means of communication to set priorities?
• Can the team map these priorities back to the roadmap? Does everyone on the team understand the rationale behind them?
• Is the team aligned on these priorities from the enterprise level to the project level? If not, what’s the reason for the misalignment?

As you are thinking through all of these, think through some direct questions you might ask of these teams to get at things you may not be able to observe directly. We’ll use these later in the roleplay we’ll do in our group meeting.

Sharing experience (30m, small group)

Meet with your small group and connect what you learned in this lesson to situations you’ve seen with your state projects. Consult the notes you took throughout the lesson and try to link them to a story that you can tell about a particular project. It’s probably useful to do some brainstorming on this before you meet with your small group to trade stories.

When you get together with your small group:

1. Share your stories with each other.
2. Figure out which ones are the best candidates for a case study or use case that would be helpful to share with other state officers.
3. As a group, choose useful stories and write notes on how they link up with the concepts shared.
   • Include in your notes:
     • When did this story take place?
     • What were the events or background leading up to this story?
     • How did this story demonstrate an ideal or non-ideal situation?
     • What specific principles from the lesson does this story illustrate?
     • If the story shows an ideal, what were the conditions that made it work? How did it fit with the principles shared in the lesson?
     • If the story shows a non-ideal, what could have changed to make it better?
4. Share these notes with the larger group when you meet.
5. After discussion with the larger group, document these stories and their connections to the lesson to help other state officers understand how this lesson’s concepts apply to their work.

Roleplay and discuss in community (1h, group)

You’ve thought about your state projects and its team members’ sense of their priorities. You’ve talked about it with your small group and traded stories. Now it’s time to roleplay asking your team questions about their current priorities, roles, and alignment. You’ll do this in the larger group discussion.

Below are a few questions to get you started, but you should come up with some on your own. It’s best to do this roleplay in pairs, so pair with someone who isn’t in your small group. One person should ask the questions and the other should answer from the perspective of their chosen state project. Take turns having different pairs roleplay the questioning in front of the large group, then take some time at the end to discuss how the question-asking went and how you might use some of the questions with your state.

1. How do you decide on team priorities?
2. What’s the most important thing you’re working on right now?
3. What’s the next big thing the team will work on after this?
4. Can you help me understand how your work fits into the bigger picture?
5. How do you keep track of what you should be working on as individuals and as a team?
6. How do other departments help you with your work and help you accomplish these priorities?
7. Do other departments (like IT, procurement, etc) share the same priorities?
8. If not, what priorities are those departments tracking toward?

In the guides

This lesson is the beginning of a journey. If you're interested in learning more, there's material in the 18F Derisking Guide that you'll want to check out.

From the Federal Field Guide:

• Building with loosely coupled parts
• Leadership empowering teams
• Path to production

From the State Software Budgeting Handbook:

• Demos, not memos
• Hire in-house

Wrapup (5m, solo)

Take a few minutes to share your reflections on this lesson.