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.

A bit late to the party, but I had a hard time wrapping my mind around this whole "subtractive" thing. It seemed counter-intuitive. I thought about it off and on since I read this post yesterday, and finally, I'm ready to comment.

Do I see it? Yes and No. Looking at it from the perspective of a self-employed person, I need to produce products that satisfy my own aesthetic standards and also satisfy other's standards. Beyond that, I need to make sure that what I produce gets into their hands and money is exchanged. This is not subtractive at all.

OTOH, I recently hired an "employee" to handle my income and tax stuff. In that sense, yeah, he is removing a tremendous hassle for me, and he helps me stay legal. The money I pay him is well worth the time he saves me and the peace of mind I get. So my accountant is subtracting a threat from my environment.

But ultimately, no, getting products out the door and into the hands of clients is a creative process, entirely additive. Truly, I would dread being in an environment where my work was thought of as subtractive. It seems so... thin. I would just gravitate to, "I don't need this shit. I can do better than this." Maybe that's why I've never been successful at anything other than my own enterprises.

I'm not trying to be a pain. I can see how what you are saying is how large organizations work, but in general, when you look at what's coming out the doors of the factory, addition, not subtraction, is the driving engine of an enterprise.

Or maybe I'm like Nick. I just don't get it. Even so, I always like a challenge, and this post was challenging, so thanks.

Thanks for the comment, this is awesome. Here's some thoughts off the top of my head:

You're right: creative work is all about creating and so you're adding, you're bringing something new into the world that didn't exist before.

But when we do this, especially as part of a collaborative team, there is context. There's human nature to account for with your team members; there's markets to account for with the product itself. (I think you can extend this even to the most avant-garde of art: you are still producing work in the context of what came before, and it will still be seen that way, whether or not you choose to account for it. But I digress...)

There is a lot of addition in the process of development: coming up with ideas, testing them, refining them. And I'm not saying you should forcibly ignore this way of seeing things.

In another reply I talked a bit about how in videogame companies, producers and designers are kind of "natural enemies" - the designer's job is to build new things and the producer's job is to represent the realities of scheduling and having to actually ship something at some point in the future. In self-employment I think you have to embody both these personae yourself and that's an interesting balancing act for people. It is a paradox to hold these things simultaneously, because one of them is a voice that says "There's still so much to do!" and the other is a voice that says "I've gotta be done in T minus... 10... 9..." My experience is when I can hold these things simultaneously there's a kind of equanimity to it, where I am excited to make something expansive and creative and new, but also grounded in the reality that I want other people to experience it and so I must be disciplined.

So another way to say what I'm saying is that everyone, even if they're on a large team with a specific role, needs to be able to hold this paradox, and I'm saying the additive view is easy, it comes naturally. We like building things, and so that's how we see it, as building.

But viewing your work as "subtractive" is acknowledging the context. It's acknowledging, if I want to build this code, I also need to be responsible for its maintenance, for communicating about it to others, for accommodating the inevitable cognitive biases that people will experience in working with it. It's acknowledging, if I want to build this code, I need to make sure it's robust enough to do what it needs to do. I need to make sure the thing I'm building will be ready when it is needed. I think some of these factors are more obvious than others.

Even during the most "additive" creative phases, like total blue-sky brainstorming about new ideas and prototyping stuff, I think true professionals work to always keep in mind, this work fits into a schedule. Not in a way that creates a tension that closes their minds and reduces them to panic - see Dan Pink's work on incentives here: financial incentives can ruin creative work by forcing people into a myopic mindset about convergence - but rather in a way that makes them value every day, and say, right now my most important work is brainstorming. Maybe it's walking around outside and not consciously thinking about the creative work because that's the best way to let my brain soak on it and come up with great ideas. But it's not completely open-ended. At some point I'll have to stop this and move on, so my job now is to do whatever I need to make good decisions that let me proceed.

In all of this, the "subtractive" part is that everyone is acknowledging, we're trying to build a product. We're not a bunch of people in a room together all doing the thing we think is really cool. We have stuff to address - finances to address, emails to reply to, fires on the horizon we don't think others have seen yet so we should start ringing bells about them, etc. All of this is necessary to subtract from the remaining work so we finish this product so that we can add it to the world.

Sorry if this is a little rambly: does this make any sense?

Maybe a shorter way to say it is: because our creative output must be structured in a way that acknowledges the context it lives in, while the creative output itself may be additive, the necessary work to produce it is, to a great extent, predetermined by the form, and thus gives us a structure of necessary work that must be subtracted from before our work is complete.

Well thanks for that detailed answer. I got it at the last part; that is, when the whole thing is taken together, most aspects of "production" have little directly to do with production at all but if they do not occur, there will be no production. In that sense, they remove the barriers to production, and if looked at that way, it can be seen very clearly.

In fact, when I look at that way, as owner, operator, president, secretary, treasurer, CEO, etc of my own company, I'm also the janitor, driver, mechanic, and groundskeeper, etc. I want to make sure that the minimum time and money is spent on those things, at the same time, without that infrastructure, nothing gets done. Rent, I long ago observed but did not connect, is totally subtractive. Keeping the shop clean: subtractive. Maintaining the tools, investing in new ones...

