Recently in culture Category

I've talked about this one to various managers over the years when the topic of work-scheduling humans comes up. There are two big frameworks for deciding who works which tickets:

• Throughput: Assign the person who will complete the task fastest to the ticket or story. Helpdesks often work on this model, since they're frequently quite under water.
• Growth: Assign the second most knowledgeable person to the ticket/story (or third, or fourth if you have that many people) so they can get experience solving the problem. This method solves the cross-training problem.

Both approaches are valid, and which approach a team takes is balanced against the incentives the team operates in. For a Helpdesk team, which is often under-staffed, throughput tends to be highly prioritized. For a Dev team with on-call responsibilities, growth tends to be the norm to make sure problems can be handled by anyone and to stop burning out your senior talent. Security teams tend to be a blend of both; with ticket-based security reviews urging throughput mindsets, where incident-response prioritizes growth. For Platform teams that tend to be involved in a lot of incidents due to running the systems that problems happen on, even if the problem wasn't actually the platform system, throughput mindsets are hard to avoid.

Now add coding LLMs to the mix.

The on-label reason to use agents such as Claude is throughput: spend less time working on tasks to improve your throughput. For Engineering Directors this is a great thing, because you can get throughput advances in your reporting teams without sacrificing engineering maturity, letting you lean on the product roadmap a little harder.

I'd argue that the throughput nature of LLM agents actually sacrifices some growth at population-scale when used in currently typical tech-companies. By moving from a purely generative mindset when building code to a revisionary mindset, going from writing code to reviewing and editing generated code, engineers spend less time learning problem-spaces in detail. Less time learning means taking more calendar time building up true domain knowledge. Coding agents are a somewhat different thing than the decades of "just add another abstraction layer and forget about the lower level details" we've been doing since 1970. It is true that most engineers in SaaS companies aren't spending lots of time hand-tuning assembly for execution on their ISA, and doing so is actually very bad practice unless you're in extremely specific problem domains. The difference between yet another abstraction and coding agent is the difference between abstraction and synthesis.

Abstraction is a distillation of a problem-space into an API, which can represented by grpc protobufs or function-calls, or whatever. You have inputs, expected actions, and expected results; the abstraction handles the details so you don't have to and often someone else is responsible for updates over time.

Synthesis is building novel functionality through combining multiple things to create a new thing. Humans traditionally have been the synthesis engines of code-production, but coding agents are beginning to automate portions of this.

Writing code is synthesis. Until the advent of coding agents, your IDE would give you support through syntax highlighting and API short-cuts, reducing the cognitive load of bare syntax problems to let you focus on higher level problems like how a function should handle bad inputs. The IDE gives you support for abstractions, but leaves the synthesis to you.

Once coding agents get added in, you shift from generating code, synthesis, to reviewing automatically generated code whenever the agent creates something for you. This is when cognitive biases come into play. Remember the mindset thing I opened this post with? An engineer under throughput stress is going to be less diligent about checking generated code in detail, and will shift more of their domain learning to troubleshooting test-failures and incident-response. Less domain knowledge will be developed during the initial writing. An engineer with no throughput stress, perhaps they're doing some for-fun coding, is more likely to take a fine toothed comb to generated code to learn what the generated code is trying to do, why it works the way it does, and what best-practices it seems to be following; in this throughput-free case the coding agent is a driver of growth.

Coding agents end up magnifying the biases present in the team's environment, enhancing positive feedback loops. The advertised reason to adopt coding agents is to increase developer throughput! The throughput bias is baked into the technology and its marketing, which means organizations requiring coding agent use need to take steps to provide some negative feedback loop enhancement to avoid large-scale degradation in coding quality and incident severity. Use of these agents make an organization more sensitive to growth/throughput bias shifts prompted by org-chart and quarterly goal shifts.

Combine the bias-enhancing quality of coding agents with the industry-wide retraction in US-based jobs for economic reasons, and you should be seeing a general retraction in overall growth mindsets among US-based engineers.

This BlueSky thread from Cat Hicks is on the money. 

