|
|
|
|
@ -0,0 +1,301 @@
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Alias: [""]
|
|
|
|
|
Tag: [""]
|
|
|
|
|
Date: 2022-03-01
|
|
|
|
|
DocType: "WebClipping"
|
|
|
|
|
Hierarchy:
|
|
|
|
|
TimeStamp:
|
|
|
|
|
Link: https://klinger.io/posts/managing-people-%F0%9F%A4%AF?ref=refind
|
|
|
|
|
location:
|
|
|
|
|
CollapseMetaTable: Yes
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Parent:: [[ReadItLater]]
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
 
|
|
|
|
|
|
|
|
|
|
```button
|
|
|
|
|
name Save
|
|
|
|
|
type command
|
|
|
|
|
action Save current file
|
|
|
|
|
id Save
|
|
|
|
|
```
|
|
|
|
|
^button-ManagingpeopleAndreasKlingerNSave
|
|
|
|
|
|
|
|
|
|
 
|
|
|
|
|
|
|
|
|
|
# Managing people 🤯 | Andreas Klinger
|
|
|
|
|
|
|
|
|
|
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](https://klinger.io/posts/joining-hypergrowth-startups-%F0%9F%98%AC) are my recommendations on joining hypergrowth companies in general.
|
|
|
|
|
|
|
|
|
|
**Who am I?**
|
|
|
|
|
|
|
|
|
|
* I managed several small and midsized engineering teams
|
|
|
|
|
* CTO at [On Deck](https://beondeck.com/)
|
|
|
|
|
* 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 has 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 talented people.
|
|
|
|
|
|
|
|
|
|
#### Avoid back and forth
|
|
|
|
|
|
|
|
|
|
* When defining processes, avoid back and forth
|
|
|
|
|
* Eg. if you give feedback on something assume that they will either do it or get back to you with reasons why not
|
|
|
|
|
* Don't expect them to get your approval
|
|
|
|
|
* _Ain't nobody got time for that_
|
|
|
|
|
|
|
|
|
|
#### Trust
|
|
|
|
|
|
|
|
|
|
* Always reflect if your nervousness is due to other people's work or your insecurity
|
|
|
|
|
* Should other people have to handle your emotions for you?
|
|
|
|
|
* Also, it's easy to trust when things go well
|
|
|
|
|
* The real challenge is when things go wrong
|
|
|
|
|
* Always differ between your frustration about a situation and your frustration about a person
|
|
|
|
|
* I am not saying "stay out of it"
|
|
|
|
|
* Stay in the loop, set expectations, voice opinions, but let them handle it. Use your handbrake if needed.
|
|
|
|
|
|
|
|
|
|
#### Trust through transparency
|
|
|
|
|
|
|
|
|
|
* The easiest way to have people trust your work is by transparently sharing it without request.
|
|
|
|
|
* Have everything accessible where people would look for it
|
|
|
|
|
* Don't make them ask for it, because most won't
|
|
|
|
|
|
|
|
|
|
#### Trust is not binary
|
|
|
|
|
|
|
|
|
|
* We tend to think of trust as binary
|
|
|
|
|
* I either trust someone, or i don't
|
|
|
|
|
* But this isn't true
|
|
|
|
|
* You trust different people with different things differently over time.
|
|
|
|
|
* Think of trust as something that you systemize
|
|
|
|
|
* Eg what kind of trust do you give a new team member?
|
|
|
|
|
* What are they expected to do in the first weeks? first month?
|
|
|
|
|
|
|
|
|
|
#### Don't confuse autonomy and abandonment
|
|
|
|
|
|
|
|
|
|
* I frequently meet founders who hire people "and get out of their way"
|
|
|
|
|
* While this is in principle correct, it doesn't absolve you from enabling them to succeed
|
|
|
|
|
|
|
|
|
|
#### Decision Layering
|
|
|
|
|
|
|
|
|
|
* Different people in the company on various levels rely on each other on doing their work.
|
|
|
|
|
* A product manager can't do their job if the CEO doesn't know what their current priorities are.
|
|
|
|
|
* Don't load your work onto others in the company.
|
|
|
|
|
* And also avoid stepping into their work just because looks more fun.
|
|
|
|
|
|
|
|
|
|
#### Avoid drive-by management
|
|
|
|
|
|
|
|
|
|
* Don't start throwing your opinion or ideas around in meetings
|
|
|
|
|
* You most likely lack context, and most likely, you won't be the person needing to follow through.
|
|
|
|
|
* Make it clear that it's just opinions and not decisions.
|
|
|
|
|
* But know the power that the "opinion of the founder (or manager)" has towards most employees
|
|
|
|
|
* Use [fyi tags](https://klinger.io/posts/fyi-how-founders-can-avoid-drive-by-management) in async communication that usually lacks the "nuance" of voice.
|
|
|
|
|
|
|
|
|
|
Btw, I call it drive-by management because the manager comes by a group of people having a discussion. They throw requests, change mandates, and ideas around like bullets, create confusion, panic, chaos, and when they leave, they leave a bloody mess behind.
|
|
|
|
|
|
|
|
|
|
#### Feedbacking people
|
|
|
|
|
|
|
|
|
|
* people x context = output
|
|
|
|
|
* I had great people in bad setups that had lousy output
|
|
|
|
|
* I had very ordinary people in great setups that churned out more work than a whole team
|
|
|
|
|
* When you feedback work, it's usually easier to discuss the context objectively than the person themselves
|
|
|
|
|
* What is the situation that led to current problems?
|
|
|
|
|
* What changed? What is currently required?
|
|
|
|
|
* A junior engineer not keeping up with the work?
|
|
|
|
|
* Is it their fault? Or is your team right now not able to support a junior learning the game?
|
|
|
|
|
* This is ok, but should be either fixed or acknowledged (by discontinuing)
|
|
|
|
|
* A huge production incident happened?
|
|
|
|
|
* How was this possible in the first place?
|
|
|
|
|
* Where was the focus of the engineering team?
|
|
|
|
|
* Was there a process in place to avoid it?
|
|
|
|
|
* Should there be one?
|
|
|
|
|
* The person breaking production isn't at fault here.
|
|
|
|
|
* A whole team focused on other priorities
|
|
|
|
|
* Was this for the right reasons? (eg release pressure?)
|
|
|
|
|
* Or the wrong ones? (lacking sophistication?)
|
|
|
|
|
* Always assume people you hired are motivated, and have the best intentions in mind
|
|
|
|
|
* And fire the ones that don't
|
|
|
|
|
|
|
|
|
|
#### Firing should never be a surprise
|
|
|
|
|
|
|
|
|
|
* People should never be surprised that they are fired
|
|
|
|
|
* Context changed; new requirements should have been communicated
|
|
|
|
|
* When you discontinue someone, you do it usually because of context
|
|
|
|
|
* The company changed
|
|
|
|
|
* The expectations of the role changed
|
|
|
|
|
* You realized you looked for the wrong hiring criteria
|
|
|
|
|
* It's most likely more your fault than theirs
|
|
|
|
|
* They might have hoped that their new efforts were enough
|
|
|
|
|
* But they will still understand when you fire them
|
|
|
|
|
|
|
|
|
|
#### Never delay firing
|
|
|
|
|
|
|
|
|
|
* Once you decide to fire someone, do it.
|
|
|
|
|
* Frequently people keep employees around in a zombie-like state
|
|
|
|
|
* "We should discontinue them."
|
|
|
|
|
* But you don't
|
|
|
|
|
* It's not for them
|
|
|
|
|
* They are most likely unhappy in their setup
|
|
|
|
|
* Not appreciated
|
|
|
|
|
* Not able to do good work
|
|
|
|
|
* You are most likely doing it for yourself
|
|
|
|
|
* Because you are not feeling good about firing someone
|
|
|
|
|
* They deserve better than you caring more about your feelings and future than theirs
|
|
|
|
|
* Set up a call and discontinue them
|
|
|
|
|
* Avoid any chitchat in the beginning
|
|
|
|
|
* Start directly with the topic and have explicit clarity on the next steps
|
|
|
|
|
* Make sure to communicate it as fact and truth
|
|
|
|
|
* Remember that in this moment it's not about your feelings or problems
|
|
|
|
|
* Then help them find new roles
|
|
|
|
|
* They trusted you with their career, make sure to keep that trust
|
|
|
|
|
* Last note: In some countries firing someone is a matter of days in some months
|
|
|
|
|
* In either case manage that process pro-actively and with respect to the people who trusted you
|
|
|
|
|
* Those people trusted your team with their career
|
|
|
|
|
* Most likely the reason they are leaving not their fault but the changes in context
|
|
|
|
|
* Help them landing a new role that fits them
|
|
|
|
|
|
|
|
|
|
#### Explicit > Implicit
|
|
|
|
|
|
|
|
|
|
* Clear decisions after meetings
|
|
|
|
|
* No clear decision? Make that explicit too.
|
|
|
|
|
* Clear owners
|
|
|
|
|
* No clear owner? Make that explicit too.
|
|
|
|
|
* Hear everyone's opinions
|
|
|
|
|
* Make explicit who makes the decision
|
|
|
|
|
* And what the decision is
|
|
|
|
|
* etc
|
|
|
|
|
|
|
|
|
|
#### Best practices: Start by making true what's real
|
|
|
|
|
|
|
|
|
|
* When looking for best practices or changes in the team/processes, always look at first what already naturally emerged
|
|
|
|
|
* If you hire good people, they usually start looking for solutions naturally
|
|
|
|
|
* Is this good? If yes, make it explicit
|
|
|
|
|
* "Make true what is real"
|
|
|
|
|
* If not, discuss changing it
|
|
|
|
|
|
|
|
|
|
#### Expect to refactor your company every few months
|
|
|
|
|
|
|
|
|
|
* Fast-growing startups have to refactor how they operate internally every 3-6 months
|
|
|
|
|
* So just go with the minimum changes you currently need
|
|
|
|
|
* There will never be a final endstate
|
|
|
|
|
* You will always be unhappy with processes in your company
|
|
|
|
|
* You will have growing pains until you stagnate
|
|
|
|
|
* Use the same principles you'd use in refactoring code
|
|
|
|
|
* Consider to
|
|
|
|
|
* Test in small isolation first
|
|
|
|
|
* Peer review
|
|
|
|
|
* Not to change everything at once
|
|
|
|
|
* Avoid over-engineering
|
|
|
|
|
* etc
|
|
|
|
|
|
|
|
|
|
#### Burnout
|
|
|
|
|
|
|
|
|
|
* It's a common misconception that burnouts come from hard work.
|
|
|
|
|
* Burnout comes from a felt loss of control and/or impact.
|
|
|
|
|
* Remember that you can burn out employees (or yourself) with little to no work.
|
|
|
|
|
* How can you give people control over their impact?
|
|
|
|
|
* How can you define boundaries around chaos around them?
|
|
|
|
|
|
|
|
|
|
#### Chaos is felt less by the people creating it
|
|
|
|
|
|
|
|
|
|
* A common frustration of founders is that their team can't keep up with pivots.
|
|
|
|
|
* As a founder, you most likely got more context on changes, you know earlier of them, and most importantly, you have control over them.
|
|
|
|
|
* Employees don't.
|
|
|
|
|
|
|
|
|
|
#### Expect more from managers that report from you
|
|
|
|
|
|
|
|
|
|
* By default, mistakes are not their team's fault but theirs
|
|
|
|
|
* Share your honest opinions on things with them privately
|
|
|
|
|
* By default, always give them the trust needed to make decisions
|
|
|
|
|
* They are accountable for the outcomes
|
|
|
|
|
* Responsible for all failures
|
|
|
|
|
* But not responsible for the success
|
|
|
|
|
* Success is the team's achievement
|
|
|
|
|
* They should also, whenever possible, give spotlights to their team instead of taking it for themselves
|
|
|
|
|
* The deal is simple: They get more authority; the team gets more ways to shine
|
|
|
|
|
|
|
|
|
|
What a cheerful ending 😬
|
|
|
|
|
|
|
|
|
|
Anyway… I hope this article is useful to some 🙏
|
|
|
|
|
|
|
|
|
|
There are many more things that I obviously miss – so feel free to send me questions via [twitter](https://twitter.com/andreasklinger) or if you have ideas on improving this article, please [send me pull-requests](https://github.com/andreasklinger/klinger-io)!
|
|
|
|
|
|
|
|
|
|
Btw if you like the article, [I'd appreciate if you'd share it](https://twitter.com/intent/tweet?text=Managing%20People%20an%20article%20by%20%40andreasklinger%3A%20https%3A%2F%2Fklinger.io%2Fposts%2Fmanaging-people-%25F0%259F%25A4%25AF)
|
|
|
|
|
|
|
|
|
|
PS: [My team](https://www.notion.so/odteam/Product-Engineer-Playbook-859b2c4c95f849788554f1749d038c6f) is [hiring](https://jobs.lever.co/ondeck/bb589015-9cfa-4ee2-9eb2-5d0b5f5230ec)
|
|
|
|
|
|
|
|
|
|
© Copyright
|
|
|
|
|
|
|
|
|
|
2022
|
|
|
|
|
|
|
|
|
|
Andreas Klinger
|
iOS
3 years ago