Every so often it becomes popular for a certain type of thought leader to campaign against the existence of hierarchies in tech companies. Frequently, this is coming from founders or very early employee engineers. Basically, people with significant monetary interest in not sharing leadership responsibilities. In a slightly more informed, slower world, that would probably be enough to defeat the wave of thought pieces and blog posts. But this is not that world.

The reasons why this tends to catch on each time are kinda interesting, even if the causes for its cyclical resurfacing are distinctly not. Frequent readers of this terrible blog will by now know that I'm going to start with the structural approach, so let's get to that.

Reasons people might not think hierarchies are useful

• They don't understand the value proposition of management
• They don't understand the skill set of management
• They are in management and don't like to do management things
• They are not in management and would prefer to gatekeep persons unlike themselves from influence
• They've experienced unuseful hierarchies and not useful ones
• They're Libertarians and unused to considering how being in a group dynamic has tradeoffs that should result in an overall positive experience

I'm not going to address each of these specifically, and I won't address the last at all. No point. Let's instead take it as read that the value in having a hierarchy isn't obvious to most people, and it usually isn't obvious because they haven't seen it actually work. This is doubly more common (and frequently the source of the thought leadership cycle starting again is directly from) execs and founders who are in management roles and have no idea how to do that job, and as such don't value the job.

Many unfortunate readers will have experience with execs that are terrible at being execs, would be terrible at being managers, and because of that constantly do a bad job at both while making it difficult for anyone else to do a good job at either. Sorry.

How to derive value from your hierarchy

For each tier in a hierarchy, there is someone in the tier above, someone in the tier below, and peers at equivalent tiers in other sub organizations. Let's say we're talking about:

• VP
• Director
• Manager

Let's go through these a couple of times

• The Director owns EXECUTION of their org's functions and assigned SCOPE of RESPONSIBILITIES.
• Their VP owns providing necessary RESOURCES for success, and guidance for EXECUTION (how much varies depending on how far up we are in the hierarchy, at VP/Director, not very much)
• The Manager owns EXECUTION on the sub tasks of the Director's Org's functions, and the associated sub SCOPEs of the component RESPONSIBILITIES
• The Manager is owed necessary RESOURCES for success
• The Manager is owed guidance for EXECUTION from the Director
• The Manager is held accountable for success by the Director, possibly modulo resourcing
• The Director is held accountable for success by their VP, possibly modulo resourcing
• The Director (attempts to) hold their VP accountable for RESOURCES necessary for success of the assigned RESPONSIBILITIES

Hopefully you get the way these responsibilities and relationships stack across the levels. 

How hierarchies overlap with getting stuff done

OK so yea abrupt left turn but all the above is just context necessary to understand what this is about. It's this:

I'm usually having this conversation because someone is trying to contextualize what leadership does, how they should be interacting with a system, or there's something specific relating to career growth and responsibilities that we should cover

I also like to mention that this is sort of an idealized version of what it should look like, many of these parts are often missing or incomplete, and knowing where those voids of organizational ownership and accountability are can be a multiplier in effectiveness, because you can better understand why things are failing and look for implicit or invisible work that is helping things succeed or causing them to fail. Seeing real gaps where something isn't handled (or isn't handled well) because no one owns a tier of execution is incredibly illuminating.

This builds from the bottom up, with the rough following structure to the pyramid:

Learning Environment

This is the actual baseline work that needs to get done. Hands on keyboard, doing a thing. Usually executed as a component of learning your way around.

Technical Implementation

This is the things that surround the foundational technical work. You can't just type code into space, so there's some implementation stuff that you'll directly rely on. An example here is something like "we code in python, on an linux". 

Implementation Assumptions

These are the assumptions that are baked into the first two layers. Things like "I have a functional DNS system," or "I have access to other services that are outsourced to other teams". Roughly, it's an initial boundary layer between what is inside of your influence and what is outside of it.

Implementation Complexity

