7. @andreasklinger
- high level learnings from SV
- learnings engineering management
⏩ I shared all slides on twitter.com/andreasklinger
& I will focus on early-stage/small teams
Goal of this talk 🍾
8. @andreasklinger
The biggest challenge in (
EU vs USA
In ( teams focus much on the “HOW”.
Eg the technical implementation.
In the ) teams focus on product/market/traction.
Why i focus on “early stage”?
9. @andreasklinger
We needed to build
Product
Recommendations
Looked at ML… nah overkill…
Implemented a simple recommendation
engine via a GraphDatabase. Basically
“People who liked also liked…” using a
few external SaaS services using Neo4j
and a few smaller nodeJS services that
orchestrate etc etc……… 😴
⬅
Example
10. @andreasklinger
, @rrhoover:*
“Can we… like… simply have an admin form
and do it manually… but launch tomorrow?”
* Ryan Hoover, CEO of Product Hunt, a company backed by
YCombinator, A16Z, Google Ventures, Greylock, Betaworks, Naval
Ravikant, Ashton Kutcher, Andrew Chen, GaryV, Alexis Ohanian, …
14. @andreasklinger
Hiring worked
- i managed to hire amazingly smart people
They knew what to do…
- way better programmers than i am
- i didn’t want to lose them 🙀
But i needed to learn…
- how to stop being a control freak.
- how to enable them.
- being a manager.
- didn’t want to become a full-time manager 😬
16. @andreasklinger
- define processes
- facilitate communication if processes fail
Management
Leadership
- provide a reason to go somewhere, not the path
- guide people when needed (incl. career)
18. @andreasklinger
You always have management.
You always have hierarchies.
They might not be explicit
…or enabling
…or fair
…or inclusive
…or good
“Management is bad”
“We have no hierachies”💡
💩
SF BRO
19. @andreasklinger
…the person who decides
- Teach *how* you decide, not what you decide.
- Only every 10th decision should reach you.
- Only every 100th decision you override.
- Push authority to place of action.
…a full-time communication hub
- we have no full-time managers
- see it as anti pattern / process mistake
- eg CEO of AngelList (100pax) helps w/ Sales
- eg COO of CoinList does Design
A manager is not…
20. @andreasklinger
step 1 -> step 2 -> etc…
person a -> person b -> person c -> etc…
but…
Processes are not…
21. @andreasklinger
process = expectations made explicit
Eg:
“We do pull requests reviews every morning”
“Leave notes for deployment in case you can’t deploy yourself”
“No codestyle discussions -> linters”
“Share weekly meetings in the team calendar”
“Define your team OKR until X”
“Leave notes of every call”
22. @andreasklinger
Don’t over-engineer
Do refactor your processes
Every growing team needs to refactor
their processes ~6 months.
- keep them simple
- let them emerge naturally
- make them explicit(!)
- it won’t work forever
— wait for new problems to arise
- refactor again
🛠
23. @andreasklinger
Hate process problems? 🤢
You will always have them…
…until your company stagnates or dies.
Sorry.
Embrace change ♻
This is often a exhausting phase.
Differ between your frustration with people
and your frustration with context.
24. @andreasklinger
people x context = output
amazing people perform horribly in wrong context
average people perform brilliantly in good context
context includes process but also if people are
happy, fulfilled, improving, like working with other
people in the team, etc etc
context is your responsibility as a leader 😬
25. @andreasklinger
Leadership 😇
- focus on people
- their ability to improve
- their life
- their standing in the team
- their whole career, not just this current job
- focus on ideally 10 people max
- use 1on1s for people topics, not project status
- a leader never has a bad day 😬*
* still working on that one 🤷
- provide a reason to go somewhere, not the path
- guide people when needed (incl. career)
In detail:
30. @andreasklinger
Who decides here?
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Marketing person
Used to do UX hates
new UX
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
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
Pete
Adds his opinions
to everything
F** pete.
Totally not a real situation
that happened at Product Hunt
31. @andreasklinger
Who decides here?
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
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
Marketing person
Used to do UX hates
new UX
Pete
Adds his opinions
to everything
F** pete.
Project team asked to decide
32. @andreasklinger
Who decides here?
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
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
still
disagreement
Marketing person
Used to do UX hates
new UX
Pete
Adds his opinions
to everything
F** pete.
Project team asked to decide
33. @andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
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
Project team disagreed
Designer has UX competence and UX ownership
Engineer didn’t want to override
Reformulated as risk question.
What risk is ok to proof right/wrong?
A small prototype was built.
User testing showed the new UX performed better.
34. @andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI better.
Doesn’t see the point.
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
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
Project team disagreed
Designer has UX competence and UX ownership
Engineer didn’t want to override
Reformulated as risk question.
What risk is ok to proof right/wrong?
A small prototype was built.
User testing showed the new UX performed better.
(Spoilers: The new UX was still removed in later
versions b/c it didn’t work well with a redesign
the Designer did)
35. @andreasklinger
Support the project team and their decision
They are closer to the problem/solution
Explain why you think differently
“Do whatever you think is right, but better be right”
Hire + Fire for good judgement
Careful: your “opinion” has weight - do not derail by accident.
Ask to be proven wrong
But insist on the proof.
Disagree and Commit
Read: Andrew Grove, High Output Management
Read: Jeff Bezos, Amazon Shareholder Letter, 2016
Rare interventions
Really necessary or just your “opinion”/“ego talking”?
If happens regularly => process problem
Don’t just tell *what* you decide, but *why* – and teach *how* decide
Avoid Drive-by Management ☠
The problem is with the manager 😑
37. @andreasklinger
< It’s never a team bandwidth issue…
It’s always a prioritization issue!
speed = right work, not “fast” work.
- prioritize the right work
- build up momentum
- create engineering confidence
- focusing on single player experience
Team too slow?
39. @andreasklinger
code—linter enforces complexity rules (rubocop, prettier)
=> code simple enough
automatic static code analysis (brakeman)
=> code secure enough
tests pass (circle.io, rspec)
=> code save enough
pull request enforced adding of tests (danger.js)
=> code tested enough
automate everything
Optimize for single player 🕹
40. @andreasklinger
use feature flags & dark launches (flipper)
=> code can be shipped faster (eg half done)
use demo instances
=> code can be shown easily for feedback
provide small, sanitized production db dumbs
=> code (and bugfix) can be developed with real data
make it easy to ship, mess up, build & learn
Optimize for single player 🕹
41. @andreasklinger
assume someone will be alone when 💩 goes down
=> automate devops scripts
=> document approaches
have everything in git (incl infrastructure)
=> easier to see reasons for regressions
have post-mortems after worst cases
write down what happened and what the action is
(no action is ok)
=> easier to act faster next time around
help future worstcases
Optimize for single player 🕹
42. @andreasklinger
define weekly meetings
=> clear time to ask questions, less adhoc interruptions
meeting is owned by the team doing the work
=> clear agenda
=> they guide through meeting, they decide who joins
leave notes of meeting
=> focus on decisions + todos, not discussions
=> good notes = less FOMO, less reason to join
make meetings efficient
Optimize for single player 🕹
44. @andreasklinger
- code will either change or die
- codebase management = keeping changes cheap
- confidence encourages change
Isolation and colocation of code > Code-reuse
Tests
Test of boundaries = must have
Test of internals = focus on edge cases
Reuse/Refactor
When you have 3 cases
Codebase management ♻
45. @andreasklinger
Codebase Management: Simple > Easy
https://www.youtube.com/watch?v=rI8tNMsozo0
Remember:
Most complicated problems
are just complex problems
in disguise.
Break apart, prioritize,
simplify.
47. @andreasklinger
- create small units
- share ownership
- document
- refactor
- test
- reevaluate best practices over time
Treat your organization like software
Treat people like capable adults
- you can either hire driven intelligent people
XOR
- micro-manage people
(those two are mutually exclusive)
Every problem is ultimately your fault.
- you defined processes
- you hired team
- you guided them