I normally find this author quite enjoyable to read, and this seems like "the piece" he's been wanting to write for a long time. So it's surprising to find it thrown together so seemingly hastily and written so poorly.
It starts off with a couple paragraphs filled with non-parsable sentences like "I was employee #20 at the first start-up and the first engineering lead" (which start up again?) and "A growing groups needs to continually invest...", and then it spends four full paragraphs talking about "1:1", without ever bothering to define what a 1:1 is. It sounds like it must be a meeting of some type, but not one I've ever heard of, and as far as terms go, it seems to be almost designed to be non-googlable.
I gave up at that point.
So hey, Rands, if you're reading this. I (and probably others) would really appreciate it if you gave this article another edit or two. Put it back up here when it's ready!
You've touched on a few of the conceits in his writing style:
1) He writes as if you're at least somewhat familiar with the stories he's been telling all these years.
2) The stories are presented as parables, and the details may not all be 100% consistent from year to year.
The "parable" conceit could be a convenient dodge to avoid fully justifying or proving his points, but I've found the coherence and strong voice of the writing to be respectable enough so far.
If you're really curious about the names of the startups you can easily Google up his LinkedIn profile. Click through to the book covers on his site to find out his real name. Rands is a pen name that goes along with the familiar storytelling style of the blog.
He tries to avoid naming his companies. He worked at Apple from ~2002 to 2010, and was simply banned from giving any details, or even mentioning that he did work for Apple (though it's on Wikipedia). I guess the habit stuck.
What I really like about The Joel Test-the-article (http://www.joelonsoftware.com/articles/fog0000000043.html) is that it contains links to other articles presenting the individual points in more detail and providing context some readers are complaining is missing in the Rands Test.
It kinda serves as an "index.html" to all of Joel's writings, the page that you can point a novice to and let them explore from there.
I completely disagree on status reports. I've only worked at one company where we sent them weekly. I found them invaluable for looking back over what I'd accomplished. I viewed it more as a weekly journal than a tool of oppression.
That said, the rest of the management system was in shambles, and they'd have failed nearly every other question. I don't believe that inherently makes status reports a bad thing, though.
I thought the point was that a simple status report is a cop-out. Rands seems to prefer ambient awareness and constantly recalibrated communications. Keeping your own journal is one thing, managing via soundbites is another.
I thought the point was that a simple status report is a cop-out.
That's his point, but I think it's overly broad. Just as axe murderers have a preference for axes, bad managers have a preference for status reports. That doesn't make axes or status reports inherently bad. I think, "do you send status reports?" should be an inconsequential step toward, "do you have poor communication with your management team?"
If you wrote something in your journal/status report that was useful it probably would have been more useful in your bug/task tracker or wiki or somewhere else that your colleagues could find it in context.
This is the real point the author is trying to make. Any information you would put in a status report should already be in another system already. You have your task and project management system, your bug tracker, your version-control system, and your code-review system. All of these should list essentially all the things you've done and it would be easy to look back over a historic list for your user.
Status reports are generally duplication, and if they aren't, then the tasks are not being tracked properly.
Not everything can easily be itemized into a bug tracker or project management system. Sometimes you just need to tell a story. This is particularly true in disciplines outside of engineering.
Not all teams are co-located. Real-time communication mediums are sometimes the wrong choice, like when you need to curate your message. Meeting minutes are just another kind of team-wide status report. Collaboration is complex and nuanced. Status reports have their problems, but they have a place.
For every person you encounter who hates doing status reports, you'll probably find one person who hates attending or participating in meetings, even those that are well run.
Exactly. Status reports are effectively a black hole. In the best case they duplicate data. In the worst cases they contain irrelevant data or they eat important data.
Well done. I'm not a programmer, but some time ago, I simply stopped sending routine 'status' information until someone complained. Then I sent it. This simple step has saved me a couple of hours a week.
Gathering status is important. Rands explains that engineers are typically using other tools in their job that can do that kind of reporting. A manager's job is to synthesize status from your distributed journal of bug closures, emails, wiki updates and notes from the 1:1.
A manager's job is to synthesize status from your distributed journal of bug closures, emails, wiki updates and notes from the 1:1.
A competent manager might argue that it would be a better use of his time to delegate to his resources to identify what in their distributed journal of bug closures, emails, wiki updates and notes represents signal and what represents noise.
I don't know any competent manager who isn't busy enough:
* managing multiple projects
* fighting fires with customers
* chasing down issues, managing expectations
* attending meetings he/she doesn't want to attend so that his/her resources can better spend their time on delivery tasks
* triaging his/her own inbox (when you're a manager, everyone who sends you an email expects you to treat it like it's an emergency)
* handholding the resources that for one reason or another he/she can't fire
* writing his/her own status reports to deliver to paying customers
Ideally, collecting status is great work for an administrative resource like a project coordinator, but that's usually a luxury item that managers can only dream of.
>A competent manager might argue that it would be a better use of his time to delegate to his resource
the first sign of all the bad managers i've met - s/he delegates. S/he aren't competent enough to perform his/her duties (including and especially - taking decisions) and covers it as delegation.
Status reports are second worst - they mean that the manager doesn't have enough competence/skills/interest in being continuously aware of what happens in his team. Frequently the team responds in kind :)
Er...the delegation thing depends on what the manager is being paid to do.
Not every technical manager can be an expert in all the fields he/she supervises. That's why they hire other, individual contributors who are more focused on the details or tactical implementation without having to worry about the strategic.
Cool, if status reports are your thing you might want to check out Thinkfuse (http://www.thinkfuse.com). We've built an entire app around making status reports more useful (like sharing reports with your whole team, archiving them, and being able to follow other teams you might need to know things about).
Interestingly, we've also got quite a few startups (a couple dozen that I know of), using us to send monthly or bi-weekly updates to their investors as well.
As I read the list, I was surprised to see that one on it. It seemed very unRands-like. I was happy to see a -1 by it.
I completely agree that they are a poor way to manage. The problem is people become more concerned with the artifact than what the artifact is supposed to be communicating. Eventually, the become nothing but noise and lost time. Managers feel good that the artifacts are being generated, but the underlying problems are being ignored.
>The problem is people become more concerned with the artifact than what the artifact is supposed to be communicating.
This can happen to any formal reporting or management system. Status reports, especially frequent ones, are actually one of the less game-able systems out there. Though they really need to be augmented by more automated recording and reporting of measurables to help keep them honest.
>> That said, the rest of the management system was in shambles
I think that's the issue. I think status reports work great in companies where the management is really good and competent. Ironically, it doesn't feel like status reports in that environment though, just day-to-day flow.
It starts off with a couple paragraphs filled with non-parsable sentences like "I was employee #20 at the first start-up and the first engineering lead" (which start up again?) and "A growing groups needs to continually invest...", and then it spends four full paragraphs talking about "1:1", without ever bothering to define what a 1:1 is. It sounds like it must be a meeting of some type, but not one I've ever heard of, and as far as terms go, it seems to be almost designed to be non-googlable.
I gave up at that point.
So hey, Rands, if you're reading this. I (and probably others) would really appreciate it if you gave this article another edit or two. Put it back up here when it's ready!