April Update

This month was mainly dedicated to managing the house project. This job has been quite intense lately and I will soon need a vacation.


Perhaps a picture shows it best:

If you find this looks like an industrial workshop, you are not wrong. Between three and twelve workers share this space daily to measure, cut, sand, assemble and clean up various pieces and materials.

Also, this space did not exist three months ago. As in, its volume was outdoors, a part of my yard. Arguably, a lot happened already.

Yet this space is also meant to become a living room. So a lot remains to be done still.

The work I am still most excited about, and which motivated the entire project, is at the nexus of the following picture:

In April, all the air conduits were installed through my home. Its unfortunate original architecture was the main reason why three months of complex construction work were needed before this could be installed.

Ostensibly, the actual ventilation unit is still missing. There are some unspecified delivery delays. Again, a lot remains to be done.


This month (in fact, most of my time since I returned from Geneva in March) pretty much felt I was occupied with a full-time management job. My routine every day went approximately as follows:

  • 07:30-09:00 kickstart my thinking in preparation for later action in the day:
    • review current deliverables and progress, and highlight items at risk or significantly delayed.
    • review currently open decision or design questions.
  • 09:00-12:00 on relevant days, go to the gym and pick up the brain of my personal trainer / coach on house-adjacent and leadership topics. This is also the time where I make up my mind about current topics identified earlier. On other days, run personal errands (groceries etc).
  • 12:00-14:00 visit the construction site and spend some quality time with the team:
    • take pictures of current areas of work;
    • have a friendly chat with the current workers on site;
    • answer questions they may have, including possibly filing new questions for later analysis;
    • ask clarifying questions about recent changes, with the aim to both further my own understanding and build our relationship;
    • request advice, suggestion or recommendations on current open decisions or design questions (also towards relationship building);
    • inquire about plan adjustments or incidental changes: what do they think of feasability? Timing? Any obstacle I might be missing? (again, towards relationship building)
  • 14:00-15:00 summarize any new findings that day in writing. Depending on current topics, this leads to different messages for different audiences:
    • the on-site team lead wants a confirmation and reminder of what we talked about that day.
    • the main contractor’s project lead wants to know about any decision or change that may impact planning or budgeting.
    • the contractor’s work planner wants to know about anything new that needs to be ordered or changes in the work organization.
    • my architect is also my delegate project director and wants to know every time my thinking / wishes change to be able to represent me when I am not available.
    • a couple of other secondary contractors have a relationship directly with me and need a combined update specific to their work.
  • 15:00-17:00 additional problem-solving or analysis, as needed that day. Each week, on average, only two days out of five need significant extra work in that period. It’s also been quite different every day:
    • design research with my architect: comparing options, making and reviewing specification drawings, etc.
    • design research with a supplier: scanning through catalogues and filling in an order spreadsheet.
    • decision analysis with a contractor or sub-contractor: something unexpected was discovered or happened, and we need to change plans. What is the best course of action? I always ask then to provide some alternatives to compare, but at that point I made my overall direction clear already so I usually trust them to take the right decision. If a technical discussion is needed, I ask my architect to engage on my behalf.
    • requesting and reviewing quotes from new suppliers or sub-contractors.
    • budget/invoice review & payments.

Additionally, every two weeks my architect runs a leadership meeting on-site on my behalf where all the responsible parties review the work so far and author a shared “progress document” that highlights decisions and action items.

This is “just” a formality, in the sense that most of the relevant topics are already being discussed and solved as needed in-between these meetings.

However, it is also a formality, in that the meeting notes also turn into contractual obligations. For example, we already used these documents a couple of times to settle a dicussion around work that may or may not have meant to be done in a particular way, without needing to argue about it.


Looking back, I realize that my management style was directly influenced—and improved—by several of the books I read (and recommended) in the last three months.

Here are some example things I was definitely doing differently this time:

  • delayed decisions: whenever I found something that needed a change (either after it was done already, or a change in specifications), this time I first I merely suggested that I might be wanting a change, then I asked for recommendations or possible risks/obstacles from the relevant worke(s), and only then I brought the item to the leadership group for actual decision-making.

    My key motivation here is that I did not want anyone feeling like their earlier work was wasted or a change was made against their best judgement. I also wanted to foster a strong sense of ownership, which is also key to getting folk to fix things themselves directly.

  • soft accountability: whenever I noticed something unexpected, I chose to not show surprise or disappointment (even though I might have felt it a few times internally). Instead, I pointed to the thing non-confrontationally and asked to the work lead what they thought about it and would recommend.

    Most of the time, this was sufficient to prompt a self-initiated corrective action without me having to ask for anything directly. In case no answer was immediately available, I simply took note of it and brought it up at the next discussion with the leadership group.

  • empathy and trust: quite in a few cases, practical considerations limited folk’s ability to reach the originally envisioned goals. This also included mistaken interpretations of earlier discussions, leading to a different direction being taken, with little chance of resuming the original plan by the time we found the discrepancy.

    To relieve my anxiety, in these cases I did ask to get clarity on the situation and verify that all reasonable alternatives were being considered; however, because I had built a culture of accountability already, I trusted the team when they recommended against taking corrective action and instead chose an accepting stance. My reasoning was that pushing for a backtrack and re-do would have caused excess planning pressure, and increased the risk of delayed delivery (or extra mistakes in an attempt to satisfy deadlines). A few things ended up quite differently than what my architect wanted, and I am OK with that.

    In hindsight, an accepting stance here was also reasonable: after all, those items where a discrepancy occured were those we had given less attention to, so by definition they were already secondary from my perspective.


