Over the last couple of weeks I have been trotting out an observation based on an interesting conversation about software engineering teams with Jonny Dimond: mediocre work is the worst kind of work.
Good work is, of course, wonderful & desirable: good as in effective, impactful, gets things done. Good as it is engaging, challenging, immersive.
Bad work is also surprisingly acceptable: bad as in it is a terrible hack, or has all kinds of problems. Bad as in its nasty, irritating, or unnecessarily hard.
You need to be OK with bad work. Bad work is how people get to good work, because sometimes there isn’t time for good work, and because there will be always work that people don’t enjoy doing.
Mediocre work is… neither of these. Mediocre as in technically correct, works well enough, meets expectations. Mediocre as in dull, unengaging, simple. This kind of work doesn’t really get a reaction out of people - and if too much of a team’s work is mediocre then it feels like that team will become mediocre, thorough selective attrition and general mehness.
Tangentially, this meme was flying around:
Every FAANG tech job. pic.twitter.com/UjZGaOaOiw
— Dare Obasanjo (@Carnage4Life) January 29, 2021
This fits with a very common meme inside Google that the company hires the smartest engineers in the world then has them shuffle protos between services. Over the years I was at Google the meme shifted from a wry smile by folks doing interesting work, referencing the inevitable boilerplate they had to deal with, to a cynicism that Google was not what it was, that the real engineering was not happening any more.
Transforming protos, dealing with organizational hurdles that don’t seem to add value (why, yes, I should get a review for that ariane entry bit), and all of the other laughed-at stuff are prime examples of mediocre work. It’s not bad (the legal team really might want to look at the launch!) but it’s a 1x activity - you predictably get what you think you will and it always takes too long.
But Google is still astonishingly productive. Even from the outside, I stumbled across it all the time. Look at the commits to Skia, or Bazel, or Tensorflow, or any of the thousands of other notable projects that Googlers contribute to regularly. These thing are hard, in deep problem domains, and the problems they are solving are real. Go use Google Maps, or Lens, or even just search - they’re remarkable. YouTube is remarkable. Android is remarkable. Google Cloud is making billions in revenue despite being waaay in third place competitively - remarkable! Its not to say that these things couldn’t be better, or that Apple or Amazon or GameStop isn’t doing it better, its to say that these products are largely good, they have tricky problems, and they should be places where folks can do good work.
Yet, given all that, the experience of working at Google is - often - seen one of slow moving mediocrity.
If a company like Google with arguably the most developer-friendly environment ever built and a ridiculous proliferation of products to work on can’t consistently get folks doing good, engaging work, then what hope does everyone else have?
The pattern I observed at Google (and across the industry) is that work is not at a consistent pace. There is a constant swirl of high complexity, high time-pressure projects. Sometimes these are driven by acquisitions, sometimes by external market demands, and sometimes even by a particular leader’s vision or passion.
These projects tend to be big (10s-100s of people), move very quickly, and disproportionately attract big hitters: talented, driven engineers who have a desire to get something done. These projects also usually accomplish their initial aim - though whether their aim is sustainable in the long-term is a lot more questionable.
It’s really hard to sustain that pace though. From the small N sample size of folks I overlapped with almost every one of those skilled engineers rotated on to a more sedate role at some point - either sustaining or growing their previous work, or moving on to a more research-y or lower-cadence project. But - most of them again ended up in the thick of it.
Most folks seem to go through a handful of different phases:
- Intensity, where they are deploying their skills (and pushing them on challenging projects). This isn’t always long hours, but it is almost always a lot of pressure - high visibility for example.
- Recovery, where they are focusing on quality, mentorship, maintainance or some other less pressured set of initiatives
- Growth, where they are actively trying, and sometimes failing, to work in a new area: a new technical area (back end to mobile, or networking to runtimes) or a new organizational domain (management, tech leadership, customer facing)
These cycles aren’t a set length, and my intuition is that they get longer as you get further in your career. I have seen some great folks go through this where they may have spent 2-3 years in the intense phase, a good 18 months of recovery, and then another 2 years in growth. I’ve also seen folks loop through the cycle in a 6 month crunch, followed by 6 weeks of aimlessness, then a 3 month growth cycle.
Google, by design or evolution, is pretty well set up for folks to repeat that cycle many times in their careers, whereas many companies try to keep people in a certain mode of working. The upside of this is that you get folks who have had long technical careers at Google, and who seem likely to continue - the list of significant projects they have worked keeps growing, and the time between somewhat fades into the background.
The downside is that it is very hard to tell the difference between someone in a “recovery” phase and some one who has fully slumped into doing full-time mediocre work.
There are certainly distinguishing characteristics - someone who has never demonstrated talent and intensity is more questionable, though it can be hard to tell with folks who have joined the company from a startup (in both directions). Similarly, a person who has done Things Of Legend but has been in recovery too long may have become stuck in the mediocre slump, and will not naturally move to growth (or back to intensity) on their own.
Outside of the person’s career development, this can often demoralise other folks on the team. If you add an engineer looking to operate with intensity to a team in operating differently, the newcomer will be endless frustrated. This is common for teams who are in recovery mode after an intense period: because of their pressure and delivery they justified additional headcount, but by the time the person joins the team they have passed the really critical milestones, and the newcomer finds they have joined a team plodding along at a sedate pace. Maddening.
To make it worst, that’s nearly indistinguishable from the case where a team has had its core drivers leave, and the remaineder of the group slips in to mediocrity through burn-out followed by absence of motivation.
The difference between the two is that the former group will generally start shifting into different modes: an individual will step up and start driving direction or move into leadership, some folks will move on to different teams, newcomer energy will be welcomed and deployed. That is usually most evident in retrospect though, which makes it very hard to evaluate which type of team you have joined, or even which type of team you manage!
The one part of this that Google doesn’t do at all well is acknowledge this dynamic. Career ladders and growth plans tend to be a Softbank-slide-like smoothly progressing march up and to the right, not acknowledging that a real career is peaks of accomplishment and growth separated by plateaus of integration, recovery and wobbly, struggling growth. Perhaps incorporating this explicitly would help folks think about their careers, and their teams, in a more holistic way. Probably wouldn’t stop the memes though.