Do public status updates work for an engineering team?

January 30, 2012 8:54 PM

Apparently many successful software companies have processes where engineers write daily status updates that are publicly visible. Google has a system called 'Snippets' and Facebook has 'Colbert'. Any insiders want to share their experience with such reporting tools? Does anyone know of any resources that describe the pros and cons, nut and bolts of these processes?

As a technical project manager, I'm fascinated by the tools and processes used by successful software companies. This blog post from idonethis.com describes a system where engineers publicly write about the work they accomplished each day and also about work they intend to complete the next day. The big idea is that the act of writing and sharing increases accountability and ultimately, productivity. Does it really work? What's your experience as a manager or engineer been with such a process? How would it affect morale? How does it work in your team?

posted by unmodern to Technology (11 answers total)

How would it affect morale?

Destroy it. Or what do you except to happen when you take skilled professionals who work on projects that last months or years, and then demand a daily status update with potential for public shaming if they fall behind for any reason.

At the very very best developers would see it as clueless trend-hopping, a waste of time, and an insult.
posted by drjimmy11 at 9:15 PM on January 30, 2012 [3 favorites]

Any insiders want to share their experience with such reporting tools?

I cannot speak for those companies in paticular, but there apparently are several things going on:

1. Weekly/daily status reports to give some sort of accountability.
2. Public accountability of work in progress items.

Such methodology underpins widely accepted and used project mangement methodologies like Kanban, where you have a big board with tasks that get assigned to developers and get moved through different cycles. This way everyone knows what the bottleneck is. I prefer the more informal weekly/daily status updates from competent engineers, at least when I'm in the position to be leading projects. I get much more detailed reports, I can tell who is bullshitting and I don't put a bureaucratic burden on everyone. Did I mention that I, and everyone else, can tell who is bullshitting? Well, nearly everybody, but smart developers quickly hone in on the, "You are still working on that?" and will offer to help and quickly realize there's some wheel spinning going on.

Destroy it. Or what do you except to happen when you take skilled professionals who work on projects that last months or years, and then demand a daily status update with potential for public shaming if they fall behind for any reason.

I've worked (as a developer) on large civil engineering projects that took this long. Weekly and daily status reports are the norm. It helps everyone keep on task. There's no public ridiculing among professionals, in fact the opposite. Software developers seem to have an aversion to it, but in my experience the good ones love the accountability. Even the ones who aren't all-star developers but good workers love it, as I've seen natural selection of talented programmers taking the hard tasks and less skilled developers take the easier task and everyone is happy they are taking tasks they know they can get done in a target time frame they can actually hit.

Of course a lot of this comes from the top and if you constantly judge people on whether or not they're hitting their updates without regard to the technical difficulty, you'll get people who challenge themselves feeling burned. "Dreamers" also tend get burned but for every 10 people who consider themselves a high level architect, only one them actually ends up being at that level.
posted by geoff. at 9:40 PM on January 30, 2012 [1 favorite]

It sounds like a written version of the standard daily stand-up meeting in an "agile" environment. I am generally suspicious of most development methodologies, as they get in the way of programming (NSFW language), but a simple "I did this yesterday; I'm doing this today; I'm blocked on these issues" kind of centralized location for developers in lieu of a daily stand-up meeting sounds like a good thing instead of the mind numbing wastes of time that are team meetings.

Just don't add process for the sake of process. Your team should be sharing information and reviewing code already. If they're not, this isn't likely to be the silver bullet fix. If, instead, you just believe your team is not being as productive as they should/could be, the problem is likely not with your developers but with their environment or unrealistic expectations.
posted by ndfine at 9:46 PM on January 30, 2012

It (daily status updates) works where I am now and did not work well where I was before.

Before it was all about the report and the metrics being passed up to management. It was demoralizing. Here it is all about a team communicating their efforts to each other and the team leader. It is empowering.
posted by Captain Shenanigan at 9:47 PM on January 30, 2012 [5 favorites]

Did it one place, we had weekly goals that we set out on monday and reported progress on friday. We emailed in a basic list on monday then friday we went over where we were with the team. It was no big deal. The goal wasn't to shame anyone or put anyone on the spot. It just establishes a momentum and gives people to speak to unexpected blocks or ask for help on something. More a team bonding experience to discuss stuff than a shame session.

