[QCon 2019] High-Performance Remote and Distributed Teams

Randy Shoup @randyshoup

For other QCon blog posts, see QCon live blog table of contents


  • You to not often interact face-to-face with the people that you work with
  • Models- single site, multi site, remote first
  • Anti-pattern; Centralized HQ control. Most things and all decisions done at HQ. Others get work doled out to them
  • Anti-pattern: Site + Satellite Remote – One or several site where people work every day and one or two on own
  • Remote first – everyone on video and slack. Model that Ok to interrupt b/c net slow


  • Larger talent pool
  • Take advance of localized supply and demand
  • Parallel hiring – can grow teams in parallel. Not tied to a recruiting team. Each site can hire in parallel
  • Geographic hedge – can hire more in one region if things slow down in one
  • Diversity and inclusion – flexible location/hours, geographic/cultural, neurodiversity (b/c communication styles vary)
  • Retention – can live different places, employee satisfaction, productivity
  • Little/no commute
  • Flexibility
  • Personalize work environment
  • If at HQ and work with remote people, more flexibility because your teammates are remote
  • Ensure each team full stack so not relying on team in another country for communication
  • Follow the sun. Round the clock triage, on call handoffs
  • Close to customers. Local presence, customer empathy, local implementation/customization


  • Local laws (hire/fire/severance)
  • Local recruiting norms
  • Local compensation – pay everyone as if at QA or by local market. But must be consistent
  • Local currency – do you pay in US dollars or local currency
  • Local regulation – laws, taxes
  • More travel. Problem to never see teammates
  • No commute == no exercise
  • Solitude/isolation
  • Time management. Easy to keep working
  • Best to be single site or remote first. That way don’t have onsite conversation and inform (Or forget) remotes later
  • Don’t have one site dole out work. That’s outsourcing
  • Managing time zones – respect time zones over others. Watch DMs off hours. Trade off inconvenience. Use overlapping hours well


  • Possible to do remotely, but better to bring in a bunch in person
  • Bond with cohort
  • Instill company/team culture
  • Mentor/buddy system – ideally two role/team and culture
  • Structured onboarding that can do at own page – ex: recorded training


  • Video
  • Audio
  • Internet Connectivity – mifi hotspot good in rural areas
  • Comfortable desk/chair/etc or coffee shop or co-working space
  • Quiet/child proofed space


  • Maker’s schedule – want chunks of uninterrupted time. Try to have meetings close together to preserve time.
  • Manager’s schedule – mostly meetings
  • In a remote environment, blocks of time mater more
  • Block out calendar, office hours


  • Good to have remote manager. Sets example, shows career advancement possible, empathy
  • Clarity on goals
  • 1:1 are sacrosanct, not a status meeting, praise in public (can be slack)/correct in private. Don’t have management by walking around so won’t see implicitly


  • The half life of rust is 6 weeks
  • An interaction reinforces it


  • Video
  • Chat
  • Collaborative docs


  • Be really explicit about “what is the problem you are trying to solve”
  • Clartify the “why”
  • Straighforward language
  • Repetition – a lot
  • Culture of “ask in public” – remember to model this
  • Also model “when in doubt ask”
  • Be open to feedback when write doc and be specific about the feedback want
  • Clarify the purpose of meeting
  • Pre-reads. Or read doc together if can’t do before. Feels weird first time, but gets everyone on same page
  • Template agenda for common meetings
  • Cancel meeting if no agenda
  • Have senior person moderate to stay on topic
  • Allow time for chatting/social bonding


  • Did quarterly
  • Primary goal was social bonds and connections
  • Do high bandwidth communication
  • Planned well in advance
  • Rotate locations
  • Spent a day learning together
  • Prioritizing fun and team building
  • Hackathon with theme
  • Internal Conference
  • Structured activity about coding

My impressions

This was great. I’ve heard much of it before, but hearing it again helps reflect. And there were some that were new to me

Note: Randy mentioned his collegue’s 2017 QCon presentation a few times. Here is a summary

[QCon 2019] Navigating Complexity – High-performance discovery teams

Conal Scanlon

For other QCon blog posts, see QCon live blog table of contents

Discovery vs Delivery

  • Delivery: completing lots of tickets, points completed, happy team
  • Discovery – different goals
  • Two types of work; two different ways of thinking
  • Dual track agile – discovery is for learning. Inputs into delivery track.
  • Discovery will happen whether planning to do it or not. ex: bug report
  • Can change % of tie on discovery vs delivery over phase in project


  • Welsh word
  • Complex/Chaotic/Complicated/Obvious
  • Also box in middle for when don’t know which in.
  • Complicated – can use knowledge to see what to do

Key areas of discovery work

  • Maximize learning – accelerate discovery, MPVs
    • Want to encounter problems as quickly as possible
    • Learning is messy and doesn’t easily fit Scrum process
    • MVP goal – maximize learning while minimizing risk and investment
    • MVPs can be paper prototype or a single use case
  • Better ideas – idea flow, collective intelligence
    • Levels: Psychology safety, dependability, structure & clarity, meaning, impact
    • Validate with people outside team
    • Closer relationships with specific customers so can see reaction as progress
  • Alignment – OKRs, Briefs, Roadmap
    • OKR = objective and key results
    • Think about where want to go and how get there
    • Should understand why vs an aspirational goal
    • Alignment and autonomy are orthogonal
    • Product brief – map from strategic level to feature going to build. It is not a requirements or architectural doc
    • Roadmap – show on larger ranges of time
  • Metrics – 3 levels, correct category (delivery vs discovery)
    • Business, product and engagement metrics.

My impression

I like that he provided an outline with the key points up front. The OKR section was detailed with examples. I like that there were book references/recommendations. And it was certainly interesting. I think I expected it to be about something else, but I’m glad I came. I would have liked more on examples of discovery projects specifically.

[QCOn 2019] The Trouble with Learning in Complex Systems

Jason Hand from Microsoft – @jasonhand

For other QCon blog posts, see QCon live blog table of contents


  • We use terms where not everyone on same page as to meanings.
  • Ex: what does “complex” mean
  • Types of systems
    • Whether can determine cause and effect
    • Ordered vs unordered
    • Ordered – Obvious (Can take it apart/put it back together. Know how works. ex: bicycle), complicated (ex: motorcycle)
    • Unordered – obvious, complicated, complex (ex: people on road, human body), chaotic (ex: NYC)
  • Sociotechnical systems – th epeople part is hard

Complex system

  • Causality can only be examined/understood/determined in hindsight
  • Specialists, but lack broad understanding of system
  • Imperfect information
  • Constantly changing
  • Users good at surprising us with what system can/can’t do


  • Takes time
  • Takes success and failure. Need both
  • Learning opportunities not evenly distributed
  • Sample learning opportunities – code commits, config changes, feature releases and incident response. Commits occur much more often than instances
  • However, the cost to recovery is low for the more frequent opportunities
  • High opportunity – low stakes and high frequency. GIt push is muscle memory
  • Low opportunity – high stakes and low opportunity
  • Frequency is what creates the opportunity


  • Everyone would agree impacting the customer is an incident
  • If didn’t affect the customer, not always called an incident.
  • If not called an incident, no incident review.
  • Missed learning opportunity
  • We view incidents as bad.
  • Incidents are unplanned work.
  • Near misses save the day, but don’t get recognized or learned from
  • Systems are continuously changing; will never be able to remove all problems from system

Techniques to learn

  • Root cause analysis is insufficient. Like a post mortem, it is just about what went wrong.
  • Needs to be a learning review
  • Discuss language barriers, tools, confidence level, what people tried
  • Discuss what happened by time and the impact
  • ChatOps better than phone bridge because can capture what happened. Nobody is going to transcribe later. Having clean channel for communication helps.
  • However, incidents not linear.
  • Book: Overcomplicated
  • If someone just does one thing, the learning doesn’t transfer. Need operational knowledge and mental models

Learning Reviews

  • Set context – not looking for answers/fixes. Looking for ways to learn even if no action items
  • Set aside time/effort to be curious
  • Asking linear questions (ex: five whys), don’t get to reality system
  • Invite people who weren’t part of incident response. They should still learn and can provide info about system
  • Understand and reduce blind spots

My impression

Good talk. It’s definitely thought provoking. And suggests small things one can do to start making things better