This is the meta-complexity of how those implementation assumptions interact. Someone can dramatically change the scope of work that needs to be done if they outsource a critical part of the service ownership, but are they pushing risk or concerns elsewhere that could lead to problems further up or down the chain. A common example of this is an executive saying "Well, this would be easy to do if we'd just use (other solution)," ignoring that implementation of that solution would be not viable for reasons that aren't in scope for the project. This is also known as Socializing the Risks and it's how a disturbing amount of people get ahead in life. 

Functional complexity

This is where we get into the broader scope of if the implementation serves meaningful goals - moving outside of the direct technical space and into "what function does this serve, and does it do it well?". You see examples of this being done poorly when can achieve the desired outcome, but it's incredibly toilsome to do so, or in the positive sense, when the system you're interacting with encourages a functional outcome with a minimum of overhead. 

Solution fit

Meta-change complexity

Long term vector impact

Organizational Health Impact

You're doing all of these things, but are you doing them in a way that is sustainable, healthy, and creates an environment that doesn't intrinsically burn people out? Does the organization recognize signs of overburdening and address them? Does it change when it sees them? Organizations by default want to consume people, have you made that more or less likely?

As the real fans in the chat know, I have to switch things up frequently or my ADHD gets bored. So, at this point, I'll cover the last 3 from the top down, because they're easier to explain that way. 

Execution on vision

The company has a vision of a thing it wants to achieve. The best SaaS provider on the planet, whatever. The executive leadership team is responsible for defining this and pushing that vision forward. 

Mission vectors

From that vision, there are specific areas of focus that leadership will prioritize and drive. You can't fix every problem at once, you can't go after every opportunity, this is the strategic negotiation and prioritization that executive leadership should be doing. What are they betting on? What are they giving up? The output of those conversations will be a set of mission vectors that they want to execute on. Something like "We want to capture this percentage of this part of the addressable market for our product". 

Company Function

This is how the company achieves the mission vectors - defining organizational level responsibilities, functions, how the company operates and manages moving forward, in pursuit of those goals. The decisions for things like reorgs to better move groups solving similar problems closer together, etc.

note bene: I may come back to this one to expand it some, and am interested in how it does/doesn't make sense to people.

So this came up in a slack and then i had a long expansion and someone asked me to make it a post so they could link it to people and well ok fair enough  

It’s gonna be heck of low effort post though

Technical positions can be thought of in the following model. That's not to say that they should be, or that this model is good. It is a model, don't mistake it for the reality.

- Scientists are primarily focused on expanding the capabilities of the field and finding novel ways to cause novel things to happen.

- Engineers are primarily focused on turning theory and high-level practical guidance into functional machines and infrastructure.

- Mechanics are primarily focused on whether the machine or infrastructure produces the desired outcome.

- Scientists mostly don't care about what the Mechanics think about their efforts, and only kinda care about what Engineers think.

- Engineers frequently are frustrated at the abstract nature of Scientist efforts, and often deeply horrified at the ways Mechanics get things done.

- Mechanics mostly don't give any fucks about whatever Scientists are doing, and often think Engineers spend way too much time caring about the how instead of the result.

- Scientists all-but require formal education to perform in that lane.

- Engineers usually have formal education, but it could be a deep trade school instead of academia.

- Mechanics are often self-taught through experimentation, but may have gone through trade school or academia.

- A Scientist was involved in figuring out how dead dinosaurs can make energy (and murder us all).

- An Engineer was involved in figuring out how to use that energy source to make efficient motion happen.

- A mechanic is involved when the damned thing breaks down.

- A coding Scientist is working on new algos, new crypto, fundamentally new ways of doing things.

- A coding Engineer is working on making things (based on science both old and new) run efficiently and smoothly and predictably.

- A coding Mechanic is working on shipping the fucking feature and really doesn't care what the Engineer lead thinks about their code smell.

Unfortunate truism in this model's exhibition IRL:

- The layers tend to operate the same way drivers do about other drivers' chosen speeds.

- The layer above you is lost is lost in the fucking clouds. 

- The layer below you refuses to see the big picture.

These things are actually about APPROACH not background. My computery shit is 100% shade-tree mechanic. My management theory is fucking science. My org building is some deeply skilled engineering. In each of them I'm using different approaches because that's what mostly works well for me. These are tools, not labels to be use to confine and define people.

