(Primary motivation: Rezende & Mohamed, 2015. :contentReference[oaicite:0]{index=0})

1. What KL Divergence Actually Is

KL divergence measures how far one probability distribution is from another:

A few properties I need to keep front-of-mind:

• Not symmetric: $D_{KL}(P|Q) \neq D_{KL}(Q|P)$.
• Not a “distance” metric (no triangle inequality).
• It is an expectation under $P$, meaning the direction strongly affects behavior.

The direction is not cosmetic: it changes optimization behavior (mode-covering vs mode-seeking).

2. Where My Confusion Came From: KL vs Cross-Entropy

I previously thought:

“KL term is basically cross-entropy.”

This is only conditionally true.

The key identity is:

where

• cross-entropy: $H(P,Q) = -\mathbb{E}_{x\sim P}[\log Q(x)]$
• entropy: $H(P) = -\mathbb{E}_{x\sim P}[\log P(x)]$

So if $P$ is fixed, then $H(P)$ is constant, and minimizing $D_{KL}(P|Q)$ is equivalent to minimizing cross-entropy $H(P,Q)$.

That is why in standard supervised classification with fixed labels, it feels like “cross-entropy = KL”.

The correction to my belief

The “KL term” is not intrinsically cross-entropy. Cross-entropy is what KL reduces to when the target distribution $P$ is fixed and we only optimize $Q$.

That “fixed target” assumption is exactly what breaks in many important ML objectives.

3. The VAE / Variational Inference Setting: KL is Not a “Label Loss”

Rezende & Mohamed frame variational inference as maximizing a lower bound on $\log p(x)$ (the evidence), because the true marginal likelihood is typically intractable. They write the ELBO as:

This is the core equation in the paper. :contentReference[oaicite:1]{index=1}

Here the KL is:

This is the conceptual point I had wrong: this KL is not comparing “predictions vs labels.”
It is comparing:

• $q_\phi(z \mid x)$: an approximate posterior produced by the inference network (encoder)
• $p(z)$: the prior

So the KL term is a regularizer / information constraint: it prevents the inference network from encoding arbitrary information in $z$ and pushes the posterior toward the prior.

Why my cross-entropy intuition fails here

In classification, $P$ is typically fixed (true labels).
In the ELBO, $q_\phi(z \mid x)$ is learned and changes during training.

So even though the identity $D_{KL} = H(P,Q) - H(P)$ always holds mathematically, the “$H(P)$ is constant” trick is not something I can rely on in intuition. The moving part $q_\phi$ is exactly what I’m optimizing.

4. Another Important Subtlety: KL Direction Matters

The ELBO uses:

This is the “reverse” direction relative to what I mentally associate with supervised learning (which usually resembles $D_{KL}(P|Q)$ with fixed $P$).

This direction has practical consequences:

• $D_{KL}(P|Q)$ (“forward KL”) strongly penalizes putting low probability mass where $P$ has mass → tends to be mode-covering.
• $D_{KL}(Q|P)$ (“reverse KL”) strongly penalizes putting mass where $P$ has low mass → tends to be mode-seeking.

In variational inference, this asymmetry is part of why approximate posteriors can miss modes (the “mode-seeking” behavior is a known limitation). Normalizing flows in Rezende & Mohamed are partly motivated by making $q_\phi(z \mid x)$ flexible enough to reduce that approximation gap. :contentReference[oaicite:2]{index=2}

5. Why Normalizing Flows Make the KL Term Even More Central

Rezende & Mohamed propose constructing the approximate posterior by transforming a simple base distribution through a sequence of invertible mappings (“normalizing flow”):

• start: $z_0 \sim q_0(z_0 \mid x)$ (often Gaussian)
• transform: $z_k = f_k(z_{k-1})$ for invertible $f_k$
• end: $z_K$ has a more complex distribution $q_K(z_K \mid x)$

Because the transform is invertible, the density changes via change-of-variables:

