Skip to content

Commit 8062b30

Browse files
hspakhspak
committed
feat: new post
1 parent 6d6e992 commit 8062b30

File tree

4 files changed

+210
-1
lines changed

4 files changed

+210
-1
lines changed

‎docs/feed.xml

+56-1
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,66 @@
22
<feed xmlns="http://www.w3.org/2005/Atom">
33
<title>Hong's Blog</title>
44
<link href="https://hspak.dev/"/>
5-
<updated>November 14, 2022</updated>
5+
<updated>December 28, 2022</updated>
66
<author>
77
<name>Hong Shick Pak</name>
88
</author>
99
<id>https://hspak.dev/atom.xml</id><entry>
10+
<title>What if I'm Wrong</title>
11+
<published>December 28, 2022</published>
12+
<updated>December 28, 2022</updated>
13+
<link href="https://hspak.dev/post/what-if-im-wrong/" type="text/html"/>
14+
<id>https://hspak.dev/post/what-if-im-wrong/</id>
15+
<content type="html">
16+
&lt;p&gt;I've spent almost all my career working at startups (so far) and we are always
17+
venturing into the unknown. Everything is an evergreen deployment. Company
18+
processes are being built from bottom up. The product is constantly changing
19+
trajectory. We're doing whatever we can to hit to arbrarily set milestones for
20+
the company. Everything is effectively being bulit under a handful of
21+
&lt;a href=&quot;/post/strong-opinions-loosely-held/&quot;&gt;opinions&lt;/a&gt; from a select set of people.&lt;/p&gt;
22+
&lt;p&gt;And this trickles down as the company grows. Engineering leaders make their best
23+
judgement for technical direction. Product leaders make their best judgement for
24+
feature development. Ops leaders makes their best judgement for company wide
25+
operations. But what if they're wrong? No human is correct 100% percent of the
26+
time. What can leaders do to help mitigate the cost of being wrong?&lt;/p&gt;
27+
&lt;p&gt;What if we remove the leadership context here and just focus on how we might
28+
navigate uncharted territory in general. Let's start from the most naive
29+
strategy. We try a thing, see how it did, recalibrate and try again. Maybe we
30+
can give ourselves a better starting position because of the domain knowledge
31+
we've collected over the years. And sometimes when we recalibrate, we might be
32+
backtracking -- and that should be &lt;em&gt;an accepted strategy of charting the
33+
unknown&lt;/em&gt;. Imaging trying to navigate a maze, but we're not allowed to backtrack.
34+
That's effectively an all-or-nothing strategy. It's all-in on the first,
35+
initiall decision -- and if it's wrong, we fail.&lt;/p&gt;
36+
&lt;p&gt;Now if we step back into the context of leadership, any sign of backtracking is
37+
seen as a wrongdoing. I don't believe that any amount of signal is going to give
38+
us a perfect insight -- we work with probabilities instead (as we do with just
39+
about everything in life). What is difficult is that a leader makes decisions on
40+
behave of many people, and its become absolute blasphemy to be wrong, ever. Part
41+
of the issue is that any decision made by a leader is levered by other folks. If
42+
a founder's founding thesis is wrong, backtracking means putting everyone at the
43+
company out of a job. But on the flipside, it should never be a massive
44+
surprise. Company progress should ba constantly tracked. Large initatives should
45+
be broken down. To go from &amp;quot;everything is fine&amp;quot; to &amp;quot;nevermind&amp;quot; may point to a
46+
never-backtracking mindset.&lt;/p&gt;
47+
&lt;p&gt;There are also just some things in life that aren't reversible or shouldn't be
48+
and that's okay too. No analogy is perfect. Look at Zuck going all-in on VR.
49+
It's a thesis that may take a long time to pan out. It's a large gamble and it's
50+
hard to imagine as a bystander of how exactly Zuck should've broken down the VR
51+
execution. But one of the advantages of software is that its incredibly easy to
52+
build and tear down. Companies should lean into that trait of software and
53+
harness it to allow the company to also be enabled by fast feedback cycles.&lt;/p&gt;
54+
&lt;p&gt;Effectively, I believe that the most effective method of executing (particularly
55+
in a startup sense) is to optimze for quick iterations (I'm sure this will look
56+
very different based on context), and allow backtracking (i.e canceling
57+
projects*, reverting changes, going back to status quo). Everything I listed for
58+
backtracking hurts, but it's better to go in reverse if we're headed for a
59+
cliff.&lt;/p&gt;
60+
&lt;p&gt;* &lt;em&gt;Google might be an exception here because they don't seem to learn at all
61+
from all their canceled projects. There is never a silver bullet!&lt;/em&gt;&lt;/p&gt;
62+
</content>
63+
</entry>
64+
<entry>
1065
<title>Working Hard and Working Smart</title>
1166
<published>November 14, 2022</published>
1267
<updated>November 14, 2022</updated>