This is about something that I wasn't ever able to explain well until recently. I've been using the same approach for a long while, but making it understandable was difficult.  I don't know if this achieves that. 

The key that unlocked the attempt was applying something I learned a while ago, and that I say a lot about my own processes, which is the next header line. While discussing what I was trying to get across with some people, I realized that what I was actually proposing was "go forth and Harry Tuttle your company" and honestly, that's probably the best possible metaphor here. Anyway, that thing I say too much: 

The purpose of a system is what it does

This is one of the things that I say often in my professional discussions, obnoxiously frequently in political/societal discussions, and at all times it is the foundation of my analytical efforts.

I do not care about the intended purpose of a system. I care about what it does. 

I encourage you to feel the same. You will occasionally find people who say that it's important that we care about a system's supposed purpose instead of its demonstrable purpose. In general, those people have a vested interest in the system's current impact not changing.

This focus of concern is probably fairly obvious to you. The implications may be less obvious.

• Most systems are tuned for intended purposes that are not the system's actual purpose
• Many systems have stated goals that are orthogonal or hostile to their actual purpose and demonstrable impact
• Many, if not most systems have metrics being used that aren't well-correlated with the system's actual purpose
• Many, if not most (if not actually almost all) systems are being fine-tuned and managed in ways that do not, and other than accidentally, can not improve the observable outcomes

This, obviously, is a Problem™. The usual solution is to work harder on correcting the output. Sometimes it's a whole bunch of "let's figure out the correct metric so we can measure what is happening." Sometimes it's someone doubling down on the selected or obvious metrics. Sometimes it's "accountability" impacting people's performance reviews because the system they work in isn't doing it right. This is all completely wrong, and it is also why this problem is so common. You have this problem because you have mismanaged the system in question. Applying more management of similar intent is only going to make it worse. You can't fix bad code with more code; you can't fix bad metrics with more metrics.

Are you yelling at me?

From this point, I'm going to be fairly adversarial in tone. Try to avoid reading this as me yelling at you. I'm yelling at your execs, at my execs, at every exec either of us have ever had. I'm yelling at the industry we exist in and industry in general. I'm yelling at the forces that market capitalism focuses upon us. I'm yelling at the banquet hall ceiling about this turbulent priest and no knights are about to walk in then out again. I'm just yelling, but I do have a point.

OK, let's get weird 

Managing an organization to the goals of the organization is some extreme "skating to where the puck is" bullshit.  Knock it off, immediately. 

Stop trying to make complex mechanisms do what you want in ways that make sense to you.

Start trying to make complex mechanisms exhibit the foundational attributes necessary for the thing you want to happen regardless of what else the system is supposedly doing. 

It is, unfortunately, sports metaphor time. Let's stick to something that we relatively simple like "track." The athlete wants to win. Does the coach manage towards "winning"? Does the coach manage towards foundational elements, and assume that winning is a byproduct thereof? Is there a split? Now let's strain this poor metaphor. What if it's a relay race competition with 100 competitors per team? Is the coach going to manage to "go win" or is the coach going to manage to the fundamentals of what a winning team looks like?

Answers are pretty obvious, right?

So why the hell are you trying to manage a security team to "numbers of reviews" or "ticket closure rate" or "how long a consulting ticket takes to get to done"? Do you think any of those lead directly to "winning"? Do you think any of those help with retention, which is undoubtedly your actual hardest problem this decade? Are you creating metrics based on "how annoyed my exec peers are with me" instead of "how healthy this security team is"? Yes. You are. The question is: "Can you make yourself stop doing that, and actually lead your org as if it is what it is, an organization made up of humans?"

Uh wait what?

Define for me what a successful security team looks like. What it feels like. Define for me what the vibe is. Define for me how people talk about that one team they were on that just fucking worked. Yes I'm serious. I'm stone-cold, dead serious. All of your metrics are causing you to push effort and people into things that aren't actually improving the things that cause your metrics to improve. Read that again if you need to. OK fine, another metaphor:

