Amazing CTO | More happiness and success
🚀 Issue 9.1

by Stephan Schmidt

Happy Friday,

engineering culture is often neglected. And when not neglected then badly implemented. The biggest mistake is that CTOs do not see engineering culture as a management tool - one of their best - that brings alignment and safes time and management bandwidth. You need to decide what the culture looks like and how it helps you safe time. Bottom up culture and values by beauty contest don’t work. Finishing with some ideas that safe your precious time to include in your culture are:

• Inclusiveness
• Own things & take responsibility
• Craftsmanship and no shortcuts
• Transparency

This week’s insights include

• ⛅ the new CTO Job Market Weather Report
• The a-hole test
• Saying no - twice.
• Book recommendation 📚: “Lost in Math” by Sabine Hossenfelder. It’s about software development!

Good reading, nice weekend ❤️ and until next week,

Stephan

⛅ CTO Job Market Weather

How is the CTO job market? It looks like it is weakening even more. Numbers are down for the US and Germany. Let’s see if they take up again next week, though with weakening investment it might not happen.

Stories I’ve encountered last week

IBM’s a-hole test

One of my cultural values (see engineering culture) is about respect. How do you find out if someone is toxic during recruiting? IBM seems to have invented a test. If you have many recruits - probably you haven’t - try it out.

https://johnpublic.mataroa.blog/blog/the-asshole-test/

The Hardest Thing About Making Decisions Is Saying No

Title says it all. My mantra: prioritization is not about “A then B then C”, but about “A not B”. Which is about learning to say no.

https://fev.al/posts/saying-no/

The Google Incentive Mismatch: Problems with Promotion-Oriented Cultures

Worth a read for this quote alone “For instance, when I was leading Google Sheets, we had a lot of small bugs and usability issues, […]. Users wanted us to implement disjoint selections, fix our charting UI, […] However it was a constant struggle to prioritize these types of issues vs. “bigger impact” projects.”

https://www.warp.dev/blog/problems-with-promotion-oriented-cultures

These are the storytelling lessons I learned from Steve Jobs

Everyone knows I’m a Steve Jobs fan and a Tim Cook … let’s say I don’t like him or the Apple he created. There are so many things to learn from Steve Jobs (see above “Focusing is about saying ’no’”) so go and learn

https://www.fastcompany.com/90747313/steve-jobs-lessons-tony-fadell-build-book-excerpt

Preventing burnout: A manager’s toolkit

A topic I see in some of my coachees. Gladly we talk more about mental health issues in and from startups, but not enough. If you want to prevent burnout with your direct reports, read this. And as a manager it’s your duty to care.

https://about.gitlab.com/blog/2022/05/03/preventing-burnout-a-managers-toolkit/

Two workers are quadratically better than one

This is not about developers (Yes, two developers is the perfect team size!). But about queues. Queues are everywhere and are non-intuitive. So every bit of insight into queue theory is welcome - and entertaining. Not convinced? “If we have 10 tasks, they wait a total of 30 steps. If we have 100, they wait a total of over 1300 steps.” And you wonder why people are unhappy with development speed (or rather, their waiting time!).

https://www.hillelwayne.com/post/queueing-prism/

Did extroverts ruin remote work for the rest of us?

An important text on the future of remote work in development (though I don’t know why all the text is bold)

https://makeworkbetter.substack.com/p/extroverts

The great VC pullback of 2022

Bad news ahead. If you want a new CTO job, go before the windows closes. And ask (always ask!) how much money the startup has in the bank and how much runway is left.

https://mattturck.com/vcpullback/

Book of the week

This week’s book is “Lost in Math” by Sabine Hossenfelder. You want to know what it has to do with software development? Calm down my young padawan. The book is about why there hasn’t been progress in physics for the last decades. The point Sabine makes is that physicists like the beauty of their models more than they like progress tied to reality. I’ve started coding 40 years ago and have seen great progress from machine code and BASIC. But then we lost it (I blame Lisp!) and developers are more interested in the beauty of their languages and frameworks than in solving real problems (what problems even?!). So this books seems to be written about software development. If you’re interested in our industry and software development, this book will have some “Eureka !“s for you.