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.
Venkat Rao deeply examines the US and British versions of The Office and tries to distill a theory of management from them. Seriously, read the whole thing.
Update: The essay’s description of over-performing losers moving up to join the ranks of the clueless (if you read the essay this will make sense) reminds me of a story. There was a guy on our high school football team who wanted to come in first in every drill. If the coaches told us to take two laps around the track, he had to finish those two laps first. If the coaches had us pushing a sled, he’d push the sled the hardest. I won’t tell you what all the other players called him, but even at that early age, most people seemed to get that his effort was almost entirely misspent.
The guy wasn’t a great player, and the coaches didn’t give him any extra playing time because he practiced harder than he needed to. His extra investment in over-performing in unimportant drills didn’t make him a better football player. I wonder what he’s up to today?
Paul Graham explains on how people who make things must manage their time to maximize their productivity:
When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.
I think that the biggest sap on my own productivity is my failure to schedule my time to maximize it. I pride myself on being accessible and unperturbed by interruptions, but at the same time I think that keeps me from entering the mental state to really get things done.
Today I was thinking of disparate impact not in terms of employment law, but rather as something we’d be wise to look out for and avoid in a more general sense. In terms of employment law, disparate impact is any hiring condition that has the effect of discriminating against a protected minority without serving any essential business need, even if that discrimination is not intentional. (Disparate treatment describes intentional discrimination.)
Legal definitions aside, I’m fascinated with the idea of disparate impact. It has me wondering about it in a larger sense. For example, let’s say I manage a development team and we make most of our decisions during meetings where everyone argues their side and the person who makes the most compelling argument usually wins. Such a system privileges people who argue well in a group setting over people who may be more quiet. If decisions were discussed in email rather than in meetings, perhaps the best writer in the group would see things go their way more often.
In the future, I’m going to look out more for these types of disparate impact in organizations. What skills and personality types get an advantage even if they don’t provide any additional value to the business? Nobody is going to be busted by the EEOC for letting these kinds of situations arise, but they can make your company a bad place to work, and lower the quality of your decisions.
In business, people talk a lot about accountability. In essence, it means verifying that people do what they’re supposed to, and addressing it with them directly when they do not. There’s a big problem with accountability, though, and it’s that it’s not easy to hold people accountable. Telling someone that they’re not performing up to snuff is one of the most difficult jobs a manager has, in part because it’s uncomfortable and in part because it has to be done in such a way that it leads people to improve their performance. (Unless, of course, they’re being fired. That’s even worse.)
World of Warcraft blog runs an advice column for guild leaders, and last week’s question was from a guild leader who needs to address a performance problem with a member of his guild. The details are amusing, but what really interested me was the proposed solution — using an addon for the game called Failbot.
Here’s the description:
Add some public humiliation to your raid! FailBot reports in raid chat (or another channel of your choosing) whenever a raid member “fails.” These fails are only things that are preventable by the individual on a consistent basis, so if someone’s name pops up it was irrefutably their fault, which makes it a great way to see who in the raid needs to improve without having to personally call them out.
I’m fascinated by this tool. It makes me wonder how we might develop similar tools for software developers. Clearly automated regression testing suites are part of the answer. I’m also trying release tracking tools like Pivotal Tracker.
I wonder what the similar tools are in other fields.
A few links from the past few days.
© rc3.org. Powered by WordPress using the DePo Skinny Theme.