Though your results will likely be quite different than described above.

Authority.

Now, that’s not hierarchy, and it’s not imposed structure, or any of those things. When I say “authority,” I mean the authority that comes from below. I believe it was on this blog that I first read that definition of authority, and it’s been incredibly useful in trying to figure out what’s wrong with the company.

We have a lot of *authoritarian* upper management. Their style is “Do this *because I said so and I’m in fucking charge*.” The problem is, of course, that no one trusts them, no one believes what they’re saying, there is a LOT of speculation about their ulterior motives because they’ve historically doled out information to suit their ulterior motives already.

A lot of that comes from fear. As many people have already said, you get promoted to your level of incompetence. Well, our project leads (with the exception of a small few) are basically at that point. They’re in over their head, and they snap back to this reflexive “fuck you, I’m in charge” attitude to protect themselves from having their decisions questioned.

I ended up talking to one of the guys the other day (the get out of my head day), and the crux of the conversation was that his problem with the team was that he had no authority. His authoritarian attitude prevented anyone from ever developing that trust in him, and his stubborn inability to have a discussion or admit he was wrong about a decision was driving the team to chaos.

As a designer, I’m responsible for setting a LOT of gears in motion. At any time, dozens of people are working full-time to enact plans that I *hope* will turn into something reasonable. I have to make plans, in the void of any sort of certainty, based on speculation, research, discussion, and hope. I’m often wrong.

When an engineer’s spent two weeks developing a feature based on a spec I wrote, and it turns out for various reasons to not function correctly, I don’t stubbornly stick with it. I don’t not admit I’m wrong, and I don’t ever ever ever tell the engineer it’s their fault (unless it really is). I go to them, tell them why I was mistaken, how we can take a step towards fixing it, and see where we go from there.

This isn’t a problem for a a couple reasons: 1.) While developing the original spec, I sought their input and feedback as often as was appropriate. 2.) I treated them as a partner in the project, not as a peon.

Without those things, going to them later and discussing that the system didn’t work would engender frustration and misery – I would have handed down some document from on high and demanded them to do this come hell or high water. When it didn’t work, it would be my fault. They did their job properly, I fucked up.

With those things, going to them later and discussing that *our* system didn’t work the way we thought it would is easy. We can sit down and analyze the mechanics of the system, how it’s different from how we imagined it might be, and what kinds of solutions we can implement so that the next iteration is stronger.

The next time I have to work with the same person, they can trust me because they know my methodology, know that I’m honest, know that I value their input, and know that I’m willing to bust my ass and ignore my ego to make sure that we’re making the best thing we can.

I believe this has borne out in practice. At this company, I’ve been on three projects at various times, and *every time*, the project has ended up as the one everyone’s *wanted* to work on most, and the one that’s generated the most “buzz” at the company. I’d love to take credit for that because my design ideas are incredibly awesome, but even if that’s partially the case, maybe (I hope), the bigger part of it is that I work in a way that gets the team invested in the game as their own, and gets them excited about the ideas in the game as if they were their own. In many cases, even if I came up with the seed, the plant belongs to the team, and is totally different than what the seed might have grown into if I’d tried to grow the plant myself. Better, in every case.

So, yeah. The ability to get people working together, to trust in you that you know what you’re doing, to be open and honest in your communication, to know that there aren’t ulterior motives behind what you’re doing, and to simply believe in you.

Authority.

“I’ve written several posts about the importance of feedback, but I hadn’t thought about how feedback as a social technology embodies the “learn and latch” pattern. The general process of feedback is to let somebody do something, and then offer them feedback on how they did and what they could do better. They learn from the feedback, try again, and latch the new behavior.”

This is one thing that’s really interesting to me. I want feedback. I want it as fast and as thoroughly as you can possibly give it to me, but if I had to choose one, I’d choose fast over thorough.

For me, I feel like I can do a very general “sweep” of a concept quickly, but drilling down into it means more investment of time on my part. I want to make sure the general stage of the process is *good* before making that further investment. So, once I’ve got the basics outlined/written, I’ll almost always ask for feedback.

Problem is, I rarely get it. When I do, my style of working is to iterate very quickly, write down stuff *even if it’s not 100%*, and rely on iterations to weed out stuff that’s wrong, and strengthen the stuff that’s right.

Without feedback, that iterative style is pointless.

Still, in a field like videogame design, I don’t think there’s a better method that rapid iteration to get to a goal. There are few “right” solutions, and if you wait ’till you “know” something, you’ll never get anywhere. You have to guess, you have to speculate, and then send those speculations out into the world. The more people give you feedback on your imaginary direction, the better job you can do. You can at least know whether you’re communicating your ideas clearly.

But in addition to few people regularly giving me feedback, almost no one else *requests* it. This is strange to me, because it implies their fundamental approach is very, very different.

More later.

Welcome to management my friend.