There actually has not been enough reflection in the tech community about DOGE
all I see are "they're not engineers" "that's not what engineering is" I want a thick good really real piece to sink my teeth in about all the parts of this that ARE "like engineering"
I would write it except I want to stay safe
Engineering can be so much better than this and more than this. It's absurd how much we're resigned to this entire area of human work being held hostage by this kind of culture.
I do not believe that the majority of the software people I have worked with all these years sit around thinking, "I want cancer research to be destroyed." We have mountains to climb no doubt, we are trapped in some bad cultures no doubt, but I do not believe this of you for one moment.
Our tech community needs SO much more repair, processing, and collective reflection. The people who worked to support government and science were so betrayed by other groups. The people in flashy big tech cos feeling like their values were betrayed. Just so much repair needed here

I absolutely agree that our tech community needs quite a lot of collective reflection, processing, and work on repair. For a variety of reasons I've done a fair amount of casual research into recovering from trauma of various types. Some of this comes from having lived through the dot-com, great recession, and profitability-crunch contractions in the tech market, and some from good old fashioned life experience outside of the workplace. Trauma is trauma, and we have some pretty good ideas what chronic (ongoing, persistent) trauma does vs acute (single traumatic event) trauma.

Acute trauma: sudden-death layoff.

Chronic trauma: never being allowed to stay on one project long enough to get something good for your performance review, making you constantly fear the next layoff will have your name in the list.

Each of these affects the body and mind differently, and when entire populations are subjected to chronic traumas you get population-level reactions. When those chronic traumas are structural, as is the case with management culture in all of big US-tech, remediation becomes next to impossible. When individuals in this chronically traumatized population can't fix it, you get three big trauma-responses:

• Cynicism. I can't fix it, that's just how it is. If you set your expectations low enough, you get to be happily surprised once in a while! It's great.
• Heroism. Rally your fellow workers to overthrow the corrupt system! Who is with me? If not, I'll do what I can alone.
• Trauma harder as a way of life. Obviously, we're in a cut-throat system which means I need to cut throats. QED.

Big-tech management likes workers in the trauma harder category, is somewhat tolerant of cynics, and is designed from the org-chart out to prevent the heroes from getting anywhere useful and to redirect their energies in positive directions like burnishing the company's reputation among diversity hires. Do this for a few decades and you have an entire population of highly educated workers who have been trained their entire careers to look at the next sprint/month/quarter's deliverable for your team and kinda ignore what the rest of the company is doing. How your quarter's project to reduce stream latency by 15% at the p95 level relates to the efficiency of data-analysis in ICE isn't always obvious, don't look up or you might find out.

So take these workers who live in this pit of oppression every day for their day-jobs, and put them into an open-source community for their fun-time activity. What happens then?

• The cynics contribute as they're able, expecting corporate malfeasance to show up at any point, often seeing it when it isn't there.
• The heroes go about building a community that actually is healthy for a change! Whew.
• The trauma harder crew perpetuate corporate-style power structures because that's how tech works, accidentally reinforcing the cynics and frustrating the heroes

Fixing this sort of thing requires so much work.

• The cynics need to be taught that their defensive pessimism is not appropriate by repairing the structural injustices
• The heroes need to understand they're not alone and are being listened to through an effort of collective reflection
• The trauma harder crew needs to realize that alternate structures are viable, and understand the damage they've endured in the existing system through extensive processing

You can't do this overnight, it will take a revolution of some kind. Some revolutions are slow, like the heroes getting somewhere with governmental support allowing unionization to creep in higher and higher numbers until union contracts dominate worker terms and conditions rather than Radford salary reports. Some revolutions come quick like whole industries getting nationalized after a socialist junta and remodeled away from oligarchic control. Some come generationally, like China overtaking the US for big-tech exports forcing the oligarchs to look elsewhere to stay fat.

Our tech community needs SO much more repair, processing, and collective reflection.

I ran into a pretty common attitude regarding workplace diversity the other day. It was on a Q/A site. Paraphrased, the issue is:

Q: How can we improve the diversity of the candidates we hire?

A: That actually hurts the diversity of your hiring pool, because many people see "diversity!" on a hiring page and immediately go somewhere else. Who wants to be hired to a place that'll give a job to an unqualified minority just to meet some numbers?

The mechanism this answerer was assuming, that diversity programs are quota systems, has been explicitly illegal in the US since the 1980s. The Supreme Court at the time ruled that quotas like that were what this answerer said: racism, even if it was intended to correct for systemic biases. If you find your prospective workplace is using quotas, or explicitly hiring following racialized patterns, you have strong grounds for a lawsuit.

