Remote Management (on working remotely part II)

CC Photo by Don McCullough

Managing a team remotely

I’ve spent a fair amount of time since relocating reading and learning about leading distributed teams. This is what I’ve learned thus far.


I wish I could tell you that there is lots of great material out there about managing a distributed team. Truth be told, there isn’t. There is lots of material, it just isn’t that great. Lots of the material spends time on what tools to use, and how allowing employees to work from home a day or two a week is a complete game changer. That wasn’t what I was looking for. Most articles and books had a couple really good tidbits and then 80% stuff that was repeat or filler or not applicable. I’m certainly still learning, but I wanted to share what I have found.

Honestly the best resources I have found are doing actual work on open source projects where everything is distributed. My days of contributing to Fedora and EPEL taught me more about remote management than any class or article could have.

FOSS contributions teach distributed team workflow more than reading about it does.

Background

I had one remote person when I worked in Portland. It was also somebody I have known for nearly a decade. He’s very good at what he does, and requires very little management. With the switch to me being away from my team, I didn’t know how it would go. Our team’s work style was a lot of pairing, discussion, and generally being talkative in an open office environment (sorry not sorry).

I decided to start reading everything I could find about managing a distributed team. In the few months after I left Portland, my next two hires were remote; one in Belfast and one in St Louis. This meant that 4/9 people were remote. We were a truly distributed team, and not just a manager sitting away from their reports.

Communication with a cadence

Communicating with remote employees takes a little bit of extra attention. To get the pulse of your team and employees, you need to pull, a lot. As baseline, I set up a cadence for meeting with employees. 1:1s are sacred. I often have to reschedule them or rearrange them, but I almost never cancel them. They are important. If my job as a leader is to serve, I need to know what my people require. Meetings can happen over Blue Jeans (or hangouts, skype, whatever) almost as easily as in person. Blue Jeans and our equipment in the office allow for body language to be read, and for high fidelity interactions. I won’t go into details as to how to manage 1:1s, but don’t skip them. You won’t get that 5 minute coffee break with your employee later in the week. 1:1s are also essential for morale. Time with a manager is important, time building a career path and setting expectations is worth the investment for that employee.

Transparency is paramount

Another thing to put at the forefront is transparency. Shortly after I went remote, we (my team and department) got rid of all private channels in HipChat. I kept transparency on the mind. What was it really? To me, transparency isn’t about a broadcast of information constantly, but it is about everybody having the tools the information they need to do their job. Sometimes that means knowing where to look, but that information must be accessible.

Put more in writing. Having a distributed team means timezone issues. The folks in Europe were trying to read scrollback of HipChat for the last 16 or so hours they were offline and catch up on whatever the team was doing. That works, to an extent. However, that should be considered bonus and not expected. HipChat is not a system of record. HipChat does make discussion on how to do things more consumable for outsiders though. This can be great as a teaching tool.

After a few months of trying to be more diligent about writing things down, I knew I still had gaps. I now write a weekly “happenings” email to my team on Fridays. On Thursdays I do the outbound team status report to the rest of engineering. The Friday email has anything I choose. It’s often things I learned during the week from meeting, email threads, and the like. It sometimes contains idea, or other things you might normally put in a staff meeting. Happenings are also a great place to document decisions made throughout the week.

Standing Meetings, and seriously, do you need them?

Staff meetings. I don’t have a staff meeting. This is for a few reasons. Firstly, I meet with everybody on my team 1:1 every week, nearly without fail. If I have something to cover, I can cover it then. Secondly, we often found a staff meeting would end up being a broadcast of info from manager to employees (I’ve found that to be true sitting in both roles in staff meetings). I now just write down most items we’d cover in a staff meeting. It may take me an hour, the same length as a staff meeting, to write up everything going on, but I’ve saved 10 team hours by not having the rest of my staff sit through that time. They can read that email when they feel like it. If they were out of the office that day, doesn’t matter. The content is still in their inbox. If we have specific topic to discuss that isn’t a broadcast, we’ll set up something to knock that out.

In general, I’d like few standing meetings for my staff. I’ll take them as a manager and distill the important items out for the team. I’ll also ensure any standing meeting continues to be a worthwhile use of time for me.

A quick get together