‎docs/index.html

+9
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,15 @@
2727
<div class="indexBlock"><a href="https://hspak.com/">By Hong</a></div>
2828
</div>
2929
</div>
30+
<div class="block">
31+
<div class="entry">
32+
<a href="/post/what-if-im-wrong/">
33+
<h2>What if I'm Wrong</h2>
34+
<div class="date">December 28, 2022</div>
35+
<div class="preview">I wonder how many people in positions of power think this and what do they do to mitigate nagtive effects?</div>
36+
</a>
37+
</div>
38+
</div>
3039
<div class="block">
3140
<div class="entry">
3241
<a href="/post/work-hard-work-smart/">

‎docs/post/what-if-im-wrong/index.html

+86
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
<!doctype html>
2+
<html>
3+
<head>
4+
<title>What if I'm Wrong</title>
5+
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6+
<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
7+
<meta name="referrer" content="strict-origin">
8+
<meta name="author" content="Hong Shick Pak">
9+
<meta name="viewport" content="width=device-width, initial-scale=1">
10+
<meta name="keywords" content="Michael Pak, Hong Shick Pak, Hong, Shick, Pak, Michael, Blog, hspak">
11+
<meta name="description" content="Blog of Hong Shick Pak">
12+
<meta property="og:url" content="https://hspak.dev">
13+
<meta property="og:type" content="website">
14+
<meta property="og:site_name" content="Hspak">
15+
<meta property="og:title" content="Hspak">
16+
<meta property="og:description" content="Blog of Hong Shick Pak">
17+
<meta property="twitter:creator" content="@hspasta">
18+
<link rel="canonical" href="https://hspak.dev/">
19+
<link rel="stylesheet" href="/index.css">
20+
</head>
21+
<body>
22+
<div class="outer">
23+
<div class="container">
24+
<div class="block">
25+
<a href="/"><h1>Blog</h1></a>
26+
</div>
27+
<div class="block">
28+
<h2>What if I'm Wrong</h2>
29+
<div class="date">December 28, 2022 </div>
30+
<div class="body">
31+
<p>I've spent almost all my career working at startups (so far) and we are always
32+
venturing into the unknown. Everything is an evergreen deployment. Company
33+
processes are being built from bottom up. The product is constantly changing
34+
trajectory. We're doing whatever we can to hit to arbrarily set milestones for
35+
the company. Everything is effectively being bulit under a handful of
36+
<a href="/post/strong-opinions-loosely-held/">opinions</a> from a select set of people.</p>
37+
<p>And this trickles down as the company grows. Engineering leaders make their best
38+
judgement for technical direction. Product leaders make their best judgement for
39+
feature development. Ops leaders makes their best judgement for company wide
40+
operations. But what if they're wrong? No human is correct 100% percent of the
41+
time. What can leaders do to help mitigate the cost of being wrong?</p>
42+
<p>What if we remove the leadership context here and just focus on how we might
43+
navigate uncharted territory in general. Let's start from the most naive
44+
strategy. We try a thing, see how it did, recalibrate and try again. Maybe we
45+
can give ourselves a better starting position because of the domain knowledge
46+
we've collected over the years. And sometimes when we recalibrate, we might be
47+
backtracking -- and that should be <em>an accepted strategy of charting the
48+
unknown</em>. Imaging trying to navigate a maze, but we're not allowed to backtrack.
49+
That's effectively an all-or-nothing strategy. It's all-in on the first,
50+
initiall decision -- and if it's wrong, we fail.</p>
51+
<p>Now if we step back into the context of leadership, any sign of backtracking is
52+
seen as a wrongdoing. I don't believe that any amount of signal is going to give
53+
us a perfect insight -- we work with probabilities instead (as we do with just
54+
about everything in life). What is difficult is that a leader makes decisions on
55+
behave of many people, and its become absolute blasphemy to be wrong, ever. Part
56+
of the issue is that any decision made by a leader is levered by other folks. If
57+
a founder's founding thesis is wrong, backtracking means putting everyone at the
58+
company out of a job. But on the flipside, it should never be a massive
59+
surprise. Company progress should ba constantly tracked. Large initatives should
60+
be broken down. To go from &quot;everything is fine&quot; to &quot;nevermind&quot; may point to a
61+
never-backtracking mindset.</p>
62+
<p>There are also just some things in life that aren't reversible or shouldn't be
63+
and that's okay too. No analogy is perfect. Look at Zuck going all-in on VR.
64+
It's a thesis that may take a long time to pan out. It's a large gamble and it's
65+
hard to imagine as a bystander of how exactly Zuck should've broken down the VR
66+
execution. But one of the advantages of software is that its incredibly easy to
67+
build and tear down. Companies should lean into that trait of software and
68+
harness it to allow the company to also be enabled by fast feedback cycles.</p>
69+
<p>Effectively, I believe that the most effective method of executing (particularly
70+
in a startup sense) is to optimze for quick iterations (I'm sure this will look
71+
very different based on context), and allow backtracking (i.e canceling
72+
projects*, reverting changes, going back to status quo). Everything I listed for
73+
backtracking hurts, but it's better to go in reverse if we're headed for a
74+
cliff.</p>
75+
<p>* <em>Google might be an exception here because they don't seem to learn at all
76+
from all their canceled projects. There is never a silver bullet!</em></p>
77+
</div>
78+
</div> <div class="block">
79+
<div class="footer">
80+
<a href="#top">To Top</a> · <a href="https://hspak.com">By Hong</a>
81+
</div>
82+
</div>
83+
</div>
84+
</div>
85+
</body>
86+
</html>