Within the last year, news broke of a company that got into hot water by someone posting "I'm hiring for X, give me all of your non-binary, queer, women, and minority leads please!" to Twitter. The strong implication by this statement was that this company was using a racialized hiring process which is illegal.

These days hiring pipelines at large US companies are engineered to avoid getting sued, and therefore don't use quotas. To build a hiring pipeline that furthers a company's diversity goals, while also avoid getting sued, requires several things:

• You must interview/treat everyone who applies equally.
• You must assess each application the same way.
• You must make your final hire/pass decision based on the merits of the application.
• (US) You must give preference to military veterans, by law.

So far, this is an "equity" argument. But building a system to improve your workplace diversity needs a few more steps.

• You can change the mix of your applicants by biasing where you advertise the job.
• You can't hide the job posting and pass out application links to your preferred groups. You still need to post them on your jobs page.
• Remove biasing language from your posting and job application process.
• You still have to treat all applicants the same once they've applied.

Equity, in other words.

Furthermore, some companies are beginning to reframe their diversity programs towards a "meet the market" approach. In that they assess their diversity program success based on how well their employee mix matches the potential job market for their roles. If a given position is 82% male in the job market, that's the target they'll push for; not 50%.

Equity, because that's the most legally conservative option if you want to avoid lawsuits for discrimination in US courts.

For many reasons, discussions at work have turned to recovering/handling layoffs. A coworker asked a good question:

Have you ever seen a company culture recover after things went bad?

I have to say no, I haven't. To unpack this a bit, what my coworker was referring to is something loooong time readers of my blog have seen me talk about before, budget problems. What happens to a culture when the money isn't there, and then management starts cutting jobs?

In the for-profit sector of American companies, you get a heck of a lot of trauma from the sudden-death style layoffs (or to be technical reductions in force because there is no call-back mechanism in the SaaS industry). Sudden loss of coworkers with zero notice, scrambling to cover for their work, scrambling to deal with the flash reorganization that almost always comes with a layoff, scrambling to worry about if you'll be next, it all adds up to a lot of insecurity in the workplace. Or a lack of psychological safety, and I've talked about what happens then.

This coworker was also asking about some of the other side effects of a chronic budget crunch. For publicly traded companies, you can enter this budget crunch well before actual cashflow is a problem due to the forcing effects of the stock market. Big Tech is doing a lot of layoffs right now, but nearly every one of the majors is still profitable, just not profitable enough for the stock market. Living inside one of these companies means dealing with layoffs, but also things like:

• Travel budget getting hard to approve, as they crank down spend.
• Back-filling departures takes much longer, if you get it at all.
• Not getting approval to hire people to fill needs.
• Innovation pressure: have to hit bolder targets with the same resources, and the same overhead.
• Adding a new SaaS vendor becomes nearly impossible.
• Changing the performance review framework to emphasize "business value" over "growth".
• Reduced support for employee groups like those supporting disabled and racial employees.
• Reorgs. So many reorgs.
• Hard turns on long term strategy.

If a company hasn't had to live through this before the culture doesn't yet bear the scars. The employees certainly do, especially those of us who were in the market in 2007-2011. Many of us left companies to get away from this kind of thing. That said, the last major down period in tech was over ten years ago; there are a lot of people in the market right now who've never seen it get actually bad for a long period of time. "Crypto Winter", the fall of many crypto-currency based companies, was as close as we've gotten as an industry.

When the above trail of suck starts happening in a company that hasn't had to live through it before, it leaves scar tissue. The scars are represented by the old-timers, who remember what upper management is like when the financial headwinds are blowing strong enough. The old salts never regain their trust of upper management, because they know first-hand that they're face eating leopards.

Even if upper management turns the milk and honey taps on, brings out the bread and circuses, and undoes all the list-of-suck from above, the old-timers (which means the people in middle management or senior IC roles) will still remember upper management is capable of much worse. That changes a culture. As I talked about before, trust is never full again, it's always conditional.

So no, it'll never go back to the way it was before. New people may think so, but the old timers will know otherwise.

I've been a moderator on ServerFault (a Q&A site like StackOverflow) for over a decade at this point. I am deeply, intimately familiar with what people in a hurry to solve a problem look for. They want:

