unicolet.org

Following up on my previous post On Fear , I was reflecting on the possibility that: bad reports will ignore your fears and only focus on the goals. As a result your satisfaction will be low good reports will only pick up on the fears that are explicitly stated as a goal. As a result your satisfaction will be OK-ish, but at great expense great reports will understand your fears before you even state them or without needing to go into the details. As a result your satisfaction will be at its greatest potential, allowing full delegation and growth for both

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!