How I Work

What I actually do

I lead design for BigQuery and Google Cloud's AI-native data tools. Agentic BigQuery, BigQuery Studio and the Data Agent Kit are live on a top-3 revenue product, built by a team I grew from five to eleven. Alongside that I am a founder, at Digital Pool and HangarX.

I have never stopped building. This site is hand-written, no framework and no dependencies, and I still read and write the code my teams ship against. That is not nostalgia. It is the only way I know to keep an honest estimate of what a thing costs.

How the day job and the ventures fit together

Twelve years at Google, and LunarCrush, Digital Pool, HangarX and Northlit all ran alongside it rather than after it. It works because the lines are clear: the ventures are declared through Google's outside-work process, run on my own time and equipment, and none competes with anything Google sells.

The two halves teach each other. Google gives me scale nothing else will match; the ventures give me the whole loop, decide, build, ship, find out on Monday whether I was right. I learned agentic tooling on my own products before bringing it to my team at Google, and I know what a 0 → 1 costs because I have paid it four times.

If it worries you, the useful question is not whether I am busy. It is what I would stop. Ask me; the answer is short.

How I hire

The bar I will not move: show me something you took all the way. Not a case study about a project, the thing itself, shipped, with the ugly parts still in it. What you decided when the deadline came and something had to give is the job.

The unpopular version: I would rather hire the designer who shipped something imperfect mostly alone than the one who polished three screens inside a large team. The first has met reality.

Nearly everything else I am willing to be wrong about. Around seventy-five interviews in, the signal I trust most is specificity, whether they can tell me why and not just what. At senior level I screen hardest for whether someone makes the people around them better.

How I run critique

The designer opens, not the most senior person, and opens with the decision they made and what they want help with. "Feedback on anything" gets you feedback on everything. Work in progress only.

Out of bounds: restating the brief, redesigning it live, and taste with no consequence for someone using the thing. "I don't like it" is not a note. "This makes the destructive action the easiest one to hit" is.

I speak late, often not at all, because if I go first the room agrees with me. The designer decides. I set direction and the bar, not sign-off on screens.

How design and engineering share ownership

I sit on both sides of this line, so there mostly isn't a handoff. I prototype in the real stack, engineers correct me, and the argument moves from "is this feasible" to "is this right" in one conversation. It also makes my estimates honest, and engineering can tell.

I teach it too. When my designers needed version control and agentic coding tools I did not hand that to engineering. I taught it, and reviewed the code they shipped while running the team.

Agentic products change it again, because there is no screen to hand off. The artifact is a loop: what the system may do, what it shows first, how a person interrupts, what happens when it is wrong. None of that is a redline, so a designer who cannot get inside the system to watch it fail is guessing.

How I grow people

Weekly one-on-ones, and quarterly expectations we both write down so neither of us is reconstructing them in November. Twice a year each person tells me where they want to be in two years, and I go and find work that moves them there, including work above their level. Sponsorship, deciding who gets the visible project, is the whole game.

The measure is that people leave more senior than they arrived. Two senior designers hired and productive quickly, one promoted, and several I still mentor after they stopped reporting to me. That last one matters most, because nobody has to keep taking the meeting.

The other measure is that they stay. Most of my team has been at Google more than five years and the newest joined two years ago, which in this discipline is a long time to keep a senior group together.

What I have changed my mind about

I used to think a calm room was the goal. Absorb the noise, keep the team steady, let people work. My team tells me that part lands, and that it costs something I could not see.

If I take the organisational hits, the team never sees the reasoning, and decisions arrive looking arbitrary. The same instinct that makes me easy to disagree with in a one-on-one made me less forceful in the rooms outside the team, where allocation actually happens. Being pleasant in the room is not the same as being effective in it.

So I no longer treat "protect the team" as a complete description of the job. Protection without transparency is opacity with good intentions. I show the reasoning even when the outcome is bad, and I am blunter where being liked buys nothing. My team told me the same thing about timing: assessment should never be news.

I do not think the calm was wrong. I think it was insufficient.

How I run a team that is outnumbered

More product teams than designers makes coverage a design problem, and treating it as scheduling is how teams burn out. So I build the operating layer: engagement models so every team knows what support it gets, a capacity planner design and research share, an onboarding document, and one tracker engineering and product read too.

My team's sharpest criticism was that they could not see what neighbouring teams were building, and suspected duplicated effort. Same problem one level up: if the work is not visible, somebody solves it twice.

What I am looking for next

Not a title. A kind of problem: systems that act on someone's behalf, at a scale where getting them wrong matters. Once software can do things in your name, the interface stops being a screen and becomes a relationship, and almost nobody has worked out what trust, interruption and recovery should feel like.

I have been circling it from both sides, agentic data design at Google and AI ventures at HangarX, and I would like to stop splitting my attention. I want to stay a player-coach: a role that forces me to choose between leading and building makes me worse at both.

What would take me away from a product like BigQuery is proximity to the frontier, and a shorter distance between deciding and finding out. I am in Northwest Arkansas, have run teams across three countries and four time zones, and travel for what needs a room.