Now I am at a place with a daily standup where, in theory, we are only supposed to discuss blocks but it has turned into a daily status meeting. It is useful if only for the fact that you can give someone a heads up if you are going to have to pull someone in on a problem. This is more "official" and less bull session because senior management sits in sometimes.

We also use a agile planning app, we set down an esitimate and are supposed to update it religiously with 15 minute blocks. I find that to be a pain, but it keeps senior management from asking for constant status updates.

All in all, my experiences have been good.
posted by Ad hominem at 9:50 PM on January 30, 2012 [1 favorite]

I've used something like this, on a weekly basis. I think daily would be too much. It's not a bad system, especially compared to the alternatives (cough, daily standups). Most people never look at them. Lots of people never do them. There is little to no pressure on any team I know of to stay terribly up to date on them. I can't think of a situation when I needed to look at anyone else's. On teams without autocratic management (ie, 95% of teams) they are very, very optional and most people forget them once every few weeks. I think I did mine once for all of December because my reminder is on Mondays and I missed a lot of Mondays. That is about how important they are, and I think that's key to why they're awesome.

The trick is that we are more commonly held accountable on a *quarterly* basis for what we finish, so it's helpful to have at the end of the quarter so you can remember "Oh, I meant to do this or that, but I got derailed by fighting this fire and it didn't happen." Sometimes those fires aren't so easy to remember on the spot. So that's the incentive to stay up to date; you do eventually have to account for what you were doing for the last 3 months, and writing it down every week makes that process a lot lighter-weight.

I feel like it only really increases my productivity when I am being pathologically unproductive. If I look back at a week and can't think of a single thing I accomplished that's worth writing down, I know I need to get my shit together. On the other hand, if I look back at a week where I took care of a ton of awesome stuff, that does feel really good. This is why I think a daily one would be too much; as a software engineer working in a large codebase there are just days where all you do is investigate a hard-to-trigger bug, or refactor some crap that needs refactoring, or your machine gets out of line and you have to do maintenance, or your datacenter bursts into flames and you spend the whole day yelling at the datacenter guys. I think those days would be extra depressing if you just had to write down "Figured out why job x was running out of heap memory and it's because I'm a moron and this took me all day."

For a while I worked someplace that didn't have them and I just kept my own in a text file for my first several months because I found the routine of thinking back to my previous week and carrying over my unfinished todos to be comforting. It helped me get past that Monday morning sense of "Hold the phone, what's my job again?" So I guess that's an endorsement from me: it's a software development process I did voluntarily for more than one day. I certainly can't think of any other software process about which I can make that claim. I don't think they'd work very well if there were any kind of policing or public shaming involved, but if they're a recommended-but-voluntary way of tracking your own time I think they're pretty good.

I agree in a general sense with drjimmy11 that any process your manager makes you do and bugs you about on a regular basis is automatically crap and everyone hates it. My manager bugs me once a quarter to do my updates, which takes about half an hour working from weekly updates, and I suspect my quarterly updates would take more like 2 hours plus arbitrarily large delta for procrastination if I didn't have my weekly updates, which take me 5 minutes a week. That procrastination delta is unpredictable so I tend to just do my weekly updates.
posted by troublesome at 9:52 PM on January 30, 2012 [3 favorites]

I cringed just reading the description. However if what you're after is communication then it wouldn't be so bad. (Though who is going to read these?) If you're after a metric expect your workplace to become a seething stew of resentment. My end of day notes are usually along the lines of "Bug in calibration. Maybe scoping error." And that's useful. Anything more would be actually doing the work. Sharing that seems... pointless. I'll just post "Fixed scoping error in calibrate()" when checking it in to the revision control system anyway.

Instead of the grade school "What I did today" writing, how having the coders finish up the day by actually documenting all the code they worked on that day? Code is never documented well enough. That by its self is a benefit to productivity. And if you wanted to make it a metric you wouldn't get burned at the stake.
posted by Ookseer at 11:12 PM on January 30, 2012 [2 favorites]

