DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary
  • Scribbles
  • Remote or Distributed?
  • Some Interesting Stats
  • Analysing Distributed work
  • Analysing Travel
  • What can you do as a manager?

Was this helpful?

Export as PDF
  1. Managing a DevRel Team

Distributed developer relations

Brandon West from Amazon AWS talks about how to manage a distributed developer relations team, especially where each person on the team tends to travel a lot.

PreviousHow to mobilise your community during a pandemicNextUnderstanding company goals

Last updated 4 years ago

Was this helpful?

Summary

A distributed team that also travels a lot is a double whammy when it comes to potential burn out.

  • It's better to use the word "distributed" rather than "remote".

  • Although there are a lot of upsides of distributed work, it affects the peer to peer relationships within the workplace. It is interesting to note that the supervisor to report relationship is not that affected.

  • Travel, though is great for a lot of people, it can lead to burnout and lower health overall.

  • As a manager you can follow these few tricks:

    • Create Logical Groups that reduce the scope of travel and the scope of remote communication that's necessary.

    • Use your PTO and make sure everyone else in the team is actually doing the same.

    • Finds other channels to affectively fulfil your targets with minimum travel required.

    • Make sure you set up clear paths and processes for enabling the types of communication you need.

    • Make sure everyone closes the loop of conversation and is on the same page when it comes to communication style.

    • Face to face conversations cannot be replaced. Try to get as much team conversation times as possible.

    • Don't overcommit yourself and try to make sure no one else on the team is working more than required. The more exciting an opportunity is, the slower or more considerate you should be about accepting that thing

    • Tell everyone the best things to do somewhere besides work.

Scribbles

Remote or Distributed?

What do you think about when you hear the word "remote"

  • You might picture a place far away, expensive, hard to get to, with limited resources, lack of autonomy

It's better to think about the term 'distributed' rather

  • You will think about something redundant, resilient, close to the end-user, able to be interconnected but all the nodes can work autonomously as well.

  • When you have these communications with your team, consider it from their perspective - for them, you're the remote person

Some Interesting Stats

  • Grads are 68% more likely to be interested in remote jobs

    • This is because that's where the majority of the new jobs are going and there's an uptick in the number of people who want to work remotely.

  • 39% of the employees spend some time working remotely

  • Working from home has grown by 140% since 2005, 10x faster than office work

    • If you're someone who's making hiring decisions for managers, you need to be looking for someone who can effectively manage a distributed team.

Analysing Distributed work

Upsides

  • It's lower stress and you get higher engagement from the people who are based outside of the office

  • On average, they tend to work about 4 hours more per week while maintaining the same amount of happiness.

  • You get to be closer to your family

  • The regular commute and traffic time is saved

Downsides

  • Correlated strongly with a deterioration in peer to peer relationships

    • However, it does not have that same effect on the supervisor to report relationships

      • This is largely because, for communication, your manager always has to speak with you, having consistent meetings helps to stay up to date, understanding the status of tasks, blockers etc.

    • But the same communication line between team members are not as necessary or not dictated as a process of being part of the organisation.

Analysing Travel

Upsides

  • When you travel to a new country, these experiences can bond people who travel together. It creates certain emotional bonds and experiences worth cherishing later!

  • It is correlated with a lower body mass index and a lower blood pressure.

Downsides

  • You feel more overwhelmed because of the inability to keep up with work, while it piles up.

  • It might lead to sleep deprivation, eating poorly, everything else related to your bodily health.

  • Travelling a lot can strain your personal & coworker relationships.

  • If teammates that are not necessarily the best match, are travelling, it might lead to arguments/ stress and cause burnout to accelerate.

What can you do as a manager?

Logical Groups

  • Distribute the things you're doing into logical groups that reduce the scope of travel and the scope of remote communication that's necessary

  • These groups can be built

    • Around geography, like making regional teams.

    • Around channels, you do not have to travel always to do devrel work. A lot of it can be done via

      • live streaming on twitch

      • writing awesome blogs posts

      • creating technical content

      • going through open source SDKs, clearing out a few issues.

  • If you notice people are getting close to a burnout point, you can have rotation within the team for responsibilities.

Lead by example

  • Make sure that everyone you talk to is actually using their PTO.

  • Review that and if someone's not using it, make them use it, they need to.

  • Make sure you have some vacation planned that you're looking forward to.

Find other channels

  • Find ways for people to do their work without the necessity of travelling

Clear Paths

  • Make sure you have clear paths and guardrails in place for enabling the types of communication that you need.

  • All the important things need to be in an asynchronous system with a central source of truth that people can refer back to, update on their schedule and know how things are going.

    • Example:

      • Brandon's team's weekly standup meeting usually has a 40% attendance because of travel, schedule conflicts, talks etc.

      • So for this, there's a structure defined for that team meeting, where there's a rolling document where everyone goes and puts their update.

      • In case you are not able to make the meeting, you can still review what other people are up to, comment/ collaborate on that document and it's totally fine.

  • Make certain processes for travel-related things that suck, like expense reports, as painless as possible.

Close the loop

  • It's also very important to make sure everyone's on the same page when it comes to communication style.

  • Everyone needs to close the loop:

    • When an instruction is given, it is repeated back to the person who gave the instruction.

    • This makes sure that the person executing the task and the person signing the task both understand exactly what's happening

    • It also means that the status must be delivered at the end of the event.

  • Example:

    • Someone asks you to do a certain task when they're gone and you agree to it. This is an open loop.

    • It becomes a closed-loop when you revert back to them, maybe in an email, telling them the status of the work and any action items there further.

  • If you don't close the loop, if people don't have that teamwide expectation, it leads to a lot of strife and conflict that starts to make those personal relationships within the team degrade.

Face to face

  • Face to face conversations cannot be replaced.

  • There's a lot of room to misinterpret things over chat/ email.

    • Words mean things to different people, especially in a distributed team when language barriers are also there.

  • Suggestion:

    • At least once per quarter, get everyone in the same room and talk about all the work you're doing.

    • Make sure that you make time within that for emergent conversations.

Slow yes

  • As someone who loves to help, devrel people tend to be willing to do all kinds of different tasks.

  • But that also leads to a tendency to overcommit yourself, even as a manager.

  • It is important to ask people to take time to think about the things they commit to.

  • The more exciting an opportunity is, the slower or more considerate you should be about accepting that thing because we tend to get blinded by that emotion.

  • As a manager, if you look that someone might have overcommitted themselves or they look on the path of burnout, you should move forward to say that and try to find someone else on the team that might be able to help.

Share experiences

  • Tell everyone the best things to do somewhere besides work.

  • As a manager, it might be helpful to put a process in place for that like writing a guide to the city that you've been to the most.

    • Adding in highlights about a nice hotel which is well positioned, reasonably priced, a transport preference, awesome restaurants to check out or something special for a day trip!

  • As a manager, you should encourage and help people to take the time to enjoy things that they do.

  • A nice thing can be to allow someone to bring their family along at some events so that after work they might be able to enjoy and get their time to do things they would love to do.

Brandon West (AWS) - DevRelCon San Francisco 2019