Artificial metrics are flying by instrument. They're individual "better/worse" dials that in amalgamation are supposed to tell you which way things are going, as long you are paying attention to the correct combination of them at the correct moment, and don't over-react to the feedback loops and crash the whole thing via a PIO. Instrument-only flight is harder than visual flight, it takes extensive practice, and the mistakes have worse repercussions.

You can instead choose to just fly visually. It's easier, it's safer, and it'll get you where you're trying to go. The thing is, your entire industry thinks it's impossible, and worse, they think it is irresponsible. They're kinda right. You have to be good at the innate skill of flying, instead of the skill of navigating by instrument. Guess which one the "become a manager in tech" system produces. Bonus points: recognize how that is itself a PIO. 

Bonus Bonus Bonus points: Consider that if you've learned the skillset of visual flight poorly, and you don't use the instruments to correct yourself, how will you ever know it's going wrong in time?

Yea, the thing itself is easier to do this way. The thing itself will produce better results when done this way. You cannot hire fools to do it. You have to actually hire for emotional intelligence and the ability to connect on a personal level with all your hard-skills engineers. I do actually know how to do that but I won't ever write that one down. That's my whole secret.

OK so, confused? Is this where I sell you on the self-help book and the associated cult membership? Nah. 

Integration

You're already routinely discussing terms like "emotional intelligence" when talking about leadership and management skills, even with the most obnoxiously "i am my code" people you know. I'm asking you to take those ideas and apply them as if they're primary skillsets with important uses, instead of something that's "useful for keeping the employees feeling like you care." I'm asking you to set aside the inherent sociopathy in managing people as widgets while dealing with them as people. As is often the case in all these posts, mostly I'm asking you to reject cynicism. Emotional intelligence matters for every single thing about managing humans. Why wouldn't it matter for managing your team's collective direction and output? 

What I'm getting at is that defining how you run your org should be based on those soft skills that actually affect how the people who make up that org interact, rather than what fits cleanly in a ticketing query. The query can tell you if your org is doing the things you think it should do. It cannot tell you if your org is functioning correctly, healthily, or sustainably. If you manage to the ticket metrics instead of those things, you will lose those things, and never quite understand why.

WTF I cannot put "team vibe" on a dashboard

Not with that attitude you can't. Yea, it is gonna be hard. I'm not trying to say this is easy. Your company has processes in place to make sure you don't do something weird like this. You're going to have to work around them for long enough to prove that you have a point. This is a subversive strategy. This is the Harry Tuttle method of organizational management repair. If you're lucky you can define this well enough that your own management layer can give you a window to prove it out. You won't be. You'll need to prove it out without pre-clearing it a few times, probably in a few places, before people accept that you've got a knack for this.

You won't have people crediting that the thing you're obviously doing is what you're actually doing. In general, other managers will view this as being unfairly manipulative since obviously you're misleading your people about what the real priorities are and how you will help them achieve success through them. Ain't nobody ever going to approach you to say "hay your team metrics are great and everyone wants to work on your team and you haven't lost any engineers all year and what's your secret?" They're going to ask your boss how long they will let you get away with running a good feelings daycare. Gravitas is the currency of tech engineering management, and you have to deliberately disclaim it at every opportunity. It's hard.

What matters for your team/org's success is the fundamental human relationships, comradery, esprit de corps, support and space-curation, and especially, all of the prior while treating-em-like-adults. Those things make up the totality of why people want to work on your team and are excited about working with and supporting their peers. These are not invisible things. These are things you can pay attention to, structurally. These are not things you can quantify with numbers. You're going to have to get comfortable with forming, expressing, and defending opinions based on things besides "data." Not because you don't have data, but because you don't have quantifiable numbers that represent themselves, and our industry is poisoned into believing that only such things are data. We've got thousands of years of evolution helping us understand how group dynamics are flowing. Yes, using that is a skill set. That's my point. Build and use that skill set. Learn how to read people's reactions. Learn how to understand people's motivations. Learn how to see how people work in groups and as individuals. Do the work.

Cheery "You can do it!" motivational section

When someone says "what metrics do you manage by?" I say "mostly feedback in 1:1s, career conversations, impact feedback on my people from their peers, and to an extent, retention." When they ask "how do you quantify those things?" I ask them "why the hell would anyone try to quantify those things?" 

