Selling Tech to City Government: A CIO's View | Podcast

If you want to sell technology to a major American city, you need to understand how decisions actually get made on the inside. Not the org chart version. The real version, where procurement rules, budget cycles, integration requirements, legal terms, and the CIO's personal philosophy all collide in ways that determine whether your deal closes or disappears.

‍

On Episode 12 of In Pursuit, host Mike Vichich sits down with Art Thompson, Chief Information Officer for the City of Detroit and Michigan CIO of the Year, named one of Government Technology's top 25 people to watch in 2026.

‍

Art joined the city in 2016, shortly after Detroit emerged from the largest municipal bankruptcy in American history, and has spent the decade since building a technology organization that now supports 32-plus departments and a $60 million IT budget inside a $2.5 billion city operation.

‍

His perspective on what it takes to sell technology to city government is grounded, specific, and at times refreshingly blunt. Watch the full episode here.

‍

Government Is a Long Haul Game

The first thing Art wants vendors to understand is simple: if you are looking for a quick win, go somewhere else.

‍

"Government is definitely, when you're doing business with government, it's a long haul game. You know, if you're looking for a short win, go somewhere else."

‍

A mid-size technology purchase in Detroit, say a million dollars, takes roughly seven months from the start of the RFP process to a signed contract. That seven months includes requirements development, the RFP itself, vendor evaluation, contract negotiation, and a final city council review.

‍

Once city council votes to approve a contract, there is an additional week during which they can reconsider. Only after that week passes is the vendor cleared to move forward.

‍

For vendors who are used to commercial sales cycles, this is a fundamentally different operating environment. Understanding that timeline and planning around it is not optional. It is the baseline.

‍

Detroit Has to RFP Everything

Unlike many other cities that can use cooperative contracts to speed up procurement, Detroit's city ordinance requires a competitive bid for every purchase above the procurement threshold. Cooperative vehicles like NASPO, Sourcewell, and Omnia are not an option for primary procurement.

‍

Art is candid that he loves cooperative contracts in principle. When you need something done quickly, they are a great tool. But in Detroit, they serve a different purpose.

‍

"Unfortunately for me, they're more of a comparison tool. So I have to go out to bid and then I can use them for better pricing."

‍

For vendors, this means there is no shortcut around the RFP process in Detroit. Every deal goes through competitive bidding. The vendors who win consistently are the ones who understand that process and invest in responding well, not the ones looking for a side door.

‍

The Two Wins Every Vendor Needs

Art describes the procurement process as requiring two distinct wins: a technical win and a procurement win. Understanding which team owns which is critical for vendors trying to navigate the process effectively.

‍

The technical win belongs to the department. The department identifies the need, sets the requirements, and ultimately selects the solution that fits their operations. IT's role on the technical side is guidance, not gatekeeping. Art's team reviews for security, integration feasibility, realistic delivery timelines, and fit with the city's technology environment. They are not there to override the department's decision. They are there to make sure the decision is grounded in reality.

‍

"We want the departments to be the ones who choose what they get. They gotta have a stake in the game. Their requirements are the key foundation. And then it's up to my team to build upon that."

‍

The procurement win involves following the city's formal process: the RFP, the evaluation, the contract negotiation, and the city council approval. Art's team works closely with procurement throughout, but the process itself is non-negotiable.

‍

For vendors, the implication is clear: build your relationship with the department that has the problem, not just with IT or procurement. The department's voice shapes the requirements. If you have not had substantive conversations with the people who will actually use your product, your RFP response will read like it.

‍

How IT Gets Involved and When

Art is direct about when he wants IT at the table: as early as possible. The sooner his team understands what a department is trying to accomplish, the better positioned they are to help define what the technology solution actually needs to do.

‍

For enterprise purchases, meaning solutions that span two or more departments, IT takes the lead. Art's team consolidates the voice of multiple departments, facilitates the requirements process, and owns more of the technical evaluation.

‍

With 32-plus departments, it is not practical to have everyone at the table for a large-scale purchase. IT represents the collective need.

‍

