unicolet.org

Photo by Daniele Levis Pelusi on Unsplash This week I joined a Risk Storming workshop led by Beren Van Daele . Disclaimer: my attendance was spotty due to overlapping events, but I think I got a passing understanding.   One aspect of the workshop stirred my attention, and it was the mention of fears in the context of goals vs fears. Obviously anyone wants to achieve certain goals, so it makes sense to set goals and to mention them in a workshop like this. However when setting goals there are certain second-order effects or side-effects that we want to avoid, minimise or eliminate entirely. Here are a few reasons why I found intriguing (and valuable!) the explicit mention of fear. Acknowledge fears when planning Acknowledging fears and taking them into account into planning is a desirable trait in any wise person who seeks to

I once asked my therapist: I often find myself thinking about work while I'm not working, for example while doing house chores, watching my kids at the park, etc. and I'm not sure how to feel about it. Does that make me a bad father/partner? Nutella for Breakfast, source He asked me back: what's the attribute of every thing that can make it bad or good? No matter how much I thought about it I could not answer the question. After a pause, he then said: it's quantity. Are you thinking about work all the time while at the park, or just a moment? Think about it: a glass of wine is good, but a bottle isn't. A spoon of chocolate spread is ok, maybe even healthy. The whole jar isn't.

An enabling constraint is a limitation or rule that, rather than hindering creativity or progress, actually promotes innovation and problem-solving. In software development, we've all experienced the positive effects of enabling constraints. Examples of enabling constraints in sw development are: trunk-based development continuous integration static code analysis/checks, i.e.: enforcing rules such as function or method length, number of parameters, naming conventions, etc Recently, I've been thinking about the use of enabling constraints at the organizational level. One example I think I heard here was about strengthening the cooperation between engineering and marketing. The solution can be remarkably simple: have marketing prepare the material for a feature  before  its implementation. What I was wondering is: how should we think about this change in terms of Team Topologies? Before diving into the topologies and interactions I would observe that this change adheres to some

I just read Prof's Galloway latest No Mercy/No Malice post ( link ) and I am actually not sure how to name my feelings after learning how low Intel has fallen. I've never been a particular fan of Intel ever since they were found to be bribing/coercing PC manufacturers to prefer Intel chips (instead of AMD): At its peak in 2000, Intel’s market cap was $500 billion. Since then, the S&P is up 243%, and Intel down 80%. If Intel had kept pace with the S&P, the firm would be worth 16X what it’s worth today. A stark reminder of this fall from grace: Jensen Huang (CEO, Nvidia) is worth more than Intel. The firm is at risk of being dropped from the Dow. Wow, just WOW! 

Best take so far on founder mode:  https://oxide.computer/podcasts/oxide-and-friends/2098243 The hosts do a fantastic job of keeping the discussion entertaining, despite its length. Some key takeaways: Oxide write-intensive culture as a mechanism to build trust and keeping the company true to itself: a writing- (and reading-!) intensive company culture does, in fact, allow for scaling the kind of responsibility that Graham thinks of as founder mode the false dichotomy between founder mode and "traditional" manager mode the feat that founder mode will be used to justify all kind of behaviour and decisions Footnote: interestingly they link to the same interview of Brian Chesky that I linked too in my previous posts on the topic.

Two weeks ago, a post by Paul Graham about unconventional company management sparked significant discussion in the Refactoring community. Initially skeptical, I shared my thoughts after reading the post multiple times. Graham's compelling question lingered: what if the common way to run companies isn't the best approach after all? Intrigued by this idea, I decided to delve deeper. I watched two insightful interviews with Brian Chesky, CEO of Airbnb, which I believe offer context to his remarks at the YC event mentioned by Graham: "Leading through uncertainty: A design-led company" (Config 2023) "Brian Chesky's new playbook" I recommend the first video for those short on time. After watching these interviews, I found Chesky's ideas resonating strongly with me. His core philosophy can be distilled to: "If you do what everyone else does, you'll get the same results everyone else gets." This approach seems to be working. Airbnb's impr

A  post by Paul Graham caught a lot of attraction in the Refactoring community  a couple of weeks ago. I read the post a couple of times, and then rushed to share my thoughts (which I reproduce below). The essence (at the time) is that I was skeptical, even though I think Paul Graham's post asks a compelling question: what if the common way to run companies is not the best after all? Last week I finally had time to watch a couple appearances by Brian Chesky which I believe give an insight into what Brian Chesky might have have said at the YC event mentioned by PG, which is, AFAIU, not publicly available. For the record I watched these two: Leading through uncertainty: A design-led company - Brian Chesky (Config 2023 ) (my recommendation if you're short on time) Brian Chesky’s new playbook and I have to admit his ideas resonated a lot with me. Abstracting to the core I would say that Brian's approach can be summarized as &q