Truss Goes to Washington!

We got one!

We woke up one unassuming Thursday to an email, as brief as it was impactful: “TrussWorks is scheduled for October 10th at 1400 for a 90-minute demonstration at the Pentagon.”

Holy shit.

The email went on to request that we build a prototype worksample for that meeting, and that it should be completed by the following Wednesday--that is, just five work days later. Furthermore, Nic, our government contract PM who got us into this position with our original white paper bid, was coincidentally leaving for a remote Nicaraguan island the next morning. Time to ready the coffee robot and get to work.

The requested work sample was for a replacement onboarding system for Global Corp, a hypothetical company. This was described in a series of user stories, which detailed a system with two parts: one section would be the employee’s interface, where they could submit and update personal information as well as select which benefits in which they would like to enroll. The other would be an interface for Global Corp’s HR team, to review and approve these employee submissions.

Much text in the work sample request was devoted to describing users struggling with the old system. It was clear that user-centered design was, rightfully, one of their concerns. Moreover, they explicitly requested testing, evidence of modern development practices, and modern project management methodology. These were pretty clear signs that whoever was running this project had read the USDS Playbook.

Breaking apart the request to determine a course of action consumed the better part of a day for us. We were suddenly trying to figure out: who would lead and staff the project? Who would go to the Pentagon? (“The government,” an entity that sounds as ambiguous as it does enormous, needs to know, by the end of the day!) What’s all of the context behind this contract? As the most experienced person not engaged with a client at the time (we call it “the bench”), I was the de facto lead of the project. Thrown into the hot seat, Nic and I had quick conversations as I, the engineer, became a project manager, and Nic, the project manager, became a beach bum.

The team and the stack

I left work that day both excited and unsettled. There were two important questions that, in the excitement, didn’t get fully answered: what tech stack would we use, and who would be on the Away Team for the following week’s demo at the Pentagon?

At Truss we have a leveling system for all employees. It ranges from 1 to 5, junior to senior. I am a level 4. While I’ve started a couple companies and led engineering teams, I haven’t had a lot of exposure to sales presentations, and definitely not presenting at the Pentagon. I got a little nervous imagining a panel of stone-faced four-star Generals, grilling a bunch of left-coast techies. Considering what would make a strong team, it became clear that picking a team that represented Truss as whole would be more impactful than stacking the deck with our most senior engineers. We are a diverse company united by a core set of engineering values.

Those values come out just as strongly (and sometimes stronger!) in our junior engineers than the senior. We needed to show this.

All that said, it seemed prudent to pack some big guns. Nick (not to be confused with the previously mentioned Nic,) one of our most senior engineers, was an obvious choice. He has an amazing breadth of technical experience, business savvy, and a British accent to boot. If you can name a technology created between 1970 and now, Nick has used it and can give you opinions as colorful as they are thoughtful. Rebecca, a more junior engineer, was another easy pick. She has experience working in government policy and knows her way around Washington as well as she does a build system--both quite well. This choice also allowed us to walk the walk with our values. We believe in the strength of building a diverse teams (Truss is over 40% female at the time of writing), and encouraging the development of junior staff. Having made these choices did wonders for my confidence. I was sure we’d be ready for whatever was in store.

The other lingering question was which web stack we’d use. Our preference for web applications these days is a Go API powering a React frontend. These both have well-maintained, modern ecosystems. Keeping a strong boundary between frontend and backend with an API has an benefit of making it easy to add native mobile frontends later. The challenge was that the engineers on the bench at the time weren’t intimately familiar with that stack, and on a four-day timeline, we decided it was necessary to go with something more familiar: Python and Django. Django is a great stack for prototyping, though we generally don’t use it for production workloads as, among other things, we have a preference of type-safe languages. The discrepancy felt a little awkward, so we made a note to explain this distinction in our submission.

Getting started

One of the first things we did was create a user flow design led by Breanne, an engineer with a background in UX research. Before any application code was written, she helped us all imagine the application flow through the end user’s eyes. This helped us get clear on what we were building. It also surfaced some design ambiguities we didn’t see coming and saved a bunch of work down the road.

At the same time, another team was preparing our Continuous Delivery pipeline, extending a successful stack we’d created previously. A CircleCI 2.0 pipeline would build and test a Docker Python image, which would then be deployed to Amazon EC2 via its Container Service (ECS) with a blue/green deploy strategy. This enabled each commit to be tested and deployed with no downtime. We also took advantage of an existing set of Terraform modules we’d already built (and are publishing), which made it easy to get our AWS environment up and running. This meant by the end of the day, we were testing and deploying our first versions on production-grade infrastructure.

While the infrastructure was top notch, our app basically just looked like this:

Coding, coding, coding

We spent some time over the weekend building out views and controllers in Django. The work we did Sunday gave us the bare bones of each page layout, and some connective tissue between them:

Now the three main sections of the site were up: the Login page, Employee page, and Reviewer page. None of them were very functional, but we were set up so that come Monday, we could divide the work among the members of the team without stepping on each other’s toes. 

By end of day Monday, we had something starting to resemble a real app:

Well, almost. “Prettiness” was not one of our top priorities at this point, though we did want to ensure that we weren’t making any design decisions that would tie our hands later. The design work that we did on Day 2 really helped with that.

Oh, and what’s that animal, you say? Why, it’s a tapir! We were given a GitHub repo of that name by The Government to submit our final work. We weren’t 100% sure that they really meant the animal; in the world of government contracting, it could have been some arcane acronym. We crossed our fingers and hoped that the silly/cute logo would win us points. 🤞

The home stretch

Our goal was to have the site essentially completed by the end of Day 4, since there are always things that need fixing. As part of our standard work practice, we schedule regular demos to show off the sprint’s efforts to the project’s stakeholders. This ensures that nothing can get too far off the rails during development. On a normal, longer project, those demos are anywhere from one to six weeks apart, usually tied to our sprints. On this project, we were doing demos at the end of every day.

This practice gave us two additional benefits. First, the demo script served as a set of user stories that we could use to ensure that all the functionality we wanted to show off was built and working. But also, each demo was practice for the presentation that we would need to be giving at the Pentagon in a week--something we wanted to have locked down.

By now, the app had taken its final form:

In addition to some polish, we added a neat “Reset Demo” button. Since the application was published to a live website for review, we wanted to give people a way to reset the site back to the initial state after playing with it. To do this, we took advantage of Django’s flush function, plus the fact that our initial demo data was created with a Django  management command. This made resetting our demo state, which otherwise could have been a tricky problem to get right, a fairly simple two-line feature. This came in super handy as we tested our live site.

Truss goes to Washington

All that was left was for the Away Team to head to Washington D.C. and present the demo. In the days leading up to that, we secured travel arrangements, rehearsed the script, and debated (perhaps too much) what type of attire would be appropriate.

When we arrived, first contact with the Pentagon was not dissimilar from airport security. Inside, it was nothing like we’d expected. Imagine a mashup between an office building, a shopping mall, and a war museum. The existence of a CVS and Panda Express were particularly surprising. Also, our efforts to not be underdressed were hilariously off base; the Defense Digital Service team that we met with were in our more familiar uniforms of t-shirts and jeans. This was a relief.

There is an obligation to keep rather light on the details, so we’ll fast forward through our presentation and the hour of questions that followed. I can say that we found our interviewers to be wonderful people. They are working hard to make significant improvements in technology that will positively affect service members and their families. We delivered a great presentation (in my opinion) and couldn’t be happier to have the opportunity to meet the folks there.

And the winner is...

If you’ve ever had what you thought was a pleasant first date and then found yourself compulsively checking your phone fifty times a day, you have some idea of what it’s like to bid on a really great contract. Of course we wanted to play it cool, but for a small company, getting the first sizable government contract is a big deal. Those of us that spent the previous two weeks deeply focused on the presentation were especially interested. Alas, as they say, a watched inbox doesn’t produce an awarded contract.

Nic, freshly rejuvenated from vacation, was being hit with such a barrage of requests for updates that I thought he might soon need even more PTO. He had to explain to us that during an active bid, vendors have limited access to government contacts in an attempt to maintain “fairness”. Due to this well-meaning policy, we basically faced an impenetrable black box for several months. Attempts to convey interest, request estimated award dates for planning and strategy, or even provide a thank you letter, were met with a poker face of an email: “Thank you for your query, but we’re unable to provide additional information at this time.”

Thankfully, on Friday, December 8th, the waiting game finally came to an end. Nic jumped in Slack and victoriously announced that we had in our possession a signed contract for the Department of Defense’s Personal Property Prototype! Chat exploded with Party Parrots and 🎉 reactions, the likes of which we’ve hardly seen.

If this were a Hugh Grant rom-com, we’d start rolling the credits and insinuating that everything’s smooth sailing from here on out. For us, however, the story is just beginning. The DOD system that we are working on is responsible for the relocation of every US military service member and their family. This is a ~$2B market and represents over 15% of all yearly moves in the country. So we need to get it right.

This is an exciting time for Truss, but also government technology projects in general. New, small companies like ours are working with the USDS and existing government agencies to modernize services that will affect millions of Americans. There’s a lot of new ground being covered, and we’re happy to share what we’re learning. So, stay tuned for updates, and for the more adventurous: we're hiring!