Fog Creek Software
Discussion Board

Getting Things Done When You're Only a Grunt

Do you have any ideas for getting things done when you're not in charge?

How do you bring an organization that scores 1 or 2 on the Joel Test up to 11 or 12?

Joel Spolsky
Tuesday, December 25, 2001

I've been in this situation at prior jobs. I have to agree 100% with what Joel has said here. Start doing the right thing, and it usually catches on.

As for the work environment: The most valuable thing I've ever found in a noisy office is a pair of sealed headphones, the kind that go all the way around your ear and form a little sweat seal from the pads around your ears. Hook these up to whatever music you like and that eliminates an amazing number of distrations. A pair of $120 headphones like these has paid for themselves a dozen times over in lost irritation.

As for the email client, ditto to Joel's suggestion on that one. I often feel the need to respond to an email as soon as it comes in, but by only checking every hour or three (or even less frequently), I find that I get quite a bit more done, and half the email conversations work themselves out without my input just fine.

Troy King
Tuesday, December 25, 2001

This happened to me when I went from being a consultant to being a team leader with a medium sized company. The company was scoring very poorly on the Joel Test, and worse, they had staff in place to "help."

For example, they hired co-ops from a local university for QA. And they had a QA manager who would try to juggle too few resources around too many projects. So there was no consistency and no reliability of QA.

Unless... your project implements automated unit testing. We just did it. We also "just did" a bunch of other simple things like dependency analysis, &tc. &tc.

To this day, that core chunk of code from that product is the most stable intellectual property that company owns. And it's just as well, since everyone from that team has moved on.

Some of the "innovations" were adopted by the company, but some weren't. I think you can always create a field of positive change around yourself, but the "viral" effect needs either a receptive environment or constant re-infection.

If people are frustrated and simply don't know how to write software well, then you can change their work and even their careers setting a new example.

But if there is some systemic problem that reaches into the culture of the company... you may not be able to create permanent change.

But that's ok. If you really, really want to mold the culture and practises of a company, you ought to do what Joel did.

And start your own :-)

Reginald Braithwaite-Lee
Wednesday, December 26, 2001

Hmm, I thought this discussion was a joke because this was started by a "Joel Spolsky" without there being a corresponding daily entry.  I shouldn't have signed myself as Joel in retort earlier.  Anyway, my two pence...

- Leave a couple good books in the office library.  Every company I've worked for compensated me for them.  And alternately leave a copy of the Joel Test in some prominent place.

Getting books only works for small offices, as in larger ones they'll be stolen.  I once experimented with a couple Extreme Programming books.  Now the company does daily builds (which I was asked to set up) and pays lipservice to unit testing.

- Become Special Ops.  In Mythical Man-Month, Brooks describes a "surgical team."  One person on the team could work on finding tools to cut down development time and/or reach better performance.  Maybe this is an idealistic position, but I find managers rarely mind letting people take time to write a good automated build, for example.  The most important thing is to make change painless (and well-documented); otherwise no one will care for your new order of things.

Fortunately, nothing on the Joel Test requires full buy-in from everyone, like unit testing would.  I knew a lead programmer on a team that wanted to spread the good word on unit tests.  So he called a big informational meeting, and sat with people to teach them how to write tests.  A month later, his team was the only one writing the tests.  What was the problem?  It took too much buy-in, and plus he gave no real mechanisms.  He was willing to give much of his time, but just wasn't being effective.  Lukewarm friends, stalwart defenders of the old ways.

Wednesday, December 26, 2001

This reminds of me of Stephen Covey's Circle of Concern/Circle of Influence in the 7 Habits tome which I was just reading last night. Thanks for helping me see the practical side of the idea.

Arasnath Kimis
Wednesday, December 26, 2001

I have worked in at least two companies that would score low on The Joel Test. The first one, I didn't really care about much, and I was kind of stuck there for a number of reasons. I left, because after analyzing the effort that would take to make things right I saw that it didn't pay off for me. I was very selfish and I kind of regret that. I know that the head of development is still working there, and is still practicing a ridiculous methodology, that causes similar frustrations on new employees.

