Having reflected on the truths of How to Speak Government, I was reminded of a post I wrote a couple years ago on the importance of empathy. The ideas certainly seem related. It’s really hard to act on the recommendations the former suggests without really believing it.
TL;DR: “Make their mission your own.”
For something a little bit different, today’s post was written by a colleague of mine, Abby McQuade. Her decade-plus of experience as a buyer of government technology means she knows what she’s talking about. Remember, if you can’t win it you can’t work it. Ignore her advice to your peril.
When you’re selling technology solutions to government agencies, the way you communicate can make or break your deal. Government buyers operate in a unique environment with distinct pressures, constraints, and motivations. Here’s how to speak their language and position yourself as someone who truly understands their world.
Lead with Understanding, Not Features
Government employees face relentless criticism from all sides. They work long hours with limited budgets, dealing with unfunded mandates, changing regulations, and pressure from multiple stakeholder groups. When you walk into a meeting, acknowledge this reality.
Start by demonstrating that you understand government is fundamentally different from the private sector. Don’t show up acting like you know everything just because you’ve worked in tech or consulting. Instead, express genuine humility: “I know there’s a lot I’m going to need to learn about your specific challenges and constraints, even with my background.”
This positions you as a partner, not another vendor who thinks they have all the answers.
Show Respect for the Mission
Government workers aren’t in it for the money. They’re there because they care about serving constituents and making a difference in people’s lives. When presenting your solution, connect it explicitly to their mission.
Instead of just talking about efficiency gains or cost savings, frame your solution in terms of how it helps them better serve the people who depend on them. How does your technology help them fulfill their mandate more effectively? How does it reduce the burden on their already stretched staff so they can focus on the complex cases that really need human expertise?
Know Your Audience’s Constraints
Government agencies operate under specific statutory requirements and regulatory frameworks. Before your meeting, do your homework:
When you reference this knowledge casually in conversation, it signals that you’ve done the work and you’re serious about understanding their unique environment.
Use the Right Terminology
Language matters in government. Small adjustments show you understand the culture:
Emphasize Communication and Transparency
Many government roles involve serving as a bridge between the administration, the legislature, and the public. If your solution has a communications component, emphasize how it helps agencies:
Good communication isn’t just nice to have in government—it directly reduces administrative burden and helps constituents access the services they’re entitled to.
Acknowledge the Interconnected Nature of Government
Nothing in government happens in a vacuum. Federal decisions impact state agencies, state legislatures affect executive branch operations, state policies influence local governments. Courts shape how agencies interpret their mandates.
When discussing implementation, show that you understand these interconnections. How will your solution work within their existing ecosystem? How does it account for the various stakeholders they need to coordinate with?
Position Yourself as an Ally
Remember that you’re speaking to people who are genuinely trying to do difficult, important work with insufficient resources. Your tone should convey:
Frame your solution as a way to make their hard job slightly easier, not as a magic fix for problems you assume they’re too incompetent to solve themselves.
Be Specific About Value in Their Context
When discussing your solution, be concrete about the value in terms that matter to government:
Avoid generic claims about “efficiency” or “innovation.” Instead, demonstrate specific understanding of their workflow and pain points. How does what you’re trying to sell to them make them more effective at fulfilling their mandates and mission?
Final Thoughts
Selling to government requires a fundamentally different approach than selling to private sector clients. Government buyers can spot vendors who don’t understand their world from a mile away. But when you take the time to truly learn their environment, speak their language, and position yourself as someone who respects the importance and difficulty of their work, you’ll stand out as a partner worth working with.
The key is simple: do your homework, show genuine respect, and remember that these are people doing critical work under challenging circumstances. Speak to them accordingly.
When the topic recently came up about scheduling a weekly team sync call, to the chagrin of a few colleagues, I suggested 7am PT on Mondays. Given how most of my work is tied to Eastern and Central time, I’ve become accustomed to waking up early. Even on weekends (I’m writing this on a Saturday and I was up about 6:30, for example).
I get that it doesn’t work for everyone, but for me, early mornings are ideal. They also make an excellent subject for a song (this one’s been a favorite of mine since 2006):
By name, at least, I’ve now worked at six different vendors of government solutions. There’s a fundamental tension that arises when building for state governments especially, that I’ve seen over and over again:
This tension creates numerous challenges. First, how should the system be architected to support configurability in the first place? It adds cost and risk to do so. And then, how should vendors approach communication of configurable features to a paying customer who doesn’t need the options? If you’re collaborating closely during development (as you should) it’s going to come up in planning and status meetings.
A case I’ve made that usually resonates is that having configurable options enables us as a vendor to maintain a (mostly) common codebase across customers. And that means when an improvement is made for any customer, everyone benefits. More succinctly: forks are bad. I can tell at least one tale of a high profile private customer that initially insisted on having their own radically customized copy of our company’s core product line, only to regret it a few years later when it took months to back port newer features to it.
Here’s a few considerations for product and engineering folks to consider when developing a solution for scale through repeated implementations:
Finally, an anti-pattern:
if customer == 'Customer 1':
doAThing()
elif customer == 'Customer 2':
doADifferentThing()
elif customer == 'Customer 3':
doYetAnotherThing()The above might be fine for your first couple projects, but if it’s still in your code by project 3 or 4, you’re doomed.
Yes, there are serious logistical obstacles to overcome, concerns about space junk are real, and the cost is likely pretty crazy, but nevertheless, the idea of data centers in space is pretty darn cool. I applaud Google for the audacity of the idea as a solution to a number of problems earthbound data centers present.
Back when I was at AWS, a few times a year they ran an internal campaign based on the Think Big leadership principle. People could submit ideas to an internal tool and a handful would be selected to be pitched to senior leaders. While I had one of mine get to that stage (a fun experience), one that didn’t (but I think should have) was a suggestion to build an AWS region on the moon.
My thinking was simple: when humanity finally gets a lunar colony established, there will likely be a need for easily accessible, low latency compute. And the economic advantages to the “first mover” would be significant. I never got any feedback on the submission, but I’d be willing to wager there’s a secret team somewhere in Seattle or HQ2 working on the notion, especially given the increasing requirements of AI and the fascination folks like Jeff Bezos have with space (to be clear, I’m speculating; I have absolutely no knowledge of this either way).
It’s also nice to see that the idea wasn’t completely crazy if Google is considering an orbital data center, which seems just as hard (if not harder?)
Anyhow, fun things to think about. Also, if the question is “what is your dream job?” the correct answer is “astronaut.” Always.
And finally, IFKYK:
My team just wrapped up a big proposal. I love the feeling when a month of writing and design work comes together. And it’s not just completion of the response itself that’s satisfying; it’s the culmination of all the groundwork that comes before, often a year or more of it.
Doing sales work requires a certain amount of brazen optimism that doesn’t come natural to many technologists, as we tend to be pessimists realists. To win customers’ trust (and their pocketbooks), you have to believe deeply that you are the best option for success. Deeply enough that it shows as genuine, because this kind of belief can’t be easily faked.
No, I’m not advocating for recklessly abandoning reality or straight-up lying. And yes, things are going to go wrong. We all know that. But the challenge of delivering a solution to a problem can’t solve itself. You can’t work it if you can’t win it. So yeah, you gotta first figure out a way to get into the ring, and leave future problems for your future self. Trust that you’re smart enough to address them, or at least be brave enough to risk failure.
I’m reminded of a chapter from The Geek Leader’s Handbook that talked about various approaches to proving truth in the workplace. While I wasn’t thrilled with the way the book broadly framed “geeks” vs “non-geeks” as fixed categories, it’s certainly the case with many engineers I’ve worked with (myself included) that we tend to disbelieve a statement until it’s proven true, and we especially don’t want to claim a fact without ample evidence. Whereas sales folks can operate more on hunch and gut feeling, believing something is achievable even when the outcome is unsure.
No where does this show up more than in the process of scoping and then selling projects; business folks need a cost (i.e. people x time) but engineers say giving such an a priori estimate is impossible. While the latter is true in the literal sense, it has to be done regardless. Rigid thinkers like myself have to get over themselves and do the best they can.
What I’ve found to work best is to find colleagues who bring a perspective at the other end of the “it must be proven before we call it true” and “it feels true so it is true” spectrum, and partner together on sales efforts. Is that not what we partly mean when we say there’s power in diverse thinking?
It’s even more powerful when some of these colleagues have been buyers of what you’re selling, because ultimately they’re the type of person you have to convince.
This article makes a good case why soft skills matter more than ever in the AI era. It’s why I think training that strengthens them is a good idea. It’s also why they should be screened for during hiring and promotion, even in especially for technical roles and extra especially for technical leaders.
Not to brag or anything, but I made this claim about AI back in 2017. Was I ahead of my time?
Something I appreciated about working at AWS is that consultants were not thrown to the wolves without training, the most useful of which was a series of mock customer meetings that modeled likely real-world interactions with both business and IT stakeholders.
Proverbial soft skills are difficult to teach, but they’re critically important, and this kind of simulated experience does a decent job prepping new hires for the challenges they’ll face. And framing it around an actual project might just result in useful artifacts or marketable solutions. Win win!
I’m hoping to eventually replicate this practice at my new gig, and thus wanted to capture a rough online of how I’d structure such a training. Perhaps it makes a case for my prior post?
Participants
Planning Work
(drafted by Project Team, reviewed by Coach, and approved by Sponsor)
Customer Meeting Guidelines
Three Phases
1. Discover
2. Design
3. Demonstrate