I'm just a couple months shy of being seven years from my last college class. I know that this isn't a significant number to you, but it is to me: it certainly doesn't feel like I've been in the real world that long, but it does explain why, when I stop to think about it, I've learned a whole lot from the four companies I've worked for in that span. I thought I'd share a few of those lessons about what has worked and failed: both for me as a developer, and in terms of managing a development team. Some of these things may be out of your control, but you might be able to pressure management to change the things you can't.

I don't want to shame or praise any particular companies here: every company has their own style, and everyone is always striving to improve the way they work. For that reason, I don't want to say who does what poorly, or claim that Lullabot does everything right (though admittedly, the Lullabot way has worked best for me). But, just to give you a sense of where I'm coming from, I will say that I have worked in variety of environments: a team devoted to the company's product (a web app), an agency that built Drupal sites for a variety of clients, a company that built Drupal sites and an installation profile for non-profits, and now, at a consulting company where I'm mostly building client sites. For the past two and a half years, I've worked remotely for mostly-virtual companies, so some of my lessons learned are specific to working on a distributed team.

First, some all-purpose lessons:

Keep standups focused on one project.

I've done some varietal of scrums in every company I've worked for, and at most, we had a daily standup call or meeting with everyone from the team or department.

This does not work.

When any one person is giving their update in a meeting like this, it's likely that half of the other people aren't on the same projects…which means they space out. It's not a good use of anyone's time. If the team is working on more than one project, have a standup meeting for each to keep them focused.

During standups, focus on the updates and punt any questions or discussion.

If you've ever been the last in a list of people giving their updates, without someone to keep everyone else on point, chances are good that you are occasionally knee deep in another project by the time the conversation got around to you. People tend to mention problems they've run into, and others may chime in with ideas or questions, and before you know it the standup has turned into a twenty-minute conversation about LESS vs. SASS.

Again, this wastes time. During a standup, have everyone do their update—what did you do, what are you going to do, what's blocking you—and if there's any part of it that requires discussion, make a note to address it at the end of the meeting. There's no reason for everyone else to wait around while two people hash out the implementation plan for some feature that no one else will touch.

Take your lunch break.

And not at your desk! You need to get away from the computer for a bit. I know it's pretty standard in most companies for everyone to grab a quick lunch and keep working while they eat, but that just leaves you at the end of the day exhausted and feeling like you haven't taken a break in nine hours…because you haven't.

If you work at the kind of company where you'll get a judgemental glance for having the audacity to step away from your work for a bit, I know a lot of great companies that are hiring. (Confession: I'm really bad at this one. Working from home makes it REALLY easy to make a sandwich and go right back to my desk with it.)

Spend the money on tools the team needs.

Make sure your team has a Github account with plenty of available private repositories. Subscribe to a time-tracking service. Get the more expensive hosting account when you're pushing the limits of what you've got. If you try to cut corners, it will bite you in the ass.

I worked for one company that didn't want to pay for more private repos on Github, so all of our clients were in separate branches in a single repository. Needless to say, this was a real pain to manage, cloning the repo took forever because it included a ton of stuff, and we couldn't really keep track of feature or bug branches so we just didn't use them.

Another time, management wanted the development team to manage the disk space on the development server, and get rid of dev sites that weren't absolutely necessary anymore. When asked to justify the greater expense of more disk on the VPS host, we had to explain that it would be cheaper to upgrade that account than to pay us for the time it would take to manage old files. Keep in mind that labor is a real cost, and trying to save money by using a manual process might do just the opposite.

Handle team assignments on a weekly basis.

On any given week, I know how my time should be distributed among projects. In previous positions, time has been doled out a month at a time. I for one find it difficult to determine where to focus my time if I'm given a few projects for the month and told to spend, say, 20% of my time on the first, and 40% each on the second and third. On any given morning, then, I need to review my time logged for the month so far and do some math just to figure out how I should spend my day.

Furthermore, things change more quickly than that: co-workers take last-minute trips for family matters or miss a week due to illness, or you get pulled onto a project that's behind schedule, or another client comes in with a small-but-critical project that needs a week of your time. By the end of any given month, the plan that you start with looks nothing like reality any more.

Having a weekly plan for project assignments and the amount of time for each ensures that everyone knows where their focus should be, while allowing for those last-minute problems that would completely scrap any longer-term plans.

For distributed teams:

Setup an IRC channel for everyone in the company.

IRC is free and there are plenty of free apps to use it. Setup a channel for the company, so people have an easy way to ask questions or chit-chat. And this really should be used by the entire company: at one employer, the developers had a Skype chat room that a couple of the PMs joined, but it really just meant that the couple of people in the company who were not using it missed out on all the in-jokes.

Setup IRC channels for each project.

This is a complement to the "individual scrum meetings per project" tip above: keep all chatter about a particular project confined to people involved in that project. You can even invite the client to join this channel, which is handy for getting answers to quick questions. Actually, this one isn't even specific to distributed teams, but it makes a much bigger difference for teams that aren't all in the same office.

Get a Yammer account.

I wasn't sold on Yammer at first, but have come to love it here at Lullabot as a way to keep up with co-workers. It's basically like Facebook but for a small group. I've talked to people who have used Yammer at larger organizations and hate it, and I can see how having too many people on there would skew the signal-to-noise ratio; I don't know how many people is too many, except that it's more-than-all-Lullabots.

With everyone at Lullabot on there, we get much greater insight into what everyone is working on, and a lot of personality that we wouldn't see otherwise: we post photos from our weekend excursions, share links to funny stories, and just generally get that social aspect that can be so hard to find in a virtual company.

And finally, for absolutely everybody:

If you're working on Saturdays, you're doing something wrong.

Or, more likely, someone above you is doing something wrong. Having too much work is generally considered to be better than having not enough work, but if you have to work on weekends more than once in a while, there has been a failure in the planning process. You've probably bitten off more than you can chew, and we've seen time and again that adding more man-hours to a project doesn't get it done any quicker. Life is too short to spend every weekend working, especially if you're so burnt out that you're not doing good work anyway.

These tips won't necessarily work for every team. For example, doing a standup meeting for every project will probably take way too much time if everyone is working on a dozen different projects…though you've probably got bigger problems if everyone is trying to keep track of a dozen projects.

Similarly, I mentioned time tracking and Github, but no tool is going to be right for everyone. We use Freckle for time tracking, but I've also been happy with Harvest (which has more features and mobile apps, but also costs more). We use Github for all our code repositories (and increasingly, for project management), but some teams need to use SVN or CVS or need to keep all their code on local servers behind a firewall; for those teams, some other code repository solution will be necessary.

As I mentioned at the beginning, I'm not trying to shame or praise any particular company, but I feel that the way we do things at Lullabot right now definitely works better for me than anywhere else I've worked. That said, we're always interested in improving any process or tool that we may use. What works where you work? What didn't work at your last job? How would you improve on the tips I outlined above?

And, if your current employer comes down on the wrong side of too many of my points above, maybe it's time to consider something new :-)

Published in

Brock Boland

Thumbnail
Brock Boland a former Senior Developer at Lullabot.