Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Engineering Management for Early Stage Startups

9,235 views

Published on

Learnings from 4 years at Product Hunt

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

Published in: Engineering
  • Be the first to comment

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.

×