Hiring for U.S. Digital Services
The new U.S. Digital Services group has a difficult task ahead assembling a talented new software developers and designers team. Many of the best developers and designers avoid the public sector because the environment is generally not conducive to producing amazing work.
The best software developers are looking for more than just a paycheck. They are looking to create elegant solutions to hard problems. The best software developers want to write software worth reading and executing. They want useless talkers to get out of their way and stop telling them why "it can't be done like that" and "NO, because we've never done it that way before."
Every startup and government agency talks about how they are "changing the world" and "doing things that matter." But few of them are places worth working because the talk is hollow.
These are my six recommendations for how Digital Services, or any organization for that matter, can prove to prospective employees that they have an environment that deserves to employ some of the country's best technical minds.
- Keep a "Few Managers to Many DOers" Ratio
- Open source code, documentation and data
- Host (quality) tech meetups
- Code review with outside developers
- Hire short-term consultants only
- Ensure great gigs for departing developers
Keep a "Few Managers to Many DOers" Ratio
Organizations that quickly build and release software have a significantly higher percentage of DOers than managers. DOers include software developers, designers and system administrators (who are increasingly spending their time coding with Ansible, Puppet, Chef, etc).
A primary driver in high performing software-run organizations is that they constantly work to keep as few managers and non-technical workers as possible. These non-technical workers include project managers, "technical" architects (who spend their days drawing useless UML diagrams instead of coding) and team leads that order people around instead of doing their own work.
Managers love to spend time in meetings. Meetings are antithetical to focus on actual work. Make sure to read Paul Graham's essay on Maker's Schedule, Manager's Schedule to understand why keeping a low manager to many DOers ratio is so important.
Open source code, documentation and data
This playbook is a great start. Make sure it's not just documentation but also code as CFPB has done with the collab Python source code and 18F with the answers Ruby source code.
There's something about knowing your code is open to the rest of the software development world via open source that makes her feel she's held accountable and writing something that matters.
A public visualization of how much code at Digital Services is currently open source, how much is private and how much is in process to be open sourced would be awesome. Figure out a way to make that dynamically generated so it doesn't have to be updated in a spreadsheet by hand. Automate the transparency rather than making it a manual process.
Host (quality) tech meetups
We have all these massive government buildings and the tech community struggles to find event space for tech meetups such as DC Python, DC Continuous Delivery, Ruby User's Group and so on. There has to be a way to cut the red tape and have at least one facility be available for tech events of 80-120 people. You're hosting so give us updates on all the amazing work you're doing at Digital Services.
Also, ensure the space is kept for real tech events that focus on software development, not the garbage recruiter-run events where passion for programming is nowhere to be found (I'm looking at you, TechMotion).
Code review with outside developers
The code is open source which is a start. The next step is to bring in awesome developers from the best tech companies with people in DC like TrackMaven, SocialRadar, BoundlessGeo, MapBox and SmartThings to sit down for in-person visits. Conduct hour-long free code review sessions for constructive code and documentation feedback.
18F does something like this with their API feedback sessions. Apply that concept to code reviews. Give quality t-shirts, stickers and simple perks to outside developers who participate. Have the best reviewers who come in recommend other great developers they think would also be helpful to keep the code reviewer pipeline stocked.
Hire short-term consultants only
Use consultants only for niche skills such as information security in less than 8 week durations, if at all. Consultants are parasites. I used to be one. Even though I tried to do good work it was impossible to properly serve the dual masters of client and consulting company.
Make information on the number and percentage of consultants at Digital Services publicly assessible. Actually it may be worth creating a webpage dashboard of all the things software developers care about so they can see how an organization stacks up in various attributes.
Ensure great gigs for departing developers
When developers eventually depart from Digital Services they should be getting gigs at private companies that have nothing to do with government sector work. If developers are coming out of Digital Services in a couple of years and being hired by Bay Area companies that's a positive indictator that the program is at least hiring the right talent.
That's my initial incomplete recommendations list. But each of those things are really difficult for most government organizations to do at all. The above items are a good litmus test for whether Digital Services is for real or will end up perpetuating the quagmire of overcomplicated government software systems maintained by an army of overpaid consultants.
Let's hope that Digital Services either writes some code worth reading or creates some software worth writing about.