Graph of the week
A guide for finding product-market fit (8 minute read) BOING! Killer chart in Lennys Newsletter. The biggest mistake I see in startups: They donāt work hard enough to find their product market fit (PMF). Most of them skip it and suffer. Wishful thinking leads to scaling before they have PMF. Then churn is high, marketing money is wasted, like pouring water into a bucket with a big hole, and the end of the runway is approaching fast. It took Slack 5 years to arrive at āFelt PMF.ā Print that chart and pin it to your monitor. Plan accordingly and work hard on PMF. PMF is the most crucial thing to get right as a startup. https://www.lennysnewsletter.com/p/finding-product-market-fit If you only read one thingStrategy for Startups (15 minute read) The second-biggest problem I see in startups (after not working hard enough on PMF - see above) is they lack a strategy (and vision). They are opportunistic and take the money they get from whomever wants to give someāand often are customer-driven instead of vision driven. This leads to many problems, mostly to too many features that no one uses and a hard to maintain software core for developers. And zig zagging. And unhappiness. None of the great tech success stories are customer driven, because customers donāt know what they need, they only know what they want. If you have no strategy, youāre screwed. Start with a business strategy (take part in this as CTO, youāre an executive, āIām a doctor, not an engineer, Jim!ā is not an excuse) then formulate a tech strategy. The article is an exceptional starter. https://rogermartin.medium.com/strategy-for-startups-9ed093de5d6a
Stories Iāve enjoyed this weekMy solopreneur story: zero to $45K/mo in 2 years (10 minute read) Article with lots of good points on how to make it as a solopreneur. Why is this relevant for CTOs? I still think we have not capitalized on the gaining in productivity in tech over the last two decades. When I had a VC-funded startup in 1999, everything was hard. Hosting (no cloud), tools (Java only! No Rails or Lavarel), performance, software (no production ready open source software for every problem), hardware (your DB can vertically scale to millions of customers), marketing (no Hubspot, no Mailchimp, we had to send our mails from our IPs!), sales. We have made huge progress in productivity since thenābut looking at startups now they donāt seem to have superpowers. They just look like startups in 1999. My guess is we dropped all productivity gains into things like React and Scrum - so productivity stayed the same overall. Solopreneurs are the ones who show where productivity is. https://news.tonydinh.com/p/my-solopreneur-story-zero-to-45kmo How-to Evaluate a Product Roadmap, for Engineers (13 minute read) What an article. To be happier and have an impact, developers need to get out of their ātell me what to codeā habit. So, yes! "[ā¦] at the end of the day, the most important thing is simply to engage with your product leader and the roadmap. Ask questions. Share ideas. Make suggestions." And then there are 9 good detailed points on how to evaluate a product roadmap. https://stephen.fm/how-to-evaluate-a-product-roadmap/ How to Begin to Shape Up (10 minute read) Shape up is the next thing. Talked to some people who use it, they never want to go back to Scrumban. More about this in the future. How Pinterest scaled to 11 million users with only 6 engineers (8 minute read) They kept it simple. No, they had it complicated, run into problems, simplified, simplified, simplified and scaled. Also, no microservices. https://read.engineerscodex.com/p/how-pinterest-scaled-to-11-million Linear code is more readable (4 minute read) Weāre developers by heart, so letās talk about code. This is a difficult one. Should you use longer methods where you can understand the complete flow or shorter methods with one abstraction level? I guess it depends, but more often than not, Iāve seen methods that are too short and hard to understand what is happening. The article is an interesting talking point for your developers (Recently I gave a workshop on how to be a senior developer, because too many startups are too junior and urgently need to speed up seniority. This was one of the topics) Iād say I would write a version in between these two. One that captures all the flow but keeps one semantic level. https://blog.separateconcerns.com/2023-09-11-linear-code.html The joys of maintenance programming (10 minute read) Some ideas about how maintenance programming is greatāespecially for junior developersālike āYouāll learn how to debugā and āYouāll learn how to program better.ā Maintenance coding is often seen as punishment, the cool people work on the shiny new things. Give this to your developers. There is fame in maintenance programming. It also seems to fit nicely into Shape Up. Talked to one CTO, they switch teams between maintenance coding and shape up feature development for more productivity. https://typicalprogrammer.com/the-joys-of-maintenance-programming Our cloud exit has already yielded $1m/year in savings (12 minute read) More and more companies exit the cloud. I think the cloud is real good for small companies because it is so cheap to start. Then you grow, and it gets costlyāand CEOs are mystified by a growing 10x OPS budget. There is a point where you can save a lot of money leaving the cloud. Later again, when you make hundreds of millions of $, there is a point to go back to the cloud. And remember: Cloud costs are not in compute but egress/ingress traffic. But if you need to safe money now, read the article. https://world.hey.com/dhh/our-cloud-exit-has-already-yielded-1m-year-in-savings-db358dea Bounties Damage Open Source Projects (2 minute read) Interesting take on paying by bounty for features (you pay some $ to someone who writes the code for a defined feature with defined tests) instead of paying developers or freelancers. Zig thinks this is bad. I think this is the future. BUT still, good points. https://ziglang.org/news/bounties-damage-open-source-projects/ Death by a thousand microservices (17 minute read) You know my stand. Microservices are good if you know what you are doing. Microservices are good if you need them. Most people donāt need them and donāt know what they are doing. āThere is a stigma attached to not starting out with microservices on day oneāno matter the problem. āEveryone is doing microservices, yet we have a single Django monolith maintained by just a few engineers, and a MySQL instance - what are we doing wrong?ā The answer is almost always ānothingā.ā Microservices are for scaling developers, not for scaling customers. https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html How I CEO: On taking advice as a leader (9 minute read) For CEOs, but mostly everything applies to CTOs. Too many CTOs try to battle it out on their own. Instead, they should ask for advice. https://mercury.com/blog/inside-mercury/how-i-ceo-taking-advice-as-leader The Le Guin precepts (4 minute read) Last not leased some ethics. āFabled author Ursula Le Guin had a sign over her desk: 1. Is it true? 2. Is it necessary or at least useful? 3. Is it compassionate or at least unharmful?ā We need more ethics in engineering. Really! āMy CEO made me do itā is not an excuse. Also, Le Guin wrote my all-time favorite book, āThe Dispossessedā. Thanks Ursula. Join the CTO newsletter! | |
