
Making shit work is everyone's job - ph0rque
http://37signals.com/svn/posts/3163-making-shit-work-is-everyones-job
======
sdfjkl
I've found myself saying "not my job" the other day. I took this as a
confirmation that it's time to leave the company (something I felt was
approaching for some time now).

This is because I'm very much the guy that "makes shit work" (comes with being
a jack-of-all-trades kind of hacker, or maybe just with giving a damn about my
work). "Hey, remember how we've set up that postfix-to-python email bot three
years ago?" - I do. "Hey, the finance data import on the MIS is broken" - Ok,
let me have a look .. there, I fixed it. This I don't mind. In fact I quite
enjoy it.

However, in turn I do expect something back. The first and obvious thing I
expect is that you don't mind that the software project I'm working on is
going to be a few days delayed because I spent time digging in the bowels of
some open source tool or staring at Wireshark. The other, and maybe not so
obvious thing I expect is that you a) listen to my suggestions and b) don't
get in the way of me working efficiently. What this means is that if I suggest
you should go with solution A and not solution B (which your pricey external
consultant suggested) and I take the time to show you several good reasons
(not my job either, but comes with giving a damn) why solution A will work
reliably and solution B will come biting you in the ass later, then you at
least hear me out.

And then when solution B comes biting you in the ass and you come to me to
work it out, at least give me the means to sort it out properly instead of
forcing me to follow your pricey consultant down the slippery slope of
exceedingly horrible workarounds, all of which I have to handhold him through
and waste massive amounts of time because he can't use email and needs to do
schedule a conference call in several days time with subjects such as "confirm
the VPN is working".

Because once I'm sufficiently annoyed, I will gladly tell your consultant that
something "isn't my job" just so he stops bothering me. And then I write my
notice, because I don't like working like this.

~~~
hef19898
You spoke from my heart! Really, you do!

~~~
sqlservian
Mine too! Your thoughts are spot on.

------
zavulon
I believe this is a response to some comments to their previous post
<http://37signals.com/svn/posts/3162-the-on-call-programmer>?

I think they're completely missing the point of those comments, but regardless
of that, I think there's a bigger point to be made here.

Over the years, I've noticed there are two types of developers: the ones who
only want to work on interesting code/new projects/etc, and the ones who get
shit done.

The first guy does NOT want to do any maintenance, only wants to work on new
projects so he can get things "his own way", throws a hissy fit or refuses to
do it outright when he has to dig through tons of horrible legacy code, etc.

