Attention!

The content on this site is a materials pilot. It represents neither changes to existing policy nor pending new policies. THIS IS NOT OFFICIAL GUIDANCE.

Tech and product management


State capacity

Ask the product and technical leads what their role is and what other responsibilities they have.

Look at the APD staffing plan vs. current staffing.

  • Bad: The state depends entirely on a vendor for vision and strategy.
  • Meh: State leads are identified but have limited time to lead the strategy and take direction from the vendor.
  • Good: State staff with IT experience have the bandwidth to lead the technical strategy with feedback from vendors.

What's this about?

Software projects are complex, creative projects that involve the orchestration of complex systems of hardware and software. The objective of this module is to lay foundations regarding the kinds of skills and capacities states should have for managing these projects. This will help you, as an SO, better support and evaluate the projects you are responsible for.

Lesson outline

Reflection: Managing projects (20m, solo)

You’ve been managing projects in many contexts. Perhaps you tackle DIY projects, big or small, at home. Maybe you wrangle food for your household, doing shopping and food prep. At work, you’re always wrangling some project or other, to say nothing of the work you do with states.

Make notes — bullets, paragraphs, whatever works for you — about all the moving pieces you need to keep track of when you’re managing a project. Perhaps this looks different for different kinds of projects, so feel free to see how the list does (or does not) change if you consider a few different projects you’ve worked on.

After you identify the things you keep track of, make a second list. This second list should be the habits and skills you need to succeed in managing projects.

Reading: Tech and project leads (30m, solo)

When it comes to software projects, there are two roles you’re likely to see in management positions: the tech lead and product manager, or PM. An important part of understanding project health is going to involve understanding these people, how they work with their teams, and how well they do that. To get started, lets start with a short video or two to set some context:

Then for some depth, we’ll do some reading.

Writing: Who’s on your projects? (10m, solo)

While this content is fresh, pick at least two people you work with on your projects who you think fit these roles. In your notebook, identify the qualities you observe in them and their work that you think exemplifies good (technical, product) management. Then make note of the things that are sources of concern for you, given what you’ve read.

Jot down a few bullets for each. We’re not diving deep here — the goal is to reflect some of the learning you’ve just done back into your own project work.

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.

Discussion: Team function (1h, group)

With a colleague, find a time to have some conversation about your projects. For this conversation, roughly follow the script below. You might work your way through each set of questions, building up a shared understanding of each-other’s projects.

  1. How would you describe the “feeling” of communications you have with your teams?

    • Stiff? Formal?
    • Informal? Plain language?

  2. Who do you talk with on your teams?

    • How many people on the teams do you know?
    • Do you get to talk with entire teams (state, vendor) or do you only get to talk to leadership?

  3. What kind of relationship do you think the state and vendor teams have?

    • With each other?
    • With the State CTO?

  4. When you talk to people in technical leadership roles:

    • Do they use plain language to describe their work?
    • Do you think they are being honest or trying to hide difficulty with complexity?
    • Do they answer simple questions in simple ways?

  5. When you talk to people in product management roles:

    • Is everything always going well?
    • Do they seem to value the people they work with?
    • Do they seem to have a broad understanding (technical and user-centered) about the product?

By the end of an hour, you should have a shared understanding of each other’s projects. Most importantly, you want to compare and contrast the teams you have observed working on your projects, both on the state side and vendor side.

Try and leave a few minutes to go back through, with your partner, and “flag” things as red, yellow, or green. Given your knowledge so far, identify things you think are good (“green light”), things that might be cause for concern or to pay more attention to (“yellow light”), and those aspects of your teams that you think are going to be a space of focus and potential intervention in the future (“red light”). We’ll come back to those “red light” concerns in future modules.

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:

From the State Software Budgeting Handbook:

Wrapup (5m, solo)

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