What is "Dirty Work"?
As an engineer, I am biased to the idea doing well career-wise is about solving highly rewarding, hard problems. StaySaaSy highlighted that the best hard problems are only one of two types:
Technically Difficult problems are where buyers of the solution are not clear if they can solve it on their own even with a lot of time and money
Really Dirty problems are where it’s solvable but takes a lot of unpleasant work
Dirty Work is the work you have to do to solve that Really Dirty problem.
This post on Dirty Work is not just words and concepts. My first experience of Dirty Work was visceral and accidental.
I once solved a seemingly impossible problem for a customer by performing trial and error over 5 hours. The result felt like magic.
At that moment, I had accidentally embraced Dirty Work without knowing what I had done. Only many months later, did I begin to understand this thing called Dirty Work.
So, I turned that magical experience into a touchstone memory, a felt sense of what embracing Dirty Work meant. I had hoped that intuitive understanding was enough for me to develop a taste for Dirty Work and perform it reliably.
It wasn’t enough.
Dirty Work, by definition, is off-putting. Nobody would willingly subject themselves to unpleasant stuff. Even when there’s a promise of better things to come after enduring the unpleasant stuff.
In my pursuit to make myself embrace Dirty Work more reliably, I found I also needed a more rational definition. At the very least, a 101-style introduction to ground the intuitive understanding and to communicate with others this understanding.
This is that rational definition I’ve always wanted to write.
So, what is Dirty Work?
Defining Dirty Work
As mentioned at the top, Dirty Work is work to solve Really Dirty problems. But, I want to be more precise.
To do that, I drew on my own experience and from the writings of three different experts in three different domain. They are
the people behind the StaySaaSy blog (which is a guide on scaling product & engineering teams from $0 to past $100M ARR by people with that experience),
Paul Graham of Y Combinator fame (who writes about his experience in startups),
and Jacob Kaplan-Moss (who writes on software engineering).
These are the key articles I base this post on:
StaySaaSy in Build Your Career on Dirty Work and Enterprise Retention Means Solving Hard Problems
Paul Graham in Schlep Blindness
Jacob Kaplan-Moss in Embrace the Grind
From the study of all that material, I believe Dirty Work has four characteristics:
is painful, and to the extent you have little competition for it,
is necessary for growth such as to unlock certain career or business opportunities,
produces results that look magical to other people,
and is the opposite of a Technically Difficult solution i.e. it has almost no pre-requisites other than a willingness to get hands dirty.
I derived all 4 points from the 3 sources I cited earlier.
Painful
Pain is cited by all 3 sources.
StaySaaSy called it “lamentable work that many people avoid”.
Jacob described it as “terrifically tedious”.
Paul Graham said it’s unpleasant and to handle it “the same way you'd deal with a cold swimming pool: just jump in”.
StaySaaSy also pointed out that one implication of the high unpleasantness means competition is low:
the more unsexy the work is, the less likely it is that a lot of really great people have taken a crack at solving it. In short, there’s likely to be low hanging fruit.
Necessary for Growth and Big Career Rewards
Since most people over-index on the pain and thus avoid it, there’s a danger you can go in the opposite direction and assume all pain is good.
Which is why it’s important to recognize that Dirty Work must be absolutely necessary for growth. must be good pay-offs.
Here is Paul Graham on how necessary and inevitable Dirty Work is when building a company and not endorsing indiscriminate pain. In the same paragraph where he compared Dirty Work with cold swimming pool, he warned:
There was a point in 1995 when I was still trying to convince myself I could start a company by just writing code. But I soon learned from experience that schleps are not merely inevitable, but pretty much what business consists of. A company is defined by the schleps it will undertake. And schleps should be dealt with the same way you'd deal with a cold swimming pool: just jump in. Which is not to say you should seek out unpleasant work per se, but that you should never shrink from it if it's on the path to something great.
In case you are easily fooled by any one asking you to join their venture because they promise a lot of pain, StaySaaSy has a really good tip. Start by joining a growth company, then look for Dirty Work in it:
find a growth company, one that really needs you to get work done, and then tackle the unpleasant work that everyone avoids. I think this is a broadly applicable path
Both StaySaaSy and Paul also cited Stripe, a billion dollar startup, as a prime example of being handsomely rewarded when going after the Dirty Work of solving payments infrastructure as a purely business idea.
Results That Appear Magical
It’s not just at the career-direction level that embracing Dirty Work can have a huge impact. At the day-to-day work level, embracing Dirty Work can make your peers look at your results with awe.
Jacob in Embrace the Grind citing the words of Penn of the magician duo Penn and Teller from the article Seven Secrets of Magic:
You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.
And the full quote was a story where Penn and Teller did a magic trick on the David Letterman Show that involved tedious amount of work which included hiring an entomologist to provide hundreds of “slow-moving, camera-friendly cockroaches”.
At the end of the story-quote, Penn ended with:
More trouble than the trick was worth? To you, probably. But not to magicians.
Jacob continued this same line of argument by pointing out:
I often have people newer to the tech industry ask me for secrets to success. There aren’t many, really, but this secret — being willing to do something so terrifically tedious that it appears to be magic — works in tech too.
He even included an actual real-life example.
For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized.
And drew parallels with real stage magicians and their embrace of tedium in service of a great performance.
So I used the same trick as the magician, which is no trick at all: I did the work. I printed out all the issues - one page of paper for each issue. I read each page. I took over a huge room and started making piles on the floor. I wrote tags on sticky notes and stuck them to piles. I shuffled pages from one stack to another. I wrote ticket numbers on whiteboards in long columns; I imagined I was Ben Affleck in The Accountant. I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized.
Opposite of Technically Difficult
Since Dirty Work is work to solve a Really Dirty problem, logically, the key is to first find a Really Dirty problem.
But, engineers have a unique issue. They are unbelievably attracted to Technically Difficult problems. Like kids to candy.
The attraction to Technically Difficult is so deep in engineers, there’s a good chance that when faced with a Really Dirty problem or even a simple problem, engineers will over-complicate and choose to implement a Technically Difficult solution.
Engineers know what I’m talking about. :)
Which is why casting Dirty Work as the opposite of Technically Difficult is useful.
As an engineer, I found it easier to identify what’s Technically Difficult and then choose the opposite.
Which is why, personally, I find this contrast very useful in my one-person software business.
What if I Hate Dirty Work?
I write primarily for entrepreneurial engineers so, if you’re a developer, I’m not surprised if you’re allergic to the term, “Dirty Work”.
Paul Graham pointed out that, “No one likes schleps, but hackers especially dislike them.”
Jacob writes for developers so he attempted to address this aversion. In his attempt, he cited Larry Wall’s virtues of the programmer, which included laziness in his post. Jacob, for all the goodness in his post, didn’t address this objection as well as I thought.
I will follow Jacob’s example and assume that any objection towards Dirty Work cite Wall’s “laziness is a virtue” as the main argument.
My preferred response to this argument is to point out two things:
Larry Wall’s “laziness is a virtue” is strictly about writing code and a good, real-world solution is often more than just code.
“Laziness is a virtue” makes better sense in building business and product when phrased as an emphasis on efficiency. But, efficiency is never the first priority when trying to solve a hard problem.
Let me dive deeper into both points.
Realize: Good Solution is More Than Code
Since Larry Wall restricted laziness purely to the activity of writing code, this instantly weakened the argument of laziness as a virtue for any serious engineer.
First, building a successful software business or product involves lots of unavoidable Dirty Work because it’s more than just writing code.
Paul Graham, speaking from experience at Y combinator, saw how many developers often want to build businesses simply by writing code.
Most hackers who start startups wish they could do it by just writing some clever software, putting it on a server somewhere, and watching the money roll in—without ever having to talk to users, or negotiate with other companies, or deal with other people's broken code. Maybe that's possible, but I haven't seen it.
One of the many things we do at Y Combinator is teach hackers about the inevitability of schleps. No, you can't start a startup by just writing code.
Second, even in a pure software engineering role, writing code is only a small part of it. Real engineers have to perform tasks such as documentation, requirements gathering, and doing maintenance tasks.
Avoiding, or doing poorly on these important, necessary tasks (remember, one key definition of Dirty Work is it’s supposed to be necessary for growth) means your career will be severely limited.
Your senior management will be reluctant to give you more responsibilities if you cannot be bothered to do routine, maintenance tasks well. Fewer responsibilities mean fewer rewards.
Realize: Effectiveness First, Then Efficiency
Even if I were to steelman Larry Wall's “laziness is a virtue” as an ode to efficiency, that doesn’t fundamentally go against Dirty Work ethos because there’s nothing worse than efficiently doing the wrong things.
And there’s a time and place for efficiency as StaySaaSy explained:
do not, in any circumstances, normalize the pain you’ve accepted. You must fight tenaciously to fix the issue. Embrace the dirty work, and then be the leader who solves it comprehensively and scalably.
Notice how there’s a sequence in StaySaaSy’s description. First, effectiveness via Dirty Work. Second, efficiency through scaling. There’s no conflict between wanting efficiency and actually solving real, hard problems.
In other words, Larry Wall’s argument for “laziness” is valid in isolation but not so in the context of finding effective solutions to hard challenges in product and business.
A Bullet Point Summary
To summarize, for engineers who like solving hard problems, there are only two kinds of good, hard problems: Technically Difficult, and Really Dirty.
Engineers often over-index on Technically Difficult problems which may not be solvable even with great resources and under-index Really Dirty problems which are solvable with unappealing work.
Dirty Work is that unappealing work needed to solve Really Dirty problems and this means it has four characteristics:
it’s painful,
it’s necessary for growth,
it produces results that appear magical,
and is the opposite of a Technically Difficult solution.
Any resistance towards Dirty Work is understandable and perfectly human. But, using arguments such as Larry Wall’s “laziness is a virtue” to justify the ill-feeling is not valid when building software products and businesses.
Building software products and businesses entails more than just writing code. “Laziness” has its place in business but only in the lens of efficiency. When an absolutely necessary and effective solution to a real, hairy problem is required, laziness becomes an actively harmful trait.