Even the most self-deceiving engineering orgs, insisting that they make always their decisions on quantifiable data, do most of their ratings and promotion decisions based on loosely-defined statements of support and feedback forms. Objective decision making about subjective human performance is, at best, a beneficial fiction. I submit that the benefits have long since expired.

Everyone has opinions. This leads children to think that all opinions are equal. Look around you, that is demonstrably not so. 

Someone promoted you at some point because they thought that your opinions are usually right. Take a firm grasp of that and your confidence that long-term, the people matter as much as the mission. Forcefully reject all the cynical nonsense they try to sell you as pragmatism, seriousness, managerial gravitas, and lead. Lead by demonstrating that the people are the most important thing. Lead by insisting on good, supportive, healthy culture. Lead by demanding that people treat each other and themselves fairly and respectfully. Make that team a thing that those people will talk about being the best team they were ever a part of for the rest of their lives.

The work will happen. All those outputs you were worried about will flow in droves. If you have to, you can build a dashboard of nonsense based on the quantifiable outputs. Just don't go mistaking the numbers for what matters, or you'll lose what actually matters, and then you'll lose the numbers too. 

Bonus bonus bonus bonus bonus points section:  How would the company overall perform if it treated customer health/growth the way I'm saying you should treat employee health/growth?

Team Norms

Welcome to the team norms document for <my org>. This document refers to us collectively, sometimes to you the reader, and sometimes to the leadership layer. Depending on your place in the organization, you may have multiple expectations from this document or for you in it. This is not my document. This is our document. You have suggestion rights, and you may use them. Keep in mind that, I will maintain ownership of this doc and may show up in your calendar to talk with you at length so that I can understand your suggestions. 

This document is not finished, and is never finished.

Hierarchy

This is a group of peers, mentors, and mentees. It has a hierarchy anyway. 

Our hierarchy exists primarily to divide work up to persons with aptitudes and interests aligned to that work. That does not mean that we will pretend it’s all collegiate fun and no one is anyone’s boss. You shouldn’t feel hassled by the fact that you report to someone, but if we pretend that you don’t, all of the power dynamics inherent in that fact become hidden. 

Let’s keep those dynamics out on the table where they can be referred to as needed. Power dynamics matter. They influence what we say and do, they influence how we respond to ideas or requests, and they influence the feedback we give and receive. It is always OK to mention them as part of any of those things. Make the subtext into context and it loses much of its unearned power. Do not insist that people who need your approval are always free to say whatever they want. Prove that it’s true, and they will. Fail them once and you'll never get another chance.

Inclusivity

This is the part where I say something about how more diverse teams build better products, and how diversity of backgrounds, identities, and opinions leads to better decisions. That is all true. However, in this organization we value diversity and inclusivity because that is the morally and ethically correct thing to do. That it benefits us, our customers, and the company is nice. We will do it regardless of how true that is. If inclusivity fails to benefit us, our customers, or the company, we will seek to realign that conflict rather than cease being inclusive. If you have a concern with this, feel free to discuss it with your lead, or just bring it straight to me. I’ll be happy to help you understand.

We support each other

If you have a payroll execution problem (that’s “mechanics of being paid,” not “compensation plan”), it’s expected that your lead treats it as a top priority. If you have a time off/emergency problem, it’s expected that your team treats covering it as a top priority. If you need to escalate something to a lead or their lead and need to stomp on a meeting, it’s expected that you will do so and they will make time or work out a time with you. Trust batteries require recharging, and knowing that we all have each other’s backs is how we keep those batteries trickle-charging at all times.

Working Hours

We do not care about your working hours for their own sake. We will not care about your working hours for their own sake.

We do care, immensely, about your ability to communicate with your peers/customers and their ability to communicate with you. We care about you getting your work done, and people who depend on you for getting their own work done. If your working hours don’t conflict with that, then they’re OK. Approach this as if it’s an important, key part of being successful here, because it is, and seek consensus with yourself, your peers, and your lead.

It’s up to all of us to keep “respecting people’s working hours (modulo emergencies)” as a shared norm. What’s that mean? It means unless you’re working on an emergency, or are doing so to flex your time elsewhere, you shouldn’t be working late. 