In this company nobody ever noticed anything wrong with having no version control (for example), or having .cpp files as big as 300Kb containing most of the source base. Most programmers were very unexperienced, and the head of development was a stubborn old man, with no formal education in software engineering, that enforced practices his way or the highway. People was perfectly happy working in that environment, and thought that giving bug reports on post-it notes, with no repro steps, was a perfectly valid bug tracking method.

The second company, was and still is a very nice place to work. However it didn't have much of a development culture, it was mainly a business consultancy house. When the bubble bursted, they realised that most customers were demanding real development rather than silly consultancy. This company realised that whilst only 15% of the consultants were billing, almost 92% of their development activity was bringing the money home. So they needed a shift, towards development.

I noticed however, a crucial difference between the two companies that "pushed" me to introduce improvements in the process of the second one. In the second company, the developers complained about the lousy process, but nobody did anything about it. That alone, makes everybody in the company be much more open to improvements. When you notice that the process is wrong, and people isn't comfortable about it, you are much more likely to succeed in making things better.

So to Joel's point of view I would add, that the first signal of a process that can be improved is that the people victimized by that process shows discomfort.

Beka Pantone
Wednesday, December 26, 2001


  First message here, thanks Joe for the excellent articles. English is not my primary language and I am sorry if I make any mistakes on grammar.

  Anyway, here's my tip. Know about the others business of your company, the thing as a whole. I work on a financial consulting small sized (4 people!) company, and everyone knows about banking and such here. As I code, I have to keep my ears open to other company issues.

  It is my business, part of it, after all. When you start to give ideas about areas that you were not primarly hired to do, people will wonder (and appreciate) your value for the company.

  So if you work on a web development team, know more than just servers and scripting language. Know a bit about the impact of e-commerce, a lot about usability, a little about website trends, what failed and what is working. You know, working almost alone on the development has made me a central part of the entire process. But when someone comes to me and asks "what you doin'g?", I can say not only 'debugging thread 563 line 13590 stack 12 process 56 on x86', but also "Making that order menu 10x faster to find".

  Different points of view, this sure will improve your work (and others will thing this too :-))

  Also an extreme important part is VALUE YOUR WORK. When you are right, you are right. Nevermind boss is saying s/he wants this or that way. Listen to them, incorporate a few thoughts on the process, but do not be afraid to say NO. Just say NO when a no is deserved. Hey... I got into many fights with my boss because of this. On my first week. But man he learned to respect me after this. Nowadays, we discuss things looking at each other eyes. It's respect... Sometimes when you are really low on the corporate ladder, you need to EARN respect. And this also comes with (good intentioned!) arguments.

  And don't forget, with practice comes perfection. Small things like seating position, the way you hold your mouse, rest each hour, sleep well. These are all small stuff when you have to finish that code for yesterday, but, very important for your quality of life.


Wednesday, December 26, 2001

"At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You're tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation."

This very thing happeneded to me in a project I was working on. I could not resist the temptation, due to deadlines. We had deadlines to meet, and waiting for several months for some trivial thing to get done simply was not an option.

I tried to have my project leader re-staff the project to get rid of this problem, but I was simply told it could not be done due to some bullshit office politics. I guess the boss had it his way in some other matter, and I was stuck with the problem of having to rewrite broken code in order to meet deadlines. Any suggestions on how to fight braindamaged office politics? :-)

I worked with a consultancy when this happened, and without knowing, I had the feeling that their policy on
staffing was to take one of the top-five guys and then
fill the rest of the positions in the development team with
less-than-brilliant people, so they could get most revenue per individual (read over charge for the less-than-brilliant ones).

It seemed management did not know the math, that if
you add 1+1 with brilliant developers you will not have
2, you will end up with 4. I find this math to be true when
it comes to writing code.

Patrik Ohman
Wednesday, December 26, 2001

