Amazing CTO | More happiness and success
🚀 29.1

by Stephan Schmidt

Happy Friday,

I stumbled upon a book on Hacker News, “Junior to Senior” for developers on how to progress from junior to senior. While this looks like a book for developers, I thought “Hey, most of my CTO coachees have a problem here too!” CTOs often do not have a clear understanding of the differences between a junior developer and a senior developer - with the difference mostly the number of years on the job. Besides that, they have a fuzzy idea of a senior being more experienced, perhaps in architecture.

This missing understanding is the reason for many problems, from pay, and raises to hiring to promotions. Without a clear understanding, how do you hire the right junior or the right senior developer? Without a clear understanding, how to ask the right questions? Without role descriptions how to talk about promotions? Where is the guidance to the developer on what she needs to achieve to become a senior?

Either CTOs have no role descriptions or they have too long of a role description. One Coachee showed me a gigantous Excel sheet from HR with role descriptions. Unclear how that is actionable, either for you, the people manager or for the employee.

Have a clear understanding of the differences in roles and write them down. Five bullet points for each role are enough and actionable. Focus on what the differences are. Do the role descriptions clearly separate the levels? What does make a developer a senior developer? And it should not be “has at least 5 years of experience”. Another mistake many make is the sole focus on two areas: Technology (coming from the CTO) and culture skills (put there by HR). Every role description I had in startups for seniors contains “has business knowledge” to make the right trade-offs and is responsible at least for an intern to see if he likes it and would like to become a manager or stay on the tech track.

So take the book, read about some ideas on juniors and seniors, and write down your role descriptions.

On to the insights.

This week’s insights include

• 🥇 Goldie of the week: How to plan?
• ❤ Brex layoffs: What not to do
• ️🩹 Self-healing systems for CTOs to save time
• 📈 Graph of the week: Layoffs by Departments
• 📚 Book of the week: Junior to Senior

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

Stephan

📈 Graph of the week: Layoffs by Departments

Interviewing.io looked into the recent layoffs to determine how much software engineers are impacted. I found the graph interesting:

Source: https://blog.interviewing.io/how-much-have-2022-layoffs-affected-engineers-vs-other-departments-we-dug-into-the-data-to-find-out/

Goldie of the week

How to plan?

“This interview was for one of those jobs leading product and engineering which are coming back into vogue” - a good thing! But the article is about planning. And it’s one of these genuine articles, not one of those copied and pasted by someone without a clue that plaster the top of the Google search results. While I don’t agree with everything, I love the article.

https://kellanem.com/notes/how-to-plan

Stories I’ve encountered this week

Brex layoffs

It is beyond me why everyone needs to publish their internal lay-off message on their blog. Isn’t this something between you and your employees? I’m not publishing my love letters, sorry. Every time I encounter this I think the employees left will feel a breach of trust reading details on a blog. Just as if one partner goes to the press and you’re damned to stay silent. At least this is presumably after the email was sent internally. I sometimes had to read news from outside to learn what was going on inside (For Germans: Handelsregister is your friend to learn about founders shifting around). Trust is hard to earn and easy to lose, so why do this? But this one is even worse (as are most) - it’s so wrong on many levels “Today is a difficult day for Brex.” no it’s a difficult day for those being laid off who fear their future. Why always the “we”? It was the CEO that made the decisions. If you screwed up, say so, and don’t use “we” everywhere to deflect the blame. Don’t whine “While impossibly hard”, think about those laid off. “We want to be as thoughtful as possible” who is “we”? “To those who are leaving: we are so grateful for the energy, ingenuity, and commitment you brought to the company. Brex wouldn’t be here without you.” - so we fired you, and close the door on the way out, thank you! I’d suggest not publishing such a post, and in the email, you wrote, don’t make it about how hard this is for you.

https://www.brex.com/journal/message-from-pedro

Self-healing systems for CTOs

Yours truly wrote an article myself about self-healing systems. The article’s main point is how they help the CTO save time and be able to focus on more important things than dealing with outages.

https://www.amazingcto.com/self-healing-for-cto-solo-founder/

How Equifax used employment records it collects from 2.5 million companies to fire dozens of its own employees for working second jobs

There is a paywall but I’m sure the is some kind of archive. “In one of the latest signs of corporate America trying to regain control of an increasingly remote workforce, CEO Mark Begor this week informed employees that some of their “teammates” were fired for having “a second full-time job while maintaining their full-time role at EFX,” which is the ticker symbol for Equifax.” With remote work going to stay this will touch every company. I’m sure there are already startups looking for funding for a business to find people with two jobs. Have you experienced someone already who had another job besides working in your department? (I have)

https://www.businessinsider.com/equifax-fires-employees-for-working-two-jobs-2022-10

Code Review Handbook

Most code reviews I have seen in startups and with coachees are determined by what the reviewer thinks they should look like, without the CTO giving some guidance. But you should give guidance, e.G., add security, otherwise, people will look for the wrong things (“I would have done this differently”). Here is a good start, a code review handbook.

https://www.sledgeworx.io/code-review-handbook/

(as the site seems Slashdotted, the archive link is https://web.archive.org/web/20221014021506/https://www.sledgeworx.io/code-review-handbook/)

Toyota Accidently Exposed A Secret Key Publicly On GitHub For Five Years

“The code was made public from December 2017 through September 2022. […] This incident adds Toyota to the list of companies that have had similar exposures; a list that includes Samsung, Nvidia, and Twitch […]”

https://blog.gitguardian.com/toyota-accidently-exposed-a-secret-key-publicly-on-github-for-five-years/

My productivity system in 2022

A GTD - getting things done - a trainer who stopped using strict GTD “But the fact that I stopped teaching people how to do GTD – which obliged me to follow it strictly as well – opened up space to explore new ways to do things. […] So I adapted and changed and, eventually, ended up with my own version of a great productivity system.” The reasons why I’m skeptical of trainers, including you, Scrum trainer! They take money for things they don’t believe in.

https://www.nunodonato.com/my-productivity-system-in-2022/

📚 Book of the week: Junior to Senior

The book that triggered my introduction this week is “Junior to Senior” by David Glassanos. There are many good points in it, and I would buy one for every junior on my team. It is a good guide - although a lot of what’s in the book should have been explained to the junior in 1:1s - you do have 1:1s that talk mostly about development and expectations, don’t you? I did like the chapter “What Makes You a Senior Engineer?” most, especially, because we do not have enough discussions around that topic.