How a Civil Servant ends up building APIs

One of my favorite stories from my time in Washington, D.C. came from a dedicated civil servant who became one of my closest friends and colleagues at the Centers for Medicare and Medicaid.

With a background in public health and a passion to help people, she joined CMS 25 years ago. Over time, the policies and programs she was working on needed websites. As she took on more and more responsibility and began managing these programs, the websites now needed to allow people to login…and be discoverable on Google…and have web analytics…and conform to design guidelines…etc etc. She found herself learning about agile software development and using github.

Today, these same policies and programs now have APIs and all of the complexities that come along with building and operating APIs such as developer portals, key management, new security risks and developer evangelism to drive the adoption of these APIs.

When I asked my friend what her proudest moment has been at CMS she told me a story about helping get lead paint out of houses with kids in Baltimore. It is the impact that drives her, not the tech. She didn’t grow up coding in her parents’ basement or have fond memories of the first app she built. As Marc Andreesson says “software is eating the world” and this is so very true for government programs and the dedicated civil servants that run them.

By the way, the US Digital Service is always hiring.

The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.

Contrast

Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.

2018 Reading List: Healthcare, Politics and Algorithms

2018 began as 2017 ended, my wife, kids and I were happily living in Washington, D.C. surrounded by current events in both work and life.  

I began the year by reading Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor by Virginia Eubanks.  This book helps you understand how bias is introduced into systems and is super relevant for folks working on or thinking about building prediction or filtering systems.

James Comey’s book gave me a better understanding of the FBI, it’s culture and relationship with the White House and DOJ. I liked the examples of empathy and reading people that he used throughout the book. Paying attention matters.

Artificial Unintelligence: How Computers Misunderstand the World by Meredith Broussard was excellent and I’ve recommended it to many of my teammates.  She talks a lot about algorithm accountability, ethics and bias.  Her simple “Titanic” data science example is fantastic.  

The President Is Missing: A Novel by James Patterson and Bill Clinton was a mystery thriller based on cybersecurity threats.  My wife and I had fun going to hear Clinton and Patterson speak during their book tour stop in D.C.  

Yes We (Still) Can: Politics in the Age of Obama, Twitter, and Trump by Dan Pfeiffer was “candy” for me as Chris Matthews describes it.  I love books like this that tell stories in an easy-to-read, funny style about the inside baseball of politics and White House goings-on.  I’m a huge Pod Save America fan and got a chance to see Dan talk with Alyssa Mastromonaco in DC during his book tour which was awesome.

The Devil in the White City: Murder, Magic, and Madness at the Fair That Changed America by Erik Larson was a really fun read for me since I rarely dig into non-fiction that reads like fiction.  I combined audible with the paperback and took a while to get through it.  Coincidentally, I finished the book on the Blue Line train into downtown Chicago.  I really want to visit Jackson Park now and see some of the old buildings.  A big takeaway was learning about all of the things that were introduced in the World’s Fair like the Ferris Wheel.

The Red and the Blue: The 1990s and the Birth of Political Tribalism by Steve Kornacki is a must-read for people interested in the current political climate and divide in this country.  It chronicles events from 1984 through 2000 talking about Clinton, Bush and the Gingrich Republicans.  Every chapter I was thinking “oh wow, so that’s what caused that thing we struggle with today.”

Medicare and Medicaid at 50: America’s Entitlement Programs in the Age of Affordable Care by Alan B. Cohen, David C. Colby, Keith A. Wailoo and Julian E. Zelizer is a very wonky read by helpful to understand the history of Medicare policy.  Since this directly impacts my work, it was super interesting for me.  The biggest story I’ve been telling from the book is about the role Medicare played in the Civil Rights Movement.  In healthcare, money drives so much of the behavior.  That was true then and is true now.


I started at least ten books in 2018 that I haven’t finished. This stressed me out for a bit then I read a quote about how having books laying around is good for you because it spurs thought, even if you don’t read every word. I loved this.

Now that 2018 is in the books (pun intended) and we are back in our hometown of Denver, CO, I still maintain my Politics & Prose membership and have added a Tattered Cover membership. Books, bookstores, reading and just being around books gives me so much mental energy, even if I don’t read every word 😉

Creating Momentum in Product Management