This flexibility makes the approximate posterior richer, which tightens the variational bound. This is one of the main contributions of the paper. :contentReference[oaicite:3]{index=3}

My updated intuition

The KL term is not an “annoying extra penalty.” It is the explicit mismatch measure between what my inference model can represent ($q_\phi$) and what the generative model assumes ($p$).
Normalizing flows are an upgrade to $q_\phi$ so that this mismatch can be reduced without sacrificing scalability.

6. When the “Target Distribution is Not Fixed” Happens in Practice

This directly answers my earlier confusion: when is $P$ not fixed?

In variational inference and flows, the “target” distribution in a KL can involve learnable distributions such as \(q_\phi(z \mid x)\) or teacher/student distributions that change over time. Concrete examples:

• Variational inference / VAE: \(q_\phi(z \mid x)\) is learned.
• Normalizing flows in VI: the whole posterior family is learned through transformations.
• Online distillation / EMA teachers: teacher distributions evolve during training.
• RL: policies and visitation distributions shift.

This is the world where “KL term = cross-entropy” stops being a reliable mental shortcut.

7. The Corrected Takeaway I Want to Keep

My previous belief:

• “KL is basically cross-entropy.”

What I now believe:

• KL is a distribution mismatch measure.
• Cross-entropy is one special case view of KL when the target distribution is fixed.
• In variational inference (including normalizing flows), the KL term is the core regularizer that shapes the posterior approximation, and its direction matters.

If I keep that in mind, the ELBO decomposition in Rezende & Mohamed stops looking like “reconstruction loss + random KL penalty” and starts looking like what it really is:

a likelihood-fitting term plus an explicit constraint on how much the posterior is allowed to deviate from the prior, with flows making that posterior expressive enough to be useful. :contentReference[oaicite:4]{index=4}

This post is my corrected summary, written as a set of “mis-beliefs → corrections,” grounded in the variational inference framing emphasized in the paper.

1) My first mis-belief: “Decoder is the posterior”

What I believed

The decoder is the posterior.

What’s actually true

In VAE terminology:

• The posterior is $p_\theta(z \mid x)$.
• But it is usually intractable in deep generative models.
• So VAEs introduce a tractable approximation $q_\phi(z \mid x)$.

That means:

• Encoder $\approx$ approximate posterior (inference network):
  $q_\phi(z \mid x) \approx p_\theta(z \mid x)$

• Decoder $\approx$ likelihood / generative model:
  $p_\theta(x \mid z)$

So the decoder is not “the posterior.” The decoder is one of the ingredients used to define the posterior (via Bayes’ rule), but the direction is the opposite:

• Decoder: $z \rightarrow x$ (generate)
• Encoder: $x \rightarrow z$ (infer)

This mapping is consistent with the paper’s emphasis: variational inference replaces posterior inference with optimization over a variational family, where $q_\phi(z\mid x)$ is the variational distribution and is learned to match $p_\theta(z\mid x)$.

2) My second mis-belief: “Encoder compresses, decoder expands”

What I believed

Encoder compresses a pipeline; decoder expands a pipeline. Therefore, VAE is a fancy compress–decompress trick.

What’s actually true (and why this confusion happens)

This “compress / expand” idea comes from image VAEs, where:

• $z$ is low-dimensional,
• $x$ is a high-dimensional image,
• and the decoder visually looks like an upsampling network.

But for forecasting (e.g., predicting yield as a scalar), “expand” is not a meaningful concept:

• The target $y$ is often 1-dimensional.
• The decoder does not necessarily “expand”; it often maps $(x, z)$ to a scalar distribution.

So the right mental model is:

The encoder and decoder are not defined by dimensionality changes.
They are defined by probabilistic roles in variational inference.

• Encoder: a recognition model for approximate posterior inference.
• Decoder: a generative model defining the likelihood.

3) What “VAE inference” really means (and why “generative inference” confused me)

My confusion

The phrase “generative inference” didn’t make sense to me, because inference should mean “estimate hidden state,” not “generate outputs.”

The correction