Okay, I have another question. One of Joel's maxims is 'hire great people'. Now, all of aren't msft or FogCreek. So we have to do with people who are smart, but aren't the smartest in the pile. And who may not be as proficient at getting things done as (say) Joel or Babak might be.

So, any thoughts on how one goes about raise the standard of your dev team? (Firing them en masse is not an alternative :-))

Wednesday, December 26, 2001

To Paul, re: How do you raise the standards of your development team?

Start with Joel's book review list ( and the recommendations folks made after the list. Don't expect everyone on the team to read every book at once, but encourage them to try some of the short ones. These can be really inspirational to a team, getting them to recognize the need to change. For me, "Writing Solid Code" did just that; but it's very C-based, so it might be a bit dated. Ditto "No Bugs!". another book that inspired me. "Peopleware" is a good, short, inspirational classic.

If you can get one or two people to give these books a shot, you should start to see change. Good luck!

Martin L. Shoemaker
Wednesday, December 26, 2001

The question here is what to do?

There are a few things that one can do to invoke change.

My favorite is stick your neck out. It is a fine line between sticking your noise where it does not belong vs. trying to learn and be aware of what is going on.  The number of times that I have asked, or inquired as to things that were NOT my responsibility is probably one of my best traits.

I remember when the manager received a way cool video disk player. This was a number of years ago, and it was one of the old large format video disks with a serial interface. Of course the disk player was for evaluation purposes. My buddy and I thought the thing was so cool that we dropped what we where doing and proceeded to write a graphical duplicate of the remote control. We were writing education software at the time, and thus all machines had a touch sensitive screen. Needless to say, in one afternoon the two of us had a working graphical “touch” enabled copy of the remote control on the screen.

This allowed the management to evaluate, and demo the player (and of course justify requesting more $$ from the upper management). They used that program for years to come.

The alternate to the above would be to submit a project proposal to management, and try and convince them that writing a remote control application would be an excellent starting point for evaluating the use of the player for educational purposes.

The process of writing the proposal, waiting for a replay…meetings etc would have taken MUCH longer than just doing it. By sticking out our necks, we of course accomplished something that would not have been done other wise. The god like status of writing such a utility in one afternoon also impressed other developers in the office. We received a letter of thanks from the upper boss. So, when possible stick your neck out.

Sticking your neck out also gives one a reputation of being interested in other projects, and things going on. It is the opposite of the “ISLAND” mentally that many places settle down into. Be open, and yak yak to everyone! The ideas and change this kind of attitude makes is amazing.

3M calls this process of sticking your neck out as boot-legging. Recall the story of post-it notes. The time involved to actually get approval for this type of product would have taken months and months. The fellow simply had a bunch of post-it notes made up, and then passed them around. When people started asking for more…well..they had to go back to the source. Again, the moral here is to stick your neck out. Break some rules…

Many times I have asked someone about their project…and sure enough we have some code, or routines that we wrote just last week that fit their needs perfect.

I guess the moral of the story is don’t be an island, be aware of what is going on, and spending time talking to people that you DO NOT actually have to talk to. It also makes the work place a more enjoyable place to be.

Albert D. Kallal
Wednesday, December 26, 2001

Neutralize the Bozo by continually reporting bugs against them so they can't do more damage? Perhaps there's a better way: do a code review. Print out the code, gather together a few coders and go over it line by line in an _educational_, _constructive_ tone.

The key of course is to do this regularly, and do it to everyone, not just the Bozos.

Phil Aaronson
Wednesday, December 26, 2001

Regarding Martin's post, to Joel's list of recommended books I would definitely add: The Pragmatic Programmer. Which is probably one of the best books I have ever read about "writing good software". Here's a website you might like to check:

Beka Pantone
Wednesday, December 26, 2001

One of the problems with improving things as a grunt is being sucessful enough your immediate manager looks bad.

"Hey, how come things suddenly got better when Dave joined the team, and why are we paying you so much to manage the group when he seems to be doing all the managing?"

