Managing People 🤯 §

Metadata §

• Author: Andreas Klinger
• Full Title: Managing People 🤯
• Document Note: This article provides advice to managers of small teams and startups on how to effectively manage people. It covers topics such as taking ownership, decision making, fostering trust and transparency, providing feedback, and avoiding drive-by management. It also suggests to look for best practices that naturally emerge when hiring good people and to expect more from managers that report to you. It emphasizes that mistakes are not the team’s fault but the manager’s and encourages them to give their team members more authority and ways to shine.
• URL: https://klinger.io/posts/managing-people-%F0%9F%A4%AF

Highlights §

• As a manager, everything is your fault (View Highlight)
• You either created the processes where this outcome happened • or you hired (or did not fire) the wrong people (View Highlight)
• You manage processes; you lead people (View Highlight)
• • your job is not to manage people • but to manage processes and lead people (View Highlight)
• 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 (View Highlight)
• Act how you would want them to act if the role would be reversed. (View Highlight)
• Processes are expectations made explicit (View Highlight)
• Processes are expectations made explicit (View Highlight)
• Processes are expectations made explicit (View Highlight)
• Have few but very explicit processes and expect them to be followed (View Highlight)
• 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. (View Highlight)
• Their manager has a handbrake they can use to hard-stop decisions. (View Highlight)
• It’s hard to get people to own a problem space fully • But this is the goal (View Highlight)
• Feedback them, help them • Trust them and let them make mistakes (within damage barriers) • Consider mistakes “them leveling up” (View Highlight)
• 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. (View Highlight)
• Stay in the loop, set expectations, voice opinions, but let them handle it. Use your handbrake if needed. (View Highlight)
• 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 (View Highlight)
• 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? (View Highlight)
• • 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 (View Highlight)
• 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 (View Highlight)
• • 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 (View Highlight)
• 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 (View Highlight)
• People should never be surprised that they are fired • Context changed; new requirements should have been communicated (View Highlight)
• 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 (View Highlight)
• • Once you decide to fire someone, do it. • Frequently people keep employees around in a zombie-like state (View Highlight)
• • 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 (View Highlight)
• 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 (View Highlight)
• • You will always be unhappy with processes in your company • You will have growing pains until you stagnate (View Highlight)
• 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 (View Highlight)
• Burnout comes from a felt loss of control and/or impact. (View Highlight)
• How can you give people control over their impact? • How can you define boundaries around chaos around them? (View Highlight)
• They are accountable for the outcomes • Responsible for all failures • But not responsible for the success • Success is the team’s achievement (View Highlight)