Procure great development teams by avoiding 5 traps

Ben Morris
STSI Point of View
Published in
5 min readAug 30, 2018

--

Technical team working around a conference table. (Image credit: Photo by rawpixel on Unsplash)

You (as a government buyer) want a great digital product built, which requires a team of talented people. Presuming you don’t have that team in place, you need the right contractor. The right contractor has to bid on the work, then hire and assign talented people to your project. Talented people have to want to work on the project, and do so in an environment that helps them be effective.

This is easy to buy into as a high level strategy, but all to easy to sabotage in low-level execution. Below are some pointers on how to procure a great team. In particular, these are common levers in contracts or procurement processes that I’ve seen that promote or constrain success.

1) Don’t be penny-wise on rates

Don’t be afraid of high hourly rates. In general, you’ll spend more money hiring developers at an average bill rate of $99/hour vs. $149/hour. I’d rather run a project with of 5 staff at an average $149/hour than 10 staff at $99/hour. The smaller team will get more done.

In procurements, this means both an evaluation model that doesn’t weigh price heavily. Ideally, you will throw out too-low rates as failing a realism test and introducing delivery risk.

2) Allow developers to bring their craft

Talented team members have spent a tremendous amount of time honing their tools and practices. They try different operating systems, editors, keyboards, build tools, etc. Developers obsess about things which may seem silly to an outsider, such as text editor font and color scheme. I’ve known people to custom-build keyboards. The take-away is: let developers choose their tooling.

In contracts, this means not imposing government-furnished equipment (GFE) unless it is truly necessary. If information sensitivity truly requires GFE, invest in decent equipment and a process to bring in new tooling with low friction.

3) Allow time and location flexibility

Talented, effective professionals know their work rhythms, and know where and when they can get quality work done. Often, this might involve face-to-face collaboration in a traditional office. It can also include hours, days or weeks outside of the office. The flexibility to work remotely is a huge recruiting and retention issue, which substantially impacts quality of talent and rates.

Most federal agencies have a telework policy for employees, and the supporting technical environment. It only makes sense for contractors to operate a similar way. I’ve occasionally seen objections along the lines of: “How do we know they are really working?” If that level of trust is missing, it’s time to reconsider who you’ve hired, and find real means to track satisfaction with work performed.

This flexibility also allows teams to take advantage of contractor facilities. Some government facilities short-change investment in work space for contractors. Why pay for top teams and force them to work in second-rate spaces that hinder the productivity you are paying for?

In contracts, this means a clear work location clause that provides for remote work, as well as the related technical capability/policies. This is not an all-or-nothing proposition — remote work need not equate to never seeing the team in person. Let the project need and team norms drive the mix of in-person interaction.

4) Factor in slack time and skill investment

Talented people continue to explore and grow skills. Day-to-day, they need a bit of slack time to explore tangents, such as researching a new library or language. This ‘off-task’ exploration tends to generate high returns, as they now have a bigger shelf of tools to pull from, and can better find those simple solutions to new problems when they arise.

Similarly, people need to engage in communities and deeper learning experiences such as conferences and other events. We need to acknowledge that people will take time away from projects for such events. They might also temporarily support a proposal or technical challenge. All of these allow staff to stretch their capabilities and return a stronger contributor.

Contracts and pricing models must factor in the need for ‘off-task’ work. This might be factored in to slightly higher hourly rates for time & material work. Firm-fixed-price per team contracts can also support this kind of flexibility, and requires clear expectations between the vendor and government program/oversight managers.

5) Be careful with labor category & key personnel requirements

Minimum requirements for labor categories tend to do more harm than good. At best, they provide some protection against a contractor providing under-qualified people (again, find better ways to manage performance and customer satisfaction). Far more often, they create arbitrary limits on who can be hired for a given role, and rule out people who could make the strongest contribution.

In contracts, this means procuring teams, or having looser definitions of labor categories, including key personnel. Some specific examples of things to avoid and why include:

  • X years experience in a specific skill or technology. Talented people might be able to quickly learn a new tech based on parallel experience. Further, does a candidate have 5 years experience, or the same one year five times?
  • X years minimum professional experience for junior roles. I’ve seen the lowest-level labor categories require 2 or 4 years experience. That’s just silly. Allowing firms to bring in new college hires can be good for everyone. I’ve seen new hires become highly-valued team members (out-performing some “senior” experience level staff) within their first year.
  • X certification. Certifications can play a role, but should seldom be a pass/fail. They are easy to verify, which is why evaluators like them, but that’s about it. I’ve known enough PMPs who I wouldn’t trust to manage themselves, much less a program. Further, rigid adherence to specific certifications/ methodologies (PMP, CSM, SAFe) goes against agile principles.
  • X degree. Many talented people don’t have a degree, or a degree in the ‘right’ field. It is reasonable to include a degree requirement so long as ‘or equivalent experience’ language is included.

--

--