BUT BUT BUT, do not blame 'a person' for it. That's a cop out. Fix it structurally, in the process, so it isn't repeated.
Ok weekend thread ЁЯз╡ time ЁЯСЙ
Since college days, I have launched 4 products (2 fail + 2 sold), started up thrice (1 failed, 1 sold, 1 running), lead a team at a $1B+ startup and worked as lead engineer at a Fortune 100 giant
Here are some learnings (tech/management/product)ЁЯСЗ
BUT BUT BUT, do not blame 'a person' for it. That's a cop out. Fix it structurally, in the process, so it isn't repeated.
From cofounder problems to team bandwidth, to bad code. More money can stop a leaving cofounder from leaving, let you hire more people, or scale your server 10x.
It is a bandaid. Fix it properly eventually though.
You can articulate well, you will do better in life. If you can't you'll be treated like trash.
If someone is given a task beyond their capacity, whose fault ?
If someone is overpaid while hiring, whose fault ?
If someone's performance isn't tracked, or feedback given, whose fault ?
No, seriously! Not kidding.
Robot mode = you want to be paid X dollars for Y hours and fulfill all the requirements
Involved mode = you want to be part of ideation stage, put your inputs in, discuss differences, and see impact of your work
1/4
Same person can be robot at one place, involved at another, or robot today, involved tomorrow.
But doing a work meant for robot in involved mode (or vice/versa) will be disaster.
2/4
Robot mode people enjoy peace of mind and laugh at involved mode people because of their work-life-balance, and how.
3/4
Both have their pros and cons, and own satisfaction and joy. Nothing to be made fun of. Different modes work out well for different situations and stage in life. Respect both.
4/4
It is very simple. Hire for merit for the skills you can judge, hire for sincerity in other verticals.
When you can't judge, you can trust sincerity.
Want a raise? First deliver a fantastic product launch, then immediately as for the raise.
Want to assign someone a big project? Give them a big bonus first, then assign it to them.
Hanlon's Razor = if something is wrong, it is by mistake, not someone deliberately sabotaging it
Wayne Dyer = between being right and being kind, be kind and you'll always be right
Win at work with these 3 principles. Always
It is easy to get into functional vs OOP, architecture discussions, coding practices. BUT WAIT.
Zoom out for a second. What does the product need? What does the user need? How does the software need to work? Only that matters
- easy to access
- easy to learn
- does what it says
- fast enough to not frustrate me
- no surprise bugs
- reliably recover from failures
Build that!
2. Speed, recover from failures, Just WorksтДв - these keep people here, make them lazy to leave, hook them
If people not coming, focus on 1, if not staying, focus on 2.
If you liked the thread, you'll love the podcast.
