The third item on the Google re:Work blog about the five attributes of an effective team is meaning: work is personally important to team members. By now we have psychological safety, we can depend on our coworkers to deliver on their promises, and have enough structure and clarity to know the plans, roles, and goals of our team. But for some reason the work isn't personally meaningful. There are many causes of this, some overlap, some come in big swarms.
- Maybe you're the junior person on the team and are stuck with all the BUGFIX tickets, and never new feature work. You're learning lots about how the codebase interoperates and some of the strange decisions made along the way, but this isn't what you want to do. This isn't making, this is... janitor work.
- Maybe the team is a pathological den of vipers, and you're just here for the (fat) paycheck. Your real passions are elsewhere.
- Maybe the work you want to do has been consistently given to other people, so you've given up trying.
- Maybe you've been moved from team to team so often you haven't had a chance to build any sense of ownership and pride of work.
- Maybe your big passion is open source software, and the only way to make that happen is a closed source job with a paycheck.
- Maybe the release patterns are so onerous that all attempts to make them better have foundered on the shoals of past practice and you've shrugged and given up.
- Maybe you're the QA on the team and have been ignored so long you've habituated to not being listened to.
Whatever the reason, and there can be many, the job is... nice... it just isn't all that meaningful. And when that happens, the fifth item on the re:Work list (we believe the work fundamentally matters) simply can't happen. If you're experiencing this lack of importance in your work the big compensating behavior is:
You detach from work, because it only sort of matters.
Detachment. We saw some of this with the compensating behaviors for the lack of structure and clarity, but lacking this also causes detachment. You might participate in quarterly planning; but it's more half-hearted than earnest, throwing up ideas just in case you can make change this time, but privately convinced it'll never happen. When this is lacking, you see people focusing most on the current sprint's work rather than the long term goals, because the short term goals are easier to identify and use for motivation.
Also, you will see more focus on the people on the team than the work of the team. We have dependability now, maintaining that matters more than the work itself. While the work may not motivate (it doesn't matter), keeping your relationships healthy does. Again and again I hear about companies and organizations that are structured to magnify your connection to each other as a buffer against the psychological impact of shitty work.
So if you have been marinating in this sort of toxicity and get a new job, what kind of behaviors are you prone to in your new job?
- You are primed to think that the work you do doesn't matter, and will need heavy convincing to think otherwise.
- You are less likely to take quarterly planning seriously.
- You are primed to not bother with tiny bugs, not worth the effort to smash.
- You build cynical shields around getting attached to work.
That last is the most toxic behavior, and is also why pre-DevOps Operations teams were as nasty to work with as we were. I was totally damaged this way, and it has everything to do with why I lost my job in November 2013. Let my pain help you.
Old-school Ops teams
The Operations teams of yore, the Dragons in the Datacenter, Mordak Preventer of Information Services, the Bastard Operator from Hell, all had cynicism as a core organizational and team building concept. We did it that way because we were structurally disempowered, which made our work hard to connect with success. Yeah, we kept everything running -- but we weren't helped by how business processes or development processes worked.
All too often, Operations was seen as a service center: there to keep everything running, and be the professional installers and maintainers of all our systems. If you approach the maintainability and availability problem-space from a "service center" mindset, you delegate all the responsibility for availability on the team with the least power to actually affect it. The last decade plus of Site Reliability Engineering discourse has proven that availability is an end to end problem, not only a problem at the production endpoints. When you have a team who is responsible for something they only have a little control over, you get cynicism.
This is entirely human. Any time you have a group of humans whose job it is to clean up after other people's messes you get cynicism. I personally have seen the same Ops-team dynamic in:
- Animal Control officers (you did what to the dog?)
- Emergency Room professionals (you stuck that where?)
- Janitorial staff (where is the barf this time?)
- School Bus drivers (where is the barf this time?)
- Apartment move-out cleaners (did they not understand that stovetops need cleaning?)
Get a group of these people together and you get exchanges of dark horror stories, all as a way to bond with each other. Knowing others have seen the horrors you have makes those horrors easier to withstand. Go to conferences with a lot of former sysadmins and sit in the bar, you'll hear the war-stories of cleaning up after other people's messes.
This becomes a problem when the cynic starts someplace that actually doesn't have those attributes. They cynic all over your team, probably where you aren't around, and start either poisoning the team or alienating them.
If you're a manager or team-lead and see your new person showing some of these signs, there are a few ways you can help get them reconnected to work:
- If they're not paying enough attention to low level bugs (and the rest of the team is), in your 1:1 ask them how low stuff was handled at previous jobs. This will give you context for where they're coming from. You probably will learn more about the minimum threshold of suck before anything was worth fixing. This gives you what you need to point out how different this workplace is.
- If they're used to environments where the new kid on the team gets ignored until they've proven themselves, make sure they're included and listened to in planning. Eventually they will figure it out.
- If their motivation is open source, work to get them permission to commit fixes to upstream projects.
- Foster any sense of ownership they seem to be developing and defend it against all comers.
- If you are a team-lead and not the manager (the manager will never see this first) and you get the Cynic's Handshake of snarking about management, return the handshake (give them an anecdote of Management Gone Wrong from a previous job) to earn their trust, and start pointing out how this job actually isn't structurally disempowered and how much better it is from your previous place.
The signals here are subtle, and the causes are the kind you won't learn about in the first few weeks of them being there. Get them to tell stories about their past jobs and listen for patterns. So much of what you need to decompensate these behaviors comes in those casual conversations.
Your job here is to learn why they're not connecting with the work and try to build/rebuild that sense of importance. Some people never had it in the first place, they're the easier ones. The people who had it then lost it as a way to maintain psychological safety are going to be your hardest cases. Any time you try to get someone to overcome a safety reflex, you will be fighting.