AI-ASSISTED DESIGN PRACTICE
Closer to the Craft: Evolving Design Leadership With AI
Extending a leadership practice that already stayed close to craft — now hands-on, not just observational.
Alex Thanasenaris - 7 min read
Career
Leadership
AI Workflow
Design leadership has never meant stepping away from craft for me. Every team I've led, I've stayed close enough to the work to critique it well, jump into a file when it mattered, and keep my own judgment sharp rather than let it go stale. That's a deliberate part of how I lead — I've said before that the job is to stay close enough to the craft to be useful in it, not to hover above it.
But there's a real difference between staying close enough to guide craft and being hands-on enough to build it end-to-end yourself. At the altitude leadership operates at, most of the actual production runs through other people's hands, by design — that's what makes a team more than the sum of one person's output. What's changed is that Claude and Claude Code make it possible to close some of that distance without giving up the seat. I can go from directing and reviewing to actually producing, at a pace that fits inside a leadership role instead of requiring me to step outside one.
The question I wanted to test wasn't whether the judgment was still there — leadership sharpens that, it doesn't dull it. It was whether that judgment could translate into direct, hands-on execution fast enough to be worth doing myself, on top of everything else, rather than only ever exercising it through the people I was directing.
The instinct to reach big first
My first move was to reach for something that felt appropriately senior: a unified security operations dashboard, generalized from the kind of sprawling, fifteen-product enterprise portfolio I'd actually worked across at Verizon. Fictional company, fictional vendor ecosystem, real complexity. I built three iterations of it — each a genuine, defensible piece of design and engineering judgment.
And it was too much. Not too much work — too much scaffolding. Before anyone evaluating the piece could judge a single design decision, they'd have to first absorb a fictional company, a fictional fifteen-product vendor portfolio, and the internal logic of an invented security domain. I'd built something that proved I could still think at staff level, and in doing so, buried the thing I actually wanted someone to see.
The pivot
Recognizing that took longer than it should have, mostly because the instinct to reach for the biggest, most senior-looking problem is exactly the instinct twenty years of leadership trains into you. Scaling back felt, for about a day, like it might read as scaling back my ambition too.
It didn't. I shelved the enterprise concept — not deleted, just set aside as a deeper technical artifact rather than the flagship — and rebuilt around two much smaller, much more honest projects: a two-screen tool for tracking my own case-study artifacts, and a tightly scoped AI-native admin console prototype.
1 week
the enterprise concept's built time
→
1 afternoon
each, for the two smaller projects
What stayed constant across scale
Here's the part that actually surprised me. The critique instinct I applied to a fictional enterprise security portfolio was identical, move for move, to the one I applied to a two-screen personal utility. In the big project, the AI flattened four incompatible severity scales into one generic badge. In the small one, it gave a full pasted prompt and a two-word note the same one-line input field. Same failure, same fix.
That consistency answers the question I actually started with — not whether the judgment was still there, but whether it could show up directly in my own hands, at the pace AI now allows, instead of only ever routing through someone else's execution. It could. The muscle wasn't missing. It just needed a faster loop between direction and production to prove it could operate at that speed too.
The part I almost left out
The honest version of this story includes the fact that my first instinct was the wrong scope, and that recognizing it meant setting aside real, finished work rather than pushing it across the finish line out of sunk cost. I thought about leaving that part out and just presenting the two smaller projects as if they'd been the plan all along.
That would have been a cleaner story and a less true one.
It's also, I'd argue, the most on-brand thing I could show a hiring manager. Deciding what not to build, mid-project, because the scope was competing with the actual goal — that's the same leadership judgment I'd apply to anyone else's roadmap, just applied to my own execution instead. Going hands-on didn't put that judgment on hold. It gave it something more immediate to work on.
Where this leaves me
I still think the acceleration is the real story here, not a talking point. I went from an idea to a working, critiqued, iterated prototype — twice, in two different domains — in less time than it used to take me to get through one round of stakeholder-ready wireframes. What AI hasn't done is remove the need for someone to sit with the output and ask what it smoothed over to get there, or whether the whole thing is even the right size for what it's trying to prove.