The opening talk of running remote 2019.
I tried to explain what makes distributed teams and remote work special.
I talk about the most important aspect in remote teams: trust
5. @andreasklinger
Product Hunt ➡ AngelList
Current Role: Head of Remote
Product strategy lead for
remote centric products
Helping international talent
finding international careers
2017
6. @andreasklinger
angel.co/jobs
Free job listings
7.000+ startups hiring remote
incl 1.000+ fully remote startups
alist.co
Premium Recruiting services
Hire your VP of Engineering
angel.co/talent/source
Talent Search Engine
1.000.000+ registered users,
who are open to remote jobs
8. @andreasklinger
Disclaimer
Talk is opinion-heavy, feel free to disagree
- what worked for me might not work for you
- i am experienced with small (not large) teams
- concepts can be applied to non-remote or non-tech teams 👍
Consult your doctor, use at own risk
9. @andreasklinger
Goal of talk
- Differences for remote teams
- PH’s approach to autonomy
- Decision making and ownership in your team
10. @andreasklinger
Why remote work?
- Logical evolution of digital knowledge work
- Everybody is already working remote
The only question is just how much and how enabled?
- Large companies (like eg google) are basically
remote teams in denial
- Optimizing daily life leads to better productivity,
inclusion, happiness & retention
And my personal motivation:
- International talent should have international careers
11. @andreasklinger
Remote teams require ~5x the process as colocated teams.
- eg 5 people need to act like 20-25 people (until large size)
- you plan meetings, have agenda, define work processes.
Co-located teams can monkey-patch bad processes
- eg more meetings, “management by walking around” or
simply by micro-manging
Co-located teams: meetings are easy, writing stuff down is exhausting
Remote teams: writing stuff down is easy, meetings are exhausting
Remote good for iteration (focus)
In person good for innovation (nuance)
Strong connections to team needed to “know what’s going on”
because video-calls suck.
How is managing remote teams different?
20. @andreasklinger
“I either trust someone or i don’t” = wrong
Trust is not binary.
You trust some people more than others.
You trust people with one thing more than with another.
Your trust in people changes.
Systemizing Trust
Thinking about trust
21. @andreasklinger
“Trust is earned” = true, but…
What about new people joining?
How will you enable the new Product Manager to really give their best?
Systemizing Trust
22. @andreasklinger
“Trust comes natural to me…” = sure…
Without creating systems around how/when/why we give trust and
what we expect in return we are opening up ourselves (or the company)
to biases.
Martha joined, and just gets it… She is a go-getter showing where we can improve.
Steven on the other hand is constantly out of line and nagging about problems.
… or we risk losing your values (that enabled us to work efficiently) as we scale.
“When i joined you said this is a ‘ask for forgiveness’ type of company?
I had to get permission for every little step…”
Systemizing Trust
23. @andreasklinger
Systemizing Trust
Trust
… through process
… through explicit & transparent communication
… through sharing authority
… through decentralizing decisions
… through understanding each other's (eg cultural) differences
… through intentionally meeting each other
… etc
Without systemizing and managing trust remote teams simply don’t work.
Systemizing Trust
24. @andreasklinger
Always the most important thing:
Meet your people face to face
Getting to know each other as humans cannot be
replaced.
Meet for team retreats, project kickoffs,
pivot discussions.
Regularly. It’s worth it.
Systemizing Trust
First PH team at YC Demo Day YC S14
This was the first time we met in person.
We had worked together for months,
but we didn’t know if we should
shake hands, hug, kiss…
What kind of relationship did we
have at this point?
Meeting in person is worth the ⏱ & 💰
Before we go into with PH’s approach on autonomy:
26. @andreasklinger
People are fast and capable
Unless they are blocked
Being blocked in remote teams is extremely expensive.
- No “Management by Walking Around”
- Timezone differences
2
Optimizing for Single Player Mode
29. Optimize for
Single Player
Mode
Does not mean isolating
or working always alone
But avoiding unneeded
inter-dependencies
and blocking
Autonomy != Abandonment
“We trust you do whatever you think is right”
without framework will just frustrate people.
Single Player Mode
30. @andreasklinger
Step 1:
Establish a “find a path” attitude
Product Hunt
“Design missing?” -> use standard components
“Product aspects unclear?” -> you decide, get feedback later
“Unsure what to work on next?” -> decide based on effectiveness
“Technical implementation too complex?” -> fake it for now
Optimizing for Single Player Mode
31. @andreasklinger
If you like product a
you might like product b
We had no time to build a good technical
solution.
⬅
Recommendations
Optimizing for Single Player Mode
32. @andreasklinger
* Product Hunt, a company backed by YCombinator, A16Z, Google Ventures,
Greylock, Betaworks, Naval Ravikant, Ashton Kutcher, Andrew Chen, GaryV,
Your uncle, Alexis Ohanian, …
Add recommended products:
Recommended Post Id:
*Some Post (delete)
*Some other Post (delete)
*Another Post (delete)
Recommended Products
Add
Product Hunt Admin Dashboard *
34. @andreasklinger
📺
🎮
Step 2:
Invest in tooling and automate feedback
🔎 Code—linter, static code analysis, tests, auto-formatting,
bots that check best practices of code-reviews, …
=> Developer knows code is good enough
🔦 Feature flags, dark launches, demo instances, easy deploys & reverts, …
=> Developer can ship with confidence
📝 Infrastructure changes in git, tool access in team keychain,
documented previous post-mortems, …
=> Developer can fix worstcase scenarios
Invest in Developer UX
So that people have fast constant feedback, before anyone gets even online.
Optimizing for Single Player Mode
35. Example 1: Code Reviews
- Everyone every morning
- People can rely on it and don’t need to remind
- Address feedback with code or comment.
- No need to wait for people to “re-review and approve”
- As reviewer:
- Do not to critique but help to ship faster
- Don’t focus on how you’d do it unless it’s objectively better
- Focus on high level discussion not implementation details
- Never block unless dangerous. Give 👍 by default
- As reviewed coder:
- Get two +1 before going live
-> Need to ship earlier? Go for it. We trust you
- No codestyle discussions, ever
-> add linter rule or STFU
Step 3:
Processes to enable and avoid back/forth
36. @andreasklinger
Optimizing for Single Player Mode
Step 3:
Processes to enable and avoid back/forth
Example 2: Fix-it Friday
Every Friday everyone can work on whatever they think is useful.
Idea: The opposite of “death by thousand cuts” is “thousand little bandages”
🛠 No “authorized” backlog needed.
🛠 Let your developers decide…
🛠 Everything is fair game.
After 2-3 months you should start seeing
significant improvements.
Document and acknowledge achievements!
Apart of Fix-it Fridays avoid refactoring without product value
37. @andreasklinger
Don’t over-engineer
Instead refactor your processes
regularly
Every growing team needs to refactor their
processes ~6 months.
- keep them few & simple
- let problems emerge
- look naturally grown solutions
- discuss as a team
- make them explicit(!)
- accept that they won’t work forever
— wait for new problems to arise
- refactor again
🛠
Optimizing for Single Player Mode
Step 3.1:
38. @andreasklinger
Step 4:
Keep stuff out in the public
- By default
- discuss in public team chat channels (or leave summary)
- share documents
- take meeting notes
- share decision summaries (eg after each call)
- etc etc…
Never get to the point that someone needs to ask for information.
Because they won’t. Especially the new folks won’t.
Optimizing for Single Player Mode
40. @andreasklinger
Outcome example: Onboarding
Product Hunt
day 1: ship something
even if just README.md update
week 1: demo something to the team
even if super small
month 1: remove something
even if just small legacy code
build something reusable
even if just small legacy code
if this isn’t possible. the team’s fault.
if you break something. the team’s fault.
if you are blocked. the team’s fault.
the on-boarding works.
new engineers spearhead (or often lead) projects usually within weeks after joining.
He is amazing.
Took over PH Engineering after i left.
Took our principles & brought them to the next level.
A lot I mention in this presentation I learned from him.
@rstankov CTO of PH
Optimizing for Single Player Mode
41. @andreasklinger
Optimizing for Single Player Mode
@devladinci ❤
(Sofia, Bulgaria)
“But Andreas, i am not a web-developer”
Joined as junior iOS developer,
took over iOS development.
Later transitioned to leading web
projects within weeks,
Now owns SEO strategy at Product Hunt
(and works on multiple other products)
@rahulmfg ❤
(Chennai, India)
“i don’t think i can do this”
Submitted bug reports to PH,
learned rails + react to join PH,
was very much overwhelmed Jr when
joining ;)
Launched “Promoted Posts”.
Today PH’s biggest money maker
Outcome: Enabling people to grow as developers and take ownership
Process -> Confidence -> Ownership -> Momentum -> Trust
Disclaimer: Both (and many more in the team) are amazing developers and would have been successful with or without PH.
I don’t claim that this a magic technique. They rock. I believe our approach at PH is very healthy and should be done by more teams.
43. @andreasklinger
…the person who decides
- Only every 10th decision should even reach you.
- Only every 100th decision you should override.
…a full-time communication hub
- try not to have full-time managers*
- see it as anti pattern / process mistake
- eg CEO of AngelList (until 100pax) helped w/ BD/Sales
- eg COO of CoinList does Design
- eg CTO of Product Hunt builds features and is #1 to pick 💩-y dev chores
A manager is not…
* changes when you get large… but see how long it doesn’t has to.
Delegation of Trust
44. @andreasklinger
Delegation of Trust
- define processes
- facilitate communication if processes fail
- provide a reason to go somewhere, not the path
- guide people when needed (incl. career)
You manage processes
You lead people
45. @andreasklinger
How do you enable people to take ownership
and make the “right” decisions?
Teaching them how you decide not what you decide
Framework
Where does the company want to go to? (vision)
What’s the plan to get there? (strategy)
How does the company make decisions? (values)
Which decisions do team members own? (authority) 👈
Delegation of Trust
46. @andreasklinger
Delegation of Trust
There is no right or wrong answer to this.
Hundreds of books were written about this.
You just need your answer.
But don’t worry too much…
Your answer will change a lot over time anyway.
48. @andreasklinger
In every project (or meeting) it needs to be clear:
- who makes decisions
- who adds opinions
If you don’t make decisions -> you just add opinions
Ideally the project team should make the decisions.
They are also the ones dealing with the consequences.
If you need to override decisions:
Consider it an intervention and find out what went wrong.
Delegating trust
Delegation of Trust
Opinions VS Decisions
49. @andreasklinger
Previous Engineer
hates the new UX
and thinks it’s
against best
practices
Senior Designer
Used to do the
mobile UX
hates new UX
Unrelated Co Founder
Tries to finally get that
team to use data
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Current Engineer
and Project Lead
doesn’t like new UX
but can do it in
time
Designer
wants to try
alternative UX
approach to an old
feature, sees big
opportunity
Senior Eng Pete
Adds his opinions
to everything
F** pete.
Decisions vs Opinions
Delegation of Trust
Unrelated Co Founder
Thinks the new
layout could be
big opportunity
Who decides here?
50. @andreasklinger
Previous Engineer
hates the new UX
and thinks it’s
against best
practices
Senior Designer
Used to do the
mobile UX
hates new UX
Unrelated Co Founder
Tries to finally get that
team to use data
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Current Engineer
and Project Lead
doesn’t like new UX
but can do it in
time
Designer
wants to try
alternative UX
approach to an old
feature, sees big
opportunity
Senior Eng Pete
Adds his opinions
to everything
F** pete.
Decisions vs Opinions
Delegation of Trust
Unrelated Co Founder
Thinks the new
layout could be
big opportunity
Who decides here?
The team right?
Right?
But who in the project team?
The Lead?
The Designer should “own” design decisions, right?
Everybody?
51. @andreasklinger
Whenever stuck, reframe decisions
as risk discussions
Delegation of Trust
Sometimes authorities and competences overlap. But when people try to
convince each other who is right, they have a binary discussion
What is the risk we are willing to commit? -> Usually risk = resources
What resources can they agree to commit?
1 week of the whole team? of the designer’s time?
What could be the outcome? A prototype?
Worstcase: Disagree and Commit
Tip #1
52. @andreasklinger
When stuck, sometimes you just need to ship
Discussions about readiness with “perfectionists” are sometimes tiring.
Is it ready or not? This is again a binary discussion.
Instead use feature flags
to release it to 1% of the audience
At PH used the 1% approach for multiple
“too large to ship, but still unfinished” products.
Heck i even shipped products missing essential
features to 1% of the audience.
As soon as it’s live… the discussion changes.
Delegation of Trust
Tip #2
53. @andreasklinger
Sometimes you accidentally derail decisions
Avoid drive-by management. Jumping into a discussion
and without context adding your opinions.
Remember:
Your opinion as manager/founder carries weight.
Use
#fyi tags to signal your intent.
Especially useful in multi-cultural teams
#fyi #suggestion #recommendation #plea
https://klinger.io/post/183526480955/fyi…
Method by
Dharmesh Shah
(HubSpot)
Delegation of Trust
Heard about it
via Wade Foster
(Zapier)
Tip #3
54. @andreasklinger
Embrace change ♻
Building teams is exhausting.
Problems will just get replaced with new problems.
Until your company stagnates or dies.
Differ between your frustration with people
and your frustration with the situation.
Delegation of Trust
To wrap this up…
55. @andreasklinger
Ultimately everything is your fault.
You established the processes.
You mentored the people.
You hired the people.
You maybe didn’t fire the people.
If you struggle figuring this out,
don’t push your stress on the team:
Get a coach and level up
Delegation of Trust
Good news everyone,…
56. @andreasklinger
Giving and managing trust in a team
Your team is ok w/ more ownership.
Usually the problem is w/ yourself (the manager)
🤗
😬
Delegation of Trust
Ultimately, it comes down to…
59. @andreasklinger
Further reading re management:
Joel Gascoigne about being servant leader
https://podtail.com/podcast/the-heartbeat/episode-31-
interview-with-joel-gascoigne-ceo-co-fo/
Presentation on Management:
https://www.slideshare.net/andreasklinger/engineering-
management-for-early-stage-startups-97402850
Managing remote teams: A crash course
https://klinger.io/post/180989912140/managing-remote-teams-
a-crash-course
Fin