For single-department purchases, the department steps forward and IT plays a supporting role. The department develops requirements, drives the evaluation, and makes the call. IT ensures the chosen solution does not create security gaps, integration problems, or compliance issues.

‍

Shadow IT is an ongoing challenge. When departments spin up technology solutions outside of IT's visibility, the short-term win of moving quickly creates long-term problems around support, security, and data continuity.

‍

Art's answer to shadow IT is relationship-based rather than policy-based: be easy enough to work with that departments want to involve IT early rather than work around it.

‍

What Happens in Demos and Pilots

Art's team takes product demonstrations seriously. When a vendor comes in to demo a solution, his team watches closely and is actively encouraged to push, probe, and try to break things.

‍

"My team loves to poke. When you're in these demos, when you're reviewing products, push. See what you can break, see what you can ask. And don't be afraid to ask for that sandbox where we can play after."

‍

On pilots, Art has a specific philosophy that vendors need to understand. He likes pilots, but he insists they happen during the RFP process, not before it.

‍

A vendor who gets access to a department for a pre-RFP pilot is effectively pre-selling to the evaluation team. By the time the RFP drops, the department's requirements will be shaped around that vendor's product, whether intentionally or not. That is not fair to other bidders, and it puts the city in a difficult position.

‍

His preferred approach: narrow the field to three vendors through the evaluation process, then offer each of them a 30-day sandbox pilot as part of the final evaluation. Everyone gets the same opportunity. The playing field stays level.

‍

The Contracts That Trip Vendors Up

Contract negotiation in Detroit is handled by a dedicated legal team that Art describes as very focused on protecting the city. The two terms that most commonly create friction with vendors are indemnification and termination for convenience.

‍

On indemnification, the city's default position is uncapped liability. For many vendors, particularly smaller ones, agreeing to unlimited liability on a $100,000 contract is a non-starter. Art acknowledges that some negotiation is possible, but the city's legal team does not give ground easily.

‍

For very large vendors like Microsoft or Google, the dynamic flips. The city knows it will not win every contractual argument, and Art is realistic about that.

‍

"My law team could argue all day. We're not gonna win that battle. So there are some cases where we try to line it up a little bit more to expectations."

‍

On termination for convenience, Art's message to vendors is practical: if you have a good product and you are delivering, this clause will never be invoked. The city is not in the business of pulling the rug out from under performing vendors. The clause exists to protect the city's options, not to create instability for good partners.

‍

What Business Models Actually Work

Art prefers SaaS pricing over consumption-based models, and his reasoning is straightforward: he cannot be surprised at the end of the year.

‍

"I've got a set budget. Sixty mil sounds like a lot on paper, but it's actually pretty lean when you start talking about a two and a half billion dollar organization. Surprises don't help me."

‍

Consumption-based pricing works in some contexts, particularly when the city receives federal funding that allows for one-time capital purchases. But for day-to-day operational technology, the SaaS model with defined costs and predictable budgeting is the right fit.

‍

On AI-specific pricing, Art has additional concerns. Consumption models tied to AI usage can spiral quickly when users do not understand what generates charges. People using an AI tool for things it was not intended for, like checking the weather, burns through credits without delivering value. The answer is not to avoid consumption models entirely, but to go into them with clear usage boundaries, per-user caps, and a firm understanding of what happens when limits are exceeded.

‍

One business model Art finds genuinely appealing is the transaction-based approach, where the vendor's compensation is tied directly to value delivered rather than a flat fee.

‍

He cited the Secretary of State's kiosk program as a model worth studying: no upfront costs, vendor paid per transaction, and the incentive structure naturally drives the vendor to put working machines in high-traffic locations.

‍

The Body Camera Project: A Case Study in City-Scale Technology Deployment

The most instructive case study Art walks through is Detroit's body camera rollout, which he joined at the tail end in 2016.

‍

Detroit was operating under a Department of Justice consent decree at the time, meaning federal oversight of police department operations was in place. Body cameras were a key part of the response. Rolling them out to roughly 2,500 officers, with full integration into police vehicles, was one of the largest IT projects the city had undertaken.

