Building ecosystems where people and ideas thrive together

When I joined the California Department of Transportation account, the team was four people trying to serve a million-dollar contract with growing demands. I doubled the team to eight, but the real work wasn't just hiring, it was creating the connections and shared understanding that would make us function as a team rather than just a collection of people.

I co-created the employee handbook directly with the team, which sounds small but mattered a lot. People wrote their own norms rather than having them handed down. That changed how they thought about ownership — not just of their deliverables, but of their environment. The result: 100% retention during rapid growth on a high-stakes government account.

But team building was only one part of the role. I worked across 8+ vendor partners, building the relationships that let us coordinate on budget, SOWs, and program risks. Those connections were genuine, and they brought in new work for the firm.

The Caltrans account wasn't just one team. It was a sprawling multi-vendor ecosystem where different organizations had competing priorities, different technical stacks, and limited incentive to coordinate. My role was to build the bridges that made coordination possible.

That meant translating constantly: between political and technical perspectives when tensions ran high, between state client expectations and vendor capacity constraints, between what people said they needed and what the ecosystem could actually deliver. I worked with vendors to introduce shared success metrics so we could at least see if we were rowing in the same direction.

The work wasn't glamorous. It was persistent relationship-building, creating enough shared context to make collaboration possible, and surfacing unmet needs to leadership when the ecosystem needed support it wasn't getting. But those connections kept workstreams moving and brought in new work for the firm.

My fellowship in Pittsburgh's Northside neighborhoods was community-facing work: conducting outreach, researching development projects, building relationships with residents and organizations. But what I kept seeing were places where the right tool, built the right way, could meaningfully change what a service could do for people.

That observation sent me to teach myself web development — not to become an engineer, but to close enough of the gap that I could understand what was actually being built and what it would take to fix. It's why I ended up in civic tech, and why I think about product decisions differently than people who came up through a single track.