Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
🔧
Engineering Management
for Early Stage Startups
Andreas Klinger
VPE of CoinList
former CTO of Product Hunt
@andreasklinger
⏩ I shared all slides on twitter.com/andreasklinger
Hi. 👋
@andreasklinger
Product Hunt
Place to discover
your next 😻 thing.
CTO
@andreasklinger
Product Hunt
Place to discover
your next 😻 thing.
@andreasklinger
2017:
Product Hunt ➡ AngelList
@andreasklinger
Since 2018
CoinList
spin-out of AngelList
Several products for
blockchain companies.
Eg Compliance 

Inves...
@andreasklinger
- high level learnings from SV
- learnings engineering management
⏩ I shared all slides on twitter.com/and...
@andreasklinger
The biggest challenge in (
EU vs USA
In ( teams focus much on the “HOW”.
Eg the technical implementation.
...
@andreasklinger
We needed to build
Product
Recommendations
Looked at ML… nah overkill…
Implemented a simple recommendation...
@andreasklinger
, @rrhoover:*
“Can we… like… simply have an admin form
and do it manually… but launch tomorrow?”
* Ryan Ho...
@andreasklinger
Product
Recommendations
Today
If possible still done manually.
Community suggested
Admin/Maker/Hunter cura...
@andreasklinger
“…and launch tomorrow?”
@andreasklinger
“Everything at Product Hunt is
manual, we just happen to have
servers that send HTML”
me to every new hire...
@andreasklinger
Hiring worked
- i managed to hire amazingly smart people
They knew what to do…
- way better programmers th...
@andreasklinger
Let’s talk about
Management ⚡
Disclaimer: Personal learnings and opinions.
Don’t try this at home. Consult...
@andreasklinger
- define processes
- facilitate communication if processes fail
Management
Leadership
- provide a reason t...
@andreasklinger
TLDR:
You manage processes
You lead people
@andreasklinger
You always have management.
You always have hierarchies.
They might not be explicit
…or enabling
…or fair
...
@andreasklinger
…the person who decides
- Teach *how* you decide, not what you decide.
- Only every 10th decision should r...
@andreasklinger
step 1 -> step 2 -> etc…
person a -> person b -> person c -> etc…
but…
Processes are not…
@andreasklinger
process = expectations made explicit
Eg:
“We do pull requests reviews every morning”
“Leave notes for depl...
@andreasklinger
Don’t over-engineer
Do refactor your processes
Every growing team needs to refactor
their processes ~6 mon...
@andreasklinger
Hate process problems? 🤢
You will always have them…
…until your company stagnates or dies.
Sorry.
Embrace ...
@andreasklinger
people x context = output
amazing people perform horribly in wrong context
average people perform brillian...
@andreasklinger
Leadership 😇
- focus on people
- their ability to improve
- their life
- their standing in the team
- thei...
@andreasklinger
Decisions 💥
@andreasklinger
Who decides here?
Product,
Problem,
Customer,
etc
@andreasklinger
Who decides here?
Product,
Problem,
Customer,
etc
Decisions close to the product.
- By default:
- the proj...
@andreasklinger
Who decides here?
Product,
Problem,
Customer,
etc
Layers
Strategic
Operative
Learn about OKRs
https://rewo...
@andreasklinger
Who decides here?
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Marketi...
@andreasklinger
Who decides here?
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI ...
@andreasklinger
Who decides here?
CTO
wants the team to use
“data-driven” approach.
Hard to do in new UX
CEO
likes old UI ...
@andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
wants the team to use
“data-driven” appr...
@andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
wants the team to use
“data-driven” appr...
@andreasklinger
Support the project team and their decision
They are closer to the problem/solution
Explain why you think ...
@andreasklinger
Performance :💨
Engineering Team
@andreasklinger
< It’s never a team bandwidth issue… 

It’s always a prioritization issue!
speed = right work, not “fast” ...
@andreasklinger
“Speed through confidence”
We want to avoid: “unsure if…”
Think of it as
CPU (Competent Person Unit) vs Te...
@andreasklinger
code—linter enforces complexity rules (rubocop, prettier)
=> code simple enough
automatic static code anal...
@andreasklinger
use feature flags & dark launches (flipper)
=> code can be shipped faster (eg half done)
use demo instance...
@andreasklinger
assume someone will be alone when 💩 goes down
=> automate devops scripts
=> document approaches
have every...
@andreasklinger
define weekly meetings
=> clear time to ask questions, less adhoc interruptions
meeting is owned by the te...
@andreasklinger
Code Base 🌋
Management
skipped
atlive
talk
-read
online
slides
@andreasklinger
- code will either change or die
- codebase management = keeping changes cheap
- confidence encourages cha...
@andreasklinger
Codebase Management: Simple > Easy
https://www.youtube.com/watch?v=rI8tNMsozo0
Remember:
Most complicated ...
@andreasklinger
TL;DR 😴
@andreasklinger
- create small units
- share ownership
- document
- refactor
- test
- reevaluate best practices over time
...
@andreasklinger
Questions?
Thanks!
PS:
Feel free to send me questions via Twitter DM,
if we miss each other here.
Nächste SlideShare
Wird geladen in …5
×

Engineering Management for Early Stage Startups

10.740 Aufrufe

Veröffentlicht am

Learnings from 4 years at Product Hunt

A talk i gave at Europe's largest Developer conference www.wearedevelopers.com and www.pioneers.io

Veröffentlicht in: Ingenieurwesen
  • Als Erste(r) kommentieren

Engineering Management for Early Stage Startups

  1. 1. 🔧 Engineering Management for Early Stage Startups Andreas Klinger VPE of CoinList former CTO of Product Hunt
  2. 2. @andreasklinger ⏩ I shared all slides on twitter.com/andreasklinger Hi. 👋
  3. 3. @andreasklinger Product Hunt Place to discover your next 😻 thing. CTO
  4. 4. @andreasklinger Product Hunt Place to discover your next 😻 thing.
  5. 5. @andreasklinger 2017: Product Hunt ➡ AngelList
  6. 6. @andreasklinger Since 2018 CoinList spin-out of AngelList Several products for blockchain companies. Eg Compliance 
 Investor accreditation and background-checks for ICOs. VPE
  7. 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. 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. 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. 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, …
  11. 11. @andreasklinger Product Recommendations Today If possible still done manually. Community suggested Admin/Maker/Hunter curated. If not enough: populated through automatic recommendations ⬅
  12. 12. @andreasklinger “…and launch tomorrow?”
  13. 13. @andreasklinger “Everything at Product Hunt is manual, we just happen to have servers that send HTML” me to every new hire afterwards
  14. 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 😬
  15. 15. @andreasklinger Let’s talk about Management ⚡ Disclaimer: Personal learnings and opinions. Don’t try this at home. Consult your doctor.
  16. 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)
  17. 17. @andreasklinger TLDR: You manage processes You lead people
  18. 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. 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. 20. @andreasklinger step 1 -> step 2 -> etc… person a -> person b -> person c -> etc… but… Processes are not…
  21. 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. 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. 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. 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. 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:
  26. 26. @andreasklinger Decisions 💥
  27. 27. @andreasklinger Who decides here? Product, Problem, Customer, etc
  28. 28. @andreasklinger Who decides here? Product, Problem, Customer, etc Decisions close to the product. - By default: - the project team. - the person implementing. Everyone else (including you): “just adds opinions” “she who codes, decides”
  29. 29. @andreasklinger Who decides here? Product, Problem, Customer, etc Layers Strategic Operative Learn about OKRs https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/ USEOKRr
  30. 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. 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. 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. 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. 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. 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 😑
  36. 36. @andreasklinger Performance :💨 Engineering Team
  37. 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?
  38. 38. @andreasklinger “Speed through confidence” We want to avoid: “unsure if…” Think of it as CPU (Competent Person Unit) vs Team I/O Optimize for single player 🕹
  39. 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. 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. 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. 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 🕹
  43. 43. @andreasklinger Code Base 🌋 Management skipped atlive talk -read online slides
  44. 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. 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.
  46. 46. @andreasklinger TL;DR 😴
  47. 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
  48. 48. @andreasklinger Questions? Thanks! PS: Feel free to send me questions via Twitter DM, if we miss each other here.

×