As a Product Manager, shipping and launching are always on my mind. Here are a few techniques I’ve used over the years to create momentum and keep the team excited about making progress and aligned on our ship dates and goals.

The big conference launch
I don’t love the “hit a date” tactics in product management but have used a big conference launch to generate steam successfully a few times. We did this with the launch of the CMS Blue Button API last year. When you have a big opportunity to generate press, attention and a bunch of new users / customers, it’s worth it. If you take this approach, make sure it’s a team decision and be ready to compromise a lot to get things shipped so you hit the date. You need to fundamentally appreciate how much teams hate having a date dictated to them and be an equal member in the quest. You are in this together. Also, be ready for tons of other non-software type work like doing press, building conference materials and being in a bunch of meetings making the various executives and stakeholders feel comfortable that the launch is on track.

Iterating towards the big vision
I know agile development is all about shipping working software, incremental pieces of the big vision. Sometimes it’s hard to get this train rolling. One of the approaches I’ve used a lot is getting the basic deployment pipeline setup early to deploy “hello world”. Once this is going, don’t be afraid to deploy tiny pieces. It will gradually build momentum.

If your product is stuck in some frustrating planning or architecture phase, try to find a way to keep moving forward. Can’t decide on a complex architecture? Try shipping a super simple user survey you can circulate around. How about shipping a basic piece of plumbing you are sure will be used in the product. Especially in the enterprise, my experience has been this really matters. Go a few cycles without shipping anything and the team will slow down to a crawl and morale drops. You’ll be having conference calls to plan the next conference call.

Intrinsic motivation meets good product goals
Luckily, most of the teams I’ve worked on over the years have a common understanding of the product goals and are motivated as hell to see the vision realized. In this environment, a PM needs to clearly articulate the goals and talk about how they are realized over time to give the team a good sense of the road ahead. If the team stalls, it’s usually the PM’s fault. Some decision is not being made and the path forward is not clear for the team to execute.

Summary
Good luck in 2019, I hope you build amazing things for people. As a PM, you know when the momentum isn’t there. Maybe you feel it yourself, the passion is gone and you aren’t obsessing about the product you’re building. Maybe the team feels broken and there are a million reasons why you can’t make progress. Hopefully if you find yourself in this state, you can use some of the techniques above to create momentum and ship!

Additional reading

The definition of “going live” – lessons from PivotDesk in 2012

Featured image from Undraw.

Glenmont to Farragut North

Beautiful, sad, newspaper, phone
Looking down, looking around, tall, short, fat
Hurting inside, motivated, exhausted, music
Glasses, hat, old, new, style, healthy, loving
Depressed, arms open, arms crossed
Friends bump into eachother and hug
Guy with a ponytail stares mindlessly at his phone
Girl with sad eyes daydreams

Launching Your State Digital Service

A Digital Service team with a one or two year “digital tour of duty” model  is a way for the top engineers, designers and product managers in your city or state to work full-time on the civic tech problems that make a difference for your citizens.

Most of the best tech talent in your State is not working for the Government.  They have probably never considered a career in public service or have no idea where to plugin.  A Digital Service creates that pathway.

The United States Digital Service

The U.S. Digital Service was founded in 2014.  Technologists from around the country move to Washington, D.C. for a one or two year term.  Most of the 180 or so USDSers are assigned to an agency like HHS, DHS, DoD or the VA.  Some work on longer-term projects at a single agency and others will work on many varying projects across multiple agencies.  The USDS is paid for out of a part of the OMB budget called ITOR.  Because the USDS has found technology solutions that save millions of dollars and executed on projects yielding very positive results for the American people, their funding and work continues.

Setting up your State Digital Service

In a State Digital Service model, the keys are funding and air cover.  It needs support from the top, either from the Governor or Mayor.  A big decision that needs to be made is where the Digital Service lives in your State’s Government structure.  Often, the initial thinking is for the Digital Service to report into the Office of Information Technology (OIT) because “it’s a technology thing”.  If OIT works across agencies and has great leadership, this could work well.  If not, your Digital Service could simply be viewed as staff augmentation and likely will fail.

You’ll need a charter, funding and the first cohort of awesome designers, engineers and product managers from your State ready to serve.  If the right structure is put in place, the talent in your region will seek out opportunities to be involved.