Please do not send non-emergency emails or chats late. It encourages other people to work late to respond, just out of politeness if nothing else. This goes on for a while and suddenly we’re responding to chat at 3AM because that’s what people expect. Gross! Let us not do that. If you have something you’ve got to type out, well, that’s the way the brain works sometimes. Scheduled send is your friend. Send the email or chat message off during the next normal working hours. 

The counterpoint is: please do not make a habit of working late and using scheduled send to hide it.

Out of Office

It's not anyone’s business why you’re not working today, modulo that there are boundaries where HR/Legal says it has to be someone else’s business when it’s multiple days. Aside from those boundaries, if you’re taking the day to watch the kids, go to the doctor, buy a car, or sit on the porch and contemplate your infinite being, that’s all fine. 

Whatever it is, it’s fine.

Don’t tell us. 

Don’t ask people about it (again, outside of HR/Legal boundaries). 

Sending a message to <internal comms> and setting your <internal messaging> status to an OoO note is sufficient notification. Block your calendar if you have time, and keep Workday accurate. We understand that many of you will have lots of societal pressure built-up about saying why you’re out and apologizing about it. Please do not. If you want to share something you were/are doing, that’s of course fantastic. What we’re avoiding is the implication that you have to justify your OoO to the team. This norm only works if we all stick to it. Please accept that little bit of discomfort you feel not explaining your absence as your personal contribution to an environment where people don’t feel the need to explain that they have a life and sometimes it interferes with work.

Meetings

There are four types of meetings:

1. Just hanging out - This would be a wacky thing pre-covid, but it’s OK now to just have a meeting with some people to chit-chat. If someone invites you to a hangout meeting, you are 100% empowered to decline without explanation. Don’t go bugging people to accept them. 

2. Announcements - This is a meeting for big time announcements and possibly immediate Q&A. An invite is expected to be accepted and you’re expected to show up, modulo time off and working hours.

3. Decisions - This is a meeting where someone will make a decision. Other people are there to influence or inform that decision. If you’re optional, feel free to not show. If you’re mandatory, please do attend. If you are going into a decision meeting and the deciding person is not there, and has not sent someone to represent them who will make the decision, the default and correct thing to do is reschedule that meeting. Decision meetings do not happen without the ability to make a decision.

4. Discussion - This is a meeting where we are going to discuss something. Being optional or mandatory on the invite isn’t very informative. Most of the “should I go or not” comes from “are you concerned that the discussion will lead towards decisions you disagree with if you do not attend?” It is always appropriate to wait for a break in the meeting flow, and ask “does anyone expect an opinion from me in this meeting?” and if the answer is “no,” and if you don’t feel the need to be there, leave. It is OK to leave a meeting you don’t think benefits you or benefits from you being there.

Meetings do not self-justify. But also, don’t be the person constantly complaining about meetings. Find a balance. While trying to do so, remember that any decent meeting has someone running it, someone in charge of a decision (if it’s a decision meeting), and if it was complex or large, it had an agenda well before it was scheduled to begin.

“Someone in charge of a decision” does not mean “a manager/lead.” It means someone informed to make the decision. That may well be you.

Virtual Meeting Expectations

Unless you are presenting, we have no expectation that your camera remains on. If you’re presenting internally and don’t want your camera on, I will usually defer to you. We have to work with partner teams that may have different norms, so we cannot set an absolute here, but within our team, cameras are great for empathic or emotional communication, but not a requirement for all communication. For many people, it’s mentally taxing to see your face reflected back at you constantly, and we’d rather you spend those mental cycles and daily willpower getting things done, and having enough left for yourself at the end of the work day.

Focus time

Feel free to book focus time onto your calendar. Please ask people to treat it seriously. Please direct them to your lead if they make a habit of not treating it seriously. We recognize Wednesday as a standard day for this, we encourage you to expand upon that if you need to. Please don’t let more than half your week become blocked-out focus time, and if you’re in a lead or coordinating role, it probably needs to be 1.5 days or less. You are encouraged to discuss coordinating “no meeting days” as focus time inside your teams and working groups, but please get peer and lead input before finalizing a decision. 

