Amazing CTO Newsletter
🚀 #3 2022
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,
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
Rage Against the Codebase: Programmers and Negativity
The topic of this newsletter.
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?
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.
Strategy is not X
If you don’t want to read “Good Strategy/Bad Strategy” (but you should), here are some important points
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.
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.
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.
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? :-)
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.
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.