Startup risks, praise-to-criticism ratio, TPMs 💡
Startup risks, praise-to-criticism ratio, TPMs 💡
Monday Ideas • Edition #99
💬 Unblocked – Get the right answer, now
As per Stack Overflow’s developer survey, 60% developers spend between 30 and 120 minutes every workday searching for answers, often about their own workspace and code.
This is an area where AI can be truly disruptive, which is why I am happy to promote the fantastic work done by the guys at Unblocked 👇
Unblocked provides helpful and accurate answers developers need to get jobs done.
It tailors answers by complementing your source code with relevant discussions from GitHub, Slack, Notion, JIRA and more. So you spend less time digging for answers and more time writing great code.
Unblocked is free forever for teams who join during the beta. You can learn more below.
1) ⚖️ Market vs Execution Risk
Early-stage startups are incredibly fragile and face all kinds of risks. There are two main ones, in particular, that are useful to consider:
💸 Market risk — you build something that nobody wants
🔨 Execution risk — you are not able to build the solution.
There the more an idea, or a problem, is obvious, the less the market risk, and the more the execution risk that you face. If your idea is to create AGI (OpenAI), or to summon cabs in 2 minutes from your phone (Uber), the question is not whether people will want it, but rather if you are able to build it.
In fact we have to assume that all obvious — but unsolved — ideas are hard, otherwise somebody would have solved them already.
Conversely, there exist plenty of niche or weird ideas, for which execution is kind of trivial, but it is unclear whether you are looking at real problems, or simply nobody cares about it.
Market risk is defused by your expertise about the problem, while execution risk is defused by your build skills.
Last month I wrote a full essay about things you should consider before starting a startup 👇
2) 💛 Praise-to-criticism ratio
For those who receive it, feedback should act as a way to assess their overall behavior. This means identifying both things they get right, and things that they don’t.
In real life, though, this balance isn’t always met — many managers I know give an outsized amount of negative feedback with respect to the positive one. There is a tendency to believe feedback should be mostly corrective, which is false and causes two obvious problems:
📋 Self-evaluation — if most feedback people receive is criticism, they will think their performance is bad.
🙉 Bias against feedback — people will associate feedback with negative emotions, start avoiding it, and handicap their own growth.
The ideal praise-to-criticism ratio has been studied extensively. Research indicates that in the highest-performing teams this ratio is 5:1, that is, people receive more than five positive comments for every negative one.
If this seems outlandish to you, think about people on your team.
How much do they really do wrong, in percentage of their total actions? Chances are even your average performers do 80% of things right. You should acknowledge those as well.
I wrote a full essay about how to give feedback well 👇
3) 🗺️ What is a Technical Program Manager?
A typical Product team may consist of a Product Manager, Engineering Lead, Design Lead, and some engineers.
Often times that is enough, but for extremely complex programs where you have multiple teams working together, a Technical Program Manager steps in to orchestrate the collaboration across all these domains.
To put it in another way:
Product Managers focus on the what and why.
TPMs help Engineering Leads with the how and when.
A TPM is the nervous system ensuring product and engineering continues to stay aligned on the what, why, how and when.
At large companies, where it becomes necessary for Product Managers to focus on the strategic aspect of their role, a TPM is brought in like a tactician to help execute on the grand strategy. So, the TPM enters the stage to develop an end-to-end execution plan on how to ship a solution to a technical problem.
Such problems are of varying complexity, usually ambiguous in definition, and need to be delivered in collaboration with engineering, product, design, and marketing within a certain time & budget.
But how do TPMs do that? I wrote a full article last year, with the help of my friend
, to demistify the TPM role 👇And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the paid plan — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
The praise-to-criticism one was such an excellent reminder. Sometimes as managers we try to focus too much on negative feedback because we believe it's harder to do (so we should do it!) and is probably the type of feedback people don't receive from their peers. However, positive reinforcement is also a very powerful tool. It helps people focus on their strengths which is a proven way to be improve outcomes :)