Development Expenses

The guidelines we have in <Internal Documentation> hold true for our organization, but we want to be explicitly clear that using them to their fullest is good, proper, and correct. We will bias towards “yes” for things in this category, and not “are you sure you really need that?” That bias is subject to review if it feels like it’s being abused.

Organizational Cynicism

We reject organizational cynicism at all times, and use a broad definition of the term to do so. That doesn’t mean “don’t act like nothing is cool.” Organizational cynicism is much worse than that. Organizational cynicism is “We have an approval gate on that but it’s just a 100% rubber stamp because no one has time.” It’s “There’s probably no value in this workflow, but everyone expects us to do it.” Things like that will strangle an organization, ruin its reputation, burn out its people, and exhaust its partners’ goodwill. At all times we seek to be an organization that deals with itself and its neighbors honestly. 

That honesty can be very difficult. For example, it's never easy to tell someone that you’d like to help but you’re resource constrained and rather than giving them some (insufficient) attention, you’re focusing on things that are more important. It may well be correct though for the more important thing, for yourself, and even for the less important effort that is disappointed by the decision.

A good way to think about this is that the company collectively decides where to put resources (people, time, money, etc). The company is never completely right, and frequently quite wrong, so we flex and make our own decisions too. The combination of those is how we collectively decide what’s important. It’s good to stand by those decisions. It’s also good, when there’s time, to say “are we sure that’s still the right decision?”

Yes, that’s contradictory. Sorry. (Not sorry.)

What do we do when we don’t follow the norm?

This is a document about our collective cultural norms. We’ll find other ones we want to document, either to fix something that isn’t working, or canonicalize something we like. While these norms will change over time, our default should be to resist change, and course-correct acting outside them. 

Your key phrase is: “We don’t do that here.” There’s no judgement made or implied. Point out that that isn’t how we do things here, and move on. If someone insists on it, then talk with them separately or bring it up with their leads. Escalate that if necessary, but it shouldn’t be. 

For the most part, we’re asking people to be their honest self. Where we aren’t doing that, we’re asking them to make space for the people they work with to feel free to be their own honest selves. In both cases, politely and calmly reminding someone of our culture’s expectations is helping all of us, and is a good thing to do. The best response to being reminded of the norms is “Thank you” and moving on.

OK, but what if it’s my Lead acting outside the norms?

“We don’t do that here.” 

But power structures can make that difficult. It’s OK to not rush to be the person saying it if it’s difficult for you. It’s OK to do that in private, or ask someone else to do it if that’s easier. It’s important that it happens, but that happening can come later if need be. The goal is to remind us of our norms, not to make you individually accountable for enforcing them.

This was sent out to my part of the Google Security Engineering org by myself after consultation and input with my local-group management peers. If you’re at Google, it’s visible as a /2020stress short link. This version of course has some edits.

I should preface this with my own perspective. My neighborhood in Security Engineering at Google has been hitting it’s goals very, very well this year. And thus I’m certain that we’ve got people who are working way too hard, because there’s no way we should be hitting all our pre-COVID goals in the midst of <waves vaguely at everything>. Then there were some conversations with people reaching out for advice about how they felt off and weren’t sure what was going on. Some of these people haven’t ever been “burnt out” before (have I mentioned, Google Security is a great place to work). 

I realized that we had a mix of “a lot of our people are working too hard right now” and “a lot of our people are overstressed in new ways right now.” That’s a combo that causes a fragile risk. What if two TLs and two senior engineers burn out hard at the same time? Those green KRs sit there staring at me, whispering “we’re costing too much, and you can’t see it.” My management peers and senior engineers/TLs have been talking about it, and a concrete and sensible plan is being worked out. I decided it was time to do something proactive, even if a little messy, about the way people were feeling, and my peers were supportive.

I’m not claiming expertise at anything except “being a person with a hilarious amount of life-long generalized anxiety disorder” best summed up by this recent tweet:

Empathy

Maybe she’s born with it

Maybe she ... developed it as hypervigilance as a result of childhood trauma

— daily daria number I lost count (@shadow) June 9, 2020