In probabilistic modeling, “inference” usually means:
compute or approximate the posterior over latent variables.

In a VAE, the true posterior is:

But VAEs do not compute this directly. Instead, they learn:

So:

• VAE inference = run the encoder to obtain $q_\phi(z \mid x)$ (or its parameters).
• Generation / sampling = sample $z \sim p(z)$ (or a conditional prior) and decode $x \sim p_\theta(x\mid z)$.

These are different operations. Inference is “backward reasoning.” Generation is “forward simulation.”

The paper’s message is basically:

we make inference scalable by turning it into an optimization problem, and then amortizing it with a neural network.

4) Strawberry yield forecasting: how I map “state vs observation” properly

Now I apply this to a practical problem:

• I observe temperature and fruit count.
• I want to forecast strawberry yield.

Observed variables (measurements)

Let:

• $T_{1:t}$ = temperature history up to time $t$
• $C_{1:t}$ = fruit_count history up to time $t$
• $Y_t$ = yield (today, or at harvest)

I’ll group the observed covariates as $x$:

Latent state (unobserved but important)

A forecasting model often benefits from a hidden state representing things I don’t measure well:

• plant vigor
• stress (heat / water / disease)
• phenological stage
• cultivar or management effects
• microclimate differences

Call that latent crop condition $Z_t$.

So, in Bayesian terms, what I actually want is:

i.e., “given observed data, what crop states are plausible?”

That is exactly a posterior.

5) What the decoder becomes in this forecasting case

In a forecasting-oriented VAE (more precisely, a conditional VAE), the decoder is a probabilistic forecast model:

This is the “forward” story:

• if the crop state is $z$
• and covariates are $x$
• then yield $Y$ follows some distribution.

For example, the decoder might output $(\mu_\theta(x,z), \sigma_\theta(x,z))$ for a Gaussian yield distribution.

So yes: the decoder is the forecasting component.
But it is not “expanding” by default—it is defining a likelihood.

6) Then what is the encoder in this forecasting case?

During training, I have both covariates and yield, so I can infer what latent crop state best explains the outcome:

Interpretation:

“Given sensors and realized yield, what hidden crop condition must have been present?”

That’s posterior inference (approximate), and it is the core meaning of “VAE inference.”

This is aligned with Rezende & Mohamed’s viewpoint:
the inference model $q_\phi$ is trained to approximate the true posterior while keeping optimization tractable.

7) The forecasting-time detail I initially missed: I need a conditional prior

A key practical point:

At prediction time, I do not know $y$, so I cannot directly use $q_\phi(z \mid x, y)$.

To forecast, I need a distribution over latent states given only covariates:

sometimes called a conditional prior.

Then forecasting is:

1) Sample latent crop states: $z^{(k)} \sim p_\psi(z \mid x)$
2) Decode yields: $y^{(k)} \sim p_\theta(y \mid x, z^{(k)})$
3) Aggregate samples to get a predictive distribution.

This is how the model produces:

• a mean forecast
• prediction intervals
• multi-modal outcomes (if relevant)

8) Comparing this to LightGBM (the baseline that keeps me honest)

LightGBM is typically:

a direct mapping from engineered covariates to yield.

A VAE-style forecast is instead:

This difference matters when:

• there are hidden factors not captured by $x$,
• the same $x$ maps to multiple plausible yields,
• or uncertainty calibration is important (operations planning, labor scheduling, contracts).

If none of those are true, LGBM is usually the better engineering choice.

9) My corrected takeaways (the short list)

What I used to think

• Encoder compresses
• Decoder expands
• Decoder is the posterior
• “Generative inference” means predicting

What I now think

• Encoder is the approximate posterior: $q_\phi(z \mid \cdot)$
• Decoder is the likelihood / generative model: $p_\theta(\cdot \mid z)$
• In forecasting, decoder is best seen as a probabilistic forecaster, not an “expander”
• “VAE inference” means latent state inference via the encoder
• For forecasting, I often need a conditional prior $p_\psi(z \mid x)$ to sample latent states when $y$ is unknown