‎posts/0006-what-if-im-wrong.md

+59
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
Name: what-if-im-wrong
2+
Title: What if I'm Wrong
3+
Description: I wonder how many people in positions of power think this and what do they do to mitigate nagtive effects?
4+
Draft: false
5+
Publish Date: December 28, 2022
6+
---
7+
8+
I've spent almost all my career working at startups (so far) and we are always
9+
venturing into the unknown. Everything is an evergreen deployment. Company
10+
processes are being built from bottom up. The product is constantly changing
11+
trajectory. We're doing whatever we can to hit to arbrarily set milestones for
12+
the company. Everything is effectively being bulit under a handful of
13+
[opinions](/post/strong-opinions-loosely-held/) from a select set of people.
14+
15+
And this trickles down as the company grows. Engineering leaders make their best
16+
judgement for technical direction. Product leaders make their best judgement for
17+
feature development. Ops leaders makes their best judgement for company wide
18+
operations. But what if they're wrong? No human is correct 100% percent of the
19+
time. What can leaders do to help mitigate the cost of being wrong?
20+
21+
What if we remove the leadership context here and just focus on how we might
22+
navigate uncharted territory in general. Let's start from the most naive
23+
strategy. We try a thing, see how it did, recalibrate and try again. Maybe we
24+
can give ourselves a better starting position because of the domain knowledge
25+
we've collected over the years. And sometimes when we recalibrate, we might be
26+
backtracking -- and that should be _an accepted strategy of charting the
27+
unknown_. Imaging trying to navigate a maze, but we're not allowed to backtrack.
28+
That's effectively an all-or-nothing strategy. It's all-in on the first,
29+
initiall decision -- and if it's wrong, we fail.
30+
31+
Now if we step back into the context of leadership, any sign of backtracking is
32+
seen as a wrongdoing. I don't believe that any amount of signal is going to give
33+
us a perfect insight -- we work with probabilities instead (as we do with just
34+
about everything in life). What is difficult is that a leader makes decisions on
35+
behave of many people, and its become absolute blasphemy to be wrong, ever. Part
36+
of the issue is that any decision made by a leader is levered by other folks. If
37+
a founder's founding thesis is wrong, backtracking means putting everyone at the
38+
company out of a job. But on the flipside, it should never be a massive
39+
surprise. Company progress should ba constantly tracked. Large initatives should
40+
be broken down. To go from "everything is fine" to "nevermind" may point to a
41+
never-backtracking mindset.
42+
43+
There are also just some things in life that aren't reversible or shouldn't be
44+
and that's okay too. No analogy is perfect. Look at Zuck going all-in on VR.
45+
It's a thesis that may take a long time to pan out. It's a large gamble and it's
46+
hard to imagine as a bystander of how exactly Zuck should've broken down the VR
47+
execution. But one of the advantages of software is that its incredibly easy to
48+
build and tear down. Companies should lean into that trait of software and
49+
harness it to allow the company to also be enabled by fast feedback cycles.
50+
51+
Effectively, I believe that the most effective method of executing (particularly
52+
in a startup sense) is to optimze for quick iterations (I'm sure this will look
53+
very different based on context), and allow backtracking (i.e canceling
54+
projects*, reverting changes, going back to status quo). Everything I listed for
55+
backtracking hurts, but it's better to go in reverse if we're headed for a
56+
cliff.
57+
58+
\* _Google might be an exception here because they don't seem to learn at all
59+
from all their canceled projects. There is never a silver bullet!_

0 commit comments

Comments
 (0)