Amazing CTO | More happiness and success
🚀 45.2by Stephan SchmidtHappy 🌞 Sunday, This week only a small observation. In the past, I’ve already learned that no one knows Joel on Software anymore. A titan of practical software development insights 20 years ago, insights lost like tears in the rain. But this week DHH (inventor of Rails, huge impact with books like Rework ten years ago) released a new deployment tool called MRSK. And most comments on Hackernews: “Who is DHH?” Sigh. It’s like a physicist asking “Who is Einstein?” This week insights - 🦹 System design and the cost of architectural complexity
- 🤖 Understanding People Matters More Than Understanding Tech
- đź’» Directly Responsible Individuals
n
Good reading, have a nice Sunday ❤️ and a great week,
Stephan
CTO-Coach and CTO-veteran If you only read one thingSystem design and the cost of architectural complexity “Many modern systems are so large that no one truly understands how they work.” https://dspace.mit.edu/handle/1721.1/79551 Stories I’ve enjoyed this weekUnderstanding People Matters More Than Understanding Tech Amen. “If there was only one piece of advice that I wish I had known early in my career as a software dev is that understanding people is more important than understanding tech, by a long shot.” https://letterstoanewdeveloper.com/2023/03/06/understanding-people-matters-more-than-understanding-tech/ Directly Responsible Individuals One of the problems every CTO I talk to has to some degree is: People don’t take the responsibility they should take. Have you tried DRIs? This is about projects but the same should be the case for quality, performance, etc. DRI is where you need to start, then with lots of experience, responsibility can be shared by a team. If you give responsibility to an inexperienced team, it’s like sending your kid to the Tour de France. Doomed to fail. https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/ Self-Admitted Technical Debt “Self-admitted technical debt (SATD) consists of annotations, left by developers as comments in the source code or elsewhere, as a reminder about pieces of software manifesting technical debt (TD), i.e., ’not being ready yet’” Do you have lots of FIXME in your code? As CTO, did you even look? If not, check now ;-) https://neverworkintheory.org/2023/03/16/self-admitted-technical-debt.html One of the best podcasting apps you know is built by a single person Our industry hasn’t reflected the changes in developer productivity from better tools, cloud, and SaaS services. It is astonishing what one person - or a small team - can do. Hire for quality, and keep your numbers small, as DHH the inventor of rails said “Small teams, small problems, large teams, large problems”. https://www.theverge.com/2023/3/20/23648650/marco-arment-overcast-solo-acts Our production servers were suspended by Google Cloud When I ask “Do you have BCDR (business continuity/disaster recovery) implemented?” I most often get the answer “We’re in the cloud”. Duh. https://www.onvoard.com/blog/our-production-servers-was-suspended-by-google-cloud There’s a Good Chance You’ll Regret Quitting Your Job Quite some of the CTOs I’ve met recently want to change jobs or quit executive work. Interesting take on the topic. https://www.theatlantic.com/ideas/archive/2023/03/great-resignation-quit-job-regret/673346/ How I structure my teams for growth Scale is one of the most important topics in a startup. I wonder why so few CTOs have a plan beyond vague ideas. I don’t agree with everything in this piece, but it’s a good read. With the eternal discussion of matrix vs. tree organizations (I prefer trees) https://medium.com/@smnbss/how-i-structure-my-teams-for-growth-3272e4c3fc28 The Effective Decision From Drucker. From 1967. And still, the biggest problem in startups having a bad decision process. https://hbr.org/1967/01/the-effective-decision | 