Engineering Management for Early Stage Startups

🔧
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  
Investor accreditation and
background-checks for ICOs.
VPE

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

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

@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

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

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

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

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

@andreasklinger
Let’s talk about
Management ⚡
Disclaimer: Personal learnings and opinions.
Don’t try this at home. Consult your doctor.

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

@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
…or inclusive
…or good
“Management is bad”
“We have no hierachies”💡
💩
SF BRO

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

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

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

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

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

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

@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 project team.
- the person implementing.
Everyone else (including you):
“just adds opinions”
“she who codes, decides”

@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

@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

@andreasklinger
Who decides here?
CTO
CEO
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Engineer
and Project Lead
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

@andreasklinger
Who decides here?
CTO
CEO
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Engineer
and Project Lead
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

@andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
CEO
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Engineer
and Project Lead
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.

@andreasklinger
Who decides here?
Marketing person
Used to do UX hates
new UX
CTO
CEO
“Waste of time”
Previous Engineer
doesn’t hate the
new UX but thinks
it’s against best
practices
Engineer
and Project Lead
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)

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

@andreasklinger
Performance :💨
Engineering Team

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

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

@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

@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

@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

@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

@andreasklinger
Code Base 🌋
Management
skipped
atlive
talk
-read
online
slides

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

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

@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

@andreasklinger
Questions?
Thanks!
PS:
Feel free to send me questions via Twitter DM,
if we miss each other here.

Engineering Management for Early Stage Startups

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Engineering Management for Early Stage Startups

Semelhante a Engineering Management for Early Stage Startups (20)

Mais de Andreas Klinger

Mais de Andreas Klinger (20)

Último

Último (20)

Engineering Management for Early Stage Startups