Once you’re setup and have your inaugural team on board, now the real work begins.  Picking the right projects is key.

The Work

In my year with the U.S. Digital Service I have seen a few scenarios where our USDS team was uniquely positioned to make a big impact.

Cross-team Projects

At CMS, the Blue Button 2.0 project required many different teams align on a shared product vision.  As anyone that has worked in a large enterprise knows, this is very complicated and hard to pull off in the best of circumstances.  Because the USDS had the air cover from CMS leadership, we were able to recommend and execute on a path forward that brought together several teams across divisions within CMS and shipped Blue Button 2.0 within a few months.

Procurement

The USDS brings great engineers to the table alongside an agency team to assist with procurement process and technology decisions.  The USDS helped design an Agile BPA and various processes to evaluate vendor proposals that included submitting code samples to Github and more.  This is such an important part of the success of USDS, the team even has a nickname, the Procuremenati!

Design Sprints

A design sprint is a process in which a small, cross-discipline team goes really deep on a problem for a short amount of time, typically 2-4 weeks (Ex: Defense Digital Service design sprint).  The nimble structure of a Digital Service team uniquely positions it for this type of work whereas normal agency constraints may hinder a successful design sprint.

Is your State ready?

To drive innovation, find new sources of talent and generally improve the quality of the software they are building for their citizens, State and Local Governments leverage many types of structures such as University Partnerships, Bloomberg I-Team Grants, Code for America and 18F, and more.  In my home state of Colorado for example, there’s a thriving open data challenge called Go Code Colorado, a Code for Denver brigade, over 1,300 datasets in the Open Colorado data portal and learnings from work with Code for America and more.  This is the type of CivicTech energy you want as you ready for your State’s Digital Service.  It shows a strong demand to engage in Government from your local tech community.

Each team begins differently.  The US Digital Service was born out of the technical problems during the launch of healthcare.gov and is four years old now.  The Canadian Digital Service launched less than a year ago and has added GovTech leaders like Aaron Snow to the team.  The UK Digital Service began in 2010 out of a “Digital by Default” mandate and has paved the way for other Digital Service teams.

Summary

The Digital Service magic happens when you combine the private sector design, engineering, and product management talent with Government talent that has the policy knowledge, deep subject matter expertise and understands how to navigate bureaucracy.

More Reading…

Digital Service Teams

Working alongside Digital Service Teams

Playbooks and Reports

Articles

CivicTech in Colorado

Screencasts for Product Managers

Screencasts are easy to build and a great way to convey information.  As a Product Manager, being awesome at communication is a big part of your job.  Can you tell a great story to customers?  Are you articulating the product roadmap to your company?

I have used screencasts to:

  • Demo a “Getting Started” experience on the website
  • Show off the product at a conference booth
  • Give product updates at Board Meetings
  • Describe the customer journey for a new product to team members
  • Help sales reps communicate with beta customers
  • Announce new product features on blog posts
My setup is:
My workflow to build a screencast is:
  1. Open Byword, type out a 1/2 page script (5 min)
  2. Grab scrap paper and pen, sketch a storyboard of the screencast (2 min)
  3. Plugin USB mic, open Quicktime Player and record the audio a few times to get the pace and tone of your voice sounding right (5 min)
  4. Open Screenflow, import the audio track. (1 min)
  5. In Screenflow, click record and capture video of your screen following along with the storyboard you sketched.  Do this a few times to get it perfect.  (5 min)
  6. In Screenflow, edit your screencast adding call outs, transitions and titles. (15 min)
  7. In Vimeo, go to Create / Music Store and search for an instrumental background track.  One you find one, download it and import into Screenflow.  Adjust volume levels of your voice track and the instrumental track. (10 min)
  8. Export your screencast to Vimeo (2 min)

Total time: 45 min

Tips

In Vimeo, there are a few helpful settings under “Privacy”:
  • password protect your video to share with a select group of people
  • set “where can this video be embedded” to “only on sites I choose” if you only want the video available within your app for example

I’ve used my iPhone to record a few seconds of people around the office, people in front of a whiteboard or monitor, etc.   If you are building a screencast to tell a customer story this can work well.  Plug your iPhone into your laptop and import the clip into Screenflow.

Examples

Further Reading