• A how-to explaining exactly how to get from where they are to where they need to be.
• No faffing about with judgment calls regarding the wisdom of doing so.

This is good for Q&A sites, because not everyone is good at generalizing their solution from 30 other answers similar but not quite like their case. They want a step by step how-to that will get them out of the hole they're in. The most trusted ServerFault answerers (I was among them once) were good at doing this. We didn't throw RTFM at them, or cite section and sub-section of the manual they should have read. We explained why it went bad, how to get out of the hole, and perhaps some next steps. The better ones weren't judgmental in describing the foot-guns in play, but described negative consequences that you might not want to experience.

ChatGPT and related technologies act like higher quality answerers. You ask it "give me a step by step guide to get to where I need to go," and that is what it will produce. A step by step guide, no judgement about any foot-guns you're playing with. So nice. You don't have to put up with the judgmental best practices chorus to do so, and it isn't judgmental every time. You don't have to hope to get a nice answerer the way you do on ServerFault/StackOverflow.

Whether that solution is actually fit for purpose is not guaranteed, but it sure looks authoritative. This is where the cognitive biases come in to play.

Humans looking for help want one thing: someone who knows how to do the thing to help them do the thing. We asses "knows how to do the thing" many ways, but a time tested strategy is buried in the definition of the word mansplaining. To save time, these are the qualities we look for as a species:

• Is reassuring that this will actually work.
• Is confident in their knowledge.
• Is willing to go deeper if asked.

These three are extremely possible to fake, and humans have been doing so since humans were invented. The check and balance that Q&A sites like ServerFault and StackOverflow offer is voting on the answers, so actually wrong answers get some signal to validity. It have seen people be confidently wrong time and time again on ServerFault, and get cranky when their lack of actual knowledge gets called out.

Technology like ChatGPT automates producing answers that hit all three points, but lacks the voting aspect and any guarantee of actual expertise. In short, ChatGPT and related technologies automate the exploitation of human "sounds like an expert" heuristics. This is an exploit of the human cognitive system, and this is why you're going to start seeing it everywhere. It have complete faith that some startup somewhere is going to come up with the idea of:

What if we have generative LLM/AI create answers to questions that are then voted on by 'experts' and we sell the answers?

It's coming. May already be here.

For a while it seemed like Mastodon was the clear successor to a dissolving Twitter. Both had a similar mode of operation, so was familiar enough to people coming from the blue bird site. This wasn't the first migration wave from Twitter to Mastodon (I was involved in a 2017 effort) but it definitely was the largest. The wave is receding now, and with it we're seeing well reasoned critiques of Mastodon and the culture there. About that.

The main complaints look to be:

• Cultural:
  • Overly prescriptive culture around the use of content warnings.
  • Lack of awareness of the needs of marginalized communities of color.
  • Too many reply-guys
• Technical:
  
  • Only one 2FA technique, but no WebAuthN, SAML, or OAuth options.
  • Lack of unified identity across instances.
  • No concept of quote-tweet.

Cultural issues

This isn't the first time I've been part of a community that suddenly got swarmed with a whole bunch of new people who only sort-of speak the same cultural language. The Fediverse community responded the same way those older communities responded, by codifying in real time the unwritten social contract they'd been following and presenting it as de-facto policy written in concrete. If you've ever joined a community and got yelled at to READ THE FAQ BEFORE POSTING, you've seen this in action. In my opinion, this tendency drove a lot of the discontent behind content warning discourse.

Yeah, getting yelled at to READ THE FAQ BEFORE POSTING drives off new comers. It always does. It always will.

The arguments regarding lack of awareness of the need of marginalized communities came as part of the content warning discourse. "I shouldn't have to content-warn my lived experience" being the top argument against use of warnings. The second most common argument against is "I shouldn't have to content warn all political posts, because my living in this world is a political act."

The second argument came as a bit of a surprise to me, because I understood the "content-warn for politics" contract to mean, "Fediverse is a global community and not everyone is in the US, so flag your US politics posts so non-US people can skip them." It definitely was not "content warn anything that could be construed as politics." I attribute this misalignment to real time codification of social contracts getting it kind of wrong, and being taken as long standing policy by new folks. Hand in hand with this is a guideline to CW your tech-posts, because not everyone is in the tech industry and would like to skip them.