It’s funny how the leadership story really has two sides.

From the perspective “what happens if there is a problem already” we need to look at accountability and I need to pay attention to the reporting structure:

In this diagram, I used dotted boxes to represent folk or entities I talked to over the phone but did not see in-person. The full line boxes have all been on-site at least a couple of times.

The diagram is also not exhaustive; at least a couple more dozen additional workers reporting to these entities were on site over the last few months (either just once or twice, or more regularly) but I did not interact with them directly.

This diagram never became central to the project, because in the end we did not encounter major hassles. However, it did help me in an important way: it made me recognize that a few contractors on separate reporting lines had overlapping areas of work. (This is a classic sign of trouble in project management literature.) We organized some discussion upfront to negotiate the boundaries of their respective assignments to prevent conflict preemptively, and that was that.

That said, on a day-to-day basis, leadership is all about relationships. From my perspective, it looked more like this:

These are the people I am interacting with the most often, and with whom I always try to keep our last in-person conversation in recent memory.

At the risk of sounding trite, I am pretty sure that the quality time I invested with just these few folk to describe my desired outcomes was our key to completing the project on time, including numerous additions and adjustments. I am immensely grateful for all the conversations that happened directly between them to discuss and solve problems dynamically, without overwhelming me with decision fatigue.

(Relatedly, I highly recommend developing a solid, trusting relationship with an electrician and a plumber.)

I also plan to keep in touch with some of them for later projects or to recommend to friends and family.


Besides the current side-project, I did a little bit of additional reading and learning this month. No books.

In The misunderstood Kelly criterion, Christoffer Stjernlöf dispels some common misconceptions about Kelly’s criteron, a mathematical idea on how to optimize decisions about numbers subject to geometric growth, which in practice means financial decisions. This piece was important to me because after observing that an investment loss of X% followed by a growth of X% does not get one to the same point as a growth of X% followed by a loss of X%, I felt there was something I should know about investment strategies. I was missing a better understanding of Kelly’s criterion. Thanks Chris!

Slate Star Codex is a Reddit community around Scott Alexander’s Astral Codex Ten, both of which I have little to no opinion of. However, that community raised a key topic last month: If people want “community” so much, why aren’t we creating it? The discussion is vivid and collects many well-argued, solid viewpoints. It gives much to think about, including a few recommendations on how to actually build communities.

In The Scoped Task Trillema, Saoirse (last name unknown) explains that the existing concurrency facilities in Rust can only satisfactorily support two of three desirable services: concurrency expression (the ability of tasks to run independently of each other), parallelism (the ability of tasks to run at the same time), and borrowing (the ability of tasks to reuse shared objects). Even though the argument is specific to Rust, I sense that it can be generalized to pretty much any language that uses affine typing and claims to prevent data races.

The above incidentally led me to (re)discover the fascinating story of the Leakpocalypse, where the Rust community in 2015 had to give up on the guarantee that object destructors always run. That guarantee was previously mistakenly assumed to be provided by the language, and had been used to design all manners of clever RAII-based resource locking mechanisms. Sadly, it turned out that the guarantee was unsound, and destructors are only guaranteed to run in an under-specified subset of cases. I found this story both fascinating and somewhat sad at the same time. (FWIW, the same problem exists in C++. It’s not unique to Rust.)

This interview of Marlon Brando.

Q: Don’t you realise that you’re thought of as the greatest actor ever?

A: Tim’s [his dog] the greatest actor ever. He pretends he loves me, he wants something to eat - get out of here. It’s true! Uh what’s the difference? See, that’s a part of the sickness in America, that you have to think in terms of ‘who wins’, ‘who loses’; ‘who’s good’, ‘who’s bad’; ‘who’s best’, ‘who’s worst?’ We always think in those terms (in extreme terms). I don’t like to think that way. Everybody has their own value in a different way; and I don’t like to think who was the best at this… what’s the point of it?

Doctor Mike‘s monthly podcast interview was with “Dr K”, the psychologist behind the wildly-popular Healthy Gamer GG channel on Youtube.

In this episode, both doctors discuss some parts of Eastern Medicine that are missing from Western (“evidence-based”) Medicine, what they are good for, and how we could go about studying them better. I found it fascinating to see two doctors who are both extremely passionate about their work engage in a scientific discussion of the kind you only hear about in history books about major advances in the 19th century.

Finally, Luke Kanies rambles in Why We Hate Working for Big Companies about the human cost of letting organizations grow past the point where they need middle managers. The main and most important point made there is an observation, that we at the level of entire societies look at countries with autocratic governments with a lot of criticism, while we remain happy to let corporations run using ruthless autocratic governance models. Luke has experienced internal turmoil about this (as a business owner), and this topic is very close to my heart as an aspiring executive. It’s unclear yet where I want to go with this.


Also, I plan to visit NYC at the end of the month. If you are interested to meet, let me know!