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.
How to make it as the new developer on a team
I’ve recently had the opportunity to both be the new person on a team and to integrate new team members onto a team that I had been a part of for a long time. Having seen it from both sides, I have some thoughts on how to join a new team without driving everyone crazy. It doesn’t matter how you became a member of the new team, everybody starts in the same place, which is to say, not really knowing the code base or the culture of the team. Learning to mesh well with the culture of a new team is almost certainly more difficult than learning to work in a new code base.
The first thing you have to do when you join a new team is check your ego at the door. It doesn’t matter how experienced you are or how many great ideas you have. At the beginning, your job is to be a sponge and learn as much as you possibly can. Just shut up and listen. Read anything you can get ahold of. Eavesdrop when other people are talking about the project. At the beginning, think of yourself as a spy — gathering as much information as you can without drawing too much attention to yourself. I even try to make it a point to try to figure out the answers to questions myself before I ask someone. The digging involved can be very educational, and showing some level of self-sufficiency will garner respect, at least until you make a big mistake that could have been avoided by asking a few simple questions.
One question I try to avoid until I get to the point of saying “our code” rather than “your code” is “Why?” Figuring out why things are done a certain way is important, but “Why?” is a question that can very easily come across as critical, especially when it comes from someone who’s not really trusted. The truth is that the stuff that makes you want to ask why often really is worthy of criticism. Just let it go until fixing it is as much your responsibility as it is anyone else’s.
The second important thing is to immerse yourself in the code style and coding habits of the team you’ve joined. Everybody who’s been programming for more than a month has their own opinion on whether to put spaces inside parentheses (doing so is crazy) or whether braces go at the end of the line or on the beginning of the next line. The team almost certainly has a policy on whether to use tabs or spaces when indenting. Beyond that, the team probably already has its own answers to more substantive questions about how their code is organized and how they deal with separation of concerns. At the beginning, do it all their way. If you have some ideas for improvement, propose them to the entire team once you’ve shown that you’re a team player. Coming in the door and writing code in your style rather than the team’s style is likely to infuriate at least one other member of the team. Furthermore, immersing yourself in the native culture is the best way to learn. People often have very good reasons for doing things the way that they do, and if you’re busy trying to impose your brilliant ideas on the team, you’ll never learn what those reasons are.
The third thing is to focus on service. Look for opportunities to be helpful wherever possible. The biggest mistake I ever made at a job was listening when the director of the group led us to believe that stuff other groups wanted from us was not as important as the things we were building for him. In the end, we had an unpleasantly dysfunctional workplace, and I found myself looking for another job.
The stakes are high. There are two ways things can play out, depending on the team dynamics. A new person who stomps all over the existing culture of the team will tend to be marginalized by the current members and will face a much tougher climb to build credibility. If the team feels confident in complaining to management about the new guy, they’ll in all likelihood try to get them disciplined or fired. If there’s something about the new guy that makes them seem untouchable (the usual scenario is that they were hired due to a prior relationship with the manager), then the current members of the team will leave. In the end, it all comes down to respect and you gain the respect of the team by treating the team with respect.