unicolet.org

After some postponing due to a busy April, I've eventually made time to listen to another Refactoring podcast episode: How to Coach CTOs . Here are my customarily short notes on the most important takeaways. I added this episode to the compilation of my favorite podcast episodes . Focus on your strengths This is brilliant advice, which is often overlooked, even though it surfaces in lots of places (Drucker, Munger, Rumelt, Covery). I'd pair it with Munger's advice to, erm, minimize your errors (he calls it avoiding stupidity ), which I interpret as a more active version of focusing on strengths. Understanding the fear(s) of your peers This is not covered in the episode, but I thought it would make a great complement to understanding their goals and their objectives. I wrote about fear last year and it's been very valuable for me to unpack executives requests and ideas. Relationship with peers Can't believe this advice is actually free: Many early-career CTOs strug...

This LinkedIn post hurt 😅: The metrics they create for engineering help them convey to the board and to the other non technical department how engineering is helping the business move forward, how engineering is adding value. Not what the DORA metrics say without any relationship to what the company is trying to achieve. As a huge DORA fan, I am hurt that DORA is not the pinnacle of clarity that I want it be, especially since I have it on the deck I present the board each quarter. The fact is that Adelina Chalmers is right. The language of business is accounting and engineering performance should be ultimately connectable to bottom line impact. If it can't, there is a disconnect which will ultimately lead to a rough wake up call. So what can we use instead? A similar question was asked in the CTO Craft slack. Here is my take, straight off the top of my head (so probably still a bit rough). Considering that a C-Level/Board would be talking at the level of impact , we need to con...