Recently in culture Category

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.

It's performance-review season at work, which means more feedback surveys, and a few questions on an all-company survey like:

On a scale from 1 to 5, how strongly do you agree with these statements:

• Management makes speedy decisions.
• Management makes high quality decisions

I want to talk about one of the typically unnoticed factors that lowers these scores in larger organizations. To get there, I need to go back to the old DevOps standby, the Westrum Typology. Figure 1 shows a slide from a presentation I've given several times that shows some of the attributes of the three types.

As you can see from the slide text, this talk is about workplace toxicity. Not at all coincidentally, when faith in the quality of management decisions is low, perceptions of workplace toxicity are higher. But that's not the relationship I'm talking about today. No, today is about improving that "decision quality" score. This slide has a row bolded regarding 'bridging'.

Westrum's definition of bridging is reaching across the org-chart. Figure 2 shows how bridging works in a bureaucratic organization.

For a concrete example, Team Left is working with an API written by Team Right. However, this API has a few bugs that Team Left would like to get fixed. How does this work in a bureaucratic organization?

A member in Team Left is in the Latinx Employee Resource Group, and shares meetings there with someone from Team Right. Using their personal relationship, the Team Left member asks the Team Right member to get the bugs fixed as a personal favor.

If that isn't enough to get the bug fixed, Team Left's manager decides if this bug is worth all the trouble and decides (or not) to ask their manager. Manager 2 makes the same decision before asking Manager 3, who makes the same decision before ordering the other manager 2 to fix the issue. And so on. Bugs have to be a certain level of painful to bother with, or they just get worked-around.

This is what 'bridging is tolerated' means; there isn't an official channel for this, but if something happens out-of-band that won't be penalized. This brings us to figure 3, and the generative organization.

Let's look at our API bugs example again:

A member in Team Left has been working around these bugs and is tired of it. They look up the members of Team Right and DMs one to ask how to get a bug fixed. The Team Right person helps them through filing a bug-ticket and setting a severity. The manager of Team Left follows up with the Manager of Team Right to get the bugfix prioritized correctly.

For contrast, let's look at how our API bugs example works in the pathological organization where bridging is discouraged.

A member in Team Left is tired of the bugs they keep running into in the API from Team Right. They talk to their manager to see if they can get the Team Right to fix the bugs. Team Left's manager makes a decision about how much political capital is required to ask for this change from the manager of Team Right. If the cost is too high, nothing is done and Team Left continues to build work-arounds.

This is briging. Generative organizations cut a lot of overhead out of team communications. Dr. Nicole Fosgren has spent the last decade studying software-producing organizations and how effective they are based on their workplace cultures, and has shown year after year that generative organizations release software faster and with fewer defects. Not only that, but software companies have been increasingly adopting generative attributes specifically to attain these performance gains.

Because bridging shows up on the Westrum charts a lot, this is what people think generativity is about: lateral feedback and rewarded risk-taking. But there is more to this, and it's the intersection of DevOps practices and the less well cited parts of Westrum's work. Famously, DevOps is about busting the silos between software development and the people who are charged with stability. Silo-busting is all about improving communication (also known as feedback), and there are a variety of ways to do this.

Look again at figure 2, the bureaucratic organization. The "official channels" are up, over, then down. Inefficient, especially in the face of emerging issues. This is also the way that pathologic and bureaucratic require feedback to run. This slowness is why incident management processes are built to bust official channels, because speed of resolution is more important than making sure every manager has approved the changes. Even so If you're in an organization that already has a lot of bridging, and rewards risk-taking — a generative culture by the chart — your scores on "management makes high quality decisions" will start going down the larger your organization gets.

This has to do with the simple truth of the "management quality" question, which is asked of everyone, which means that the worker-units at the bottom of the org-chart far out number members of the management layers.

People believe management makes high quality decisions when they agree with the decision.

In a small org with just three layers of management, everyone kinda already knows the big decisions being made. But when the organization gets bigger? Well, figure 4 looks at a deeper management structure.

