moar about why not

.gitignore

@@ -10,3 +10,5 @@ assets/vendor/modernizr/media
 assets/vendor/modernizr/test
 .bundle
 Gemfile.lock
+/html
+/md

_posts/2015-04-08-why-technologists-dont-want-to-work-at-your-agency.md

@@ -5,37 +5,48 @@ excerpt: ""
 
 If you're a government agency trying to attract technical talent to your innovation efforts, posting job descriptions for positions named "Technology Specialist — Internet"[^funny-story] may not be enough. The type of private-sector technologists you're after are used to a very different workplace. It's not a matter of privilege or a private/public divide. Startups long-ago learned that innovative efforts require innovative atmospheres, and when they arrive in the beltway, they're in for a bit of culture shock.
 
-When creating an atmosphere conducive to innovation, pay attention to how much time technologists will need to spend fighting for the right to work they want to work, versus actually just working. With that in mind, here's 18 reasons why private-sector change agents may not want to work at your agency:
+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. With that in mind, here's 18 reasons why private-sector change agents may not want to work at your agency:
 
-1. **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 which more closely mirror production environments and are optimized for creative arts. Before I can write a single function or draw a single line, it's likely I'll be forced to justify why I should be able to use the computer of my choice.
+1. **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 that more closely mirror production environments or are better optimized for 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 a hardware that's standard in the private sector.
 
-1. **Distrust of 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 pray 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 on boarding, 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 make them the administrator of their own machine.
+1. **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 pray 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 on boarding, 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.
 
-1. **Being tethered** - At most government agencies WiFi is the exception, not the norm. Many government IT departments hold on to outdated preconceptions that WiFi isn't secure, or the agency simply failed to make the necessary investment a few years back, and is not behind the curve. WiFi 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 into meetings, or have conversations somewhere other than one's desk. Most startups look physically nothing like government agencies, and for good reason. The ability to roam cross-polinates ideas and breads creativity. While you don't have to go out and buy bean bag chairs, allowing internet-centric technologists to untether from their desk is a great firs step.
+1. **You tether developers** - At most government agencies WiFi is the exception, not the norm. Many government IT departments hold on to outdated preconceptions that WiFi isn't secure, or the agency simply failed to make the necessary investment a few years back, and is now behind the curve. WiFi 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 into 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-polinates ideas and breads creativity. While you don't have to go out and buy bean bag chairs, allowing internet-centric technologists to untether from their desk is a great first step.
 
-1. **Strange 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. There's a small set of industry-standard tools that most companies use, and 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. As a developer, I'd likely either have to unlearn what the rest of the world uses, or spend time making the case for why the agency should use the industry-standard cloud services.
+1. **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 for why the agency should use the industry-standard cloud services.
 
-1. **Temporary integration** - In most companies (let alone open source project's) it's sacrilege to commit a change without an accompanying test. As software projects get increasingly complex, standard QA in the form of "open up the browser and see if it works" isn't sufficient. 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. 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 in government.
+1. **Temporary integration** - In most companies (let alone open source project's) it's sacrilege to commit a change without an accompanying test that verifies its 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 prior to 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 by government agencies.
 
-1. **Sparse delivery** — Continuous delivery is the idea that you should be constantly deploying small iterations of code, lines at a time. Unlike say, software that's that's distributed as a CD or installed by end-users, websites 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, lessoning 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 measured deploys as they are scheduled well ahead of time, by day or by week, as each change must be reviewed by stringing change control boards which hold standing meetings for just such a purpose.
+1. **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 that's distributed as a CD or installed by end-users, websites 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, lessoning 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 measured deploys as they are scheduled well ahead of time, by day or by week, as each change must be reviewed by stringing change control boards which hold standing meetings for just such a purpose. Developers want to ship code, and the more bureaucratic barriers you place between them and the ability to deploy, the harder that becomes.
 
-1. **Waterfall is an 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.
+1. **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.
 
-1. **Process isn't valued** — The final deliverable for multi-million dollar contracts is an email with a zipped attachment of the code; agencies often don't have day-to-day visibility into the project's progress (read: version control and shared issue tracking)
+1. **You don't value process** — 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) and rarely if ever, get a snapshot of the code (read: version control), two things essential to capture and expose process to stakeholders.
 
-1. **Guilty until proven innocent** — Modern frameworks are assumed to be insecure unless I prove otherwise (Rails, Node, even PHP are looked at as too immature compared Sharepoint, Coldfusion, etc.)
+1. **New technologies are guilty until proven innocent** — In government, modern development frameworks are assumed to be insecure unless the developer that wants to use them proves otherwise. It seems that in the 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 would likely be looked at as being past their peak in the private sector — things like Ruby on Rails or even PHP — are often seen as being too immature of 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 bat for it.
 
-1. **Open source as a verb** — Open source is still something you do, not who you are or how you work
+1. **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. Private sector organizations see themselves as members of a larger open source community, with many developers serving as life-long open-source contributors. For some organizations, 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.
+
+1. **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 initative? Does it go through your public affairs office? Are other teams skeptical of your efforts? Do your open source efforts have top-down support?
+
+1. **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? How much does the organization trust me to positively represent it to the broader community? How much does the organization try to hide me?
+
+1. **Geeks are the bottom of the food chain** - The single biggest different between a startup and an established firm 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. Zuckerberg. Coders in SF coffee shops. As the organization grows, that hierarchy is flipped, as 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 the bureaucratic food chain, regardless of seniority or skill. There's a reason they call it a bureaucracy, and not a technocracy.
+
+1. **Distrust of employees** -
+
+1. **Culture only happens outside of business hours** - Most small companies live and die by their culture. They pride their self on the unique feel that the office has, and when recruiting, look specifically for "cultural fit". In many large organizations, culture happens, if at all, outside of 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 hard factors. Developers want to work someone with a supportive culture, and unless you seek to create it, it's almost certain that cutlure will be stomped out by bureaucratic forces.
 
-1. Working in the open is a novelty, not a best practice
-1. Speaking at conferences is tightly controlled by a non-technical public affairs office
-1. Unless they transition to management, geeks are always the bottom of the bureaucratic food chain regardless of seniority or skill
-1. Agencies don't trust their employees
-1. Culture only happens outside of working hours (lunch, happy hour)
 1. If you're passionate about a specific topic, ethics restrictions make it difficult to transition to/from the private sector
+
 1. The hiring process is measured in months, is opaque and arms-length
-1. Recruitment is almost unheard of
-1. Restricted internet
-1. Developers can't touch servers
+
+1. **Onboarding is an afterthought** -
+
+1. **Recruitment is unheard of** -
+
+1. **Locked down internet** -
+
+1. **You erect a moat between developers and servers** —
 
 [^funny-story]: Actual job title I've had.