My philosophies
Notes to myself, written down so I stop trusting memory: the principles I’ve actually used, not the ones that sound good in an interview. One idea sits under all of them. People have a limited daily budget of good decisions, and my job is to keep that budget off the boilerplate and spend it on the few decisions and conversations that genuinely need a human.
Systems > Discipline
If a team has to rely on willpower to do the right thing every time, I’ve built the wrong system. Discipline runs out, and decision fatigue spends the same budget that hard problems need. So I’d rather fix the environment once than ask people to be disciplined forever.
A concrete one. Designers on my team wrote their own Lua to drive game and character logic. Smart people, but some of the code was getting out of hand: heavy loops, no review. I didn’t ask them to write cleaner code. I changed the path instead. They keep writing Lua (autonomy), but a commit needs a programmer’s sign-off (within scope). Inefficient loops dropped sharply, and the review surface kept catching spots where a single new C++ API call would make a whole class of Lua cheaper.
The designers didn’t love being slowed down. What sold it was the trade: in exchange for the gate, performance stopped being their problem and moved to the engineers. That’s the rule under the rule. A good constraint does more than say no. It gives something back for what it takes.
Back to the sixEnd every status report with three questions
When someone finishes telling me where their work stands, I ask the same three things. Are you blocked? Are you delayed? Are you confused about the requirements?
I want everyone to always have work they can move on, and those three questions cover the only reasons they can’t. If the answer to all three is no, I stay out of the way. They have what they need, and stepping in would just be noise. If any one of them is yes, that’s my cue: reprioritize something, set up the meeting, or clear up the requirement, so they can get back to their own work.
The questions aren’t a check on the person. They’re a check on whether the system around the person is holding them up.
Back to the sixName the elephant, never the person
Most work meetings I sit in could end early. When everyone’s repeating what we all already know, no new information is moving, and the meeting is just heat. The useful moments are the hard ones: the blocker no one’s saying, the miscommunication two people are quietly working around.
So I bring it up. There’s a method to it, and the method is the whole thing.
It’s us against the problem, never person against person. I state the problem the team is having and put everyone on the same side of it. Nobody’s in the dock.
Process problems get aired to the group. People problems never do. If the issue is a specific person rather than a situation, that’s a 1:1, in private. Calling someone out in a room doesn’t create progress, it creates a defended, shut-down room.
I find the elephant by staying close to my team, my peers, and my boss, so I feel the tension when it shows up. Nine times out of ten it’s a misunderstanding, not a real disagreement. Most engineers would rather avoid a direct confrontation than walk into one, so I stand in as the intermediary: I keep my own feelings out of it and let both sides air their context until the misunderstanding comes apart. That way nobody has to risk mixing how they feel with what’s actually wrong.
Back to the sixPut people where they’re already motivated
Three things drive good work: autonomy, mastery, and purpose. Two out of three gets someone engaged. All three gives you the best team you’ll ever work on. They don’t come from the same place, and treating them as one lever is the mistake.
Purpose comes from the organization: the mission, the product, the reason any of this matters. I keep it visible. I don’t invent a private version of it for each person.
Mastery is personal and can’t be assigned. It’s the specific kind of work that clicks for someone and the area they want to grow in. The most I can do is expose people to enough different work that they find their thing, then stay out of their way while they chase it.
Autonomy is the one I actually control, and it’s a dial, not a switch. Grant none and I’m a micromanager. Grant all of it and I’m lazy, and the team drifts. What I aim for is autonomy within scope: enough room that people feel invested and can move, inside a boundary that keeps everyone pointed the same way. A boundary set right gives something back for what it takes.
Back to the sixShow people the level above their own
For someone to level up, they have to want to see the meaning one level above their work. For an IC, that’s how their work affects the team. For a lead, how the team’s work affects the studio. For a studio director, how the studio advances the organization’s goals.
That wider view does two things. It’s how a person grows into the next level before they’re in it. And it surfaces options that would otherwise go unseen: when a technical or artistic developer knows what a feature is actually for, they can propose alternatives only their discipline would think of. A cheaper path, a better effect, a different shape of the same outcome.
The person closest to the craft often holds the best idea. They can only offer it once they can see the goal from above.
Back to the sixMake my team so elite they don’t need me
I want everyone on my team to level up into high-level seniors who can run autonomously. That means every raise, promotion, and bonus I can advocate for, I do. I want them to have all of it.
I’m honest about the selfish half. A team of autonomous seniors is a team I barely have to maintain, and every hour I’m not spending holding the existing system together is an hour I can put into making it better. The generous goal and the selfish one run the same direction: the more my people grow, the less my job is maintenance and the more it’s improvement.
Back to the six