My advice, based on the mistakes made and the lessons learned at 18F, at least from my perspective. Maybe this will all sound simple and obvious, but I’m sharing because it wasn’t for us.
Is the goal to deliver digital services to users or to transform how other agencies do technology projects that deliver services? Many orgs start with the former, obviously, but it helps to know whether you’re trying to segue to the latter, because you’ll need wildly different teams and approaches. For instance: if the former, you’ll need a few PMs and many more researcher, designers, developers, and content folks. (This is like the SF team.) If you’re trying to do tech transformation, aka consulting (like 18F), you’ll need many more PMs and strategy-minded designers/developers/content folx, because projects are likely to run smaller and demand more distributed change-management and strategic leadership.
Who funds your org? Do you have to bill and recover money from other agencies? Do you have to sell the work? Who decides whether you’re successful? Who tracks the P&L? On what timescale? Do you get to define success? Who are your customers? And, if the answer is “we don’t know” or “it’s still fuzzy,” prioritize building the reusable foundations you’ll need regardless — get your design system in place, write down principles, build communities of practice, be open about the work. Those are the things that are hard to fight for when the business model demands billable hours.
Anything you own needs funding. You can maybe get away with owning the design system or blog in 20% time, but not much else. Infrastructure projects, process tools, anything with a code base that has real dependencies — those need dedicated staff to keep them safe, secure, and useful. In the early years, 18F spun up many experiments without knowing how they would be sustained. Many were excellent ideas (cloud.gov, login.gov, Federalist, USWDS), but reconciling the fundamental disconnects between those products’ usage and 18F’s business model was incredibly painful and burned out many people.
Tell your stories, build in the open, use open Slack channels when you can, do everything as transparently and honestly as you can. It builds resilience and momentum, and pays dividends in the long run. It helps with inclusion, and it is a powerful defense against changing priorities.
Really changing how government builds technology means changing what is possible for the humans in government. Sometimes that means unlocking talents or getting out of their way; sometimes it means learning new skills, vocabularies, or habits. Regardless, it’s a major structural shift, because successful technology projects now require much more empowered decision-making and risk-ownership than we usually tolerate from civil servants. For each civil servant or existing vendor or appointee who takes on this way of working, it will be terrifying. The way to make it less terrifying is to give them cover in the form of success stories and company: start by modeling iterative user-centered product development, so there’s a proof of concept that it works to deliver a thing they needed. Then move towards pairing on meetings, research, design, and development. Do it together. Then coach so there’s space for refinement, and to gut-check the things that are hard.
It’s equally absurd to swing too hard to either end of this process: building something for an agency will not make them capable of doing user-centered iterative design and development any more than watching a video of YoYo Ma will make me capable of playing the cello. Similarly, workshops and tutorials alone will not move the needle any more than a lecture about the tango will make me able to dance it if I’ve never seen it. People need to see it works, see how it works, do it with help, and do it themselves. [Insert wise citations about pedagogical models here.]
- Have a clear criteria for intake, and a way to say “no” without making enemies.
- Work toward work-life balance; this work is too hard to sustain long hours for very long (and the hours/intensity will begin to affect the diversity/inclusion of the team eventually).
- Prioritize making the best thing the easiest thing. Anything you can make that is free/quick and helps other people do something a little better is a powerful tool for change and influence.
- Know what you don’t do, and make sure everyone on your team (and outside the team!) knows how to explain it.
Such wise words of wisdom 👏💙🚀👆🏼