Steve Balmer's performance review, and ours
Larry White argues with the idea that performance reviews are even a good idea. I tend to think that they are useless at best and destructive at worst. Good management involves giving constant feedback all year, not bundling it all up for one incredibly awkward process that takes pace annually.
Interestingly, however, there is one last bastion of economic activity that proved remarkably resistant to the triumph of the market: firms, companies and, later, corporations. Think about it: market-societies, or capitalism, are synonymous with firms, companies, corporations. And yet, quite paradoxically, firms can be thought of as market-free zones. Within their realm, firms (like societies) allocate scarce resources (between different productive activities and processes). Nevertheless they do so by means of some non-price, more often than not hierarchical, mechanism!
An observation by Yanis Varoufakis that has often struck me as well.
Yanis Varoufakis, Valve’s in-house economist, analyzes Valve’s non-management structure. Here’s a link to my earlier post on Valve’s approach to management.
Today I was sort of idly thinking about the difference between a manager and a team leader. I suppose these terms mean different things in different organizations, but I think it makes sense to propose general definitions that clarify a somewhat hazy topic. We’ll assume that in both cases, the members of the team report to the manager or team leader, at least for the duration of the project that they’re working on. (If you work at a place where people have a manager and a team leader and the responsibilities are divided, all bets are off.)
Both are accountable for the overall performance of the team. If the team fails to meet its goals or is dysfunctional, that’s on the person who’s running the team, regardless of their title. I strongly prefer to think about these responsibilities in terms of accountability rather than authority for the reasons I talked about in my post about judgement and influence. I think that teams function most effectively when the members buy into the team goals individually because they see the value in them, rather than because somebody told them to do something.
So the difference is that a team leader should be thought of as the senior practitioner on the team whereas for a manager that may not be the case. If you’re the team leader of a team of developers, you should probably be the best developer on the team, and the other members of the team should respect your technical capabilities. If you’re the manager of a team of programmers, that’s not necessarily the case. A manager may be a fine programmer, but their core responsibility is management and coordination, not necessarily bringing an authoritative voice when it comes to making technical decisions.
The difference matters in terms of setting the expectations of the members of the team. It’s a dangerous thing when the members of a team think of the person running the team as a manager but they think of themselves as a team leader. Or if the team members have a manager they expect to be a team leader but who isn’t equipped to function in that role.
I’d be curious to know what other people think about these definitions. I haven’t heard of the two titles being defined this way before, but they match with my expectations based on my experience. I think that as an industry, it might pay off to formalize them.
I’m just going to keep posting stuff about Valve until I get tired of it.
Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.
Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.
What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.
If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.
At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.
Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.
For a long time, I was shocked by blogs like Etsy’s engineering blog, Code as Craft. I had a sort of old-school “information is power” mentality that led me to believe that letting competitors know about your technology stack would put a company at a disadvantage. Building scalable systems is hard, and I thought it was foolish to give away your secrets. I also prided myself on being able to sleuth the details of a company’s technology stack using URLs, HTTP headers, and page source.
I have long since come around to the opposite point of view, but general attitudes about this stuff hasn’t changed much once you get past the most progressive organizations. Stephen O’Grady explains to the recalcitrant why hiding your technology stack is a bad idea.
The other day I said on Twitter that all problems are user experience problems, except for scaling. And the solutions to those problems are generally so complex and so specific to a company’s product, staff, customers, and existing code base that slavishly copying one’s competitors at meaningful levels isn’t really possible. At most, what you usually get is an idea of what to try next, or issues you may run into down the road.
The advantages of sharing are real, and the disadvantages are an illusion. Go forth and start an engineering blog.
Today I was talking to a friend about his job. He said his company had just had a meeting where the management told his team that they were not satisfied with the overall sense of urgency and that the team needs to be getting things done more quickly. Reading between the lines, it was clear that what the manager meant was that the team needed to be putting in more hours.
Working more than forty hours a week is hardly outside the norm in software development, but directly demanding more hours from people is a bad idea for a number of reasons. I won’t get into basic issues of justice and decency and instead focus only on effectiveness. Even if your only goal is to get things done as quickly as possible, demanding that your team work more as a group is still a bad idea.
The first issue is morale. Members of the team will not readily accept “work more hours” as a possible solution to any problem if other solutions that don’t require them to work more hours are apparent. If there are process changes that would make the team more productive, they’ll wonder why those aren’t being made instead. If there are underperforming members of the team, others will wonder why those team members aren’t being specifically urged to do a better job or being replaced.
And, of course, some team members will start asking themselves why they’re working at a place where the management tries to solve problems using the blunt instrument of “work more hours.” In the end, you wind up with an unhappy team that starts losing its strongest contributors to other jobs. If you do plan to go this route, understand that the team will hold you accountable for every second of their time you appear to waste, so you’d better have your ducks in a row.
The second issue is quality. This is an issue I touched on when I talked about the problem with all-nighters. When someone is working and they know they could be doing something else, whether it’s having dinner with the family, going to their kid’s soccer practice, or sleeping on the couch, chances are their focus is going to be on doing whatever it takes to finish as quickly as possible. Corners will be cut. The longer the team is working extra hours, the more technical debt you build up, which in turn makes it harder for developers to get things done, requiring even more work to maintain the same level of production. It’s a losing proposition.
The third reason not to fall back on “make them work more hours” as a strategy for increasing productivity is that it reduces the organization’s capacity to manage a crisis. For one thing, there are fewer hours to throw at unexpected problems. If your lead developer is already working on Sundays, those Sundays aren’t available when you get a surprising feature request from a big customer. If the team is already burnt out from previous death marches, they’re going to be pretty cynical when their confronted with an actual crisis. And finally, when the crisis arises, that crappy code people were writing at night when they were trying to watch Glee at the same time is going to be an impediment to solving whatever problem is at hand.
The funny thing is that on a good team, you never need to ask people to work more hours at all. If you have good people and they understand and have bought into the team’s goals, then they will do what needs to be done to ship, even when it means putting in extra hours. One way to make sure that never happens is to coerce them into working more hours.
Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.
Here’s an important article on employee motivation I saw on Hacker News:
The great majority of employees are quite enthusiastic when they start a new job. But in about 85 percent of companies, our research finds, employees’ morale sharply declines after their first six months—and continues to deteriorate for years afterward. That finding is based on surveys of about 1.2 million employees at 52 primarily Fortune 1000 companies from 2001 through 2004, conducted by Sirota Survey Intelligence (Purchase, New York).
The fault lies squarely at the feet of management—both the policies and procedures companies employ in managing their workforces and in the relationships that individual managers establish with their direct reports.
Most of the prescriptions in the article are standard management advice fare, but I think they key point is worth remembering — people are generally excited about their jobs until the realities of the situation beat it out of them. The main responsibility of managers is to help them hold onto that enthusiasm.
It just occurred to me that I’ve never had (or given) a really well executed developer-centric performance review, and it had me thinking about what should be in such a review. There are a lot of things that should be discussed in any performance review, I’m not going to go over those. I want to talk about the kinds of questions a developer and their manager probably ought to discuss at their review.
To me, the most important part of a performance review is to help the person getting the review get better at their job. It’s a chance for people to get feedback that will help them figure out which skills they need to improve and determine where they may be lacking in terms of professionalism. The second most important part of a performance review is to help the manager get as much value out of the employee as possible. Does this person work better undisturbed most of the time or regularly collaborating with others? Is this person happiest grinding away at hard problems that discourage most people? Do they like or dislike refactoring old code that could use improvement?
With that in mind, here are some questions that managers might want to discuss with developers in their performance review:
The last thing I’d add is that I think annual performance reviews are really important. In many cases where programmers manage other programmers, they tend to be ignored or handled in a cursory fashion, but I think that’s a big mistake. So if you’re a manager, do your performance reviews and put some real work into them. Your employees will benefit, even if they don’t appreciate them.
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Valve’s corporate culture makes the New York Times
Valve, a Video Game Maker With Few Rules
Valve gets a big feature in the New York Times. Unfortunately the article doesn’t really dig into discrepancies between the employee handbook and day-to-day life at the company. Maybe there aren’t very many, but it would be interesting to know.