As for why content warnings are there at all, Christine Lemmer-Webber posted a brief explainer for why we have them and not another system.

Christine advocated for Tumblr-style tags, not a feature that would hide content requiring a click to view. Christine also pointed out that prescriptive rules for the use of CWs are kinda bad, and yeah they are. The CW system is a poorly defined feature that leads to a lot of confusion. The argument to "treat them like LiveJournal/DreamWidth cut-tags" is entirely accurate, even if most people these days don't know what that means.

The reply-guy comment is somewhat inherent to the subcultures that tried to move to Mastodon. The instance I'm on, octodon.social, has one of the biggest open-source software instances on silence (fosstodon.org) because the maintainer got tired of all the reply-guys coming from there. So when I see people piling into the new free software focused hachyderm.io and start complaining of all the reply-guys, I'm seeing a trend. A trend that isn't exclusive to Mastodon, in fact. Reply-guys are endemic in tech social spaces and it takes effort to redirect this reflex. Effort and assistive technologies like limiting replies to posts to the explicitly mentioned, or who are already followers of the poster.

Technical issues

Mastodon was designed for hobbyists to spin up instances and run on their own, and definitely not designed to be a scalable architecture for a kajillion users on the same instance. It can get that dense, as mastodon.social and mastodon.online prove, but it takes skilled engineers to keep it going.

Second, Mastodon is fully open source without a corporate backer trying to make money on top of it. This means there isn't a security department, just a community of security minded volunteers who try to get the project to adopt new techniques. Sometimes they make it in. Sometimes the maintainer doesn't want to merge the commits for whatever reason. This is a volunteer project.

Both of these mean that top tier corporate network security techniques like WebAuthN aren't there. They may be in future versions, but they're not there now.  This also means there isn't a unified identity across instances, because it was intentionally written to be a federated system with islands of identity.

As for quote tweeting, the maintainer has mentioned many times that he has no intention of adding them, and considers them actively harmful. He argues that quote tweets are used by griefer armies to direct hostility at victims, and quote tweets promote one way discourses rather than conversations. Because the maintainer doesn't want them, he won't accept merges that add them. Simple as that.

Quote-toots are indeed a tool with many uses, some good, some bad. Some of the twitter migrants want them back because they were using them to create conversations about things, and found value. Quote-tooting preserves attribution in a way that in-line quoting simply can't. Quote-tooting also gives the original poster feedback that their messages are circulating in new, potentially hostile communities, and to take actions.

Mastodon is a different community. The nature of federation means that the Fediverse has more structural separation between some communities than Twitter allows, which comes as a frustration to some and a blessing to others. Your view of the Fediverse is filtered by the instance you're on, and two instances will see different things. This is unsettling to many used to centralized social media systems.

I like it, but I also know it fills a somewhat different niche than Twitter or Tumblr do. Nor is it a true like-for-like replacement for either.

Part 4 of a 4 part series.

The fifth and last item on the Google re:Work blogpost on attributes of an effective team is impact: team-members believe their work matters. At this point we have most of the list.

• We have psychological safety.
• We can depend on our coworkers to deliver on their promises.
• We have enough structure and clarity in our roles, goals, and plans to believe them and work towards them.
• We consider our work personally meaningful.

But for some reason you still think the work doesn't matter. Why? There can be a few causes of this.

• Maybe you're on a team that's doing great work, but your employer simply needs more of you, needs to invest in your area more, or needs to listen to you more often -- and isn't. Many QA and Security teams suffer this blight.
• Maybe your organization is simply working towards the wrong problem. You have clear roles, goals, and plans, and your team is working on the right stuff (once in a while) but you aren't allowed to do that often enough.
• Maybe you're the one person on the team that fully understands what you're working on, and no one else is even trying to get to your level. This affects senior techs (both in tenure and industry experience).
• Maybe your company had a large layoff reduction in force and what is left of your team is merely going through the motions right now, while job-hunting on the side.

Most of these points are symptoms of a breakdown in the feedback cycle of decisions. I wrote about how context for decisions flows up and down the org-chart this past July.