The lack of hallway conversations kind of stinks. Every now and again, you just need to talk to somebody for 5–10 minutes about something. For these types of interactions, I often just use HipChat video. It’s fast, doesn’t require a special code/number/browser plugin, and allows screen sharing. I wish it used the default audio/video devices my Mac already had setup, but I guess I can deal with it. It’s also not great if you’re calling somebody who uses Linux as a workstation. In these short conversations you can have a quick check-in with somebody, talk somebody down after being riled up, or just get a couple questions answered quickly. I don’t do this all that often, but it’s a nice tool to have available.

The hangout

A distributed team needs to gel. There’s nothing like face-time to actually gel. I won’t pretend that Blue Jeans is good enough. It’s not. It’s better than nothing, but is not a substitute for getting together in a room and hanging out around a table after hours. Our team does try to incorporate some social time into our schedule. We have a 2 hour block weekly called a working session. This session has conference room for people in PDX and a Blue Jeans for everybody else. Sometimes we have very specific topics and problems to tackle, with a specific agenda. Other times, we listen to music and just complain about the thing somebody is working on. We use it as a virtual table to sit around and work together. It’s also optional. It’s basically a replication of the open office floorplan, but across the world. A downside of the way that work session is currently run is that it excludes some people due to timezone issues. I’d like to move to a rolling schedule, but mornings (the most overlapping time for my team, and the company) are already full for most people.

Release Engineering hanging out after hours (only some pictured)

Getting together in meatspace

Nothing replaces being in the same place together. You share experiences, build relationships and trust. Earlier this year, my whole team was in our Portland office for a week. Every person thought it was great. We got more over-arching planning in a few days than what would take months normally. We also shared some beverages, hung out and basically had a good time. It’s really difficult to put a price on that. If you’re managing a distributed, do everything you can to get your team together fully at least twice a year. Ideally, it’s not always in the headquarters office, but better there than nowhere.

Managing the Team

Performance Evaluation

To measure productivity, you really have to measure output. Puppet Labs has been better than my past employers at that, where for some leaders, work was equivalent to time in seat. Productivity can be tickets, or shipping new features, or helping others, or detailed PR reviews or whatever. One of the main points I see is that your work can be overlooked, so work in public. This builds a culture of transparency. It also means your patch that is a work in progress can go up early for design review, and so that the reviewers can find the appropriate gifs to attach. Measuring output obviously changes quite a bit team to team. Some things are obvious, like tickets, story points, and artifacts. Other things are much more difficult to remember. I know that my recent visit to the office gave me strong reminder of how much time one of team members spends helping others. That person may not always ship a ton of work, but everybody else is better because of their efforts.

Work location

I no longer care where any of my team works. I hardly care when you work. Get your work done, the rest is background. If the work isn’t getting done, we’ll have a different conversation. If others on the team can’t rely on you, again, that’s a management and performance issue, not a location/timing issue.

You can’t do it all

Delegation is great no matter what, but when timezone shifted and you’re not right there for somebody to run up to when a crisis unfolds, you need some people. I can’t be online for every transaction, work order, ticket, request, issue, etc. When I can’t be, I have people who can be. They have the responsibly and complete authority to make calls for the team. This type of behavior is one of things I really look for in a senior (or higher) level engineer.

Keep your team engaged

Your team needs to like the work they are doing. They’re in a pretty unique spot at this point. Working remotely once, means they can more easily do it again. Working remotely also means the number of companies they could potentially work for is much larger than their geographic area suggests. This takes trust. I commonly ask team members if they’re enjoying the work. If there are things they wish they were learning that they’re not, or what I can do to help them meet their next set of goals. As a manager, keeping your team members happy means better output. This comes back to good 1:1 conversation. The honestly level though must be there. If somebody, on either end, is unhappy something needs to change. You won’t see the body language or hear the hallway chatter to catch it.

Hiring

Onboarding

I onboarded a few people since going remote. One thing that is key is start with work that has a quick turn-around time. This allows the worker to be productive, you as a manager to have things to talk about, and the employee to get their hands on lots of things early on. You also need to set tone with the employee about conversation habits. Earlier, I had several people private messaging me with questions often. None of these questions were private. I kept redirecting them our team channel. This means other people can see the questions, perhaps answer them, or see my answers and offer pointers/context/discussion. Work in the open.

