Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
As a followup to my post on accountability I give you the full list of how I evaluate team members. It's a lengthy list but it's super important they everyone understand how they're evaluated.
Reblogged from Captain by Rank.
I'm very good at delegating - people work much better when they have a real sense of responsibility. But at the same time, I don't like surprises. I don't pore over every shoot, but I do like to be aware at all times of what's going on. - Anna Wintour
Responsibilities, we all have them. But is everyone aware of what they are? As I mentioned last week, I evaluate engineers on 3 things. I didn't go into a lot of detail because, well, there's a lot of detail and the post was already quite long. However, that detail is really, really important, so here's the followup with a lot more detail.
I evaluate everyone based on what appears to be a simple list of 3 things; productivity, quality, and communication. In reality, the set of assumptions and expectations that guide you in evaluating these areas needs to be quite detailed. This is because you evaluate everyone's performance and correspondingly decide their salary based on this list. You can't hold people accountable for something they don't know about. I'm thinking of a number between 1 and a bazillion. Can you guess what it is? Ah... you didn't guess it. Bad review for you. Don't be that boss.
With that in mind, I'm going to share my detailed list as an example. BTW I'm going to use the word reasonable a lot, which unfortunately can have a lot of interpretations. Of course the engineer in me wants to define everything out to several decimal places, but it's going to have to be a judgement call. The best I can do is say that to my mind, reasonable means the following things:
You are scheduling tasks based on a 40 hour work week. Don't overwork your team. Crunching doesn't work. Really. Truly. Expect a future rantpost on this. Seriously, there's a ton of data out there now that it's a bad idea. But I'll stop before this post spirals out of control. ;)
You are making allowance that if something is a hard problem, it's going to take longer. It's your job to know what the hard problems are to the best of your ability. When it turns out you're wrong, admit it and adjust accordingly.
You are taking experience level into account. For junior people and new hires, assume tasks will take them twice as long until you get to know their abilities.
You have communicated appropriate prioritization guidelines, so that showstopper bugs and bugs causing other team members pain are handled ASAP (assuming folks are aware of them, that's an important bit), severe bugs are handled within a few days, and all other bugs are dealt with when it makes sense.
With that in mind, here's a closer look at how I think about the categories I use for evaluation:
Quality
Are they following your standards (you have coding standards, right)?
Could someone else pick up their work and make changes or fix bugs in a reasonable amount of time? In other words, is their code clean and easy to understand?
Does their code have good performance or does it execute more slowly than it should? If it is slow, is it because they're written inefficient code or is it because the system is being overtaxed? If it's inefficient, help them get the tools and knowledge needed to fix it.
Everyone creates bugs. But do they have significantly higher bug counts than everyone else? If so, find out why. Are they not getting the support they need? Are they working from unclear specs? Or is their code just really buggy? If it is, help them improve their coding/testing process so they can write fewer bugs, and catch more of those they do create before they check them in.
Productivity
Do they stay on task? Speaking personally, it is very easy to become distracted by non-work related things. Sometimes everyone needs a little break to allow their brain to re-frame a problem. However, there needs to be a good balance between cogitating and screwing around.
Are they putting in the the minimum amount of work they feel is required or are they picking up new tasks when they finish ahead a schedule? Be sure to see above about the 40 hour work week.
Are they staying on top of their bug count? It's a nice fantasy to assume that all bugs will be fixed before anything else. In the real world that doesn't always make sense. But it's important that their bugs are dealt with in a reasonable amount of time, and they don't allow too many bugs to accumulate. When that happens, you pay for it later.
Are they doing a good job of prioritizing tasks? This is especially important when they have multiple tasks for the current milestone. Very rarely does someone just have a single task that they're working on for a long period of time, so it is necessary for everyone to be able to prioritize more important tasks first. If they aren't, make sure they have all the necessary information. The onus is on you, their manager, to keep them well informed so they can make good prioritization decisions.
Communication
Are they supporting other team members by making a comfortable environment to ask questions? Are they answering questions promptly? Make sure everyone is participating as a team member.
Are they asking for help when they need it? If not, find out why not. Do they not feel comfortable asking or are other team members not supporting them? Find out and address the issue.
Are they asking for help in a reasonable amount of time? A simple metric I use is, don't spin your wheels for more than 2 hours. If you're still stuck after 2 hours, ask.
Are they letting appropriate parties know when there are issues? For example, when a task is taking longer than expected, is production and their lead aware of it? What about the people who are dependent on the feature? This is especially important when there are dependencies.
Are they letting appropriate parties know when a task is finished? If design is waiting on a particular feature, they need to know as soon as it is available. Don't let finished features be dropped when they're done. There needs to be a positive hand off when a task is completed.
Are they creating a comfortable environment where people enjoy collaborating with them?
Leads are evaluated on the same things but with extra features. Everyone loves extra features. ;) Basically, as a lead you are not only responsible for all of the above, you're also responsible for representing the team for each of these criteria:
Quality of work
Are you monitoring the quality of work that your team is doing? Make sure you are doing regular code reviews and checking that your team is hitting the quality bar.
Are you monitoring the stability of your team's work? Make sure bugs counts are reasonable and staying under control.
Productivity
Is everyone on your team staying on task and completing tasks in a reasonable amount of time?
Do you have a rough idea as to how feature completion is trending for your team? Do you know if you are behind, ahead, doing OK?
Are you representing your team and making sure that everyone has a reasonable amount of work and clear requirements for their tasks? If not, work on adjusting the schedule and getting them more information.
Communication
Are you always available to talk? "I'm too busy" is never an appropriate response to "I need to talk to you." I can't stress this enough. Make the time. It's one of the single most important aspects of being a lead in my opinion.
Are you giving regular feedback? You should be doing this every two weeks at a minimum, both when things are good and when there are accountability issues.
Are you raising red flags when tasks get behind schedule? If something is going to slip, the sooner everyone knows about it the better. That way, schedules and expectations can be adjusted accordingly. Like Miss Wintour says, no one likes surprises.
Are you clearly communicating goals and responsibilities to your team? Make sure they are clear what their tasks and priorities are, and what their responsibilities are.
Are you fostering career growth? Make sure your team members have challenging work and are getting the support they need.
Do you know your team members' strengths and interests and assign work accordingly? Have a good grasp of everyone's experience levels and set reasonable expectations based on that. This means give people challenging tasks and scheduling appropriately. My feeling is that you should always be challenging people with harder problems. Even though in the short term it might take someone longer, long term they will be happier and they will grow. This also means that you need to communicate your expectations, especially with junior people.
There you have it! A "simple" list. ;) Joking aside, it's really important that you have a list like this, and that everyone on your team is aware of what's on it. Most people usually don't like playing guessing games, especially when it comes to their career, and this goes a long way to clarifying expectations. Feel free to take this list and use it directly, or make your own list; every company and team has different goals and responsibilities. Until next time.
Agree or disagree with anything I’ve said? Questions? Let me know in the comments below or via Twitter, Facebook or email contact at captainbyrank dot com.
Cheers,
Shaun
Read more about:
Featured BlogsYou May Also Like