‍

The rollout was done precinct by precinct, deliberately. That approach served two purposes. First, it allowed the team to validate that the technology was working correctly before committing to full deployment. Second, it gave officers a chance to engage with the technology directly, with Art personally present at rollouts to answer questions and address concerns.

‍

"If we were giving you a body camera, you saw my face that day. Making sure that people knew, hey, I'm here to answer questions. How can I be transparent? What do you want to know?"

‍

The internal resistance from officers was real. Concerns about surveillance, about how footage would be used, and about whether the technology would be weaponized against them were all present. The answer was not a policy memo. It was consistency: using the footage fairly, telling officers what they did right and what they did wrong, and letting the track record speak over time.

‍

The procurement itself came down to two major vendors going head to head. Price was the last thing evaluated, deliberately hidden from the technical evaluation team until the decision on capabilities was made. Proof of concept included live vehicle integration tests.

‍

‍The contract structure allowed the city to scale one precinct at a time, which protected it from being fully committed before the technology proved itself in the field.

‍

The Real-Time Crime Center and Project Greenlight

The body camera project laid the groundwork for what came next: a real-time crime center that pulls together video feeds, 911 calls, traffic monitoring, and analytical tools into a single operational hub staffed around the clock.

‍

Project Greenlight, Detroit's business camera program, is one of the more innovative pieces of the infrastructure. Businesses that opt in agree to install standardized cameras, not just any camera, specifically standardized to a spec the city defined. That standardization means the city gets consistent video quality across more than a thousand locations and can apply AI-based analysis uniformly.

‍

"Instead of just taking anyone's video feed to just standardize. If you want to be a part of Project Greenlight, you're buying this type of camera. It just allows us to better be responsive."

‍

AI is now embedded in how the city uses that footage: loiter detection, movement analysis, anomaly flagging. Art is careful about how he describes it. The technology flags things for human review. It does not make decisions. The humans in the real-time crime center, roughly 16 people at any given moment, make the calls.

‍

AI Policy: What Art Looks for and What He Does Not Want

AI is now Art's top priority, ahead of even cybersecurity, and he frames it as something that touches every other domain rather than a separate category.

‍

His first concern when evaluating any AI-enabled vendor is model training. He does not want Detroit's data used to train vendor models. That is a near-absolute requirement.

‍

"I don't wanna take Detroit data, Detroit information, and have it be the crux for how people are training or learning their models."

‍

His second concern is the quality and provenance of the data the AI is drawing on. Free AI tools built on unvetted data sources are not appropriate for city-facing applications where accuracy and accountability matter.

‍

His preferred approach to AI adoption is inside-out: experiment internally first, validate with the city's own data infrastructure, and only then consider public-facing applications. Detroit has enormous data assets, including geospatial imagery of every street in the city going back eight years.

‍

But before that data can power AI applications effectively, it needs to be properly labeled, categorized, and governed. Art is investing in that foundation before the applications.

‍

How to Actually Get Detroit's Attention

Art is direct about what does not work: cold LinkedIn messages asking for 15 minutes. He gets them constantly and they go nowhere.

‍

What works is registering on the city's vendor portal and watching for RFPs. What also works is a warm introduction from someone Art already knows and trusts. What works is demonstrating, in any communication, that you have actually done your homework on Detroit: what the city is working on, what the mayor's priorities are, what challenges the relevant department is facing.

‍

"I think warm introductions are great. Because eventually there's going to come up that process. And I do want everybody to know that Detroit is doing technology things."

‍

The vendors who build lasting relationships with Detroit are the ones who invest in understanding the city's goals and challenges before they try to sell anything. The RFP process is competitive by law. But showing up already knowing what matters to the city is the single best way to be competitive when the opportunity arrives.

‍

==================================================

‍

This post is based on Episode 12 of In Pursuit, featuring Art, Chief Information Officer for the City of Detroit. Watch the full episode for more on geospatial data strategy, the real-time crime center, AI vendor questionnaires, and what a decade of technology leadership in Detroit has taught him about cybersecurity.

‍