I'm writing this on November 11th, 2024. In most of the world, this is when we celebrate the end of a war so terrible that everyone assumed it would never happen again. 

As the scorpion said, "lol. lmao."

This is a post about leading during politics, but not a post about politics. Leadership has this responsibility regardless of how they happen to vote. If you're in leadership and don't believe that an important part of your responsibility to ensure that working for or with you doesn't carry unfair personal risk for your peers or people, well, I honestly don't know how you found this blog. It is not for you. Leave.

If you've got employees in the US and you are in leadership it is currently your responsibility to go ask HR what the plan is to support/not support people who will be facing targeted hostility from the incoming federal government. Maybe the answer is something, maybe it's nothing, and maybe it's case-by-case. Every company's situation is different, ever industry is different, every budget is different. I'm not intending to throw shade about what your company does or does not do. I'm trying to throw shade at the idea that you don't have to decide, right now, what that will or won't be.

See the thing is, you can't have people who need to make big decisions waiting to see what you will or won't do. Especially if they're used to thinking that you will help them. They need guidance on how your actions influence their options ASAP, some of them possibly in as little as 60 days. Do not leave them hanging.

If you're not sure what to ask about, here's a crib sheet. I make no claim that I got everything here or everything here being right.

1. From where can people work? Where can they self-relocate to without worrying about their job and health care? Would we support such a move actively or passively. If that list isn’t responsive to the problem, can we expand it? Will we?
2. Are we ready to make it so naturalized employees do not need to travel for work? Putting them through airports isn't a great idea.
3. Are we considering access to medical care when deciding where we do or don’t allow/encourage offsites/conferences/etc? If not and someone travels to such a place on our behalf, do we have an emergency action plan if it suddenly becomes relevant?
4. Are we looking into temporary work-from-elsewhere provisions for affected employees and can we give them guidance on where and what’s allowed?
5. Are we looking at a process to emergency convert an employee to a contractor in order to legally support them working from their short notice relocation destination?
6. When can we provide intent? When can we provide real guidance? Our people need to set internal expectations so they can do their own risk calculus as accurately as possible

You may well get pushback about why you're asking all these annoying questions. Here's a crib sheet for that conversation:

1. Affected employees who are self motivated will begin planning job changes in the near future if we don’t provide guidance or at least intent. 
2. Future hiring will be impacted if we aren’t clear about support options and locations, including the potential of expanding locations. 
3. People expect us to support them but those expectations aren’t necessarily clear and this is an opportunity for assumptions to harm employees and therefore the company. We have to close that assumption gap.
4. We don’t have to make this a political thing, and if the company wants to do all kinds of stuff to try to downplay that aspect that’s fine, that’s a business decision. We cannot let concerns about that turn into deliberate inaction when said deliberate inaction would make every company statement we have about our company-employee relationship a hazardously misleading falsehood. 
5. If all that seems too complex then how about this: We’ve used statements of support and inclusivity as part of hiring and retention for years. The chits are being called in. Settle up or accept adverse reactions.

If your audience is listening but isn't sure who to consider at risk, here's my very rough estimate of things. Please don't make life impacting decisions as if this is right. This is based on my read of campaign rhetoric and speeches, as well as which cabinet and White House staffing posts are being decided first. If action is ordered outside of those inputs, then this is all wrong and I'm sorry about that. Additionally, if a group isn't represented here that is not my intent. I'm not trying to exclude anyone from this list.

1. Naturalized citizens are at risk as early as January 10th. Immigrants and naturalized citizens targeting is almost entirely doable via mobilization in service of an executive order and those orders are pre-written.
2. Trans persons will face legal rights issues probably by mid-February, although congress’s and the courts combined schedules make predictions very difficult. 
3. Queer (that don’t present as straight) marriage rights will face impact by summer.
4. People who can become pregnant is the hardest to predict but they’ll get around to them and they may well be number two in priority.

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.