With a management chain this deep, the top manager (the M8) has maximal global context about everything and makes their decisions using that global context. Global context is the summarized local context of every manager below them on the chart. In a highly generative environment, the downward context flow is robust. Remember how the 'decision quality' question depends on the observer agreeing with the decision? That happens most often if the observer has the global context needed to appropriately assess the decision.

When you don't have that return context, you get figure 5.

With downward context flows like this, where the summarized global context doesn't filter down the chain, context needed to judge decisions for correctness is lacking so people are more likely to judge a decision as bad. If you want to improve your "decision quality" metrics, you need to improve how feedback flows down the management chain. To demonstrate how this works, let's look at a progression of announcements of a decision. First off, a simple decision statement:

We're closing our Beijing development center effective March 1st

If Beijing were actually Beijing, Indiana (not a real place) this statement could be given on March 1st while everyone in Beijing Indiana is having a talk with Human Resources about severance packages. Under the standard US playbook for Reductions In Force, this sort of sudden death decision has to be a surprise to everyone involved. What have is:

• A statement of decision.
• No context or justification.

You see this sort of communication in command-and-control environments, where the consent of the managed doesn't actually matter so long as they do their jobs reasonably. For the Beijing Indiana case, this is entirely expected due to how US companies mostly work. Layoffs are sudden death.

However, what if it really was Beijing China? Chinese rules give way more power to workers than US rules do, and closing a workcenter like this is something that requires months of notice. March 1 could be six months out, and the Beijing office will be slowly wound down. In this case, where everyone will have months to second guess the decision, a bare statement of decision is not enough. If you want to minimize the damage of a mass reduction in force, you need to communicate some of the context.

Consider this revision. This is the same decision announcement notice as before, but with a lot more of the global context included:

Today, Staff has made the hard decision to sunset development on EBULLIENT YAK, RELIABLE EMU, and GRUBBING SLOTH. Our market performance never met parameters, and feedback from customers was that our products were solving the wrong problem. We would like to solve the right problem, but research shows we're just not where we need to be for that. Thanks to all the engineering and product managers and engineers who spent the last year on this wild bet, you worked hard.

Given our last two quarters of performance, Wall Street needs to see us improve profitability. Rather than further our investment into these three products, we've decided to wind them down. Because these projects were the only projects developed out of our Beijing space, we will not be renewing the lease on our office and will close it. These measures should result in savings that will improve our perception on Wall Street, though it will be two quarters before those changes show in our bottom line.

For employees affected by this, we will be offering remote work opportunities and placement services.

This is far longer, but it also provides a lot of justification and context for this decision:

• Several projects have consistently failed to perform.
• The company had a massive miss in their minimum viable product projections for these products.
• The company stocks are getting punished due to profitability concerns.
• These projects were the only ones in the Beijing office.
• Workers will be transitioned nicely.

However, this is a great example of communications coming from the M8 level in the manager chain from figures 4 and 5: the very top. This sort of communication is actually pretty good in most companies! This is why that whole company all-hands meeting is so valuable. Figure 6 shows how various kinds of all-hands are useful for communicating global context.

There is a caveat about all-hands meetings: they generally consider things that would be of general interest to everyone below that level. So a decision that only affects your line made at the M6 level may not get mentioned because other lines don't care. Decisions like these don't get communicated down through all-hands meetings, so the context for those will have to be moved through a different channel. You could add more all-hands meetings, but synchronous feedback sessions like those get tiresome and take everyone out of work.

You need a different method of downwards feedback for most decisions. Unfortunately, the role of manager in a highly generative environment is to be an information router top to bottom, bottom to top, and side to side, summarizing as appropriate, and keeping track of which people are interested in which decisions. Feedback is totally a game of telephone, because the M4 needs to keep track of what each of their M3s are interested in so when they hear something in that list from the M5 they can communicate it downward, and it only gets worse the higher up you get.

Now that I spent too many words explaining the problem, here are some concrete steps you can take to improve your "decision quality" metrics in your already pretty generative organization. These are all ways to improve the quality of context flowing down the org-chart:

• If you are a manager whose team's work is dominated by planning processes mostly set by higher level managers — most agile teams in large organizations — if you're not already in the planning process, poke the manager who is for status. Also, communicate the summary of the balancing-act to your reports. They will thank you for the context.
• If you are a manager of managers (everything from M4 up in the above figures) explicitly ask your reports about areas they would like more feedback from you. Prompt them with quarterly and annual planning processes if they shrug and can't think of anything.
• If you are a high level manager of managers (M5-7 above) encourage your reports to get better about downward communication of context.
• You can fake an all-hands by doing a "newsletter" email once a month or whatever and put your downward context there. Put in your planning goals, top-of-mind items, and weighty decisions you're looking to address. For extra credit, directly solicit feedback. The point is to build organizational priopreception around decisions in the pipeline.
• Communicate the process, not just the final decision. People feel better about decisions when they have a perception of the progress behind them.

Many under-represented minorities (URMs) in tech quickly learn that who your manager and team-members are matters more than overall company culture. Majority people often learn this too, but non-conformance with stereotype means this lesson is often learned faster/earlier. The friction that comes with non-conformance is like any workplace friction -- It's noticed, and maybe commented on. A team with a good culture will adjust to accommodate (within reason), a bad culture will use techniques to erase the friction and increase conformance.

Some people will never be able to achieve full conformance due to visible differences. Others can get really close, so long as they edit how they present to the world. For those who can't visibly conform due to skin color, visible disability, or other reasons, sometimes conforming extra hard in other ways can make up for it. You've maybe heard these pieces of advice, if not given to you, but second-hand:

"You have to dress better than them so they take you seriously."

"You have to learn the King's English to go anywhere."

"You can't show too much skin or all they'll think of is fucking you, and not what you actually do."

"No one can tell you're in a wheelchair on Zoom."

"Learn the Christian holidays, you'll need to know the basics to get by."

"Always turn on video so they can see you're smiling."

"Never raise your voice. They can, you can't. Soon as you do, they won't respect you."

All of this paring away of yourself can be greatly reduced if your team culture, and the culture your manager builds, is good. You will spend less time working on conformance, and more on what you want to be doing. These are the people you work with most of the hours you're at work, so this is the culture that matters the most to you. This shit matters so much.

Which brings me to one of the big pathologies in tech-hiring at big companies. We all know the 20 plus hours of "phone" screens, live coding challenges, take-home tests, and six-hour marathon interview panels has some problems, but there is a thing that often happens after the candidate has already invested half a work-week trying to get a job with a specific manager/team:

We like what we see, but we think you'll be a better fit with Manager UnknownBozo as a Level 2 than Manager DudeYouKnow as a Level 3.
$138K/year, 5% bonus oppo, and $50K in stock, with a 1 year cliff and 4 year vest. You have three days to reply or we'll rescind the offer.

The old bait-and-switch. You put in all that fucking work, including several interviews with DudeYouKnow and his team, only to be told that you're going to be given to someone else you've never even heard of. Thank you ever so much for wasting my fucking time (respect for ExampleCorp drops).

Or as hiring managers like to think of it, making sure a qualified candidate doesn't get away.

No, really. That's what they think.

I really like this candidate, but they're not quite there for the team they requested. But we have open requisitions elsewhere, let's try to see if they'll accept one? We put in all that work to qualify them.

As I've gotten more senior, seen my share of team-based trauma, trauma-recovery, helped others get over their trauma, and watched URMs realize that the team I'm on is actually not a hellpit that forces compliance, I'm really feeling this right now. I'm damned picky over who will be my manager, because I've seen what bad ones do to teams. A good corporate culture is nice clue that their teams will also be mostly-nice, but the specific manager still matters more in my calculus.

For URMs this calculus happens all the time. For companies looking to improve their minority hiring, getting a reputation for bait-and-switching offers will hurt your goals. The old axiom of, "The candidate is interviewing you as much as you are interviewing them," is so true, only for URMs and senior ICs we're also interviewing the team not the company.

I'm looking to work for DudeYouKnow, who happens to work at ExampleCorp. Not ExampleCorp and DudeYouKnow if I can get him. So if I can't work for DudeYouKnow? I'm going to hate you so much and reject the offer, or insist on another round of interviews so I can re-interview the new team.