Feb 6, 2022 · 11 min read · 0 views

I believe almost all first-time founders burn out their first employees as they learn how to manage groups of people. If this advice helps avoid a few cases, it’s worth writing it down.

I wrote this article for managers of small teams/startups. I’d assume that most might not apply to management in larger enterprises. Btw here are my recommendations on joining hypergrowth companies in general.

Who am I?

• I managed several small and midsized engineering teams 
  • CTO at On Deck
  • prev VPE at CoinList
    • Head of Remote at AngelList 
    • and CTO at Product Hunt

Let’s get started.

As a manager, everything is your fault

I know… very positive start 👀

• There is no point being angry at your team – ever
• You are in charge of processes and people
  • And you got more information than they do, always
• You either created the processes where this outcome happened
  • or you hired (or did not fire) the wrong people
• Ultimately everything is your fault

You manage processes; you lead people

• For some reason, “managing people” means for many that they need to control people’s work.
  • They end up micro-managing not only what when but also how people do their work.
  • If you got the time to micro-manage people, you can most likely hire cheaper, less talented people for your work
• I think it roots in a misunderstanding of what the role of a manager is:
  • your job is not to manage people
  • but to manage processes and lead people
• You manage processes on how you expect work to be done, where each person’s authority starts and ends, how their careers are made, and how all this can be discussed, and/or changed
• Additionally, you are leading people by example and through empathy.
  • They have goals, fears and motivations. Frequently also problems outside of work.
  • Act how you would want them to act if the role would be reversed.

Processes are expectations made explicit

• A lot of people make huge disclaimers around “processes.”
  • “We don’t want too many processes” etc
    • again, imho a misunderstanding
• Processes are not complex chains of people doing things that are burdened by horrible overheads
  • Processes are expectations made explicit
    • They can be as simple as “every morning we all do X to ensure everyone else is unblocked.”
  • Have few but very explicit processes and expect them to be followed

Decisions vs Opinions

• In every discussion/project/problem/situation, it needs to be clear who makes decisions
  • …everyone else only adds opinions.
  • Ideally, the person who will afterward do (or lead) the follow-up work makes the decisions.
    • Everyone else just adds opinions.
    • This includes people of higher “rank” or pay.
• Their manager have a handbrake they can use to hard-stop decisions.
  • Treat this as a literal handbrake.
    • Imagine a car driving, and you need to pull the handbrake because the car needs to stop, but the driver doesn’t react. Damage will follow.
    • Pull the handbrake if absolutely needed and then discuss how to fix the situation.
• Hire based on good decision-making skills
  • Fire based on poor decision-making skills
    • Good decision-making skills include listening to other people’s opinions.
  • In case of doubt, see if you can trust the decision-maker by default.

Ownership

• It’s hard to get people to own a problem space fully
  • But this is the goal
    • If they are the wrong person, you can still fire them
• Feedback them, help them
  • Trust them and let them make mistakes (within damage barriers)
  • Consider mistakes them leveling up
• The worst thing that can happen is that you frequently step in, and people disassociate from their work
  • They become drones who do what’s told instead of taking ownership.
  • If this is your goal, you can hire cheaper, less