10) One sentence that finally fixed my mental model

A VAE-style forecaster for strawberry yield is:

a model that learns a latent crop-condition variable $z$ and uses variational inference (via an encoder) to approximate the posterior over $z$, while a decoder defines a probabilistic forecast $p_\theta(y \mid x, z)$ that can be sampled for uncertainty-aware predictions.

This framing made the Rezende & Mohamed (2015) motivation click:
variational inference is the mathematical reason VAEs exist, and “encoder/decoder” are just neural parameterizations of the variational posterior and the likelihood.

• Routers: Function choice and parameter extraction
  • Did it call the right skills based on the scenario?
• Skills: Can use standard LLM evaluations
  • Embed input query
  • Vector DB lookup
  • LLM call with retrieved context
• Path: The most challenging to evaluate at scale

How to evaluate these components

• LLM as a Judge: Using other LLMs to evaluate
  • It will never e a 100% correct
  • Tuning your LLM judge prompt can help close this gap
  • Always use discrete classification labels (incorrect vs correct, not 1-100% accuracy)
  • Foolow from 13:45 (https://www.youtube.com/watch?v=LpbGpJhndQ0)
• Code-based Evals: Using traditional code checks
• Human Feedback: Using end-user or human labeler feedback

How do you decide what to focus on in an ML project? You need to find the impact bottleneck: the part of the pipeline that would provide the most value if improved. When working with companies, I often find that they’re not working on the right problem—or they’re not even at the growth stage where that problem matters. There are often issues around the model, but the best way to find them is to temporarily replace the model with something simple and debug the entire pipeline. Very often the real issue isn’t model accuracy at all. Frequently, the product is dead even if the model works perfectly.

Once you have the whole pipeline, how do you identify the impact bottleneck? Imagine that the bottleneck is fully solved and ask yourself: Was it worth the effort it would take to fix it? It’s also incredibly valuable to manually inspect your model’s inputs and outputs. Scroll through a bunch of examples and see if anything looks strange. My department head at IBM had a mantra: do something manually for an hour before doing any real engineering work. Curious whether your project is achievable with ML? Or whether ML is even needed in the first place? Contact me—I’m happy to help you find the right direction.

It predicts strawberry and tomato yields based on growing conditions like temperature, light, CO₂, and humidity.
The model performs well in forecasting, but I realized it only learns correlations, not causal relationships.
So even if it predicts yield accurately, it can not explain what will actually happen if the farm operator changes temperature or light in a real greenhouse for the period of time.

To go beyond prediction, I started building a simulation system that recommends growing conditions due to customer demands. As the farm can truly reduce the energy cost per kg of production by knowing the impact of the grow condition. For that, I needed causal inference — a way to estimate how much yield changes when I intervene on variables (like raising temperature by +2°C). Imagine how much heating 2°C more for 10 ha facility will cost.

1. Setting up causal modeling

I began by drawing a simple causal graph (DAG) that represents how different factors affect yield:

• Temperature and light directly influence yield.
• CO₂, humidity (VPD), irrigation, temperature, and cultivar affect yield (so they’re confounders).
• Some variables, like energy usage, are side effects and should not be adjusted for.

This step helped me define what needs to be controlled to get valid causal effects.

2. Integrating with DoWhy

I used DoWhy, a causal inference library, to wrap around my LightGBM model.
DoWhy helps connect the model to causal concepts:

1. Model — define the DAG fully based on plant science. This is where I had to be an plant scientist.
2. Identify — find which variables to adjust for (backdoor criterion).
3. Estimate — use LightGBM as the outcome and treatment model.
4. Refute — test how stable and believable the effect is.

My LightGBM still does the heavy lifting for nonlinear relationships, while DoWhy handles the logic of “what if” changes.

3. Checking trustworthiness

A big question was: can I trust these causal effects?

I tested this with:

• Placebo refuters — replace temperature with random noise.
  → The estimated effect disappeared (good sign).
• Subset refuters — re-run the model on random data splits.
  → Results stayed consistent.
• Sensitivity tests — check how strong a hidden confounder must be to change conclusions.
  → Effects were robust unless confounding was extreme.

These tests gave me confidence that the model captures real causal influence, not just correlation noise.

4. Results and next steps

Now, the system can simulate different environmental settings and show expected yield changes under those interventions.
For example, “if I increase PAR by 15% by turning on LED while keeping CO₂ constant, yield increases by ~6%.”
This gives a foundation for growing condition recommendations.

Next step would be:

• Combine multiple cultivars to learn condition-specific responses.
• Validate the system with controlled greenhouse trials.

5. Reflection

This process taught me that causal inference is not just a statistical trick — it’s a framework for thinking.
The key was translating plant science knowledge into a graph of cause and effect, then testing those assumptions systematically.
Thanks to this work, farmers can not only predict yield, but also simulate what happens if we change the environment — a step closer to autonomous, data-driven cultivation.

📦 Pods (Inspect, Logs, Exec, Manage)

🔍 List & Inspect Pods

kubectl get pods
kubectl get pods -n <namespace>
kubectl get pods --all-namespaces
kubectl describe pod <pod-name>

Pods on a specific node

kubectl get pods -A -o wide | grep <node>

Pod resource requests

kubectl get pods -n <ns> -o json | jq -r '.items[] |
  "\(.metadata.name)\tCPU:\(.spec.containers[0].resources.requests.cpu)\tMEM:\(.spec.containers[0].resources.requests.memory)"'

Pod tolerations

kubectl get pods -n <ns> -o json | jq -r '.items[] |
  "\(.metadata.name)\t\(.spec.tolerations | map(.key) | join(","))"'

Pod events

kubectl describe pod <pod> -n <ns> | grep -A 10 "Events:"

Pod resource usage (metrics-server)

kubectl top pods -n <ns>

🪵 Logs

kubectl logs <pod>
kubectl logs <pod> -c <container>
kubectl logs -f <pod>
kubectl logs -l app=<label>

one-liner sample to load with a key-word

kubectl logs -n name_space "$(kubectl get pods -n name_space --no-headers | awk '/prod/ {print $1; exit}')"

💻 Exec / Shell Access

kubectl exec -it <pod> -- /bin/bash
kubectl exec -it <pod> -- /bin/sh
kubectl exec -it <pod> -c <container> -- /bin/bash

🧹 Pod Management

kubectl delete pod <pod> -n <ns>
kubectl delete pod <pod> -n <ns> --force --grace-period=0
kubectl delete pod --all -n <ns>
kubectl delete pod -n <ns> -l key=value

🌐 Services

kubectl get services
kubectl get services -n <namespace>
kubectl get services --all-namespaces

🧠 Nodes (Inspect, Usage, Manage)

🔍 Node Info

kubectl get nodes
kubectl get nodes -o wide
kubectl describe node <node>

Node labels, taints, instance type

kubectl get node <node> -o json | jq '.metadata.labels'
kubectl describe node <node> | grep Taints
kubectl get node <node> -o json | jq -r '.metadata.labels."node.kubernetes.io/instance-type"'

📊 Node Resource Usage

kubectl describe node <node> | grep -A 5 "Allocated resources"
kubectl top nodes

🛠 Node Management (Cordon / Drain / Delete)

🔹 Cordon — stop scheduling new pods

kubectl cordon <node>

🔹 Drain — evict workloads safely

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --force

🔹 Delete — remove node from Kubernetes

kubectl delete node <node> --force --grace-period=0

📘 Quick Comparison

🧱 Storage (PVC)

List PVCs

kubectl get pvc -A
kubectl get pvc -n <namespace>

Describe a PVC

kubectl describe pvc <pvc-name> -n <namespace>

Check volume affinity issues

kubectl describe pod <pod> -n <ns> | grep -i volume

⛑ Pod Disruption Budgets (PDB)

kubectl get pdb -A
kubectl get pdb -n <namespace>
kubectl describe pdb <pdb> -n <namespace>

🔧 Useful Commands

Count pods on a node

kubectl get pods -A -o wide | grep <node> | wc -l

Count pods by namespace

kubectl get pods -A --no-headers | awk '{print $1}' | sort | uniq -c

List instance types in the cluster

kubectl get nodes -o json | jq -r \
'.items[].metadata.labels."node.kubernetes.io/instance-type"' | sort | uniq

Node → workload mapping

kubectl get nodes -o json | jq -r '.items[] |
  "\(.metadata.name)\t\(.metadata.labels.workload // "none")\t\(.metadata.labels."node.kubernetes.io/instance-type")"'

At the same time, friends who met me after my age of 25, draw my image as far-from talkative. I used to listen more than talk, I did not lead the party.

I am a same person, I did not suffer from any trauma. What made me to behave so different? My answer used to be “I am naturally introverted, but I tried to be extrovert in the beginning of my college life, as I wanted to be.” So, as nike says, “Fake it till make it.”

After reading the book-“Psycho Cybenetics by Maxwell Maltz”, I now have a clear view why it happened. I believe, I am open-minded for taking uncertainties, challenges in my life because I have quitted multiple journeys. Studying again after Droping the nice job in Korea. Founding a startup after rejecting the offer from well-known offers. Exiting at the moment of my company’s growing to pursue the bigger vision.

In my first startup, I was obsessed with hiring the right people, believing that once you hire the right ones, they will succeed.
In retrospect, hiring the right people is necessary but not sufficient for success.

After stepping away from the hectic founder life, I had the chance to nurture my entrepreneurial spirit through books.
In this writing, I’m going to summarize my takeaways from the book Punished by Rewards by Alfie Kohn, to remind my future self of its insights.

The book’s focus is on how to motivate employees (and similarly, students for educators or children for parents).
It’s proven that both rewards and punishments are harmful to genuine motivation — supported by hundreds of research references.
Rewards include things like bonuses tied to KPIs. If bonuses are inevitable, they should not be announced beforehand, but rather given unexpectedly — so employees don’t work just for the money.

While reading the 200+ pages (in a few days), I kept asking myself: if rewards are bad, what can a leader use instead?
The author argues that intrinsic motivation is the true driver of lasting success.
The main reason is simple: no company can provide infinite (more and more) financial rewards.
Moreover, when the bonus amount is small, performance actually drops.
When the bonus is large, it motivates temporarily — but once it’s removed, performance falls sharply.

The author calls this the “If-Then” trap — “If you do this, then you’ll get that.”
This is not just about money; it’s about any conditional reward, including praise, perks, or privileges.
The real problem is not the reward itself, but the message behind it: that people must be controlled.
When rewards are used to manipulate behavior, they kill genuine interest and trust.

The problem with financial incentives isn’t that people are offered too much money; the problem is that money becomes too salient.
It’s driven by the principle of “Do this, and you’ll get that.”
You can’t just remove the carrot and stick; you must rebuild the system so people have genuine reasons to care.

So, what creates intrinsic motivation?
We need to focus on the 3Cs: Collaboration, Content, and Choice.

Everyone feels great and motivated when collaborating with others — in business, that means with colleagues.
If your support helps your colleague get a bonus while you don’t, it’s natural to feel less eager to prioritize helping next time, even if it benefits the business overall.

If what you’re working on is meaningful to you, you’re naturally motivated.
That’s why, when I was running an agriculture startup, my team was deeply motivated — we were solving problems related to food and the planet.
I believe NGOs can attract top talent for the same reason: the work itself is fulfilling.

Another critical point is autonomy, or the power of Choice.
True motivation flourishes when people feel they have control over their work — how they do it, when they do it, and what problems they choose to solve.
Leaders often think they need to “motivate” others, but as Kohn says, you actually can’t motivate people.
You can only create conditions where they can motivate themselves.
The leader’s role is to remove obstacles and build an environment where people feel trusted, capable, and connected.

In business, the founder (or leader) should set the company vision and major milestones.
Otherwise, there’s too much noise — and it’s the founder’s role to think deeply about long-term goals. (It’s your company; you gain the most from its success.)
At the same time, when it comes to achieving each milestone, it’s crucial to listen to your team’s voices and reflect their decisions.
When people make their own choices, they not only feel more motivated but also take natural ownership.

Kohn also highlights another consequence of reward-driven systems: creativity loss.
When people work for rewards, they focus on doing just enough to earn them — not exploring, innovating, or taking risks.
Studies show that rewards make people play it safe. Ironically, systems meant to boost performance end up discouraging curiosity and experimentation.

As a remark, this doesn’t mean people will work for free.
The book clearly states that fair monetary compensation is essential — but pay for performance is not recommended.
Here are the key principles:
Pay people generously. Do your best to ensure they don’t feel exploited.
Then do everything possible to help them stop thinking about money.

Finally, it’s worth noting that rewards aren’t limited to money.
Even praise, when used as a tool to steer behavior (“Good job!” said too often), can have the same negative effect.
People start working for approval rather than curiosity or pride in their craft.

This book reminded me that the best teams aren’t built on incentives but on trust, purpose, and shared ownership.
The goal of leader is not to hand out rewards but to create a space where people genuinely want to do great work.

Great bosses aren’t born overnight – they’re shaped by the habits they practice every day. After reflecting on both my own experience and lessons from leadership books, I’ve come to believe in five core practices that truly define great leaders when they’re applied consistently.

1. Give Clear Direction

At my startup, I shared a strong vision that attracted incredible people — some joined even when the compensation didn’t match their market value. Our mission was inspiring enough to unite us. But here’s the hard truth: I didn’t revisit that vision often enough.

A compelling vision doesn’t live in a single all-hands or pitch deck. It has to be retold, refined, and reinforced every 90 days so that people don’t just hear it but own it. Hearing it once isn’t enough — they need to understand it deeply and connect it to their own goals. I learned this too late, and it’s something I would prioritize if I were leading a team again.

2. Provide the Necessary Tools

I always made sure my team had access to resources — GPUs, papers, new frameworks, anything that could help them explore faster. What I overlooked, though, was that my time was often the most valuable resource I could give.

Resources like training, technology, and extra help matter – but a leader’s attention matters most. I used to assume casual chats or shared code reviews were enough, but structured one-on-ones might have uncovered deeper needs or bottlenecks. The simplest way to confirm that your team has what they need to do great work? Just ask.

3. Let Go

Once expectations are clear and people have what they need, leaders need to resist the urge to micromanage. Early on, I sometimes over-involved myself because the work was deep tech and difficult to measure. In research-driven environments, tangible progress is often fuzzy — you might be “stuck” for weeks, yet still be advancing.

Because I didn’t set clear expectations from the beginning, I found myself constantly clarifying, defending, or justifying the team’s progress to external stakeholders. It drained energy that could have been spent supporting the team. The best lesson I learned: focus on people who understand their roles, genuinely want the responsibility, and have the ability to deliver — then give them space to succeed.

4. Act with the Greater Good in Mind

Short-term wins can be tempting, especially under investor pressure. But I’ve learned that when you consistently choose what’s best for the team or organization — even if it’s harder in the short term — you build lasting credibility.

When I had to argue for my team’s value during tough discussions about layoffs, I realized how crucial it is for leadership actions to align with the long-term vision. Acting with integrity and transparency, even under stress, shapes how people remember your leadership long after you leave.

5. Set Aside Time to Reflect

In the early days, I was always in execution mode — hiring, coding, firefighting. I rarely paused to step back and reflect. Yet reflection is where real growth happens. Whether it’s a quiet hour each week or a full-day offsite, stepping back helps you see the bigger picture.

I now believe leaders need to schedule reflection the way they schedule standups. It’s not indulgence — it’s maintenance for clear thinking and better decisions.

The Management Habits That Sustain Leadership

Leadership sets the direction, but management keeps the ship steady. Here are five management practices that go hand in hand with leadership — ones I’ve learned both by missing and by doing.

1. Set Clear Expectations

I used to assume my team understood priorities and responsibilities intuitively. We were a small, tight-knit group, so I thought shared context was enough. It wasn’t. Without explicit expectations, accountability becomes ambiguous.

People need to know their roles, the values that guide decisions, the priorities that matter most, and the results they’re accountable for. Without clarity in these areas, accountability is impossible.

2. Communicate Well

In my first startup, communication often happened informally — over Slack threads or coffee chats. It worked surprisingly well for creativity, but not always for alignment. I learned that great communication isn’t about talking often, it’s about checking for understanding.

Don’t rely on assumptions – ask questions, listen carefully, and verify mutual understanding. Open dialogue builds trust and ensures that nothing important is left unsaid.

3. Establish a Steady Meeting Rhythm

I didn’t set regular one-on-ones officially, though I did have frequent informal discussions. Those casual chats were fantastic for motivation and brainstorming, but they lacked structure. If I could redo it, I’d add a weekly rhythm — team meetings with clear agendas and one-on-ones during the first 90 days for every new hire.

That early attention aligns expectations quickly and prevents misalignment later on.

4. Hold Quarterly Conversations

This is one of my biggest takeaways from hindsight. We never had formal quarterly off-sites, and I now realize how powerful they could have been. Meeting off-site, away from daily distractions, to discuss what’s working, what isn’t, and how each person is living up to their role, values, and priorities — that’s where deeper connection and synergy form.

Quarterly conversations keep relationships and goals from fraying, even in fast-moving startups.

5. Reward and Recognize

At my startup, we were strong on passion but weak on celebration. Feedback and recognition happened naturally but sporadically. I’ve since seen other teams do this much better — giving quick, public praise and private, constructive feedback within 24 hours.

It’s such a small thing, but consistent recognition creates momentum and trust.

My journey has taken me from founder to leader, and now, back to being a follower in another startup. This transition has taught me that great leadership isn’t about authority — it’s about discipline, clarity, and care.

As my share becomes passive, which means common stock and not bound to the active founder, it becomes appealing for investors. One reason is to buy out when it is relative inexpensive. Another reason is to remove the potential red-flag when it comes to the next financial round. For some investors, big part of company share held left founder couldn’t be seen as ideal case.

Then, what decides the value of the stock in the private market, more exclusively in early stage startup. In traditional evaluation strategy, some factor * anual revenue or some factor * anual profit is applied. Howeer, anual profit is mostly negative for startups (especially, VC-backed startup; otherwise there’s no strong need of raising capital.) So, it’s often used for the mature business&industry.

See the Appendix below for the some factor

I have experienced multiple negotiation with investors, and yet it’s quite hard to find the common ground. It’s very natural to end up asking high for seller-side, and low for buyer-side. The value is up in the air, so nobody can objectively tell who is asking from the out of reasonalble range.

One strategy is to anchor the share price from the last round. Of course, there are factors to consider in this case.

1. The money is not invested into company which will have the potential to increase the inovation within the company.
2. If the share status is different (common vs preferred), its value differ.
3. The last round may have happened months or even years ago.
   The business could have evolved—or deteriorated—over time, making that old valuation less reliable.

When expectations diverge, arguing over a single number rarely helps. What works better is structuring the deal so it moves with reality. Sometimes the price isn’t fixed at signing but adjusts later—say, when the next funding round sets a fresh valuation. Sometimes the sale happens in stages: a portion now, the rest when milestones are met. A neutral valuation can also help anchor both sides, and non-cash elements—faster liquidity, a role, introductions—can close the gap without simply raising the cash number. In the end, early-stage secondary sales are less about formulas and more about aligning incentives and trust. Clarity on risk, share rights, and the company’s trajectory does more to seal a deal than any spreadsheet multiple.

Appendix: Typical Valuation Multiples by Industry & Stage