nullstream weblog - Virtual Fridays

« Linux Source Code Browsing | Cell Phone Nation »

Virtual Fridays


March 4, 2007 01:07 AM PST

Weekly meetings: the bane of productive engineers everywhere. They are doubly brutal when held on Monday mornings. There is nothing like a Monday morning weekly meeting to suck the energy out of the start of the work week. You know the drill: file into the conference room, every one taking their usual seat while trying to avoid sitting next to the guy with intense coffee breath or who farts too much.

working for the weekend

Two blissful days of waking up late, late night beers, lazy Saturday afternoon cappuccinos, concerts, gaming and other stuff have clouded your mind and now you have to remember all the details of what you did last week so that when it's your turn to speak, after going around the room listening to others drone on about their work week, you too can drone on for a few minutes about how important, how innovative, how mission critical your work is so that you can convince your smarmy manager that you're too valuable to layoff when it inevitably happens.

I think that some managers purposely schedule these weekly meetings for Mondays to take advantage of an engineer's altruism and loyalty. They assign tasks to be completed on a Friday knowing that in the planning of software, schedules tend to slip. If you can't get it done by Friday night, engineers will tend, out of professional pride or fear of losing their job, to work on the weekend to complete the assignment.

creative accounting

Tasks that are to be completed on Friday, but not reported until Monday, get two more days of unaccounted labour on the weekend: a virtual Friday.

This is a terrible practice since without rest, people slowly burn out, their productivity decreases and their resentment increases. My solution is to eliminate the weekly status meeting, and thus, the pressure to work weekends. Instead, teams should use weekly snippets, short technical meetings, tech talks, and collaborative scheduling.


Each engineer creates a point form summary of their work for the week, listing things like bugs fixed, documents written, interviews conducted, code written, problems encountered. This list is emailed to the team every Monday morning and cc'd to a searchable archive, so that you can track your progress over time. No more going around the room, in some nightmarish O(n) algorithm of boredom, listening to each person speak, in tedious detail, of their progress for the previous week. With a proper archive, you can subscribe to a person's or team's snippets to keep up to date with interesting projects.

technical meetings

The only meetings that should happen are those between a small group of engineers working on a specific task, and the meeting should have a specific outcome: "how to integrate Windows IO Completion into a cross platform networking stack", "what is the format of the config file", etc. These are things that most managers won't be able to contribute to, so they won't be tempted to attend and waste time. Engineers can go to several relevant meetings per week, since outcome of each meeting results in progress. Almost all of these meetings can occur at an engineer's desk and whiteboard, or over lunch with no formal scheduling required. The key is to keep the attendee list small so that only the necessary people are there, and the topic technical, so that managers can't interfere.

Policy decisions, like "should we open source the code", can be kicked up to a higher a level so that engineers don't necessarily have to attend, except to give their technical opinion much like the testimony of an expert in court. Luckily, those sorts of meetings are rare.

tech talks

If your company is large enough, groups may become disconnected without some kind of regular update. Tech talks can bridge this gap. Each group can hold a presentation with a question and answer session, and team members can take turns presenting. Video taping and archiving is useful for later training of new employees. No more than one tech talk per week though, and some kind of tasty snacks should served. Donuts seem to have a magical attraction for engineers (seriously, what is up with that?), but a company with class, or VC funding, will have a catered lunch to encourage attendance.

collaborative scheduling

When you cancel the weekly group status meeting, you'll still need to track the progress of the group. This is where managers can earn their keep: they can spend a few minutes with each engineer on their team to update whatever project tracking tool they are using. Collaborative, online spreadsheets are really useful for this but Microsoft Project will probably work as well. Managers can do task load balancing offline. This should all be done late in the week, preferably Friday afternoons, so that the technical issues are fresh in everyone's mind and no one feels like they have to work on the weekend in order to boost their progress for Monday.

lessons applied

My current team uses all of these ideas, and I feel much more productive because of it. Back in my undergraduate days, the faculty of engineering had as their slogan "ERTW", which means Engineers Rule The World. Well, we may not Rule it, but through the incredible reach of modern software, we certainly Run it, and any company that wants to attract the best of us, and thus create the best software, has to realize that. Eliminating the irritating, grinding parts of an engineer's work week goes a long way toward making that happen.

Comments (2)
J, March 4, 2007 10:46 AM:

Nice post... great read. I like the idea of archiving and sharing the task lists, schedules, tech talks. Middle management sure does figure out how to get in the way, don't they.

Sniffy, March 5, 2007 09:39 AM:

Our team does most of what you prescribe. It's couched in what is described as Scrum.

All links will be marked with the nofollow tag, making them useless for search rankings. Any posts containing spam URLs will then be deleted.