Last week, a clip of a Disney Imagineer Joe Rohde speaking about park design at D23 grabbed my attention. Beyond simply reinforcing how brilliant Disney is at creating an immersive experience, it immediately registered to me as a universal principle that extends well beyond creative leadership. He explained that if you effectively communicate the essence of Animal Kingdom to the park design team, “you replace yourself with the theme, and you create […] directors who can all design a chair [in a restaurant inside Animal Kingdom] with a high level of confidence that it is appropriate, so that you can set them free. I don’t care which chair it is, I only care that it’s appropriate. That’s the system that allows for tremendous autonomy and freedom in the team.”
As I thought about this and how it relates to my own engineering leadership, I was immediately brought back to something that happened with me and my team recently. Two of the engineers are working on a complete rewrite of one of our applications from the ground up, utilizing agent-first development. It’s a massive undertaking and I am serving more as an advisor than a contributor in the day-to-day direction.
As I reviewed their progress from time to time, I saw that they were using Zod as a schema writer, which is fine and well established but not my personal favorite. I heard about a potential alternative in passing but didn’t actually do my full homework. I asked the team to look into it…but then the next day, as I investigated further, I realized that it wasn’t even a viable solution for our TypeScript setup. I brought that back to the team to let them know, “Hey I was wrong. What you’re doing is fine.” I realized that what I was doing was checking their decision against my own taste instead of the end goal. In the broader scope of the project and code base, my preference was just that, a preference, and one that realistically doesn’t move the needle in any meaningful way.
Even though the team didn’t try to implement it, I wasted at least some of their time in our conversation, and perhaps even more of their time if they did spend time looking into it during that 24-hour period.
Instead, the test of the output of the team should be: does it accomplish the goal and serve the vision, regardless of the minute details of the implementation? To be clear, this sort of test doesn’t replace judgment. What it does, is it gives judgment something to check itself against.
I was able to put this into practice in a situation that happened just this week. One engineer proactively created a pull request agent skill, hooked into Teams, for the application they work on. I looked at the PR and saw that it didn’t look quite like what I would have built. But then I paused, used the “vision test”, and realized it does the job. More than that, I’m not even the one that’s going to be using it day-to-day anyway. If it works for the team, then great!
As a manager I can’t be in the room for every decision, and I shouldn’t need to be.
A clearly defined and effectively communicated business, product and technical vision (the what and the why), places the vision “theme” directly in the process instead of me. That’s the “extraordinary directive tool” Rohde was talking about, the kind that predicts good decisions before they happen instead of catching bad ones after. If that foundational step is executed correctly, I can have a high level of confidence that the line-by-line implementation of the details is going to be appropriate. That not only sets them free to be creative and work with empowering autonomy, but it also sets me free. Instead of being involved in the decision of every single minute detail, my job then becomes building the guiding “vision test” that gives them the tool to check their own work. I can focus on adding the value I bring: as the translation layer between the team and whoever owns the vision above me, as the coordinator clearing the blockers in their way, and as the cultivator of the processes and tools that let them stay focused on the how instead of the what.
At the end of the day, I really don’t care about the specific construction style of the “restaurant chair” that the individual engineer selects to place inside our application. I only care that it’s appropriate for the business, product and technical vision. And if I’ve done my job right, I can have a high level of confidence that it is.