Consistent weekly comms

A recurring bug in many leaders’ operating systems—including mine—is overlooking just how much useful context a leader can have than folks on their team.

A regular practice I’ve adopted is sending a brief, five-minute weekly video communication to my team. The weekly comms, in fact, has been a long tradition in my org predating me that I have continued. Having been on both the receiving and sending end of the regular weekly comms, I’ve come to believe that this is a critical leadership activity on a growing team.

Information dissemination is a core responsibility of a leader. Leaders have access to a huge amount of information that most individuals on the team do not. Why is Sales hiring so much? Why did we decide to work on X instead of Y? What exactly is Marketing working on? By communicating habitually with my entire team, I can tell them what is going on, why it is going on, and critically, reinforce core cultural values.

The format

My weekly comms consist of an informal 5-8 minute video and transcript, published internally and announced on our internal all-company listserv. I record a video for a few reasons:

  1. There are people willing to watch a video but not read an email.
  2. It feels more personal and creates a bit of face-to-face connection on a distributed team.
  3. It is easier.

The last bit is surprising. It surprised me, at first, and would not have been true a year ago. But now I am practiced at talking to a camera and have a good video setup that I use every day. Another factor is some excellent software called Descript that makes it simple to edit video and create transcripts. It feels like a magical advance in video editing.

I’m someone who obsesses over word choice, so I’ve found it easier to bang out a video script because I don’t worry as much about polishing it to the same extent as a stand-alone document. In the past, I tried to write a weekly email in the same format, but I was never consistent. It always felt like too much work. Recording a video is more sustainable.

I record in one take.

In practice, about one-third of the team watches the video, and one-third read the transcript, for about 2/3 total penetration.

What I talk about

  • Welcoming new team members.
  • Acknowledging major, company-impacting accomplishments.
  • Acknowledging significant accomplishments that can fly under the radar of the business. Things like open source contributions, technical debt paid off, continuing iterative improvements after a big-bang launch.
  • Announcing new policies.
  • Connecting revenue numbers with project initiatives, site traffic, major closed deals, etc.
  • Project team spin ups and spin downs.

A regular weekly comms is a great way to get a consistent message out to the entire team at once.

The habit

The key to making this work is forming a habit. If I wait until Friday morning to sit down in front of an empty text editor, I create lots of head-scratching and not much writing.

So on Monday, I create an empty document for the week that will serve as a script and transcript of the recording. I leave it open all week. On the side, I keep a running document of possible, non-time-sensitive topics to cover or topics that didn’t make it into the previous week.

Throughout the week, as I learn things from leaders on the team or hear of any information that needs to be flowed down, I capture that in the script as a quick bullet point.

On Friday morning, I write a quick draft and often send it to a few people for a quick review. Their feedback is critical—it’s a quick check to make sure I’m communicating what I mean. It is especially important to ensure I acknowledge the right people for accomplishments and don’t leave anyone out.

Then I record, almost always in one take. My assistant edits the video, exports, and then I Slack and email it to the team.

I dedicate 1.5 hours to my weekly video. Is this a lot of work? Yes. Is it worth it? Also yes. It is a chance to acknowledge efforts that could go unnoticed. It is a direct conduit to people on my team. It also makes me a better listener. Consistently creating a weekly comms puts me in a mindset of asking questions like “Is this important?” “Is it important for the team to know?” And critically, “what culture values can I communicate and reinforce?” It gets me out of my own head. It makes me a better, more informed leader.

What you talk about is what gets thought about

The weekly comms is a nudge. Done well, it can consistently and subtly shift the conversation in a positive direction. The weekly comms is an opportunity to create a story around the team and give it purpose.

References and further reading

A simple technique such as a daily standup

Groups of technically oriented people often want to optimize the work process to those activities needed for the technically oriented output, and overlook those that are focused on the needs of humans and groups of humans working together. Yes, you can have a standup and not get any value from it. You can also not have a standup and avoid providing a convenient mechanism for taking advantage of the differences in observation, interpretation, and significance made by the entire team.

If you’ve got a really good team facilitator, they’ll likely notice this and help bring it out. If they’re really excellent, they’ll convince the team to work in a fashion where it can more easily come out without them acting as a middleman to make it happen. They might use a simple technique such as a daily standup to create such an opportunity.

