Tennessee
Department of
Transportation
TDOT's technology division was modernizing how the state managed, monitored, and communicated transportation infrastructure across all regions of Tennessee. I joined as the first designer into an environment with no patterns, no system, and no precedent. Over six years I built the design function from the ground up while shipping five platforms that together form the state's operational infrastructure stack.
Shipping in state government is a different kind of hard. Procurement timelines, state-mandated hardware, legacy IT infrastructure, protected staff roles, and political pressure to accelerate projects for non-product reasons are the operating conditions, not exceptions to them. Every decision had to survive that environment and still produce something worth using.
At peak I was working across five concurrent scrum teams, each with its own product owner and 3–5 engineers, while also participating in executive-level product planning sessions with the CIO, CEO, architects, and POs to shape what got built next. The department recognized this scope formally by giving me the title Application Architect to distinguish my role from conventional design. When we hired a second designer, I wrote the institutional UX hiring criteria that defined what good design judgment looked like for state government work. She took on MQA and additional platforms from there, bringing her own research and design direction to work that built on the shared foundation we had established.
My work at TDOT ran the full vertical range of the organization, from field inspectors entering data on tablets at low-connectivity job sites to the commissioner's office, where I also contributed to public presentations and statewide communications.
Each platform served a distinct user base and operational function, but they were structurally interdependent. SWIFT generated the incident data that Smartway surfaced publicly. DWR fed the financial oversight systems that ODA and EDFS helped govern. Designing across all five simultaneously required holding the full system in view, not just the screen in front of me.
When SWIFT was ready for mapping, we had everything we needed to do it properly. A full GIS team, a specialist, and a PO pulled from GIS who understood the data deeply. Custom maps would have been genuinely better than anything a third-party tile service could provide.
I argued against it anyway. The maintenance overhead, the ongoing GIS staff dependency, and the taxpayer cost of building something we could get reliably for free were not justified by the usability payoff. I took that argument to the PO, to the GIS team, and all the way to the CIO. The CIO sided with me.
It still stings a little. But the platform shipped with Google Maps and has stayed maintainable ever since, without specialized dependencies or ongoing infrastructure cost. Some decisions show up in what a product costs to own five years after it ships, not in how it looks on launch day.