How to Lead From Home
Working from home is a hot topic right now. If you’re a manager letting your people work from home, you may have concerns. How do you ensure that people are working? How do you create a good remote work environment? Are your people really not wearing pants?
Most of all, leaders want to know if shit will still get done and will their teams be successful. Yes! Remote work is very productive, but it takes some adjustment. This post provides a few tips based on my experience as a former leader of a remote and distributed team. It is the second post in a series I’m writing about remote work.
- How to work from home
- How to lead from home (This post.)
- Geographically Distributed Teams
- When Remote Work Goes Wrong
These posts are a response to current events. For those who might read this post far in the future, let me recap. A global pandemic caused by a mediocre beer turned the entire world into zombies unable to determine competence in their representatives. This lead to companies finally deciding to let their workers work from home.
Build Trust
For all this to work, you need to build a foundation of trust. Of course, this is true when working in-person as well. The difference is managers have the illusion of more trust and control when they are in physical proximity to their people.
For example, a question I often get is “How do you ensure that people are working?” Every time someone asks me this, I laugh and throw a drink in their face. Not out of anger, but just to shake things up. As they dry off I reply with, “How do you know people are working when you’re in the same office?”
Never underestimate the ingenuity of someone who wants to slack off.
Remember, you’re not paying people to look busy or even to be busy. You’re paying them to move the business forward. Set goals and focus on outcomes. More on that later.
How Do I Build Trust?
The tools to build trust are no different whether in-person or remote. The difference is when remote, it takes a bit more intention and effort. Colocated people often build camaraderie and trust through happenstance and interactions that just don’t happen remotely. I could write a whole blog post on building trust as a leader, but I’ll focus on one specific tool, one-on-ones.
The Manager Tools Podcast has a great discussion about one-on-ones and one of the key points they make is this…
The most powerful thing we’ve ever recommended to any manager in the world is to sit down and talk to their folks on a weekly basis, regularly like clockwork.
Some managers find themselves too busy to hold regular one-on-ones. They find themselves rushing to put out one fire then another. Fires they probably started. This is a mistake. It is not good to start fires at work. Skipping one-on-ones is also a mistake. As the podcast goes on to point out,
Building a relationship and trust with your people is the fundamental act of managing.
This is your job, so prioritize it. The one-on-one is a relationship-building tool so don’t sabotage it by asking for status updates. When I was at GitHub, I wrote up internal guidance for one-on-ones that I’d like to turn into a blog post someday. Fortunately, there’s already good writing out there on the topic. The Know Your Team blog has a couple of great posts about one-on-ones.
One last note on this, make sure to leverage video conference tools for “face to face” conversations. Humans are social creatures. We are hardwired for social connection. We need to talk, laugh, vent, etc. with each other.
Build Alignment
A more important question than “How do I make sure people are working?” is “How do I make sure people are working on the right things?” Who cares if Bob is working hard if he spent an entire week optimizing a feature you planned to cut.
Build alignment and then trust your people to work on the right things.
There are many tools for alignment. I rightly don’t care what tool you use, just as long as you do something that works. Some tools I’m familiar with include OKRs and V2MOMs. Smaller companies can often get away with something much simpler.
It’s tempting for a leader to try and direct everything. That leads to an unproductive organization if everyone must wait on you for every decision. You’re one person. Instead, drive alignment with common goals and trust each team can figure out the specifics of what they need to do.
As a programming analogy, move from an imperative to a declarative approach. But a high level declarative.
Communicate often
Way in the past, the CEO of GitHub would hold an internal weekly all-hands that would be recorded and easily viewable by all employees. I used to love these videos.
When people work from home, it’s easy to feel detached from the rest of the company. People want to feel like they’re part of a common mission. This is one of the key responsibilities of a leader. Regular communication that people can read or watch on their own time becomes a focal point for feeling part of a team. It creates cohesion.
When I was a director, I wrote a weekly “newsletter” using GitHub’s somewhat hidden Team Discussions feature. I called it the CACAW which stood for Completely Awesome Client Apps Weekly. Maybe a bit overstated, but the title reflected my intentions.
Each weekly started off with a “Haack Homily” (I’m really into alliteration) where I would write about a topic that was on my mind. Sometimes I shared my thoughts on events within the company such as the latest reorg. Or I might write about the importance of code reviews and how to do them in an inclusive and constructive manner.
Following that would be a list of recent happenings relevant to my org. I also finished it off with a weekly graph/statistic of the week. It was an opportunity to highlight that we use data to inform our work and to give a shout out to something going well, or draw attention to an area where we could improve. I received a lot of positive feedback on the weekly. People told me it made them feel like a part of a larger team.
Write things down
A lot of knowledge with colocated teams takes the form of tribal knowledge. It’s passed down from person to person through oral tradition. “Hearken unto me, O ye children, and hear the woeful tale of Peter in Engineering who hath failed on many an occasion to bedeck his TPS reports with a cover sheet.”
This tribal knowledge does not work with a distributed team. In fact, I’d argue it doesn’t work that well in a colocated team, but it persists. Writing things down is absolutely essential for distributed remote teams.
The good news is, by default, most communication on a remote team is written because chat is the primary mode of regular communication. It’s pretty common for an employee to backscroll through the previous few hours of chat logs when starting their day.
When I first started at GitHub, I read every chat message in the two main chat rooms we had - The Danger Room and The Work Room. Over time, as GitHub grew, that did not scale. At some point, I could barely keep up with my own team’s chat room.
This is why we not only write things down, we summarize! Chat is great for hashing out a decision or a piece of work. But we don’t want to force those who aren’t present to have to read through a giant chat transcript just to find out we’ve decided to switch to TypeScript.
Decisions (and rationale) must be documented in a durable location. At GitHub we used to say everything should have a URL.
Assert a Direction
This is a tip from Justin Spahr-Summers in his great post, Working Asynchronously.
Open-ended question such as “What should we do to solve this in the future?” often fall flat when asked in an asynchronous forum. Seth Godin covers this phenomena in his post “Open the cookies”…
Put a bag of cookies in the break room and it might sit for days.
Open the bag and leave it out, and within an hour, all the cookies will be gone.
People are much more willing to chime in if they disagree with something concrete. But when doing so, it’s important to understand the power dynamic involved with you asserting a direction. If you’re a peer member of the team, assert away!
If you are a manager, exhibit a bit more restraint. You may think you are just proposing an idea to be taken on equal terms, but as someone with power over salaries and reviews, everyone else may take it as a fiat no matter how much care you put into the proposal. So first, give time for others to chime in. Second, if the discussion falls flat, privately encourage someone to offer a suggestion, “Your idea about the flummoxer was interesting, maybe you should put that forth.” As a last ditch effort, perhaps propose two options and ask for help deciding between them. The goal is to not cut off consideration of alternative ideas too early.
Future Follow-up
In this post I focused on a few tips for leading people who work from home. It doesn’t touch upon some topics relevant to those with a globally distributed company. When I was a manager and later director at GitHub, I had people in multiple time zones. That introduces some new challenges. I hope to write about that in the future.
Comments
4 responses