Six Months Later
What a good engagement actually leaves behind
I’ve been thinking a lot lately about what happens after we wrap up an engagement. Not the final presentation or the handoff, but six months later, when the team is on their own.
I've been in consulting for 15 years, and earlier in my career, I thought the job was to leave behind the most polished deliverables I could. More documentation, more recommendations, the most thorough handover I could put together. The thicker the binder, the better I figured I'd done. (Oof.) I'm certain now I was chasing the wrong thing. The real test is whether the team can carry the system forward and trust their own calls once we've gone. The engagements I'm most proud of rarely had a standout final week. The part I remember came later. I'd check in six months on and find the team had kept building without us, adding patterns we never showed them and working through the kind of gnarly tradeoff they'd once have emailed us about. By then, the final presentation barely matters. What lasts is whether the team can still move on their own.
Most of that gets shaped in the first few weeks, long before the final one, and the biggest lever is how we run workshops. You can walk in with the answers and present them, which feels great and gets you nods around the room. Or you can set things up so the team builds the answers themselves while you mostly stay out of the way, which is slower and a lot less satisfying in the moment. Both feel productive at the time. The difference shows up months later: one hands the team an answer, the other leaves them able to work the next one out on their own.
Documentation works the same way. Most of us have inherited a system with no real explanation behind it, and you remember the feeling, poking at it carefully, half-expecting the whole thing to fall over. Good documentation feels more like getting a math test back where someone actually showed their work. You don't just see the answer circled at the bottom. You see how they got there, the dead ends they tried first, the point where they changed their mind. A system documented like that reads like a conversation, because it keeps the decisions and the reasoning, the stuff a clean final file always leaves out. When a team can see why something was built the way it was, they can tell when it's safe to change. When they can't, they either leave it well alone, or pull out something load-bearing they didn't know was holding the rest up.
The last few weeks are the ones that tell you whether any of it stuck. We try to use that time to pull back instead of pushing harder. Fewer recommendations, more questions. More of the team driving while we ride along in the passenger seat. It can feel like you're doing less, because in some ways you are, and that's a weirdly tough thing to sit with. But an engagement that ends with a team making confident calls on their own will outlast one that ends with a gorgeous set of files nobody fully understands.
What it boils down to, for me, is one question I try to keep asking the whole way through: is this building the team's capability, or their dependence on us? The answer's never totally clean, and some things really do need to be delivered rather than co-built. But if I'm not asking it regularly, the default drifts toward dependency, because it's always easier to make something than to hand over the thinking behind it. Every time.
There's a particular kind of satisfaction in watching a team realize they've got this without us. The work's never finished, it never is, but at some point they stop reaching for us and just carry on. That's the whole point, really. The best version of this job is becoming the kind of help a team grows out of, and being glad when they do.
It's the kind of thing I'm thinking about from the very first conversation with a team. If you're trying to figure out what an engagement could look like for you, we'd love to hear where you're at and see if we can help.
📬 From the inbox
We started taking reader questions a few weeks ago, and this is the first one we're answering! It came from Janice, an IC designer watching their role change faster than the reviews meant to measure it.
How are design leaders thinking about AI when evaluating their design teams? What type of performance metrics are designers now evaluated against? To take it even further, how are or should the interview processes be changing with AI (on both recruiting and interviewee side)? How should we as individual ICs be evaluating and measuring ourselves moving forward?
You've put your finger on it: the work changed faster than anyone's way of measuring it, and we're hearing it from designers all the time. These tools moved into daily workflows fast, and few companies have caught up on how they review, pay, or hire the people using them. So when your review feels like it's grading a version of your job that stopped existing months ago, you're right to trust that read. The way we think about it is that you're caught in a lag: the gap that opens up when the work moves faster than the systems built to measure it. Your role got rewritten over the past year, and the rubric it's held against is still describing the one you had before. That friction is the lag, and just about everyone in the field is feeling some version of it right now.
There's a lot tangled up in there, so let me take it a piece at a time.
Start with how leaders are thinking, because from the inside it feels scarier than it actually is. If anything, the bar on quality went up when the tools arrived. When anyone can generate something passable, the rare skill becomes knowing which version is right, and why. Most managers we've talked to treat AI work the way they'd treat a junior's, something to check and push on rather than ship as it comes. So what a lot of managers are weighing is your taste, whether it holds up on the work the tools can't finish. Volume stopped being the hard part a while ago, which is wild when you think about how much of this job used to be output.
From where we sit, the measures are where the lag bites hardest. Most formal rubrics still count a kind of output that's become cheap, and barely anyone has bothered to rewrite them yet. The measure that does survive is an old one: you tie your work to an outcome you can name, the change it made for the people using the product and the reason your decision drove it. That was the right thing to be judged on before AI, and it's the one still standing. It's just harder to put on a form, which is part of why the forms haven't moved. Go figure.
Interviews are changing faster than the review templates. The questions are moving toward what you bring that the model doesn't, and how you'd carry a team through a year like this one. Some places now let you use AI in the room, so walking in as though you don't touch it would read as strange.
If you're showing a portfolio, expect more interest in work you made with AI, and expect the conversation to be about your decisions rather than the surface. The tools can make thin work look finished, so what sets you apart is being able to say why you made each call. If you ever end up on the hiring side, the same thing holds in reverse. Letting people use AI changes nothing unless you also change what you ask them.
The part you control most is how you measure yourself, so I'd start there rather than wait around for someone to hand you a new one. Keep it plain. Can you defend a decision instead of only producing options? Can you point to what actually changed because of your work? The one I'd watch hardest is whether your taste is sharpening as you lean on these tools, or whether you're handing over the choosing along with the making.
If you want the numbers behind any of this, the Designer Fund and Foundation Capital report from this year is the most grounded thing out there. The headline is simpler than the survey, though. The work changed and the measures didn't, and the people doing well in the gap are the ones setting their own measures first.
None of this makes the next review feel fair, and I'm not going to pretend it does. But it tells you which parts are about you and which are just the lag.
In case you missed it
Joey was a guest on the Code & Pixels podcast this week with Adekunle and Kelly, two UX engineers who spend their days right where design meets code. They covered a fair bit of what's in this issue: that low hum of feeling behind, where AI actually fits into a designer's day, and the long, slightly winding road from his first design job to starting Baseline. Check it out below!
Thanks for reading, and see you next week! 👋💛
