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
Benefits
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
Challenges
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
Onboarding
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
Workspace
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
Timing
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
Management
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
Trust
The half life of rust is 6 weeks
An interaction reinforces it
Tools
Video
Chat
Collaborative docs
Communication
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
Summits
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
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.
