Tag: Customer Obsession

Different Kind Of Fluency

Different Kind Of Fluency

By | | Comments 1 comment

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.

How to Speak Government: Advice For Technology Vendors

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:

  • Read the governing statutes for the agency
  • Understand relevant state and federal regulations (like ADA requirements, housing law, labor regulations)
  • Know whether they’re fully state-funded or receive federal grants
  • Research their organizational structure and where your contact sits within it

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:

  • Call the people they serve “constituents” or “residents,” not “customers” or “citizens”
  • Refer to agency leaders by their proper titles (“Commissioner,” “Secretary,” “Director”)
  • Learn the correct names and pronunciations for key officials
  • Understand the difference between departments, divisions, offices, and bureaus in their structure

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:

  • Keep constituents informed about their rights and available protections
  • Ensure the administration’s messaging reaches the people who need it
  • Reduce simple inquiries so staff can focus on complex cases requiring expertise
  • Maintain smooth connections between different levels of government (federal, state, local)

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:

  • Respect for the complexity of their work
  • Appreciation for their commitment to public service
  • Understanding that they face constraints you don’t deal with in the private sector
  • Recognition that they know their mission better than you do

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:

  • How does it help them meet statutory requirements?
  • How does it reduce the time staff spend on routine matters so they can focus on cases requiring judgment and expertise?
  • How does it improve their ability to serve constituents equitably?
  • How does it help them work more effectively with limited resources?

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 Everyone Is Super

When Everyone Is Super

By | | Comments 0 Comment

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:

  • On one hand, vendors want to build products that can be deployed repeatedly across states for cost-effectiveness at scale and rapid per-project implementation
  • On the other hand, states have wildly-divergent policy landscapes and political realities, even in seemingly similar domains, demanding highly customized solutions

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:

  • First Project: have scalability in the back of your mind, but don’t fall prey to YAGNI and overbuilding otherwise you’ll price yourself out of your first customer; just do basic foundational configurability and focus primarily on your immediate requirements
  • Second Project: don’t make the mistake of thinking you can discount your pricing, you’ve yet to hit economy of scale, and you’ll need any budget saved from reuse to expand your configurability capabilities and begin thinking long-term scaling strategy
  • Third Project: this all-important moment is where you can now truly begin thinking about productization, having full configurability (going beyond mere look and feel to business logic) and rapid, repeatable deployments
  • Fourth Project: now you should be reaping the efficiency benefits of your configurability and repeatability; if you haven’t yet, act fast and make investments at speed, or it’ll be too late

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.

Into The Deep End

Into The Deep End

By | | Comments 0 Comment

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

  • Project Team (Builders)
  • Customer Team (Customers) – Proxy for a real customer
  • Coach (cannot be on either Project or Customer teams)
  • Sponsor (can be same as coach, but usually will be manager / executive)

Planning Work

(drafted by Project Team, reviewed by Coach, and approved by Sponsor)

  • Define relevance to company objectives
  • Identify participants
  • Capture project title and description
  • Identify objectives
    • Skills to be learned
    • Artifacts to be built
  • Identify dependencies / deadlines
  • Scope guardrails for level of effort
  • Template
    • Participants: (identify every role)
    • Title: (one liner)
    • Description: (should clearly connect to company objectives)
    • Expected Outcomes: (final artifacts should be listed here, but ends, not means)
    • Skills To Be Learned: (be as specific as practical, acknowledging some flexibility may be required)

Customer Meeting Guidelines

  •  All are scheduled and led by the Builders
  •  All are attended by the Builders & Customers
  •  Customer team should “play the part” (within reason)
  •  Coach and Sponsor are optional but active participation should be minimized
  • Meetings are held synchronously and are recorded

Three Phases

1.  Discover

  • Builders review pre-work document
  • Builders develop agenda and questions for discovery session
  • Coach reviews agenda and questions (can be async) and gives go-ahead for meeting
  • Builders schedule and lead discovery meeting
  • Builders capture notes and document requirements
  • Builders follow up with Customers post-meeting to gather more info as needed
  • Builders meet with coach to discuss meeting, review artifacts, and plan next steps (can be async)

2.  Design

  • Builders design architecture/approach based on discovered requirements
  • Builders capture design and a build plan in a scope document
  • Coach reviews scope document (can be async) and gives go-ahead for meeting
  • Builders schedule and lead design review meeting
  • Customers give go-ahead to proceed (or iterate with Builders until ready)
  • Builders meet with coach to discuss design meeting, review artifacts, and plan next steps (can be async)

3.  Demonstrate

  • Builders execute on the build plan
  • Builders engage Customers and Coach as needed to address blockers (can by async)
  • Coach reviews completed artifacts (can be async) and gives go-ahead for meeting
  • Builders schedule and lead demonstration meeting
  • Customers give go-ahead that build is complete (or iterate with Builders until ready)
  • Builders address feedback and deliver final artifacts to Customers
  • Builders meet with coach to discuss demo meeting, review artifacts, and capture final thoughts / next steps