From George Dinwiddie’s blog » Daily Stand-Up Meetings. Reflects my background suspicion of the efficacy of Slack “standups.”

70% of what you wish you had

… most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.

Yes, I’m quoting Jeff Bezos’ 2016 Letter to Amazon Shareholders again. This quote is referenced in Working Backwards, which I’ve added to my recommended reading for engineering managers.

Pair with Making the decision right.

What I’ve been reading

The process is not the thing

As companies get larger and more complex, there’s a tendency to manage to proxies. This comes in many shapes and sizes, and it’s dangerous, subtle, and very Day 2.

A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? In a Day 2 company, you might find it’s the second.

Another example: market research and customer surveys can become proxies for customers – something that’s especially dangerous when you’re inventing and designing products. “Fifty-five percent of beta testers report being satisfied with this feature. That is up from 47% in the first survey.” That’s hard to interpret and could unintentionally mislead.

Good inventors and designers deeply understand their customer. They spend tremendous energy developing that intuition. They study and understand many anecdotes rather than only the averages you’ll find on surveys. They live with the design.

I’m not against beta testing or surveys. But you, the product or service owner, must understand the customer, have a vision, and love the offering. Then, beta testing and research can help you find your blind spots. A remarkable customer experience starts with heart, intuition, curiosity, play, guts, taste. You won’t find any of it in a survey.

From Jeff Bezos’ 2016 Letter to Amazon Shareholders. The whole letter is clear, precise, and worth reading.

What I’ve been reading

First-team mindset

Things were simpler as an individual contributor. You understood what your teammates were up to, you chatted every day, and you knew they had your back—and you had theirs. Now you’re a people manager. On bad days, it feels like you’re stuck on an island, squinting across the water at your peers busily doing … something on their own little islands.

Sooner or later, most people managers suffer a painful day that ends with self-searching questions like:

  • “Why can’t I get my team what they need?”
  • “How did I not see that coming? I feel out of the loop.”
  • “Why is everything so political?”

The good news is that you can take concrete actions to build the strong teammate-quality relationships you need with your peers to succeed.

Your peers are your first team

People management means playing on two teams, not one. One team consists of the people who report to you. The other team consists of your peers. This group includes people reporting the same boss as you, and more broadly, peers across the entire organization. Getting the support you need to succeed as a leader requires treating your peers as your team and not just an assortment of faces who happen to show up at staff meetings. The more senior a role you take on, the more important this becomes.

The priorities of these two teams will often, but not always, align. It’s inevitable that at some point, the demands of these dual roles will conflict. On the one hand, you now serve those who report to you—coaching, creating opportunities, sticking up for them against unreasonable demands, and shielding them from noise elsewhere in the organization. On the other hand, you now serve the entire organization you’re a part of, your peers, and the whole company. And ultimately, you are paid to deliver for the latter.

One antipattern newly promoted managers can fall into is prioritizing the interests of their direct reports over working with their new peers. The temptation is especially strong when managing people who used to be peers.

A useful way I’ve found to navigate this tension—and feel like you’re on a team again—is through what’s called a first-team mindset.

First-team mindset is treating your peers as your first team. Optimize first for your peers’ success, and second for supporting your direct reports. And yes, by treating your peers as your first team, you are treating your direct reports are your second team.

Thinking this way can feel overly hierarchical and wrong—so much of what we talk about when talking about the practice of management is serving your direct reports. However, in my experience, treating my peers as my first team is the most healthy way to operate because it motivates me to broaden my focus outward instead of narrowly focusing inward solely on my team’s immediate needs. In fact, adopting a first-team mindset enables you to serve your direct reports more effectively over the long haul.

I’ll discuss two ways to think about why a first-team mindset matters—suboptimization and relationships—and then I’ll explain six concrete actions for putting it into practice.


Sometimes you will have to disappoint or cause hardship for the people you manage in order to help your peers or the company achieve big-picture objectives.