Matt Mullenweg of Automattic on how something like this worked for them.
posted by Good Brain at 11:56 PM on January 30, 2012

If the work is granular enough that there can be daily status updates, then I see no problem with it. Where I worked, we had a troublesome client, and had to do morning phone calls with the boss to keep him apprised of what we had gotten done and what we were holding on. But these were trouble tickets, so it was very granular. And it wasn't about documenting failure, but simply about giving our boss an accurate answer to report to the client.

Reminds me of that Simpsons episode when battle robots were all the rage. Homer built a robot that wasn't really a robot, it was just Homer inside. When Bart discovered this, he noticed that there was a hammer thing that was designed to strike Homer. He asked Homer why he would build such a thing, and Homer said "it keeps me focused".

The moral of the story- if you have something that you can actually report, and the reporting is judgement-free, then there is no problem with it. Getting the job done and free communication is the goal, and if this hurts some "superstar's" ego, then need to check themselves. If, however, there is nothing to report besides "still working on module X", and there is the chance someone from management is going to harp on that, then it's not a good idea.

What might be better is a system where when the developers check off their milestones in the project, this can be viewed in a dashboard type of thing that interested parties can view.
posted by gjc at 6:03 AM on January 31, 2012

I've been working at Google for six months now. The "snippets" system is very low-key, like everything to do with management is here. On my team is we have a weekly meeting where we do bug triage, then "around the room" where each person gives a 30-second recap of their week.

I understand where drjimmy11 is coming from but that really isn't the way it seems to work here. On a couple of occasions I've flat out said "I basically got nothing done last week because I couldn't figure out how to do $X". The response was not "work harder, you idiot" but suggestions for places to find information and offers to spend time showing me how it works. This is the only team I've worked on at Google, but from conversations with friends who've been here longer, I believe this to be the norm rather than some unusually-supportive exception.

The last company I worked for had what appeared to be a similar system, where we'd all write up a sentence or two about what we'd worked on each week, but the notes only went to management, who were too far removed from the details to have any useful feedback. It was basically just a tool for tracking engineer time against project revenue. As Captain Shenanigan and troublesome pointed out, when a system like this works, it works because it helps ease communication among team members, not because it provides information upstream to management.

A past company I worked for did the daily stand-up style meeting where we'd all explain what we'd done the previous day, what we hoped to accomplish today, and listed any issues that were blocking progress. This was supposed to be a quick thing, five or ten minutes, but the manager in charge was incapable of maintaining focus and always dragged it out for 30-40 minutes getting into details. This process was not worth the time it consumed. Each of us saying our piece in an email thread would have been more effective, but even then doing this daily would have been too much.

From the article, which starts out ok but turns stupid halfway through:

showed the counterintuitive conclusion that progress toward a meaningful goal is the #1 motivator for employees at work, not financial motivation or downward pressure.

What? How is that counterintuitive? To what kind of oblivious person is this not obvious? If I'm getting shit done I feel good and am happy. If I'm not getting shit done I'm bored, and that makes me unhappy. Money cannot make up for boredom, and downward pressure cannot make work happen. I mean, duh. Give me an interesting job to do, explain who cares about it and why, and then get the hell out of my way so I can build it.

Then again the blogger says this:

Silicon Valley’s focus of work around the work itself is still an ongoing competitive advantage. Compare it to the East Coast and you’ll see a stark contrast in the importance of dress and facetime at the office.

so maybe that's the kind of oblivious person who doesn't know this. I've spent my whole career writing software for West Coast companies, so maybe this is a fish-can't-see-water situation.
posted by Mars Saxman at 10:02 AM on January 31, 2012 [1 favorite]

Yeah, at Google snippets are typically done once a week saying what you did the previous week. Mine tend to be a couple sentences. It takes a couple minutes a week, way less than some weekly/biweekly meetings I have.

I never read anyone else's snippets, they're mostly for managers to keep track of what their reports / other people are doing. They can be quite handy if you have annual / semiannual review periods, since you can go back and remember what you did for the last 12 months without digging through email and changelists.
posted by wildcrdj at 12:11 PM on January 31, 2012