While I haven’t been blogging much, I’ve been keeping my public snippets up to date. Still, I thought I’d comment here about some of the different initiatives I’ve managed to launch since joining 18F.
- Snippets
- The Hub
- Documentation Working Group
- Testing Grouplet
- Working Group Working Group
- Objectives and Key Results
- 18F Résumé
- US Digital Service Hub
- Lessons
- Conclusions
Snippets
Since writing about snippets on the 18F blog, there’s been a small but steady stream of snippets coming in every week. (Bear in mind there are a few more snippets collected each week that are internal-only.) I’ve always maintained that they are, and should always remain, voluntary, hence the relatively low numbers so far. That said, there are a fair number of folks who’ve intimated to me that they intend to start writing snippets, and to persuade others to do the same, for various reasons. Keeping the faith while waiting for a practice to hit the tipping point is an operating model with which I’m exceptionally familiar.
Part of the reason that I’ve been so verbose in my own personal snippets is, as befits my fancy-schmancy new title of “Practice Director”, I’ve become increasingly less heads-down on specific development tasks and more of an Instigator across several distinct efforts. In esssence, my snippets have largely become weekly status reports across four different projects: the Hub; the Documentation Working Group; the Testing Grouplet; and the Working Group Working Group. As I’d hoped, my effort launching the Hub and the Documentation Working Group, in particular, have afforded me the latitude to branch out and move several different initiatives forward in parallel.
The Hub
Since writing about the 18F Hub on the 18F blog, I’ve had the enormous good fortune of having some exceptionally talented colleagues take ownership of the design, content, and features. Michelle Hertzfeld completely owned the information architecture and started forklifting content, previously scattered across Google Docs and GitHub, into the Hub’s unified interface. On top of tirelessly performing code reviews for my own work, Aidan Feldman added a client-side (client-side!) search feature, and authored the jekyll_pages_api gem in the process. Shawn Allen started giving the Hub some Javascript love, adding the location map that provides insight into the distributed nature of our team. Dave Cole is one of the primary authors of the GitHub Markdown editor prose.io, which we’ve adopted as the Hub’s primary editing interface. Fellow Virginia Peninsula native and 18F’s Section 508 accessibility expert Nick Bristow went on a wild streak identifying and resolving accessibility issues with the Hub.
These contributions have begun to transform the Hub into the product I was hoping it would become. There’s still plenty of work to do, but whereas I got the Hub to the point where it had a heartbeat, thanks to these amazing folks, you can now start to make out the face and the hands.
The Hub is still 100% statically-generated; there’s no separate database system or search engine that we have to keep running. As a design principle, my colleagues and I would like to push this “No-DB” model as far as we can, so that it’s easy for others to have a local Hub up and running locally in under a minute. By the same token, it should make it exponentially easier for other government IT teams to set up their own internal Hubs and potentially host public Hub instances, due to very low maintenance costs and an extremely narrow attack surface.
Though we are being a litle clever with webhooks, once you get your head around the model, it’s practically no-maintenance and works really, really well so far. I’ve been working very closely with Greg Boone and Eric Mill to maintain deployment parity with the 18F website and the 18F Project Dashboard, and I’m exploring future DevOps options with Diego Lapiduz. We’re also looking for ways to better optimize the loading of the client-side search corpus, to improve the mobile and low-bandwidth experience.
As a sign that things are on the right track, brand-new team member Melody Kramer has already publicized her enthusiasm for snippets and the Hub in a recent 18F blog post. That was exactly the kind of reaction I was hoping new hires in particular would have. I started snippets and the Hub precisely because, as a new hire, I wanted a better view into the landscape of the team, and wanted easier access to the information I needed to start becoming productive. Both Mel and her cohort fellow Becky Sweger have already begun to contribute back to the Hub and participate in the Documentation Working Group.
I’ve also managed to extract a number of Ruby gems from the Hub’s plugin code:
- hash-joiner: Performs
pruning or one-level promotion of Hash attributes (typically labeled
private:), and deep merges and joins of Hash objects. Works on Array objects containing Hash objects as well. - weekly_snippets: Standardizes different weekly snippet formats into a common format, munges snippet text according to user-supplied rules, performs redaction of internal information, and publishes snippets in plaintext or Markdown format.
- test_temp_file_helper:
The
TestTempFileHelper::TempFileHelperclass manages the creation and cleanup of temporary files in automated tests. (Also, I was too lazy to reimplement Pyfakefs in Ruby.) - team_hub: Contains resuable components extracted from the 18F Hub implementation for creating a team hub using Jekyll.
The idea is that we can modularlize Hub features in such a way that the public 18F Hub is effectively absorbed into 18f.gsa.gov itself. The Hub repo will remain essentially as a template, and 18f.gsa.gov will serve as an example of how far you can develop your own Hub instance.
Granted, none of these gems are going to save the world, and the team_hub in
particular is still very much a moving target. Also, as folks are increasingly
sold on the idea of the Hub, there are very real challenges around how to
provide a better editing interface for team data, how to train non-programmer
team members on editing Markdown files via prose.io, how to deal with Jekyll
speed issues, and how to scale the Hub to a larger
organization or a collection of
organizations. (More on this last point in a bit…) However, I feel that people
really “get” the Hub and what it’s driving at now: cultivating an environment in
which
Instigators
can thrive. It’s no longer my baby; it’s 18F’s baby.
Stay tuned to the 18F Public Hub in the coming weeks, as we’re about to share more team information that will provide an even deeper view into our structure and working models!
Documentation Working Group
When I first joined 18F, everybody thought I would get to work right away trying to improve the automated testing practices across the team. However, what I first realized was that we needed better infrastructure and standards around our internal documentation more than anything. When I was doing what I was doing at Google, long before my first day on the job, we already had snippets, a project database, an employee directory, a wiki, and other internal documentation platforms and training materials. Hence, at 18F, I rolled up my sleeves, got snippets and the Hub rolling, and then started my first “working group”, the Documentation Working Group.
In addition to pulling together folks to discuss how to develop the Hub as a tool to solve 18F’s documentation issues, we’re also involved with trying to set documentation standards across projects. The point isn’t for us to own all the team’s documentation, but to own the problem of making sure all the team’s documentation is as good as it could be. The wg-documentation Trello board is open for the public to see, and speaks to our efforts to collaborate across typical project boundaries. We also count GSA communications specialist Ori Hoffer amongst our members, who helps ensure our desire for openness and transparency translates effectively for a government audience.
One effort I’m particularly excited about is the set of 18F Guides that the different working groups are starting to produce. Tom Black has gotten the ball rolling by setting up the GitHub microsite. Both Tom and Elaine Kamlley are soon to collaborate with our colleague Kate Garklavs to integrate the guides into the overall content strategy for the 18f.gsa.gov website.
Also, I used the Documentation Working Group as a vehicle to see whether my model of running an ad-hoc volunteer team would translate to 18F’s culture. So far, so good.
Testing Grouplet
Yes, you read that right: It’s called the Testing Grouplet. Call it nostalgia. That said, the group is already living up to the glorious tradition the name implies (minus the Jägermeister). That is completely due to the effort of the amazing partners-in-crime that have already assembled, not due to any magic on my part.
For starters, Alison Rowland has not only agreed to be my co-Organizer (or co-Walrus, if you want to get technical), but she actually has many of the development and testing chops that people so often assume I possess. Chris Papazian led the effort to survey the testing tools and practices across 18F projects—something people had been suggesting I do myself since I started 18F, but Chris was so damn eager to do it, I just let him, and he did a fantastic job. We’re now able to mine the survey for material to add to our Testing Cookbook, which Shawn Allen has taken the lead to draft for us. Moncef Belyamani is working on standing up a project status dashboard based on the Code for America project monitor.
As for me, I did finally get around to translating my Unit Testing Perspectives slides (which Dr. Rob Read helped me outline for my talks at USCIS and the CFPB this past summer) into the draft of what I call the 18F Automated Testing Playbook. I’ve also drafted an additional section, the Automated Testing Roadmap, which is a straight-up rip-off of Test Certified. The goal is to lead the Grouplet through editing the Playbook and the Roadmap piece-by-piece, so in a couple months’ time or so, we’ve got a solid document that can be of general use, rather than a mere braindump of one person’s experience.
The idea between the two guides is that the Playbook contains a lot of the high-level testing principles, or “why” to do things a certain way; the Cookbook contains the details regarding “how” to apply these principles using a particular language or technology stack. Alison is soon to initiate the 18F Testing Grouplet blog post series, whereby we will provide case studies of automated testing on specific projects. The Playbook, the Cookbook, and this blog series will all inform one another, as we develop a body of materials that other government IT projects can draw upon to inform how they do automated testing.
Working Group Working Group
Through no effort of my own, 18F leadership recently decided to appoint people to lead a set of “guilds” dedicated to addressing cross-project concerns. These guilds are essentially the same as working groups—or, given my desire to introduce my favored term into the lexicon, grouplets. The primary difference between a guild and an ordinary grouplet is that the leadership has explicitly declared that the group should exist and be organized by hand-picked individuals. However, just like any other grouplet, these guilds have no direct reports and no allocated resources; they will rely on the wits of their leaders to effectively marshal volunteer support and persuade their peers of the value of their propositions.
Of course, this is exactly the kind of experience I bring to 18F. This crop of guilds is a boon for me as Practice Director, since I’m in the same boat (for now), and I see a big part of my job as helping cultivate the conditions in which guilds and other grouplets can succeed. So I’ve taken the initiative to join forces with Gray Brooks to start the Working Group Working Group, or WG^2 for short.
While people often smile when they hear the name, since it sounds like some kind of computer science joke (another level of indirection solves all problems…), the intent is deadly serious: we aim to create an environment in which working groups and guilds can thrive and have a meaningful impact on 18F deliverables and operations.
The first step, as has become the vogue in government these days, was to start a draft of a Grouplet Playbook. The intent is not to set a standard process that all groups must follow, but to provide a concrete “bag of tricks” that grouplet leaders can reach into to get the ball rolling and keep it in play. The WG^2 weekly meetings themselves are a forum for grouplet leaders to discuss their challenges and concerns, as well as share their successes and helpful ideas. Nick Brethauer is taking the lead on developing a Lean UX-inspired process whereby grouplets can evaluate potential projects based on assumptions of expected impact, as well as tangible or measurable indicators of such impact. We believe the goals and outcomes that arise from such a process will help establish the viability of the grouplet model.
Objectives and Key Results
I see Nick B.’s work (Brethauer, not Bristow) as funneling directly into another time-honored Google tradition I’m attempting to adapt to 18F: Objectives and Key Results (or “OKRs” for short). The basic idea is for individuals, teams, and the entire organization to document their primary objectives for the quarter, and the tangible outcomes, or “Key Results”, that will indicate progress toward each objective.
At the end of the quarter, everyone self-grades actual progress for individual KRs, individual objectives, and the set of OKRs as a whole on a scale from 0.0 to 1.0, and uses the grade to calibrate goals for future quarters. The “ideal” grade at any level is a 0.7, as that is indicative of a “stretch goal”: a goal that was slightly beyond reach, but that likely motivated greater accomplishment than a more conservative goal would have.
I’ve been keeping OKRs for myself since starting 18F, and have introduced them into the Documentation Working Group, the Testing Grouplet, and the Working Group Working Group. I’m just beginning to introduce them to the 18F Delivery team leads (Kaitlin Devine, Josh Ruihley, and our boss Aaron Snow) as a tool to introduce clarity around our shared goals. OKRs are not a substitute for snippets, or for Lean UX-inspired processes like Nick Brethauer’s; rather, they are directly compatible with and benefit directly from these other practices. OKRs are a lightweight-yet-solid means of aligning everyone’s efforts across the organization, and ensuring that we reflect regularly on our objectives in-the-large so that we may correct course if necessary, or possibly identify even bigger goals to strive towards.
18F Résumé
Yet another Google practice that I’ve kept up for myself is that of the internal résumé. The idea is to create a high-level narrative of your history with the organization, more detailed than a typical outward-facing résumé. In it, you list projects you’ve worked on, why they mattered, the impact they had, and any extracurricular activity like publications and speaking engagements. Just as snippets roll up into grades for OKRs, OKRs roll up into résumé items. Then, with all of this documentation at hand, it becomes straightforward to perform a performance self-review. Still time consuming, yes, but at least all the facts and figures will be at-hand. Then others asked to perform a review will also have a wealth of material to draw from, at varying levels of detail, so they can refresh their memories and make substantial remarks.
I haven’t pushed this idea very much at all yet within 18F, but my internal 18F résumé is posted on my internal Hub profile for all my teammates to peruse. If OKRs manage to catch on, the internal résumé will be the next thing to promote. Also, it’s my dream to eventually post OKRs and résumés on the Hub, whereby other organizations might be inspired to adopt or to adapt them.
Now imagine if more government IT teams followed suit with Hubs, grouplets, snippets, OKRs, and résumés…
US Digital Service Hub
The prospect of creating a Hub for the broader US Digital Service has started catching on. The most significant problem is that the 18F/hub implementation is designed to scale to a single team or organization, not to a large, combined set of organizations. In asking myself the question of how to solve this problem, I remembered: another level of indirection solves all problems…
I’ve created the 18F/usds-hub repository to contain the working draft of this “Hub of Hubs”. While sharing many design principles with the original 18F Hub, its structure and implementation aims to focus on linking to other separately-maintained Hubs rather than trying to cram an entire government’s worth of IT teams into a single Hub instance. The design is just getting underway this week, but I’m hoping we’ll make quick progress in getting more and more US Digital Service teams online with their own Hubs and surfacing them through this “One Hub to rule them all, One Hub to find them; One Hub to bring them all and in the sunlight bind them.” (Sorry, Tolkien.)
Lessons
Please don’t think that I’ve got it all figured out, or that I think I’m always doing the right thing the right way every time. Indeed, I’ve learned a lot from my colleagues since joining 18F this past November. The biggest shift in my perspective has come from working with designers and user experience researchers for the first time in my life. I cut my teeth as a backend developer, and as my former colleague Matthew Simmons wrote on his whiteboard, for most of my career up to this point “Users [were] a frontend problem.”
Let me offer an example. I rushed into developing and launching the Hub last December before Michelle Hertzfeld was able to contribute time to its design and architecture. In my mind, I wanted to push past all possible sources of Resistance and ship, dammit, lest I allow the Hub to wallow in pre-launch limbo. Just prior to posting the announcement of the Hub to the 18F blog, Michelle expressed concerns about how the Hub was so rough from lack of design input that we risked damaging the 18F brand by launching it prematurely. At the time, I didn’t appreciate what she was saying, and was hell-bent on shipping anyway; but then something amazing happened.
Michelle took a good read over my blog post, and when I finally made my big argument at the very end—that I wanted to get the Hub out to spread the idea to fellow Instigators, regardless of its pre-alpha state—she made a flood of sound editorial suggestions to bring that argument up front and slough off a lot of other cruft. I accepted every last one of her edits; they all helped drive the point that we wanted to innovate and iterate in the open, in a way that preserved 18F’s reputation for quality. Now, on top of being able to count Michelle as one of my most trusted partners-in-crime, I’ve come to deeply appreciate her concerns as well. Hence with the US Digital Service Hub, I’m waiting to brainstorm with her before sallying forth with my own half-baked design ideas. I’m sure we’ll still launch early and often, but I expect we’ll have a much better product much faster now that we can combine forces on the design from the beginning.
The key to collaborations like this, I think, is that on some level we’ve earned each others’ trust. We don’t see ourselves as infallible, and we aren’t hell-bent on getting our way, exactly the way we want it, no matter what. By opening our minds and seeking to understand one another, we find shared solutions to our concerns rather than wasting time, energy, and taxpayer dollars on pointless conflicts. That’s not to say we can’t have spirited debates, but with trust in one another, such debates fuel creativity rather than resentment.
Conclusions
This is all I’m at liberty to share right now. In time, all will be revealed.
It should be obvious that, yes, I’m trying to turn 18F into Google as much as possible, at least when it comes to best practices that foster transparency, collaboration, skills development, knowledge transfer and retention, high morale, creativity, and productivity. The foundation for all of these benefits is documentation, not for its own sake, but as a process that focuses discussion and generates products that scale effective communication, which in turn aligns organizational effort. While it sounds like I’m prescribing “more paperwork” as a cure for government ills (reminiscent of the adage that "XML is like violence—if it doesn’t solve all your problems, you’re not using enough of it"), I maintain that it isn’t documentation itself that’s government’s problem: the lack of efficient, clear, transparent and effective documentation is what leads to larger systemic issues.
To make my point, notice all the links from this post to people and projects in the Hub, as well as other open 18F artifacts such as our GitHub repositories and Guides. While I don’t expect every reader to follow every link, I’m still able to direct people to explore further 18F’s structure and working models, without my having to spell out every detail in this post. People can make connections that I didn’t even think to mention, or start examining our documentation, or possibly submit changes to our code. They can tune in for future updates to see how the team changes and our work progresses. Anyone can take the step from passive reader of this blog post to active Instigator by following the web of links through the Hub and choosing their own adventure. Not everyone will, but that’s OK; at least the possibility exists, whereas it did not before.
Good documentation fosters transparency, aligns perspectives, opens opportunities, and empowers people to seize opportunities together. It is the platform upon which an environment of openness, creativity, and innovation can thrive.
Lately, to drive home this point about creating the right environment, I’ve taken to telling folks about the Conducting 1 class I completed in Spring of 2014 at Berklee with professor Eric Stern. As is often the case with phenomenal classes with phenomenal professors, sometimes the lessons you learn are applicable well beyond the subject at hand. What Prof. Stern taught us was that the Conductor’s job isn’t to write the score, or to play all the individual parts: it’s to create the space, the environment in which music can be made. What better description of a “Practice Director” could there be, than to create the space in which the best software can be delivered, in which the best government services can be provided?
Also, I reject the notion that I was hired to “help” 18F with anything. The way I see it, did John “help” Paul? Did they “help” George and Ringo? No, they didn’t “help” one another; they joined forces to create a space in which their creative energies could express themselves in concert. It’s that kind of collaborative relationship I want to have with my 18F colleagues and our partners-in-crime across the broader US Digital Service effort, not one that smacks of paternalistic charity. We all shine on, like the moon and the stars and the sun.
Speaking of possibility, choice, and space, I’d like to point out a couple of subtle changes to any return visitors. To reflect the new identity I’ve forged with 18F, I’ve changed my tagline to “18F Practice Director and [Stratocaster][http://www.fender.com/guitars/stratocaster/] aficionado”; the “former Googler” part is gone. I’ve updated my bio page to include my most recent photo, taken this past January. I’ve added an “activity” item to the nav bar to expose my 18F snippets and GitHub activity, and added a link to my 18F profile under the “about” menu.
While somewhat minor details, to me, they signal an important personal shift. I spend my days bursting with creative energy, thanks to this new team and our mission of making government better. I’m committed to this exciting new future, and I wish to define my self-image in these terms rather than allow my past to define primarily who I am.
Of course it helps that, despite my flaws and future lessons that surely await, it turns out I’m really, really good at this stuff; and Greg Godbout, Aaron Snow, and Hillary Hartley have created an environment in which both I and my partners-in-crime can thrive. I’m having the time of my life. 18F is the best job I’ve ever had, by far.