My post before this was a kind of therapy / Buddhism / personal growth kind of deal, but I also spend a lot of time thinking about how to run effective teams and to be a responsible, thoughtful manager of people. It is my work: I am a lead engineer at Bungie, an independent video game developer of about 300 employees (though not for long, we're growing.) There are some unique aspects to making videogames, and I'll use game development terminology here as I refer to, say, texture artists or sound designers or programmers, but when I talk to friends in different creative industries - film, industrial design, other software development - I find these themes are pretty universal.

If you're going to manage people, you're going to have a lot of conversations about employee performance. It's just bound to happen. Sometimes, like during reviews, it might seem excessive. You might wonder if's worth all the time it takes. It is. It's OK that you spend a bunch of time on this. As a manager, that is your job. It's your job to have well-formed opinions about how you evaluate people and how you work with them to help them grow. If you aren't spending time on that, then you may be succeeding as a leader, but probably not as a manager. Apples and oranges.

It is, however, important to spend this time well. During conversations about performance, everything you talk about should boil down to one thing: the value they contribute to the team. What is their value, and how can they become more valuable?

I find a lot of review conversations tend to focus on strengths, weaknesses, and specific work results. These seem like reasonable topics, and there's value there, but I also find this often leads to a review that looks like this:

I like to call this the "D&D Character Sheet" model of professional evaluation. You could literally do that, if you wanted, and it would look something like this:

The D&D Character Sheet model implies that a team member's value is some kind of average of their strengths and weaknesses, maybe a weighted average because if they're really especially strong at one thing, then maybe they're a rare commodity and that's especially valuable.

This is not a good measure of their value to the team. It's not like you start a project and the challenge is to hire people until your stat bars all add up past some number and then you win. Project development isn't Voltron.

When you start a project, the challenge is there's a big set of work and you have to do it all. It includes the obvious work like actually typing code and making art assets and the like, but it also includes doing the prototypes you need to make creative and technical decisions. It includes building and tracking schedules. It includes putting out a bunch of inevitable fires. It includes all the one-on-one meetings of managers with their reports. Yes, there's wiggle room in what works ends up getting done, depending on how well you make your decisions and how responsible you are, but the vast bulk of the work is getting done or you're not shipping. Let's say the set of all that work looks like this:

Every person on your team occupies a shape on this diagram, because all this work gets done by someone. For example, if you're making a videogame that requires a bunch of textures and you hire a junior artist and he spends the project painting a bunch of those textures, his role might look like this:

His role is clear, easy to describe, and has a clean boundary. And if you have enough textures to keep 6 artists busy, that'd look like this:

Then you have an associate producer to help coordinate those artists, doing a bunch of legwork and catching things related to the texture-authoring that falls through the cracks. Maybe he looks like this:

The set of all of them makes a nice, clean space, which makes sense because they fill a clear, understood role as a team in the project.

As you get more senior, maybe you're a specialist, so your shape gets bigger and the boundary remains nice and clear. Or you end up as a lead, and you're able to fill spaces in the project and pick up slack that few others can, so your boundary gets messier:

I'm not saying you can actually draw a specific chart for any real project. This is more of a conceptual thing. But I like having this conversation because I think it gets closer than the D&D Character Sheet to the truth of employee value. We can talk about what your shape is, conceptually, and what work is nearby you that you aren't covering. We can talk about whether we should make any changes to your shape. We're all only human so over our careers our shapes don't actually grow all that much, maybe we get two or three times more productive, but what really changes is we gain the ability to do work we couldn't do before. There are areas our shapes can cover only when we become more senior. We can talk about that, too: is there work you are uniquely qualified to do that would be more valuable to the team than something you're doing now?

The shape metaphor is also useful to me when talking about dysfunction. It has helped me understand a pattern I've seen and experienced several times in my career, one that initially baffled me:

Consider Nick and his manager Gloria. (Neither of them are real people. I'm making this up.) Nick is working hard and excited about everything he's getting done. He feels like he's doing the best work of his career, cranking out tons of great stuff, going way above and beyond the call of duty. It feels great and he can't wait for reviews when Gloria will recognize all his effort and contribution.

Until one day, in one of their one-on-ones, Gloria gives Nick a thin-lipped smile and takes a deep breath and tells him that he's underperforming.

The first thing Nick feels is shock and disbelief. Underperforming? Is this really happening? Then he feels anger: anger at Gloria for not seeing things the way he does. How could she be so blind to all his hard work? Then he feels dejected that his manager's view of him is so far from his own, and then there's the wave of self-doubt: maybe his best just isn't good enough, or maybe this team will just never value his strengths and he'll have to move on. Resignation starts to set in.

Gloria is just as frustrated, because try as she might to explain what she sees as very basic responsibilities Nick is dropping, it doesn't seem to stick. All around her things are suffering because of Nick's negligence, but the message just doesn't seem to get through to him. When she suggests specifics that he could work on, Nick reacts with exasperation. To him, it seems Gloria is just piling time-consuming minutiae on top of the real, significant contributions already taking up all his time.

If this sounds familiar, that's because it happens a lot.

The root problem is that Nick has a bad shape but he doesn't know it. If Nick is junior, this is entirely Gloria's fault: it should be possible to explicitly detail out exactly what is expected from a junior employee, with no room for ambiguity.

But at higher levels, there's just too much to spell it all out. It's important to try, to define boundaries for that shape so you have some way to talk about them, but you can't capture all of it in full detail. It relies on a mutual understanding about implied work.

Some work yields knowledge that you need to do other work, and so a viable role that does one of these things must do the other. If you're in charge of writing some code, you also have to comment it, because if you don't, nobody else will understand it well enough to do it for you. If you're in charge of coming up with a creative direction for a project, you also need to communicate it outwards to others, because if you don't, nobody else knows enough to do it for you.

This is Nick's problem: he is excitedly performing an incomplete role, doing some work very well but in a way that leaves other necessary work undone that nobody else can effectively do. Nick has a bad shape.

Worse yet, Nick's colleagues and even Gloria didn't immediately realize he had a bad shape. They saw him doing some of the work in one of those circles and assumed he'd take care of the whole circle, because anything less wouldn't make sense. The sliver of the circle he wasn't doing went unnoticed for a long time, which made the damage worse. By the time Gloria caught on, it was because something was on fire.

If everyone else can see the problem, and Nick's a smart guy, how is he missing it?

These diagrams I'm drawing fundamentally express project development as a subtractive process: you start with a mountain of stuff to get done, and by the time you're done, someone will have done all of it. These diagrams visualize the abstract notion that there's "all the work" and each person subtracts some of it from the space, and you're done when everything has been subtracted.

But not all work is subtractive. Consider a factory worker assembling cars. If he assembles 2 cars in a day, he makes the company a profit; if he works harder and assembles 4 cars in a day, he makes the company twice as much. This is an additive sort of work. You can do the same work, but just more of it, and you generate more value.

Creative endeavors are not additive. They are iterative, convergent processes, and so they are subtractive: you work until you have converged, and then you stop.

Nick doesn't understand that his shape is bad because he's not thinking of his work as subtractive: he's thinking of it as additive.

I've been in Nick's shoes before. I began my career thinking of my work as additive. "I'm contributing value," I thought, "Because I'm writing them this amazing code." If they criticized me for not doing something else, it made me a bit indignant. How dare they? Didn't they realize how valuable my addition to the project was?

But it wasn't an addition. It was a subtraction, just one bit of work from the huge space of work yet to be done. I couldn't see the bigger picture. I didn't see all the work that went along naturally with my coding work. Writing that code earned me knowledge that could have given me foresight into future challenges the project would face. If I'd bothered to think about it, I could have communicated those challenges to others and helped develop solutions. It never even occurred to me to do that, but from my manager's perspective it was obvious that I should: it had to get done, and I was the only one who could do it. I didn't do it, so it didn't get done, so the project suffered.

You can't truly be a senior employee until you see your work as subtractive, and until you have an intuitive feel for the set of all the work that needs to get done. Once you think in this way, you can interact with any other leader as a peer, working elbow-to-elbow, of one mind on what needs doing. Until you think in this way, without even realizing it, you are implicitly asking for those above you to insulate you from reality, to build you a little sandbox where you can work.

Nick's situation happens all the time. I can think of two major times in my career it's happened to me, and many times more than that I've seen it happen to others. It's a tough challenge for a manager: Without extreme care, this situation ends with an offended employee carrying a lasting grudge on his way out the door and a frustrated manager left wondering why the employee just never seemed to "get it."

To all employees I'd say this: when you talk to your manager, make it a point to understand her perspective on how the project needs to come together. Ask, "What do you pay attention to?" "Where do you get your information?" "What do you think the 'pulse' of the team is - and what makes you say so?" "What are you concerned about?" "What's the lay of the land, as you see it?" "How is this all going to fit together?"

And to managers, I'd say: when you talk to your reports, help them think about their work and everyone's work as subtractive, as cutting out shapes from the big space of all work. Tell them what things are clearly theirs, and talk about those with whom they share boundaries, and what those boundaries should be. Talk about imperatives: tell them what kinds of problems you foresee and what roles you see them playing in the solutions. Talk about the whole project, even the stuff they'd never otherwise hear about - especially that stuff. Give them context. Talk about convergence. Help them see their shapes.