Amazing CTO | More happiness and success
🚀 #3 2022

by Stephan Schmidt

Happy Friday,

this week I’m using the first linked article to talk about negativity. Too often our reaction as engineers to ideas is negative, a “No” or a “Can’t be done” or “But have you thought of X?”. This way development is seen as a roadblock and naysayer. Development is perceived as people who do not want to get things done, who do not believe in the mission and who are not part of the team.

But this negativity is understandable. In the end all logical errors and roadblocks will end up with developers. All future problems due to missing requirements, misguided ideas and half cooked products end up with the CTO, not those wanting new things in the first place. They won’t stay up all night.

But we need to hold back. There is a time for “no” and a time for “yes”. First there is a time for positivity, saying yes to new ideas and exploring them. And there is a time to raise concerns and think about edge cases. Begin by listening. Do not raise objections. Again this is hard for engineers, we’re trained to find solutions to problems. Our developer brains are conditioned to automatically click into solutions when we hear problems. One of my faults is I jump to solutions very fast. Already primary school attested my readiness of mind. Often I’m right, but too often my solutions are not the best, because I didn’t listen enough (working on that since some years). Solutions in our head lead to edge cases. We ask “But have you thought of X?”. We instantly make assumptions. A friend once told me the story of a product manager talking to developers about international expansion. They were already under pressure and had objections, internationalisation is no easy task. What the product manager had in mind was “What would we need to do to internationalize our product next year or the year after”. We do not listen enough and jump to solutions and objections as soon as we hear the first words. Start with listening.

As CTOs we need to teach engineers that there is the right time for everything, that the there is the right time for their concerns. Half-baked ideas will not be implemented and there is a time when we properly think about edge cases and feasibility. But the first thing is being positive about new ideas. This can be achieved with trust. Engineers trust you that you make sure there is a time for their concerns after they have listened. If you promise this, keep the promise, and they will rightfully trust you.

As for the articles, good reading, nice weekend and until next week,

Stephan

PS: If you like the newsletter, please forward 😊

For your ears - a Podcast

The Modern CTO - a podcast with a wide range of topics, some interesting and some relevant to CTOs. From Hiring to defending against Randomware (I told you to give internal IT to the CFO, didn’t I?) and building your own brand (also a recurring topic in my coachings). Many episodes worth listening to

https://moderncto.io/podcast/

Interesting Articles

Rage Against the Codebase: Programmers and Negativity

The topic of this newsletter.

https://medium.com/@way/rage-against-the-codebase-programmers-and-negativity-d7d6b968e5f3

Why America can’t build quickly anymore

How is this relevant to your startup and your CTO job? Read this quote “And this is where I feel that lawmakers of the 1970s made a huge mistake. Rather than accept the need for general rules, or choices by accountable elected officials, the lawmakers built a dispersed power structure filled with veto points that lends itself to analysis paralysis.” Doesn’t it reflect the state of your company?

https://fullstackeconomics.com/why-america-cant-build-big-things-any-more/

Polylith

I recently came across Polylith and their claim of solving “We lack a shared language for communicating architectural concepts” was interesting to me. I’ve struggled with this for decades without a clear solution, on how to integrate architecture into code.

https://polylith.gitbook.io/polylith/introduction/polylith-in-a-nutshell

Strategy is not X

If you don’t want to read “Good Strategy/Bad Strategy” (but you should), here are some important points

https://www.umr.io/blog/strategy-is-not-x

Are Your Passwords in the Green?

Yes, the table is click bait, yes the table is MD5 hashes. If you scroll down the article has some insight into bcrypt (you’re on bcrypt, aren’t you?) though, and having a rough understanding of the speed of cracking a password (hope your customers don’t reuse passwords from MD5 loving forum software) is essential.

https://www.hivesystems.io/blog/are-your-passwords-in-the-green

Software is no longer sold; it’s adopted

The word “adopted” caught my eye, the article didn’t disappoint with some insights on product onboarding. Product onboarding doesn’t seem to be a thing for CTOs. But I disagree. Features amd products you build and are successful make you successful. Focusing only on execution is 90s. As a CTO force the company to invest in product and feature marketing, and in successful product onboarding.

https://orbit.love/blog/software-is-no-longer-sold-its-adopted

On the weaponisation of open source

Recently a NPM deleted files on local drives if they had Russian IPs. At first glance nothing that should concern you. But what if your country does something that the world doesn’t like? Some interesting ideas about software as weapons and something that will become more important in the future.

https://beny23.github.io/posts/on_weaponisation_of_open_source/

Structured Concurrency

With concurrency, we still think about programming styles (OO vs. imperative vs. functional) and language features (think async). We do not have a fundamental understanding of concurrency. So every article, like this one, is a win (Non standard port? :-)

https://250bpm.com/blog:71/

How I learned to stop worrying and structure all writing as a list

An interesting in depth analysis wh y articles that look like lists are attractive - and a good thing. The antithesis to Paul Graham (love them) texts.

https://dynomight.net/lists/

Book Recommendation

A must-read book for every CTO is “The Field Guide to Understanding Human Error” from Sidney Dekker. Which astonishingly is not about the human error. Incidents are too easily pinned on humans. Someone made a mistake. But the interesting question is: Why did they make the mistake? Neither the pilot, the software developer or the devopsian wanted to make the mistake. We need to look at the incident from a time before the incident into the future to understand it, not from now back towards the incident. After reading the book you will never look at outages the same way.