Logo
Join the CTO Newsletter for free!
 
Amazing CTO Logo

Amazing CTO | More happiness and success
šŸš€ 30.1

by Stephan Schmidt

Happy Friday,

This week’s insights include

  • ☁ Why the Rails Inventor is leaving the cloud
  • šŸ¢ How to Run a Department*
  • šŸ†š Martin Fowler: Product v Engineering

… and Seinfeld 🤣

Good reading, have a nice weekend ā¤ļø and until next week,

Stephan

☁ Why we’re leaving the cloud

I’m a long-term proponent of thinking for yourself and not running with everyone else. The move to the cloud makes sense for very small setups with tiny virtual machines and for large companies (not the largest, they have their own cloud). They make sense when the number of machines grows rapidly or traffic fluctuates widely. In between the cloud is 5x more expensive and I never could see the money saved from fewer SREs - indeed AWS/GCP is so complex you need to have additional people to not make mistakes and get the most out of the cloud provider. And even then, several of my coachees paid consultants to look at their cloud costs, and the consultants told them they are doing it wrong, even with specialists on their teams. A medium-sized business needs three SREs on pager duty (depending on your customers and use cases), with or without the cloud. Why did the inventor of Rails leave the cloud? ā€œRenting computers is (mostly) a bad deal for medium-sized companies like ours with stable growth. The savings promised in reduced complexity never materialized. […] It’s like paying a quarter of your house’s value for earthquake insurance when you don’t live anywhere near a fault line.ā€

https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0

šŸ¢ How to Run a Department

Ha, it starts with ā€œGrow Without Coachingā€. As you might suspect, as a CTO Coach I don’t agree with :-) - but they are right on point, you most often do not get coaching from your boss (get a coach!). Besides that point (where you might call me biased), there are many more golden nuggets in the article for running a department, especially first time, like ā€œScale the Undelegatableā€ I’ll make this article a must-read for all my coachees.

https://staysaasy.com/leadership/2022/10/10/how-to-run-a-department.html

🤣 Life’s Work: An Interview with Jerry Seinfeld

I never understood companies that use outside consultants (I know why the managers are doing it) to tell them how to run their business, e.g. McKinsey telling a Steel CEO how to run the steel business. Shouldn’t the steel CEO be the best one at this game? Executives use consultants mostly to shift blame. If it works, I did it! If it fails, the consultant failed! This is far from my business ethic. You should use consultants when you need to grow into areas you don’t know yet. Or for temporary projects like M&As with temporary knowledge. But how to best cook and sell steel?

To put it in the words of Jerry Seinfeld:

Seinfeld on consultants

https://hbr.org/2017/01/lifes-work-jerry-seinfeld

Exceptions to YAGNI

This a good list on an important topic. You are not going to need it until you need it. One of the difficulties for software developers is to anticipate the future. Assume you need to write software to draw a triangle, then a square, and three months later an octagon, and you anticipate the future and write code to draw arbitrary n-corner shapes. Then the customer wants a rectangle. Future wrongly anticipated and your code optimized for a future that did not materialize. But some things are better to prepare for, as they are hard to change later (also my point to coachees: A tech strategy can only work in alignment with a long-term 2+ years business strategy).

https://lukeplant.me.uk/blog/posts/yagni-exceptions/

šŸ†š Product v [editor: vs.?] Engineering

I make many of these points, E.g. ā€œFinger pointing across functionsā€ for a decade, and argue against the ā€œvsā€ of Product and Engineering. You’re a CTO? Own product! Now Martin Fowler says this (not the ā€œOwn productā€ part). I thought I was avant-garde. But he’s not yet completely there, so I’m still ahead.

https://martinfowler.com/articles/bottlenecks-of-scaleups/03-product-v-engineering.html

Photoshop for text

The article has a great idea: Photoshop has a dozen tools to manipulate your images, contrast, saturation, or sharpness. Text editors can’t do any of that. Great ideas are those that are obvious in retrospect. What amount of time does your department set aside for thinking about game-changing ideas, dear CTO?

https://stephanango.com/photoshop-for-text

Technology Choices For My SaaS In Retrospect

Radical simplicity. In F# this time.

https://thomasbandt.com/technology-choices-in-retrospect

How boring should your team’s codebases be

Very boring is my point. Fun and challenge should come from deep features and novel data structures, not from challenging code bases. This article makes some observations on what is boring.

https://blog.meadsteve.dev/team-work/2022/10/13/how-boring-should-your-teams-codebases-be/

Building a resilient system: Our journey to observability at Intercom

I recently wrote about how self-healing code saves the CTO time so this was interesting. The article is a deep dive into migrating from ops metrics to tracing for better insights and coming with that better reliability.

https://www.intercom.com/blog/engineering-observability/

Should I create a Performance Improvement Plan for my direct report?

Ah, the dreaded PIP. One of the core tools at eBay for ā€œunder-performingā€ people. I wasn’t a fan of PIPs, they always seemed to be too-little-too-late, and seemed like I had screwed up as a manager before. But even for me, the article had some good points and ideas on how to deal with this - for everyone - a bad situation and make it better. If you struggle - currently! - with an underperforming direct report, there might be some help for both of you.

https://larahogan.me/blog/performance-improvement-plans/

🚩 When Is Short Tenure a Red Flag?

I’m not hiring job hoppers. They are just not worth it (mostly, there might be exceptions if you’re in a crisis and need help and expert knowledge ASAP). They need 3+ months to get productive and in the last 3 months they focus on interviewing and their new job. So from 12 months at most, you get 6 productive months. I’m not hiring job hoppers. This article though goes into more good detail like ā€œUnder 1 year should be considered ā€œshortā€ [agree!]. 2-3 years is normal and shouldn’t be considered ā€œshortā€, except for very senior leadership roles – more on that below.ā€

https://jacobian.org/2022/oct/14/when-is-short-tenure-a-red-flag/

Why we’re moving away from Firebase

I thought I put in a technical article to not be to meta (Not Meta!). As I see several marketing departments pressure technology to adopt Firebase because of GA4, I’ve chosen that one.

https://koptional.com/article/why-we%E2%80%99re-moving-away-from-firebase

You should not be using AWS. Probably.

I fear this becomes an anti-cloud newsletter, WHICH IT ISN’T! But this was too good to not include.

https://www.karlsutt.com/articles/you-should-not-be-using-aws/

Join the CTO newsletter!
Impressum