19 reasons why technologists don’t want to work at your government agency

TL;DR: If you want to attract technical talent to your agency, focus on building an environment that supports innovation and innovators.

11 minute read

If you’re a government agency trying to attract technical talent to your innovation efforts, posting job descriptions for positions named “Technology Specialist — Internet”¹ may not be enough. The type of private-sector technologists you’re after are used to a very different workplace culture.

Startups long ago learned that innovative efforts require innovative atmospheres. Chances are, your agency’s culture isn’t very supportive of that innovator’s efforts, and when the talent you recruited arrive in the beltway, they’re going to be in for a bit of culture shock. Instead, optimize for the innovators. When creating an atmosphere conducive to innovation, pay attention to how much time technologists will need to spend fighting for the right to work on what they want to work on, versus actually just working.

Here’s 19 common reasons why private-sector change agents may not want to work at your agency (and what you can do to change that):

You force developers to use tools designed for lawyers — At most agencies, technologists will be given the same hardware (computer, phone, etc.) as would be given to attorneys and other non-technical civil servants. Not all knowledge workers have the same needs. While a lawyer may live primarily in Outlook and Microsoft Word, developers spend the bulk of their time writing and compiling software, a task significantly easier on Unix-based systems like Macs or Linux that more closely mirror production environments or are better optimized for the creative arts. Before I can write a single function or draw a single line, it’s likely I’ll be forced to make the case for why I should be able to use hardware that’s standard in the private sector.
You distrust your employees - You’d be hard-pressed to find an agency IT department that would give a developer full dominion over their workspace. When it comes to IT security, developers are distinct from the average employee in two ways: first, as engineers, they often have a critical understanding of the software we use on a daily basis, how it works, and how others might try to exploit it. As a result, although not entirely immune, software developers are less likely to fall prey to the types of traps system-level IT restrictions are designed to prevent. Second, while the average employee may primarily use one or two consumer applications that can be easily installed during onboarding (“set it and forget it” IT), a developer’s daily workflow often requires low-level system access — installing or upgrading development libraries, running local test servers, or compiling common frameworks — tasks impossible when an agency doesn’t trust developers enough to give them the necessary permissions on their own machines.
You tether developers to their desk - At most government agencies Wi-Fi is the exception, not the norm. Many government IT departments hold on to outdated preconceptions that Wi-Fi isn’t secure, or the agency simply failed to make the necessary investment a few years back, and is now behind the curve. Wi-Fi will never be as secure as plugging directly into a hard-wired connection, but there’s a trade-off to be made in terms of the ability to bring rich media in to anchor meetings in the practical, or have serendipitous interactions with coworkers someplace other than one’s desk. Most startups look physically nothing like government agencies, and for good reason. The ability to roam around a space cross-pollinates ideas and breeds creativity. While you don’t have to go out and buy neon green beanbag chairs, allowing internet-centric technologists to untether from their desk is a great first step.
You prefer government-specific service providers - If you go into a technical interview in San Francisco, they’re going to ask you if you’re familiar with services like Heroku, AWS, Travis, or GitHub. The thinking is that since there is a small set of industry standard tools that most companies use, when hiring, they’d prefer you know how to use their existing toolchain, rather than have to teach what the industry’s already settled on. In government, most of those tools are almost unheard of, being replaced by government-specific imitations that often pale in comparison in features, in quality, and in documentation and support. As a developer, I’d likely either have to unlearn what the rest of the world uses, or spend time making the case myself for why the agency should use the industry standard cloud services.
Temporary integration - In most companies (let alone open source projects) it’s sacrilege to commit a change without an accompanying test that verifies the intentioned functionality. As software projects get increasingly complex, standard QA in the form of “open up the browser and see if it works” isn’t sufficient to prevent regressions in the long run. Even if it is, developers need to be confident that when they make a change, they can do so knowing they didn’t break existing functionality. For many this function is accomplished by a process known as continuous integration. Every time a change is proposed, a server runs thousands of tests to give the developer instant feedback well before the change being merged. Yet in government, continuous integration is still a “we’d like to be there” development concept, with services like Jenkins or Travis being rarely used within government agencies. There’s simply not a test-centric culture to lean on, and without it, shaking things up becomes all the more precarious.
Sparse delivery — Continuous delivery is the idea that you should be constantly deploying small iterations of code, lines at a time, to test discrete changes individually. Unlike say, software that’s distributed as a CD or installed by end users, sites and other service-based offerings aren’t versioned in the same way, and thus the cost of an update is negligible. Rather than wait for an all-or-nothing update from 1.0, 2.0, continuous delivery lets you incrementally test each change one-by-one, lessening the risk of catastrophic failure (as an example, what version of Gmail are you using today?). A private sector firm might measure deploys per day or even deploys per hour, and still be unsatisfied. In government, there’s no need to measure deploys as they are scheduled well ahead of time, by day or by week, as each change must be reviewed by stringent change control boards which hold standing meetings for just such a purpose. Developers want to ship code — it’s how we innovate — and the more bureaucratic barriers you place between them and the ability to deploy, the harder that becomes.
You still see waterfall as a viable option — There’s no question that agile development is the hot new thing in government, but that doesn’t mean that it’s the default. Traditional waterfall development is still considered a viable option, with both procurement processes and agency policy encouraging large-batch development efforts. Developers want to move quickly, and want to be part of a team that moves as quickly as they do. It doesn’t have to be full-on Scrum, Kanban, or whatever the hot new thing is, but the fact that waterfall development is still an option, let alone the default, speaks volumes about just how much development cycles differ between your agency and the private sector, and how much meta-work developers will have to do to reconcile their workflow with the agency’s.
You don’t place process on a pedestal — Process matters. Take a look at the go-to project management flow in government: an agency might maintain an Excel spreadsheet with known bugs and desired improvements and hold a regular meeting with contractors to discuss priorities, with status updates being transacted via email. At the same time, the contractor likely maintains its own project management system in parallel to organize its own task orders. All this means that at the end of the engagement the final deliverable for a multi-million dollar contract may be as little as an email with a zipped attachment of the code. Agencies often don’t have day-to-day visibility into the project’s progress using professional project management tools (read: shared issue trackers), documentation is often an end user manual in the form of a 100-page PDF, and rarely if ever, get more than a snapshot of the code (read: version control), two things essential to capture and expose process to stakeholders, not to mention, give developers the context they need when they join a new project.
You erect a moat between developers and servers — There’s an odd antipattern whereby developers are distrusted to such a degree that they can never have access to production data. You write code, you ZIP it up, you email it to someone, and they deploy it. Need to run a migration? Send them a shell script. Why are system administrators trusted with production data while developers are not? Contrast that with many startup deployment flows. You write the code (in version control), you deploy the code, you monitor the effect your change has on production, and you adjust accordingly. The bigger the disconnect between technical talent and your users, the bigger the disconnect between the software and your users’ needs.
New technologies are guilty until proven innocent — In government, modern development frameworks are assumed to be insecure unless the particular developer that wants to use them personally proves otherwise. It seems that in the late ’90s, there was a big influx of spending in government IT, and the risk barometer was set, in terms of what technology can and can’t be used, and it has been set since. Technologies that could potentially be called past their peak in the private sector — things like Ruby on Rails or even PHP — are often seen as being too immature for government use, with agencies preferring to use legacy tools like Sharepoint and Cold Fusion due to technical debt and personal expertise. If you’d like to use a technology that was invented in the past ten years — a lifetime in web development years — be prepared to go to either bat for it, or learn a new government-specific framework.
You use open source as a verb — For government, open source is still something you do, not who you are or how you work. Few agency development teams embrace an open source ethos, and those that do, often face hostility from other parts of the organization for doing so. Private sector organizations see themselves as members of a larger open source community, with many developers serving as life-long open-source contributors, even as they change roles. For some in government, open source is merely a verb. It’s a switch you flip, to toggle the visibility of a line of code beyond the corporate firewall. Otherwise closed-source workflows remain the same, with stakeholders remaining guarded to the project’s outside influence and external contributions being vetted by the same process you might vet a press release or blog post.
Working in the open is a novelty, not a best practice - Why does your organization publish open source software? Is it because it’s the right thing to do? The best way to work? Do you simply publish open source because it’s in vogue? To get free labor? Good press? Who’s in charge of the effort? Is working openly an organization-wide initiative? Does it go through your public affairs office? Are other teams skeptical of your efforts? Do your open source efforts have top-down support? Is there anyone to maintain the project once I leave?
Speaking at conferences is tightly controlled - What’s the process look like if I’m invited to speak at an industry conference? Do I ask my presumably technical supervisor who is familiar with the industry? A non-technical public affairs officer? How likely are they to say no? How far in advance do I have to seek approval? What information do they need? How long do they take to respond? Are they going to place restrictions on what I can say or do? Do I have to submit my slides in advance? Does the organization trust me to positively represent the agency to the broader technology community or does it try to hide me and my ideas to protect itself? Is my participation an asset or a liability in your eyes?
Geeks are the bottom of your food chain - The single biggest different between a startup and an established organization, government or otherwise, is how they treat technical talent. In the early stages of a startup, when there’s only room for the bare minimum, developers reign supreme. Think The Social Network, Page and Brin, Coders in SF coffee shops. As the organization grows, that hierarchy is flipped. A professional class of managers enter the fray, to direct the developers efforts. In the long run, unless technical talent transitions to management, geeks will always be at bottom of your bureaucratic food chain, regardless of seniority or skill. This is especially the case for those without formal higher education. Career stagnation is all but guaranteed. There’s a reason they call it a bureaucracy, and not a technocracy.
Culture only happens outside your working hours - Most small companies live and die by their culture. They pride themselves on the unique feel that the office has (architecture, foosball, open bar, and all), and when recruiting, look specifically for “cultural fit”. In many large organizations, culture happens, exclusively outside business hours — at lunch and during employee-organized happy hours — if at all. Even during recruitment, culture is inoculated against, by necessity of the formulaic interview process designed to focus exclusively on documented hiring factors and paper-based skills. Developers want to work somewhere with a supportive culture, and unless you specifically seek to create it, it’s almost certain that any resemblance of culture will be stomped out by bureaucratic forces.
You measure your hiring process in months - It’s sometimes freaky fast how quickly startups can hire. You can go from screening interview to offer to on boarding in a matter of weeks. A big part of that is the intimacy of the hiring process. As a result, both sides are honest and forthright, and you really cut through the formalities. It’s easy to know where you are in the process, and you have a single, human point of contact, if at any point you have a question large or small. By contrast, there’s a good chance your hiring process is both opaque and arms-length. On the one hand, your formalized hiring process is a mystery to all but your hiring department, and chances are, you don’t do a good job of communicating that process to potential hires, and even if you do, I suspect the process is optimized for compliance and efficiency, not experience. Even within the process, interactions tend to be artificial and forced, by virtue of an uninterested HR department running the process (rather than those excited to onboard the hire), meaning I’m already burned out by day one.
Onboarding is an afterthought - It’s my first day. What does the experience look like? Am I stuck in a room with lawyers learning ethics restrictions, or with visionaries talking about culture and the next big thing? How long does it take for me to get a laptop? An email login? When I show up? Hours? Days? Weeks? What does my badging process look like? Do I need to pee in a cup? How many of my high school friend’s shoe sizes do I need to remember to satisfy your background check? How do I get up to speed on the project I’m going to be working on? I’m there because I want to ship code. The longer it takes for me to write my first line of code, the harder you make it for me to do my job.
Recruitment is unheard of - In the private sector you can’t go a day without getting a tone-deaf recruitment email. It’s a running joke in the tech community. As much as we joke, that courting process, whether formal or informal, works. The uncertain is scary, and without someone pushing you, telling you just how much greener the grass is on the other side, you’re likely to stay put, public sector or otherwise. Whether it’s a hip startup or the White House calling, there’s something to be said for being wanted, for hearing the pitch, and for having someone to work through any questions or hesitation you may have.
You block half the internet - I honestly don’t know how I’d do my job without social networks like Twitter. Technology is about keeping abreast of emerging trends. Open source is about being part of a community. Without access to that community, without access to the dominant mechanisms of communication, it’s not unsurprising that many government employees are out of the loop. If reading /r/opensource is blocked, or @hackernews is inaccessible, you either sacrifice your personal time to advance your professional life, or simply fall behind. Even worse is when organizations lock down even more innocuous resources like Stack Overflow, Gist, or even GitHub, for fear of information getting out. Whenever you prevent something from getting out, you also prevent something from getting in.

Technologists would much rather answer the call of civic service than optimize yet-another-mobile-app’s ad revenue. As noted before, “[t]he talent you want would be happy to work in an un-air-conditioned garage in New Mexico if it meant the chance to change the world”. Government provides just such an opportunity, but you’ve got to at least meet them half way. While other industries might have golden handcuffs, I’d argue that the biggest barrier keeping technologists out of government today is often their “digital handcuffs” — becoming accustomed to a culture that optimizes tooling and workflows for developers, and a culture that values shipping above all else (and a culture that’s not impossible for you to emulate).

If you’re a government agency trying to attract technical talent to your innovation efforts, it’ll take more than a fancy title. Focus on building an environment that supports innovation, and more specifically, one that supports innovators. If you build it, they will come.

Actual job title I’ve had. ↩

Originally published April 21, 2015 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit