Engineering Management in Remote teams

Engineering Management
in Remote Teams
Andreas Klinger
Head of Remote, AngelList
former CTO of Product Hunt & VPE of CoinList
✌

@andreasklinger
⏩ I shared all slides on www.twitter.com/andreasklinger
Hi. 👋

@andreasklinger
Product Hunt
Place to discover
your next 😻 thing.
2014: Founding Team / CTO
Moved to San Francisco

@andreasklinger
Product Hunt
Place to discover
your next 😻 thing.

@andreasklinger
Product Hunt ➡ AngelList
Current Role: Head of Remote
Product strategy lead for
remote centric products
Helping international talent  
finding international careers
2017

@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

@andreasklinger
Starting an invite-only
investment syndicate
Investing as a group of experts
in remote startups and remote work tools
Ping me if you want to co-invest
or looking for investments
💰

@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

@andreasklinger
Goal of talk
- Differences for remote teams
- PH’s approach to autonomy
- Decision making and ownership in your team

@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

@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?

@andreasklinger
Processes? Timezones? Cultural differences? Work/life balance?
Imho everything comes down to Trust
But what’s really hard about managing remote teams?

@andreasklinger
Trust
“Is she coding?
…or playing fortnite?”

@andreasklinger
( “Is he actually motivated?”
Trust

@andreasklinger
🖥😐 “I am so excited”
Trust

@andreasklinger
+ “Mein feedback:
This solution sucks…”
Trust
,

@andreasklinger
🗺
“Nobody takes ownership. 
And if they do it’s the
wrong path… so I have to 
involve myself.”
Trust

@andreasklinger
🔨 “Are these refactoring
really necessary?  
We ship so slow already…”
Trust

@andreasklinger
Trust
/0
0/
“When did we start to need
8 people to decide even
small stuff?”

@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

@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

@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

@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

@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:

Optimize for
Single Player
Mode
Managing Trust:
Product Hunt’s
engineering team approach
to trust & autonomy

@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

Optimize for
Single Player
Mode
Thanks for
pressing jump
Now, please wait until Frank is online.

Optimize for
Single Player
Mode
Clear goals
Find paths
Rely on processes
Automate feedback
Enable to level up
Single Player Mode

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

@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

@andreasklinger
If you like product a
you might like product b
We had no time to build a good technical
solution.
⬅
Recommendations

@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 *

@andreasklinger
⬅
Product
Recommendations
Today
If possible still done manually.
Community suggested
Admin/Maker/Hunter curated.
*If* not enough: populated through
automatic recommendations

@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.

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

@andreasklinger
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

@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
🛠
Step 3.1:

@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.

@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

@andreasklinger
@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.

Decision making
🙀
Delegating Trust:
Approaches to  
delegation & decision making  
I learned over the years

@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

@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

@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

@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.

@andreasklingerLearn about OKRs
https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/
Product,
Problem,
Customer,
etc
Layer
Strategic
Operative
USEOKRr
Decide who decides what
Decision Layering
Delegation of Trust
We would all love to just
hand-over everything.
But this won’t happen.
Your job isn’t their job.

@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

@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
Thinks the new
layout could be
big opportunity
Who decides here?

@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
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
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?

@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

@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

@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

@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…

@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,…

@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…

@andreasklinger
Trust
“Is she coding?
Delegation of Trust

@andreasklinger
Trust
“Is she coding?
Why does it matter to you?
Establish trust in your team
Delegation of Trust

@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

@andreasklinger
Questions?
Thank you for your time!
PS: If we miss each other here:  
Send me questions via Twitter DM.

Engineering Management in Remote teams

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Engineering Management in Remote teams

Similar to Engineering Management in Remote teams (20)

More from Andreas Klinger

More from Andreas Klinger (18)

Recently uploaded

Recently uploaded (15)

Engineering Management in Remote teams