Geeks and suits

TL;DR: There are two types of change agents in the open government/data/source community: geeks and suits, but despite being in an industry built almost exclusively on communications, they never talk to each other

5 minute read

In the world of government IT, change happens at the hands of two separate, yet equally important groups: the geeks who build tools and the suits who implement them:

Geeks are the doers, the creators, the ones often relegated to the basement, desk stereotypically strewn with Doritos crumbs and Mountain Dew cans. To them, the status quo is nails screeching down the world’s largest chalkboard. They may be coders, designers, or UX experts, but at their core, they’re hackers. They’re excited about the next big thing, and have the means to make it happen, at least technically.
Suits are the sayers, the thought leaders, the ones in the corner office, desk stereotypically strewn with business cards and printed Power Point decks. To them, the future is an opportunity to improve on key performance metrics. They may be CxOs, program managers, or policymakers, but at their core, they’re not technical (at least not any more). They’re excited about the next big thing, and may have the means to make it happen, at least in terms of capital, both political and financial.

The odd thing is that, despite being in an industry predicated almost exclusively on the need to communicate, geeks and suits rarely talk to each other.

A geek in suit’s clothing

At GitHub, we’re lucky to build a product that many developers use on the weekend to contribute to open source, and given the opportunity, would likely enjoy using at work as well. A big part of what I do at GitHub is to simply put on a suit and talk “suit” to other suits, telling them exactly what their developers would tell them if they were given the chance: open source is not the next big thing. Open source is already here.

Often after explaining version control, APIs, and other modern web-development practices, I’m asked if there are professional services consultants (industry term for suits for hire) that can answer questions or walk them through the salient technical details. They almost don’t believe me when I suggest that not only do these people exist, but that they are already on the organization’s payroll. It’s almost as if I’ve asked the jocks to sit with the AV-club in the high-school cafeteria. We’ve all seen that made-for-TV movie before.

A matter of class

At least partially, this may be due to matters of perceived class and hierarchy. In traditional organizations, management sits well above technical talent, with technical talent making the switch to management, only when they can go no further up the technical career ladder. They’re compensated differently, they dress differently — fresh pressed suits versus some form of wrinkled khaki and a button down — and 10, 20, or 30 years after the fact, I suspect they still don’t sit together in the corporate break room (although the swirlies may now violate HR policy, thankfully).

Startups flip that hierarchy on its head. There’s no room for anything but what’s absolutely essential. As a result, developers are the top of the food chain, and are among the first, if not the first non-founding hire. Especially in young organizations, decisions are most often driven by those closest to the product itself, those who understand the technology and its capabilities, and most importantly, those who are willing to build it. There’s no such thing as startup by fiat. Why then, as organizations grow, do we begin to elevate management, often pushing that once-prized talent to the darkest corners of the organization, both literally and figuratively?

Two distinct communities

This dichotomy extends well beyond the four walls of the organization. Most technology conferences, both in terms of marketing and in terms of content, optimize for exactly one of these two groups, and when a technical conference does straddle the divide, it often goes out of its way to create a dedicated “executive briefing track”, so as not to scare one group or the other away. Heck, at one conference I recently attended, they literally had guards manning the hallway of the executive sessions, ensuring the geeks stayed well at bay.

There’s a pervasive conference antipattern emerging, whereby the geeks are given their own day, often the day before the conference, for a “hackathon”, “workshop”, or other keyword designed to indicate to the suits that the goal of the day is to , and that it’s not for them. This is balanced out by the conference proper the next day, which, cheerleading the virtues of the arbitrary conference topic, almost inevitably lacks any tangible or actionable takeaways, other than the business cards exchanged in the hall and reinvigorated sense of what was already known.

One conference, Puerto Rico’s Tech Summit, followed a similar pattern, with geeks and suits in concurrent tracks. At the end of the day, however, hackathon participants took the very stage the suits had been speaking from all morning and presented what they built that day. The contrast was hard to ignore and, shocked out of their seat, many geek-to-suit connections were made stageside to carry those projects forward.

The age of the geek

We’re living in the age of the geek. Today, as all organizations increasingly become technology organizations, successful endeavors can no longer exclude geeks from the table. In the government world, at least, Healthcare.gov was our first major chance to say “I told you so”. We’ve tried heavy-weight, process driven, command-and-control workflows, where the solution is always to throw more money and people at the problem. Yet innovation today is increasingly coming from small startups, and the geeks that run them.

For the first time, large organizations are slowly beginning to realize that there’s something to be said for those who grew up as the internet generation. Both in the public and private sector, we’re seeing more CTO, CDOs, and chief architects, many of whom, don’t dress like the rest of their C-suite counterparts. And this is just the start. Today, no world leader would make a major policy decision without first consulting their chief economist. How long will it take before geeks get a permanent seat at the table?

Bridging the divide

What would a hackathon for suits look like? Hackathons need not be technical. Call them ideation sessions or strategic problem solving summits. Take a page out of the hackathon playbook: identify a challenge, split into cross-functional teams, and present a minimum viable product in a few hours. Heck, why not invite management to your next hackathon. If ever there was a need for professional leaders, it’s under the stress of going from conception to prototype in a matter of hours, all with a team that’s never worked together.

What would happen if we did away with tracks at conferences and retooled technical training sessions to attract all roles. Suits often brag about their lack of technical knowledge, but for those making strategic decisions that affect an organization’s use of technology, at least a high-level understanding of today’s trends, even if they’re not going to be the ones sitting at the terminal, can go a long way. Imagine if a geek asked for a certain tool, or suggested a non-traditional architecture, and their boss not only knew what it was, but appreciated its potential (or could articulate a technical criticism).

What would happen if, within organizations, suits regularly checked in with technical teams, not to see the latest release, or discuss proposed features, but to hear what geeks were talking about when they’re not talking about the product. What’s the new meme? What’s trending on Hacker News? What are they excited about? What apps did they try out for the first time this weekend? What tools do they wish they had at work? How are they bending the rules just to get their job done?

I’m not suggesting that every member of the C-suite needs to know how to spin up a Node.js server, or that developers should spend their lunch breaks reading P&L statements, but in a world where implementation of any organization’s strategic goals increasingly relies on technical prowess — when for the first time in our history, government agencies consistently fail to execute large-scale initiatives whenever technology is involved — we could all benefit from a bit more dialog between s and :neckbeard:s.

Originally published December 18, 2014 | 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