Simple but common examples of this are enforcing organization-wide standards such as supported languages and libraries, issue-tracking systems, or code review standards. While allowing an individual development team to choose whatever language they want might make it more efficient in the short term, if every team did the same, the efficiency of the entire organization would suffer as people struggled to make their code interoperate and every team had to write their own tooling. A better solution, optimized for the entire organization’s success, would be to task a platform team with writing a standard set of tooling, once, even though the standards it produces may be suboptimal for any individual front-line team it supports—including yours.

This is known as the rule of suboptimization. Making changes to improve one subsystem’s performance while ignoring the effects on the other subsystems will not lead to optimum performance of the whole. Maximizing the performance of the entire system means sub-optimizing the performance of individual parts.

Other examples include canceling a project your team is invested in or asking your team to temporarily take on an “unfair” customer support burden to support a critical customer.

This is simple enough in the abstract, but it takes courage to support and implement decisions that impose tangible negative impacts on individuals on your team.

Relationships, i.e. “politics”

Real life is messy.

Servant leadership is a wonderful mindset to adopt. But it cannot be the whole story, or at least the naive version of it can’t. Sometimes you will need to execute a decision that does not directly serve those who report to you but instead helps solve a problem for your peer’s team or helps you maintain a productive relationship with that peer.

The last one, in particular, feels a lot like the skin-crawling “politics” that everyone hates. But in the end, your team’s relationships with your peers’ teams are inseparable from your personal relationship with those peers.

Work, especially at leadership levels, is done through relationships. From the outside, this can look like politics. Many people don’t like doing it. But the alternative is not building productive give-and-take relationships with your peers. This will severely limit your ability to get things done when it’s your turn to ask your peer for help on your initiative or help take some load off your overloaded team. And you’ll always be watching your back.

Give and take is part of how humans build and maintain relationships. As an IC, you would do things personally for others on your team—take over their on-call shift so they could go to their kid’s school play, act as a sounding board for ideas, and more. You didn’t do that with a cynical view towards reciprocity, but because that’s what humans who care about and support each other do. This still applies now that you manage people. And one of the primary mechanisms of support you have available is the output of your team.

If you don’t take building relationships with your peers seriously enough to put your team’s skin in the game, then you are severely handicapping your team from getting the support they need to deliver.

Practices towards a first-team mindset

Here are some ways to put a first-team mindset into practice:

1. Know your peer’s work.

At a minimum, actively learn what your peers are working on and what they are trying to get done. Understand their incentives, their accountabilities, and their challenges. You can’t support someone if you don’t know what they need. This is also an opportunity to learn from people who may approach their work differently than you do. You can start small by dropping into your peer’s daily stand-ups, but doing this right takes work.

2. Hold regular 1:1s with your peers.

1:1s are a foundational practice for building and maintaining relationships with your direct reports. Making those appointments sacred and not to be missed ensures that you communicate regularly and sends the metacommunication that the relationship is important to you.

You can use a similar practice, the peer 1:1, to maintain your most crucial peer relationships. Here’s how:

  1. Identify your most important relationships. You don’t need to meet with everyone who reports to your boss, and your most important peers may report elsewhere. Focus on the peers that you work with the most or have the weakest relationship with. Start small, but aim for no more than 3-4 recurring peer 1:1s.
  2. Ask your peer if they would like to hold a recurring 1:1 meeting. Propose whatever cadence makes sense, but every other week or monthly are good places to start. If they are reluctant, propose a single one-off meeting to try it out.
  3. Tell your peer what they need to know. Make the meeting useful for them. Provide a quick, 10-minute update to them about initiatives on your team. Be open to questions.
  4. Build a relationship with your peer. Make a point to understand your peers as three-dimensional human beings and not just as job titles.

All of this applies doubly to people you don’t personally like. You don’t have the luxury of choosing your peers. You don’t have to be buddies to have a productive relationship.

Manager Tools has an excellent podcast on the topic.

3. Give (and graciously receive) peer feedback. Don’t “drop a dime.”

A benefit of building trusting, respectful relationships with your peers is that you can talk directly to them about real things that matter—especially when those conversations are challenging.

Ask for feedback from your peers. Graciously thank them and act on it when appropriate. This builds trust that you can take it as well as dish it out. If you’re working on a big initiative, get their input, and ask them to tell you the flaws. Not only will this result in a better product, but it will also likely result in an ally when the time comes to get others on board.