I found this on the internet.

Interviews

I find remote interviewing way more difficult than I should. I still haven’t gotten close to the confidence level I have interviewing somebody face to face. I think part of that is the remote technology sets up the interview to be all business and silently removes the associated small talk, hand shaking, and other personal touches of meeting somebody. The question and response part seems to work fine. I just find that my confidence in my evaluation is much lower when interviewing remotely.

Hiring

While I’m on the topic of hiring, I wanted to mention hiring on distributed team, and the one big drawback I’ve felt thus far. On a distributed team, it is much more difficult to bring in less experienced people. When you’re team is all over the place, you need the type of people that are rather self-sufficient. That’s not to say you can’t bring in entry-level folks, it’s just more difficult.

This hurts me personally, because I love growing teams, using interns and entry-level staff. When the Delivery department was 7 people, 4/7s of them came from internships. Those same former interns as now Managers, Engineers and generally amazing people to work with.

General Thoughts

There are a few thoughts I have that didn’t fit elsewhere cleanly. I’ll put them here in the this junk drawer.

Firstly, I have a huge advantage over a new remote employee. I worked in Portland, at our main office, for four years. I know lots of people. I have a network established. I can’t put myself in the shoes of a brand new remote employee. I’m sorry if some of this invalidated because of that.

Meeting Culture

At Puppet Labs, we are extremely quick to call a meeting. I’d say we’ve built a culture of meetings, which didn’t exist 3 years ago. Yes, we’ve grown so more meetings are inevitable, I get that. I find that we turn to meetings very quickly when an email thread could drive conclusions just as easily, be done asynchronously and contain a complete written record.

I often hear people complain about the amount of email we get, and that they are afraid that sending an email is just spamming. I don’t think we get that much email. After filters of meeting notices, google doc shares, jira tickets, and public mailing lists, I think I get less than 100 emails a day. Most of those I can read quickly and take no action from.

Solving problems in an email thread is ideal. People can work on it when their schedule is best. For me, I often process email and do writing late at night, after my child is sleeping. It’s a quiet time and easy to do those things. Use email. The time you spent crafting your thoughts is yours. That time doesn’t consume all the other people listening to you craft your thoughts, waiting for the AV to spin up, waiting for the three people who are late to this meeting because their last one ran over, deciding if we have quorum to get started, etc. All of that is gone. Write up the problem, requested actions/discussion and date to complete and have a decision. This was something that worked very well in the open source world. I wish it would translate into the business world better.

If you’re afraid that what you’re sending is spamming people, stop. If I get an email that I don’t have lots to say on, I can archive it in one keystroke. It’s pretty easy. Also, I can still search later on and find it if for some reason later it does become relevant.

Don’t cross post lists. When you do this, the threads become difficult to follow if some people are on one list and not another. If you don’t know where to send to, error on the side of the larger list, IMHO. (e.g. all-developers vs your team distribution plus 5–6 other people).

Lunch time

A weird thing about my current role is that I don’t often get a lunch hour. In most cases, I expect to have my lunch at 14:00 Central. This is because that’s when the west coast is taking their lunch. What’s weird though, is that all the other remote people, not on the west coast, schedule meetings then, cause hey, it’s two o’clock for you. I haven’t really worked this one out very well yet. I’ve been a real stickler on my stop time at the end of the day. I’ve been way less careful about lunch. Fewer meetings (perhaps because we can solve more in email) would likely increase time for lunch.

Conclusion

When managing a distributed team, do everything you can to make everybody be included. Write as much as you can down. Be results-oriented. In general, none of those ideas are bad if you’re all in the same office, but when spread out, they become paramount.

I’ll have one more post on being remote friendly as a company, which wasn’t planned when I started writing. I’ve covered as worker, and now as a manager. There are things the company can do to help a distributed workforce feel connected and be effective. I’ll cover some tooling, policy and general ideas that can help make a remote friendly atmosphere. That’s what’s next.

A footnote on sources:

I’ve read 40ish articles on remote working and management. I also read Remote from the 37Signals people, and had read a few other books about distributing business earlier (like The World is Flat, 4 Hour Work Week). Most articles I wouldn’t recommend reading, as they’re just not good. One article, however, had some great graphics on who would be a good remote employee.

Like what you read? Give Michael Stahnke a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.