• If your team is doing great work but is being under-invested for some reason (in time, resources, or attention), this is a sign of a breakdown in feedback down the org-chart. Assuming you're communicating your needs upwards, the context for why that advice is not being acted upon is not getting communicated down. Or what is being communicated down isn't being believed. Troubleshoot where the context is getting lost.
• If your organization is working on the wrong problem, this is a breakdown in feedback up the org-chart. It could be the message is getting lost along the way, or your part of the organization is suffering a credibility deficit so feedback isn't believed.
• The senior pathology of being the only one who knows how it works is in part due to that person not creating the conditions where other people need to up-skill. Throughput thinking (whoever is fastest does the work) does not create cross-knowledge because there is no incentive to learn something that someone else already knows. Growth thinking (the person who knows how helps someone who isn't quite there) is far better at that.
• Layoffs Reductions in force are intentionally terrible, everyone is going to come out the other side traumatized. There are changes you can make to the RIF process to reduce the damage.

Whatever the cause, the two biggest compensating behaviors for dealing with this trauma is quite similar to what we saw with meaning, detachment and cynicism. The difference between meaning and impact are that with impact you're sharing this experience with your whole team. This means you have a support structure in place: all of your coworkers going through the same thing, thinking the same bad thoughts about management, and reinforcing each other's assumptions about how it all works.

How I got broken

In my post about personal meaning I talked a lot about how traditional pre-DevOps Operations teams became people you didn't like to work with. Too cranky, snarky, and quick to anger. I talked about how the service-center approach to operations made for an environment that fostered toxicity, which definitely applied to me from 2003 to 2011.

Today I want to talk about how going through that with my entire team was subtly different than the isolation I talked about in the meaning post. The pathology we experienced was the second bullet above: we weren't allowed to work on the right problem often enough. This meant that from time to time the decisions coming down the org-chart were the problem we had to manage.

This happened often enough it destroyed our faith in management's ability to make good decisions, and slowly trained us into thinking that only we knew how things actually worked around here -- and no one listened to us. This made us build strong cynical walls because it was better to expect the worst and be surprised when things worked out, than expect the best and be surprised when things went terrible. The team itself was great to be on, these people got it and were there for me.

However, when the official feedback processes don't work, all that's left are the casual ones. So we became assholes. If someone came to us with a bad idea, we let them know it was a bad idea, and they should be ashamed for bringing it to us. The most tragic part? This actually worked; sometimes we could scrub some of the bad off before we had to just do it. It also got us a reputation for being cranky, snarky, quick to anger, and generally hard to work with. We wanted people to think twice about coming to us with a thing.

That said, because of our traumas and how we reacted to it, we were even less likely to be invited into the official process: who wants assholes in the room?

When I left there to go to a 20 person startup as their only Ops person, I brought this mindset with me. I literally had a seat at the decision table, but I was still treating the process as one I had to be unhealthily reactive to in order to participate. Their culture was far better than the one I had left, I just wasn't primed to see it that way.

Note: I need to point out that when someone with this trauma in their head starts on your team, they consider themselves a team of one. This trauma damages your ability to trust people just because you're supposed to. The above was all about this trauma happening to a team of people, but getting a new job destroys their sense of team. That's why a lot of the same advice I gave for the meaningful article applies here.

If you are a manager or team-lead, you will start to see pathologies here once your new person starts trying to build that sense of team. The cynic's handshake will happen where you can't see it. For reports who aren't traumatized this way, the handshake is off-putting. For those that are, well, now you have two problems on your hands.

In my case, what would have helped me was my manager sitting me down and explaining to me the cardinal rule of the agile rituals: flow is everything. The improv rules totally apply. Use yes, and or no, but to keep the flow going. Using a flat no stops everything cold and people begin to hate you. That would have redirected me into more healthy communication patterns, and slowly detoxify me.

For other things, employ radical empathy. In your 1:1s complete the cynic's handshake and get them talking about org structures at their previous jobs. Even if they don't tell you it was terrible, you can still smell the terrible. It took until 2015 before I saw what I lived through from 2003 to 2011 as terrible. This gives you the information you need for highlighting how different this workplace is from their previous ones.

This is one area where the manager/lead is only weakly effective, though. If you suspect you have a cynic on your hands, you can work with your other reports to get them to help nudge the newcomer onto better ways of communicating. This is long-term work, people like me adopt cynical shields for safety reasons and it takes time to get them to come down (or a hard knock to the head in the form of getting fired).

Part 3 of a 4 part series.

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.

Part 2 of a 4 part series.

The third item on the Google re:Work blog about the five attributes of an effective team is Structure & Clarity, team-members know where the team is going, who is responsible for what, and how those plans will be measured. The plans, roles, and goals. At this point you have dependability, you can trust your coworkers to do what they promise. What happens if the plans, roles, or goals don't matter for some reason?

• Plans don't matter: Short-term thinking. If plans don't matter, won't worry about them. Just focus on the next sprint or release. Ignore quarterly planning completely, because it won't matter anyway. Work on what hurts the most, because it feels better that way.
• Roles don't matter: If you don't know who is supposed to do what, you just go with whoever feels right; the org-chart isn't going to tell you. This means you develop a tables of "Person A deal with Feature B" mappings in your head. This sort of thing happens anyway for cross-team work, but if you're doing it inside your own team, maybe you have a roles problem.
• Goals don't matter: More short-term thinking. If the quarterly goals don't matter because your team is always veering from crisis to crisis, why bother worrying about them? Just focus on what hurts right now.

Above all, you are not focusing your work on the goals of the organization, you're focusing your work to make sure your teammates consider you dependable. You will absolutely tank an organizational goal (they don't matter anyway) to help a coworker out of bad situation. If you're not helping a teammate, you're working on something to take away some of the pain of operating/maintaining/building this thing.