Give constructive feedback directly to your peers. It’s kinder and more respectful to talk to a peer directly instead of complaining to your boss. It’s also more effective because you can share specific details and context. No one likes being complained about behind their back, and doing so breeds distrust. Better yet, giving good-faith feedback helps drive your peer’s success, and done well, can build an even stronger relationship.

Don’t surprise your peer in public if you can avoid it. If your peer’s team is blocking your team, tell her directly and give her a chance to act on that information before calling out her team as a blocker in a staff meeting. No one likes someone dropping a dime on them. Speaking directly is both more respectful and efficient.

A metric of success is that you are talking with a peer 10x more than you are talking to your boss about that peer.

4. Trust your peers.

Respect each other’s turf. Let your peer team leads own their areas. This isn’t about staying in your lane or not engaging in productive debate, but it is about showing mutual respect. Ultimately, you don’t want them second-guessing decisions you or your team make in your area or expertise, so don’t do the same to them. Trust that they know their stuff. Let minor disagreements be.

5. Support your peer’s initiatives. Practice first follower.

Part of working together on a team of peer leaders is cooperating to drive big-picture initiatives. Sometimes cooperation means getting out of the way:

Give your support quickly to other leaders who are working to make improvements. Even if you disagree with their initial approach, someone trustworthy leading a project will almost always get to a good outcome.

The second point is vital—knowing when to exercise humility and trust when someone else’s intelligence, knowledge, experience, and drive will likely lead to good results. Commit to supporting them, even if you disagree about some of the particulars. Support drives results further than criticism.

6. Disagree and commit.

A huge advantage of working with a true team of peers is that you debate and argue about real issues, driving better, more informed decisions. But once the debate is over and a decision is made, you must support it—even if you disagree, even if it is to your team’s immediate disadvantage. Airing your disagreements with your peers serves no one, especially not your team. It only sows confusion and destroys relationships. This, admittedly, can be difficult.

If you find yourself in a situation where you find it truly ethically objectionable to support a decision, you should resign. But short of that, find a way to sincerely speak to the merits of the path forward, and lead the way.

Level up

Leading a team is not just about the people who report to you; it is about working collaboratively with your peers to accomplish initiatives that are larger than the parochial interests of your team. It’s natural to see the world through your team’s lens—after all, you spend most of your time and attention there—but your success will be limited if you cannot look beyond that. Embracing the perspective of your peers is not only how to get the support you need to succeed; it is an effective way to learn and practice thinking at the next level in your career journey. The first step is looking beyond your own island to treat your peers as your first team.

References and further reading

Elsewhere on the web

The Metronome. “Two minutes early to a meeting. As much as possible. The last act of my morning opening productivity ramp. What lessons do I demonstrate to the meeting attendees by being there two minutes early? A couple: beginning on time is respectful to attendees, and meetings are expensive affairs, so let’s invest our time wisely. There’s a more fundamental lesson I am teaching: Leaders are capable of showing up to meetings on time.”

Receive Better Feedback by Asking and Listen, Lead, and Grow. A great two-parter about how to ask for and recieve feedback from others.

Speak in Stories. “Too often we present our work as a series of facts. The sad truth is that most humans are bad at remembering facts. When our audience is in a related conversation days later the data we shared isn’t likely to be top of mind anymore. Our impact remains localized.”

Does Palantir See Too Much?

What I’ve been reading

  • Ted Chiang, Exhalation. A collection of short stories from my favorite living fiction writer. The Merchant and the Alchemist’s Gate and the title story, Exhalation, are my favorites in this collection.
  • Gene Wolfe, Epiphany of the Long Sun. I enjoyed books 1 and 2 of the series, but I put this one down. I read for pages at a stretch with no idea what was physically happening in the story.
  • Rebecca Sykes, Kindred: Neanderthal Life, Love, Death and Art. Neanderthals are much more interesting than you think.
  • David Carpenter, Henry III: The Rise to Power and Personal Rule, 1207-1258. The second book this month I put down. Well written, but I couldn’t get into it. That said, it’s interesting to read a biography of what sounds like an ineffective leader.
  • Steven Levy, Facebook: The Inside Story. A few technical howlers, but an engaging telling of the founding and growth of Facebook. I would have liked more detail on either the technology or the management practices.