What I Wish Someone Had Told Me Before Going Into Gov Tech

Note: This is a riff on this post here.

Don’t be afraid to step across org hierarchy early and often
Measure success in improved outcomes to users
Make tactical changes yourself - don’t stray too far from your expertise - don’t solely rely on contractors to set & execute on their own strategy
Nudging the rudder of the ship 1° affects it’s long-term trajectory
The code you write (or your teams) will be a liability 5+ years from now
Writing software on a piece of Government Furnished Equipment (GFE) is next to impossible - try to change this with Cloud IDEs, getting locally installable software approved, etc.
It is almost always a people/process problem and not a technical problem
It’s easier to make changes to an org from a place of understanding - rather than from a place of arrogance
Question how and why processes exist that have created or will create more bureaucracy
Interpret memos & directives on your own - otherwise someone else will
Be careful what you say ‘yes’ to - carve out dedicated heads down time for deep thinking. There will be enough work for you to stay at a place for your entire career
Call your colleagues - even if it’s for 5 minutes - learn why they are there and what keeps them there
Know when you reach the height of your power & recognize that it is probably your time to leave
Be bold - a strong vision for how things could be can be a HUGE motivating factor. I’ve put this into practice with projects like tracking CO2 emissions across government websites, creating government design systems, and exploring federal AI implementations.
Unbury great people from within the org and let them execute & lead
It is OK to be wrong - solicit feedback early and often - so long as you course correct quickly
Never forget why you started & the peoples’ lives you are changing. Whether you’re working on design systems, software templates, or exploring new technologies, focus on the impact on users’ lives.

← Back to Blog