OK. I'm seeing the examples. I'm getting it. :) If I were to try to motivate employees along this line (if I had them) I'd say, "You guys are keeping the enemy from storming the gates. I don't have to tell you how important that is."

Yes! And I think a key insight is, the additive work creates the subtractive work. For a videogame, we start out with some ideas, and we start fleshing those out into bigger and more concrete ideas, and as they rez in from thoughts to reality, that process generates a ton of work.

So it is janitorial services, paying rent, that kind of stuff. But also, when we design a videogame and say, to invent a completely trite example, "There are going to be four dudes guarding a door and you have to have this interesting interaction to get past them," you just implied in that one sentence:

- modeling and texturing four characters- a bunch of AI coding work- testing support for the scenario to make sure you verify it actually got really finished and won't come back to bite you later.- etc. (a TON of infrastructure)

And that's not all - you ALSO implied:

- ongoing coordination between the people modeling the characters and the designer using them to make sure they'll work for the scenario- someone paying attention when the designer later decides to cut the scenario from the game to let everyone else know so they don't waste more time on the assets- someone paying attention so when the art leads decide it doesn't fit in their schedule, someone has that conversation with the designer to make sure it's OK to cut, or to go talk to the art leads to try to make a case for saving it (and cutting something else, which then creates more work, etc.)

And so on.

I'd argue the subtractive work is the vast majority of the work, in terms of human-hours being put in. At least, it is in big-budget videogames. Yes, you're constantly making tons of little creative decisions, millions of them through the project, but it's almost all in the service of convergence - of driving towards a complete, shippable thing. The point where you're diverging, making completely new stuff up, is not usually very long. In different forms it might be - in smaller-budget indie games they generally spend less effort on the production and polish and more on the experimentation, and that's part of the indie game aesthetic.

But even then, even for solo artists or small teams, I think almost everything that you have to "grind through" is subtractive work, and even some of what you don't need to grind through (it's just that some subtractive work we happen to enjoy.)

It's at the point now where I so strongly view development in terms of convergence that even during the divergent periods, I still see it as part of the convergence. "Oh yeah, now's the part of the convergence where we need to diverge, because we can't converge until we do that..."

Not sure I agree with that. I think the fundamental experience of creating art is the realization that your idea is not real, that the achingly perfect thing in your head doesn't get to come into being like the immaculate conception, and actually the labor of bringing an idea into the world is the labor of reconciling concept with the messiness of reality, and that labor and the messiness, they are what's real.

It's just like romance, the achingly beautiful ideals that slowly you let go of in favor of the present moment whose sustenance is less glamorous but infinitely more satisfying because unlike the romantic fantasies, it's real.

I meant to get back to on this, but I got super busy. No, I would not try to make the full argument for Plato. It was just that the example you gave, the interaction with the gate guards, struck me as an example of how the whole process is driven by an idea. Thus, the case for ideas being senior to reality.

This is no longer a popular concept. Just to mention it is to get an explosion of paradox and contradictions that people have been arguing about for 2,500 years. :)

Here's a really interesting and relevant article by a guy who was an early Facebook employee - and got fired in exactly the Nick / Gloria archetype. He's writing here in hindsight admitting they were right to fire him. It's crazy how often this happens. Tech managers get badly typecast by Dilbert... in reality it's incredibly difficult and important work to get right. (I guess the Dilbert stereotype comes from the fact that, because Nick/Gloria happens all the time, it means on average we managers could stand to do a whole lot better!)

Read Next

About a week ago I woke up and got out of the RV, which I've had parked on the same street for the better part of the last five months. To my surprise there was ANOTHER RV in front of mine. It was a lot older, but about the same size.

I got a lot of feedback that the post on role shapes was useful to people, but it's only one metaphor, and no metaphor is complete. The subtractive way of thinking about work simplifies away many aspects of development: it ignores the way the needed work can change and morph over time, it ignores the way that good decisions in one area can change the work in another, and it postulates a "set of all work" as though it's a knowable thing. Other than trivially simple projects, the set of all work is not something you can just write down with confidence. A huge part of the challenge of running a project is the skill of sussing out what needs to be done in the first place, and reconciling world views between teammates so you can have productive conversations about the work.

When I think about this what comes to mind is a city. The city has development that needs doing, and also ongoing maintenance. Fires happen, bridges collapse, stuff like that. Your job, your whole team, is to array yourselves around the city to get the work done. How do you lay yourselves out?

Every place you can stand in the city involves a tradeoff between direct agency and line of sight. By "direct agency" I mean the ability to actually do things, like fix broken water mains or build a garage or pave a road. By "line of sight" I mean the set of all things you can see from where you're standing, and how well you can see them

If your project is very small, then in the metaphor it's a little village. If it's really tiny maybe it's just a little shed. And maybe there's just two of you building the shed. There aren't that many perspectives you can have on a shed. You will sometimes see things differently, because you're standing on different sides of the shed, or one of you is on a ladder looking at the roof while the other is inside looking at the interior. But it's easy to reach a shared fundamental understanding. You can get blueprints and spend half an hour looking at them and agreeing on them.