Getting great people on government contracts

Most contracts I’ve seen have a period of performance that starts the day after the award. That doesn’t give the winning vendor much time to assemble an excellent team. From a business standpoint, it’s not practical to have highly qualified (and expensive) people on the bench. Great people are also highly motivated and want to work on things that matter, not wait around.

So what happens? You get a bunch of folks who are sitting around because they’re not in high demand. This typically happens with larger vendors, who can afford the overhead to keep these folks on staff but not on billable projects. Instead of getting the right team, crafted for your particular project, you’re getting whomever is available.

But what if there were a delay of say, 6 to 8 weeks after the award? This allows the winning vendor time to source high-quality people from other projects or their hiring pipeline. I know it may sound risky to delay the procurement process even further. But it’s likely you’d waste even more time remediating technical debt created by inexperienced engineers. Or from building the wrong thing because you didn’t use thorough researchers. Allowing for a small delay gives time and flexibility to vendors, especially smaller ones, to build the right team for the project, not just a team.

Another option is a phased-in approach. Deploy a very small team of 1 or 2 people to conduct some initial discovery and user research. This sets the product direction for the full development team when they arrive. The first few weeks of a project are a ramp-up period anyway, so it makes sense to adjust the contract structure and payment to match. Roles like product manager, user researcher, or technical lead are important to have sooner, and more specialized roles can be added later.

Key Personnel clauses don’t ensure quality

Contracts begin with requests for proposals. These usually have a section called “Key Personnel”, where the vendor must document who is filling the important roles on the project. The vendor may even be asked to submit resumes of the key personnel. The goal is to ensure both the quality of the proposed team and that they aren’t swapped-out later for less qualified staff. But does this really work? Even in the best scenarios with the best of intentions, change happens and people move on. In the worst-case scenario, the vendor swaps out ‘A’ players for ‘C’ or ‘D’ players after a few months, so they can be put on newer tasks. In my experience, contracts usually don’t prevent this.

What then? The contract doesn’t help much at this point, because it refers to the “who” and not the “what”. Rather than defining the entire team up front, a proposal should describe how the team will be built and sustained.

Focus on the practice, not the people

Great people are more successful when they’re supported by a community than when working in isolation. Communities that help team members refine and improve their practice are key to sustainable and successful teams. Ad Hoc (and other digital services organizations like 18F and USDS) has four main practice areas: product development, research, design, and engineering. These four communities of practice ensure consistent quality across the organization, both in the work product and in hiring new team members.

Instead of requiring a key personnel section, government agencies should ask vendors how they recruit and retain talent, how they help their employees maintain and improve their practice, and what their plan is to address low performers. Why not look at the resumes of the people that lead the practice areas instead of individuals on the team? These are the folks ultimately responsible for the quality of the work product across all project teams.

The reality is, a team of 20, 30, or 40 people aren’t going to be productive on the first day. Contracts should accept that a sustainable product development effort ramps up over time. Even if 40 people are ready on the first day of the project, they’re still stalled as they get agile boards set up, establish a sprint cadence, and schedule research sessions.

The best approach and timing depends on the project. But we need to stop pretending that excellent teams can appear out of thin air the day after an award. Instead, let’s focus on building high-quality and sustainable teams that are right for the task at hand. We can do this better by delaying the start of contracts after award, and evaluating the practice of a team, not the individuals.