And the second guy just gets shit done. No matter what it is, he understands
that it just NEEDS to be done, and does it. He will not take it silently -
sometimes, just like the first guy, he will be loud and obnoxious in voicing
his opinion that this code totally sucks, what moron wrote this, and we should
totally rewrite it, etc.. but then he sits down, rolls up his sleeves and does
it (and then works on re-writing it in the right way, if there's time).

The first guy might be a much better programmer than the second. He will pass
a technical interview with flying colors, he's usually up to date on all the
latest technology, he's good and he knows it.

But after a few years of doing this, I will hire the second guy EVERY TIME.

~~~
jabo
Just curious: How would you differentiate between the first type and the
second type of programmer when you hire him/her?

~~~
zavulon
Good question. That's what I'm struggling with right now. There really is no
way to determine this accurately at interview stage - a smart person will
always figure what kind of answer you're looking for. One way is to have them
describe in detail what they're doing at their current/previous positions - if
they mention legacy code/doing support or maintenance, ask for more details.
See how they're describing it - matter-of-factly, or in a negative way.

However, there really is no _good_ way to do this, other than to hire somebody
for a trial period and have them do actual real world tasks. That's what I try
to do most of the time, but unfortunately it's not always possible. If someone
has better ideas, I would love to hear them.

~~~
elliottkember
Personally, I've found a sense of humour to be a reasonable indication -
person 2 is more likely to be able to step back, smile, and say "okay, this is
horrible and it's going to go badly for these reasons. But if I had to do it,
I'd X the Y with Z". If they can do that and laugh about it, I get a sense of
levity and perspective.

------
falcolas
That's all well and good until you're the only one who makes "shit work" - and
then you can't do your job because you're doing everyone else's job.

Sometimes the best thing you can do for yourself is deflect the person away
from you and towards the code's owner just so you can get your own work done.

Sincerely, jaded (nearly ex) large company employee

~~~
JDShu
Sounds like the classic free rider problem.

~~~
sdfjkl
Sounds like the classic large corporate environment to me.

~~~
mtts
Happened to me at a small company as well. Actually it's probably more of a
small company problem as "not my job" doesn't really work if there isn't
anyone else to pass the job to.

------
tlogan
You will never get rich or successful if you listen to this advice: according
to Gervais Principle[1], you will end up as looser.

Of course, you should tell others to behave like that.

[1] [http://www.ribbonfarm.com/2009/10/07/the-gervais-
principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-
the-office-according-to-the-office/)

~~~
runningdogx
Over-achievement also fits into the clueless tier. The clueless can't get rich
or into upper management except by accident, but they can have successful
careers as long as the psychopath upper tier sees them as useful.

In the GP corporate hierarchy, the losers tend to do the minimum required to
keep their jobs. If they start making stuff work beyond their immediate job
responsibilities, that's not classic loser behavior.

At one point in that series of essays, the author talks about behaviors of the
psychopath. In a startup environment, the psychopath puts in a lot of effort
and gets things done because that's the fastest path to getting the company
off the ground.

------
pxlpshr
37signals is catching flack for yet-another-blog-post not applying to larger
institutions, but this mirrors Facebook's culture in which every employee is
"QA" by serving them the latest trunk if I'm not mistaken.

Sometimes people overanalyze generalized statements to hear themselves talk.
This is just how 37s makes "making shit work" everyone's job to build a great
product. Apple and Fb do it their own way. And so forth.

The key ingredient is empowerment (and recruiting). Employees must be trusted
to own the product and customer experience without micro-managers getting in
the way by shuffling papers and responsibilities.

------
mgkimsal
This idea of "everyone pitches in" works only if everything else is going well
too. I'm happy to pitch in to help fix something, but if the rest of the gang
steadfastly refuses to do anything to make their stuff better in the future -
in other words, if they keep writing piss poor code knowing that I'll be the
one to "pitch in" when it crashes - then thanks but no thanks.

I'm truly grateful when others step in to fix something I broke, but I then
need to learn from them so I don't do it again. I was working with a team
recently and kept breaking some of their git process with my check-ins. Code
worked, but I was doing something that went against their flow. Took me a
while to sort it out, and I felt bad because it was costing one of the other
guys time. I finally grokked what he was asking for, and I've caused much less
downtime.

His attitude initially was "hey, that's no sweat - I can fix this up". That
started wearing thin by the 4th mistake, and I could tell. I felt bad, but
eventually got to the point where I'm not slowing them down anymore.

I've been on teams where other people continually write crap code - never
bothering to even check if it works - then _I_ have the bad attitude for not
fixing it: not being a "team player", etc. That's gotta work both ways.

So, yeah, "not my job" isn't a great attitude. You do have to ask tho, when
you see that attitude, how much of it is endemic to that person, and how much
of it is caused by something more systemic in the organization?

------
daemon13
Not sure I understand the reasons for pointing the obvious, especially using
such ambiguous line of reasoning.

I disagree with:

“Oh, that’s not my job,” is the sound of doom. Maybe not imminent doom, but
doom indeed.

because I have seen multinational companies [revenue $25B, $43B], where
culture and many employee's attitude was “Oh, that’s not my job,”. These
companies Net Income is billions of USD. Not sure I see how they are doomed. I
would be glad to be doomed with $1B of annual income [after taxes].

I think it is important be realistic and understand that instilling such [make
shit work] attitude is only possible in a small start-up or bootstrapped
company, and only when most of the senior people posses such attitude.

As for the bigCo:

\- It is statistically not possible to have A players with can do/will do
attitude, when the company size grows above certain threshold. So eventually
you pick-up some B/C/D people, who would start playing games.

\- I have tried several times to put together a small team of doers within
bigCo - it never works in the end because overall culture overpowers and
draines you.

\- My advice for a doer would be simple - either [1] calm down to avoid
burnout [inevitable when everybody is dumping on you] or [2] run and find a
place where your attitude and strengths will be appreciated, or even better,
find a place and run....

------
mmahemoff
This happens all the time in big companies, people are especially wont to
throw the shit over the fence to another team they don't work with. I found it
interesting how Steve Jobs dealt with this reality.

 _The janitor gets to explain why something went wrong. Senior people do not.
“When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons
matter.” He continues: “Somewhere between the janitor and the CEO, reasons
stop mattering.” That “Rubicon,” he has said, “is crossed when you become a
VP._

[http://onproductmanagement.net/2011/05/12/leaders-dont-
make-...](http://onproductmanagement.net/2011/05/12/leaders-dont-make-excuses-
crossing-the-rubicon-of-product-leadership/)

------
MaxGabriel
I am totally a 'make shit work' kind of guy, regardless if it's my job or not,
because I wouldn't be happy otherwise. But the other side to this story is my
friend Chad Meadows, who is the most competent person I know. Chad will
specifically take on lower-paying roles because he doesn't want to deal with
the paperwork and related crap that comes up. Chad will put 110% into his job,
but he'll refuse to do the crap he isn't being paid for--which is totally
reasonable.

This case sets up a more generalizable rule, which is that if you're expected
to make shit work, you should be compensated for it. When you're in a startup,
making all the shit _is_ everyone's job description, and it's part of your
paycheck, too, in the form of equity.

------
espeed
Seth Godin talks about this in "This Is Broken"
(<http://www.ted.com/talks/seth_godin_this_is_broken_1.html>).

------
jiggy2011
The problem with this attitude is that you have to be sure you actually know
what your doing. I used to have this sort of macho attitude where I was sure I
could fix any technical problem ever.

I saw it as a personal insult if anybody I knew took _any_ technical problems
to anybody other than me. The problem with this is that you will often end up
out of your depth flailing around in the waters of diminishing returns.

I am now a little older and wiser. For example, recently I was asked by
someone if I could take a look at their Exchange server problem after I was
done fixing something else. Of course the Exchange Server had not been
configured by me but rather by a 3rd party consultant but they assumed I would
be able to fix the issue quicker and cheaper.

Now I have a reasonable grasp of email (well I wrote a basic POP3 server in
Java as a college project). But I have never used Exchange before or taken any
courses on it. And I had no understanding of this particular Exchange setup. I
could probably have fixed the issue after a bunch of RTFM, but would it have
taken me 10 minutes? 10 hours? 10 days? I have literally no idea.

There is also the risk of bumbling into doing something that seemed right but
would have screwed something up and had the guy who originally set it up
badmouth me.

In the end, I just did some basic diagnostics on the users computers looking
at mail headers etc in outlook when this was fruitless I offered to call their
3rd party consultant and describe the issue to them as I saw it but insisted I
could not do anything further than that.

------
jerrya
_Making shit work is everyone's job_

Would someone diagram "shit work" for me?

Is it noun verb or adjective noun?

~~~
SatvikBeri
Noun verb. You could replace "shit" with "stuff."

------
lars512
> Once the mentality cements, everything is eventually someone else’s job, and
> they’re being a toad for inconveniencing you with it.

There's so many parts to this that they actually need unpacking.

Someone discovers a problem... are they responsible for it?

Someone can't do an aspect of their work... how hard have they tried before
seeking help? How busy is everyone else?

There's five things broken, is the new one higher priority than the other
four?

You can tell when the situation's right: several people volunteer to help, one
steps up, responsibility is shared. Likewise, when it's wrong, there's that
awkward... silence...

I'm glad to read even a short post about this. My feeling is that people are
mistaken if they think they can give away responsibility for something.
Someone must choose to _take_ it from you, and in all cases you share
responsibility for getting it resolved.

------
OzzyB
“Oh, that’s not my job,” is usually what folks say when they _can't_ do the
"shit" that needs to be done.

It's what people say when they want to save face and not be labelled as
someone who "can't do it".

It's a defense mechanism.

~~~
rollypolly
I think you're right most of the time, but I wonder if there's not also a
certain personality type that like that, regardless of their actual competency
level, that prefers doing as little as possible.

I wish one of my ex-employers had been better at filtering out that type of
people.

~~~
andrewflnr
There's also a certain personality type that just really wants things to be
done by the right person. That's something I need to consciously overcome:
this is not rightfully my job, but I'm going to do it anyway, because that's
the most useful thing to do.

------
gipsyking
> programmers will wake up in the middle of the night if a sql query tipped
> over and needs an urgent rewrite until faster servers can arrive

I sure as hell don´t wanna work there.

------
renegadedev
I run into this all the time at work. I'm the guy who makes "shit" work at our
under-manned start-up. Lately I'm finding it to my detriment because

a. management releases shit as-is instead of using it as a temporary solution
and dedicating resources to finding a better permanent solution

b. other developers hit me over the head with their pedantic view of how it
should have been implemented, which would probably thrown the project months
or even a year off-schedule

It's a thankless job.

------
RyanMcGreal
I sometimes find myself saying, "That's not my job" in the same sense that
Murtaugh would sometimes say, "I'm too old for this shit." Nevertheless, it's
easy to complain that employees in large companies don't care about the big
picture; in many cases, the organization itself tends to punish people who go
beyond their mandate to get stuff done.

------
sqlservian
Okay, I will make shit work. No problem. The fix will take a little time, but
it will solve the issue permanently. What do you mean we don't have time for
that? Sure, this is something the consultant can work on. Just remember he
wrote this code originally. [puts headphones on and starts looking for another
gig]

------
shaggyfrog
Now what if the leadership are the ones telling the grunts in the trenches
"it's not your job"?

------
debacle
The problem with that philosophy is that one bad apple spoils the bunch.

------
benevpayor
Just don't break it while you're trying to be a hero.

