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)
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 đč
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