The management team has had many conversations lately with people feeling out of sorts in ways that are new to those persons. In general, they frequently sound like people struggling with the impacts of background anxiety on their lives and work. Being that I’m pretty public about my anxiety and ADHD, I decided to talk about this. I am not a mental health professional, just someone who has walked some of this road. Seek professional advice before doing anything of importance based on any of this.

Here are some things you may be experiencing from time-to-time right now:

• Not feeling very productive/effective, and beating yourself up about it

• More worried than usual

• Staying up later than you usually would, but not really doing anything

• Finding it hard to focus when you want to

• Irritability outside of the norm

• Feeling like you’re burnt out, but it’s different, and you’re not sure why

• Finding yourself resentful at the work or the interrupts

• Finding yourself working functionally, but not really caring much about it

• Having a hard time prioritizing work or private life, together or independently

Many of you are high-functioning people who haven’t experienced deep background anxiety before. I say “before” because you’re almost certainly experiencing some of it now. We’re all currently living with:

• A global pandemic that is being managed to highly varying degrees of success

• A global protest to the problem of police brutality in the United States

• Working from home in environments that may be extremely non-conducive to being effective

• Other nation-specific troubles that may be weighing on you, China, Hong Kong, and India are all struggling with things too

• Working In a company culture based on spontaneously communicating in all internal directions, except now we don’t see anyone outside of deliberate meeting partners.

These things require extra thought and attention to deal with, and can suddenly steal focus and intrude on our minds. This can easily replicate much of the symptomatology of generalized anxiety and/or ADHD. Those of us who have lived with either of those for a long time can recognize them in the many of you. You may have been pushed into a very difficult situation without the tools to deal with it. 

First, Google resources:

<internal links removed>

Second, I’m not going to give detailed advice on handling anxiety- or ADHD-ish symptoms in a general email. If you’d like to talk to me about it, book something, it’s off the record. I expect that for many of you, you’ll be relieved at just being informed that this is real, actually affecting a lot of people, and not something wrong with you. Your managers are all happy to talk about this with you.

Third, I am going to give general advice.

1. Take more time off. If it’s kids- or family-related, make use of our generous leave. It doesn’t have to be taken in chunks, you can book pressure valve days to spend focused on your family responsibilities. If you’re not experiencing stressors at home, you can and should still take more time off. In summary, take more time off. If you ever think “ugh, I need a break” stop what you are doing and find a slot where you can take an afternoon, or day, or week. 

2. Accept that you’re not operating at full efficiency. Stop trying. Remember that we’ve got <link about no engineering heroics> codified as a norm here. Push back on work allocation that isn’t reasonable. Hold yourself and your managers/TLs/TPMs/peers accountable for realistic workloads. Realistic means “what you can do now” and not “what you’d have gotten done in 2019.” It’s not 2019 anymore and 2020 appears to be going to be a decade or two long. Settle in for a long haul and stop pushing yourself to work 30% harder to make up for all the various impacts to your functionality. I know it’s going on all over and I’m wagging my finger at all of it, including at me.

3. Define boundaries in your life and keep them. Stop working at foo o’clock. Decline meetings that stomp over your lunch break or personal/family time. This isn’t a repeat of #2. You should hold yourself accountable for realistic work output, but you also need to hold yourself accountable for keeping the space open to handle everything else, and recharge yourself enough to do good work when you are doing work.

4. Your leadership team really actually means the above. This isn’t a corporate “health is a P0” platitude. The overall situation is going to be going on for most of us through this whole year at least. We need you to be happy, healthy, and effective when this is over too. We mean it; ask us to help with it. Your entire management team are all thinking about this, we’re happy to talk about it with you, and we want to help and be helped.

5. Last, here’s some real red flags. This isn’t an exhaustive list, but if you are running into any of these, please strongly consider professional help:

• Thoughts of self-harm
• Finding yourself having the same worries over and over, especially if the cycle is increasing in frequency
• Feeling like your mind can’t stop and you can’t make it stop
• Worrying every day
• Worrying about why you’re always worrying
• Consistent thoughts of despair and hopelessness
• Unable to sleep because of worry or undefined dread