2 + 2 = 4

2 + 2 = 4

By | | Comments 0 Comment

I talk often about Conway’s Law, both here and in real life. I also talk often about working in the public sector. But for some reason I’ve never mentally put the two topics together and drawn the inevitable conclusion discussed in this article: Conway’s Law at Government Scale.

I’ve read Recoding America, and generally agree with the notion that a product operating model makes sense and leads to better outcomes. But here’s the thing: change comes slowly, if it comes at all, and solutions are needed now, across many domains.

I’m grateful for the work of those whose role is to reorganize and rethink government, and wish them success. But in the meantime, I see my role as working within the structures that exist now and doing the best that can be done. Projects can succeed, even with constraints.

Never Forget

Never Forget

By | | Comments 0 Comment

Technologists love to collect and share horror stories (see, for example, The Daily WTF). It’s one of the reasons this blog exists, as a brag document of a different sort.

No matter how stressful the situation may be, no matter how long the debugging session took, no matter how brain-melting the eventual solution was to implement, on those days when you experience a moment that you know will go into the annals of “how the heck did this happen” infamy, it brings a smile to your face.

For me, yesterday was one of those days.

It’s a little too early to tell the full story in a public place (the key stakeholders should get to hear it first), but I hope to eventually. It’s an all-time head-scratcher.

Off The Cuff

Off The Cuff

By | | Comments 0 Comment

Despite having had a number of opportunities to do so throughout my career, I’ve never progressed beyond being an average public speaker.

Thankfully I don’t have any particular phobias about it, and I can do a decent job relaying facts while being mildly interesting, but I’m far from a great orator, especially when I have to speak on the fly.

Still, every once in a while I’m happy with my ad libbing. This past week I spoke at a conference, and came up with this turn of phrase that I quite liked:

Universal problems are often best-solved through many local partnerships.

Perhaps that’s why I enjoy building for state government so much?

Tipping Point

Tipping Point

By | | Comments 0 Comment

Sitting on a late flight to New York City last night, I spent a few minutes time rereading my previous writing on radical responsiveness (yes, I do this sometimes). In the former post I said the following (and yes, it’s absolutely self-indulgent to quote myself, but here we go):

Being known as a responsive person 95% of the time usually means others will assume the best of you for the 5% of time you fail.

That ratio got me thinking: at what response rate will others start losing faith that you’re a responsive person, and thus begin not giving you the benefit of the doubt? It’s gotta be higher than 50%, because I can’t imagine thinking a person who’s likelihood to respond is no better than a coin flip could be viewed as a reliable responder. Maybe 70% or so? I bet a plot of actual response rate against fraction of people who will perceive said rate as responsive would look something like this:

The lesson: earning trust in responsiveness is hard, and keeping it is even harder!

Echoes In Eternity

Echoes In Eternity

By | | Comments 0 Comment

As I’ve gotten older, it’s become increasingly important to me to capture (usually digital) relics of what I’ve been up to. Mostly for my own benefit, but it’s a good professional habit regardless.

Five years ago today I was part of a team launching a new website and associated automated phone system helping unemployment insurance claimants at the beginning of the COVID-19 pandemic. I wish I’d done more to document our midnight release event, because it was a pivotal moment in my career. But I do have this one blurry screenshot:

This launch had a trifecta of positivity: a meaningful use case, cool technology, and (most importantly) it all actually worked! I’ve been doing this almost 25 years, and it’s rare to have all that come together. It made such an indelible memory that several of us have found ways to continue working together since.

(Obviously I didn’t get the memo about hoodies; instead opting for formalwear. No regrets on that one!)

Figuratively Speaking

Figuratively Speaking

By | | Comments 0 Comment

Speaking effectively to non-technical people can be a challenge for technical folks, but it’s an essential task for all but the most mundane (read: least-effective) of roles. One mechanism that I’ve found helpful is the use of metaphor. I’m a huge fan of trying to describe complex topics by mapping them to more broadly understood concepts. Being able to come up with such mappings fluently is a powerful skill. There may be many ways to develop it, but I suspect one is cultivating a wide set of interests.

While I was writing Tuesday’s post, it occurred to me that today’s Generative AI tools are to software what today’s 3D printers are to physical objects. On one hand, it’s incredible to be able to provide a specification and have it manifested in near real-time. Printers can make a variety of solids: toys, some kinds of replacement parts, that sort of thing. GenAI can create chunks of useful code, quick user interfaces, and basic apps, like my Pinochle scoresheet. But there are limits. Can either of these tools produce high tolerance, precision parts / highly secure, performant code? Can they build complex solutions like electronics / web browsers?

A 3D printer creating a figurine

I could be wrong, but just like we’re a long ways from 3D printing an iPhone, we seem a ways away from vibe coding Microsoft Word or an entire government system of record.