Basically we started emphasizing quality. We didn't ship as fast as they had previously, but when we had a release ready to go, it was done. Rather than issuing six bugfix releases over the next three months, we spent the next three months developing new features.

The solution? Acquire another company of 50 people to replace the group of three I was leading, then dump our group as redundant. Admittedly, the acquired company had other products that were useful, but having made our immediate manager look bad, there was no political support for us when the company decided to lay off a good percentage of the workforce.

In the long run, getting laid off was the best thing that could have happened to me, but I sure would've like the chance to continue to improve things.

Dave Polaschek
Friday, December 28, 2001

This is a wonderful topic!  I'd been doing many of these things on my own, but it's great to see it put into words.

I've taken to calling it "back seat management".

David B. Thomas
Thursday, January 3, 2002

I can empathize with Dave.

In more than one case I unknowingly made some someone else with political clout think they look bad.  I was successfully improving the productivity of the team but not meeting the needs (or wants) of some other individual in the team.  I was made to suffer their wrath in one way or another.
It is an unfortunate thing that we at the bottom (or near bottom) have to contend with such political manipulation.  Certainly, every team is different but generally this kind of social sensitivity is a significant factor in how to go about positively influencing your team.

I suppose the answer is to advertise some of the 'extra' things that you do as benefiting the group as a whole - at the same time, letting those insecure individuals know of something extra that you are doing for them.  This last part is the least pleasant.

Chris Abney
Thursday, January 3, 2002

Something that seems missing from the list is "Work on Your People Skills".  I remember when I first got to my company many years ago I came with a subset of the Joel Test:  Fix the Bugs First and Use Version Control.  When I started yelling at people, "Hey, fix your bugs and use version control!" nothing happened.  I wondered why they even hired me.  ("We want you because you're a closer," they said.)  Then I remembered my Dale Carnegie, asked nicely in the humblest of tones--"if it's not too much trouble I really think it would be worth it"--and change happened.  It was a very small company (four people at the time) so maybe this lesson doesn't apply to most...but in my opinion a title doesn't confer leadership, that's something that can come from you even if your title is "grunt."

James Fristrom
Friday, January 4, 2002

I was skimming a new book at the bookstore a couple of days ago, that suggested using "3 out of 4" principle when you want management approval of a change. Here it is...

Present 4 options, ranging from 1) Do nothing, leave everything as it is, to 4) The extreme opposite, with 3) Your ideal solution. If you make a good case of 4), you have a good chance of getting approval of 3).

Don't know if it works. Haven't had the chance to try it yet.

The book was called something like "Leading a development team."

Johannes Bjerregaard
Friday, January 4, 2002

Good suggestions. Kudos to Joel and everyone who offered suggestions.
I've got another to add:

Headphones really are a great idea. Headphones aren't quite an office door, but if you use them as a signal, they can serve the same purpose.
On my last team we came to an unwritten understanding that if someone was wearing headphones in a cubicle, s/he could only be interrupted for time-critical issues. Anything that didn't require a real-time response should be emailed or asked at another time.

Whether you're a grunt or not, if you or your teammates work in cubicle-land, give this headphones system a try.

Lenny Turetsky
Saturday, February 16, 2002

One suggestion to add to the headphones... a walkman or some other portable player.

When I'm in the zone and need to refill the mug or hit the john I'll leave the phones on.  My little way of saying I'm thinking really hard right now - don't bother me.

Mitchell Silverman
Tuesday, July 2, 2002

Just remember to ditch the headphones when you become a manager.  Nothing worse than having that "hey, don't bother me, I'm too busy" attitude.

A good manager should ALWAYS be available and willing to drop whatever they are doing to help out.  Telling the people on your team that nothing is more important than the work they are doing shows LEADERSHIP.

Too many managers in this world that can't lead!

My $0.02

Mike Derkowski
Friday, December 6, 2002

*  Recent Topics

*  Fog Creek Home