Stuff that matters to you, not stuff that matters to your boss and whoever they report to.

And if you don't have structure and clarity:

• Meaning of work doesn't matter, because you're not tracking it. What meaning you find, is in keeping your teammates happy.
• Impact of work doesn't matter because... to be frank, this metric is a manager-metric. You can feel your work has plenty of impact, just not organizational impact. But really, without those plans, roles, and goals you can't identify your impact of work well If enough to build a sense that your work has (organizational) impact.

If you're a manager or team-lead, there are a few behaviors that signal a new person has come from a place with bad structure and clarity:

• Indifference to quarterly goals (because they haven't mattered before)
• No participation in setting future goals (why bother, they don't matter)
• Extensive participation in reducing problems the team is facing, but little participation around pursuing the goals of the organization.

That last one is tricky, because it's the one that makes everyone else think this person is pretty great. You know better, because you know what isn't getting worked on.

Getting this person to decompensate takes time, it always does. They're willing to work on the team-based goals, which you can definitely harness in the short term. Longer term, make sure to point out when your team meets the plans that were set a quarter ago, and keep doing that until they realize that those plans and goals actually matter here. What you're doing is pointing out how different their current environment is from their previous ones.

You can also embrace the power of your 1:1 meetings. Ask how planning was handled at previous jobs. Get the gossip on how it was (mis)handled. You'll get a lot of details you can use to nudge them into noticing we don't work like that, and achieving planned goals makes the whole team better.

Six years ago Google Rework posted a list of five dynamics that teams need to be successful. This list is familiar if you've been working in and around office cultures for tech companies.

1. Psychological Safety. Team members feel safe to take risks.
2. Dependability. Team members get done what they promise (see below).
3. Structure & Clarity. People have clear plans, goals, and roles.
4. Meaning. Work is personally important to team members.
5. Impact. Team members think their work matters.

Well, the first item on this list is familiar. In my experience the other four points get lost in the overall discussion, even if internal functions focusing on 'office culture' do pay attention to the whole list. Overlooking the rest of these is a problem for one big reason:

People maintain psychological safety above anything else, even if it means adopting toxic coping strategies. They can put a "5" down on the "I feel safe to share my opinions" question in the bi-annual employee sentiment survey, while also sarcastically belittling anyone who disagrees with them. They can put a 5 down on that question because they know, in the core of their being, that their opinion only matters to their teammates and their team is completely ignored otherwise. You can get deep workplace toxicity while also having psychological safety.

If your teams are missing any one of these points your teams are adopting toxic behaviors to compensate.

This list was intentionally structured, if you miss on one point you can't have the points below it on the list.

This blog series will cover the overlooked four points in detail.

First up is dependability: Team members get done what they promise.

If you can't trust your coworkers to get done what they say they will:

• You learn to only accept work you can do entirely yourself.
• When someone offers to help you, you always have a plan for how to deal with them not following through on their promise.
• If you find out that you actually need help, you will reach out for help as the absolute last step. You will do everything you can to avoid that, because asking for help almost never works out.

Question: In your working life, have you felt this? What taught you that others couldn't be trusted? How did that follow you to later jobs?

When I was in middle-school (roughly ages 10 through 13) American education was fond of peer education as a teaching technique. On paper it looks fine, by teaching a thing you learn it better, and by having a peer teach the thing you get more cultural context than the capital-T Teacher doing it. In my case, it was called "foursomes" because my class was split into groups of four. To provide an incentive, the team's grade would be based on the whole team's work. The mix of students in these foursomes was distinctive: 1 high achiever, 1 to 2 middle achievers, and 1 to 2 slackers (the exact mix depended on the class). We absolutely were not allowed to self-select the teams.

This team dynamic failed dependability for the high achiever. By tying the overall grade to the efforts of the whole team, the high achiever could only maintain high achieving by spurring everyone else to their high standard. Or, as happened way more often, by doing most of the work while seething with resentment. When talking to fellow high achievers once I got to college, our universal experience was that we couldn't trust anyone to help us in our academic work, and others would happily freeload off our efforts. Toxicity poisoned us all, and this carried over into my working career.

There is another area where a person's sense of dependability is compromised, and that is from having worked in a pathological environment. Pathological environments are driven by power, your ability to get anything done is 100% related to how much power you wield. People with power over you can make you do things. Maintaining your power is key to getting anything done. Because everyone is playing power games, you can't depend on your coworkers to follow through on promises -- they'll only do it if they get something from it, won't hurt their own power, or betraying you later helps them more.

The thing is, if you don't have dependability, you can't have the other points. If you can't trust your coworkers to do what they promise:

• The roles, goals, and plans your team has (structure & clarity) don't matter because you can't trust any of the promises that roles, goals, and plans are built upon.
• If you have a sense of personal meaning in your work, it isn't because of who you are working with. Or for.
• The sense that your team has impact in the greater organization is heavily compromised because you can't trust your coworkers to do what they need to do.

If you are a manager or team-leader, you can help people retrain from past experiences where dependability was a problem. The first step is recognizing when a new person could be applying inappropriate past coping strategies to your team.

The number one signal is that they never, ever ask for help. If they get stuck, they spiral in a vortex of self-hate, pretend nothing is wrong, go deep into expectation-management to buy themselves enough time to train up on the thing, or reach out to their non-work friend-group for help because they don't trust your team to be helpful. Or all of these.

The trick here is figuring out where this is coming from. Someone who spent a lot of time in volunteer-run organizations where people didn't prioritize the work is coming from a different place than someone coming from pathological environments where trust was a weapon. You the manager (or team leader) have power over them, and if you find they are managing your expectations of them or are hiding a lot of their troubles, you're probably dealing with someone carrying a lot pathological environment damage.

You can help decompensate by gently pointing out how this environment is different than their old ones. This will take time. They adopted this stance to keep themselves safe, and people don't give up safety techniques lightly. As with all of the advice I give in this series, your enemy is confirmation bias; all it takes is one event to 'prove' that this job is just like the others and they lose all the ground they gained.

• Point out instances where people asked for help, got it, and faced no negative consequences.
• In 1:1 meetings, ask how their previous jobs handled risk-taking (asking for help is a risk). This will give you the context you need to illustrate how this team is different. It'll also give you a chance to build rapport by sharing your own experiences.
• Reward them taking the risk of trusting others, positive reinforcement.
• If you see instances of help-shaming on your team, visibly smack it down. You need to demonstrate to the new person that this behavior is not allowed.

There is another pathology that also comes from terrible environments: having to 'prove' yourself before you let yourself trust others. Many pre-DevOps Operations teams worked this way, the newbie had to prove they had what it takes before getting fully embraced. The key concept here is credibility. If someone has credibility dynamics in their head, they know that the new person (them) gets griefed and harassed until they can prove themselves.

As a team lead or manager you can help short circuit this by explicitly granting them credibility:

• Call on them in meetings.
• Ask their opinion in private, and in a meeting say that their idea was a good one.
• Give them easy-win projects.