Are your devs polyworkers? + How to REALLY scale
Stephan ?? Schmidt
Building Inkmi only for CTOs ? #1 book "Amazing CTO" ? CTO Coach ? Keynote Speaker ? ex-eBay ? ex-ImmoScout ? Helping CTOs accelerate
???'Shape Up' is great for remote development
by Stephan Schmidt
Happy ?? Sunday,
This week, singing?“?????? 99 Luftballons”?- Welcome to the 99th edition of my opinionated newsletter. This week’s insights include:
Good reading, have a nice Sunday ?? and a great week,
Stephan CTO-Coach and CTO-veteran
Need support as an engineering manager? Thought about?coaching??Let's talk—I helped many CTOs and engineering leaders with growth and making the right decisions under pressure, I can help you too.
??
If you only read one thing
The most important article for some time.?“In principle terms, you should prioritise shipping the most important thing as fast as possible over optimising the total number of features shipped.”?Oh, what simple sentences, oh how hard it is to follow. I call the second watering can principle. Everyone gets a little bit of the watering and no one is happy. Prioritising the most important thing means saying no to many other things. And weak CEOs and CTOs are not very good at saying no. So they prioritise wrong: A, then B, then C, instead of only A, nothing else. So we end up with the need to optimise the total number of features shipped instead of shipping the most important thing. Many other great nuggets in the article.?“We should all make decisions faster.”?YES!?Don’t take three months to decide what to build, then be unhappy if it can be build in a week. Decide faster! How decide what to build??Have a long term vision, and then make incremental progress towards that vision."?- most founders confuse their idea for the startup with a vision, it’s not. And then they don’t have a vision, and again we don’t know what to build, so we build the stuff from people who shout the loudest or cook OKRs best. Plus?“Determine the ideal first, ignoring all constraints such as money or time”. I often tell people, if you had a genie in a lamp, would your customers really ask for this? Wouldn’t they ask for something different? This is what your customers want. Try to make it happen. And finally?“If you can optimise revenue without building new features, you should do that”?I see startups left and right that have bad sales departments that can only sell things with new features - free software development - or with features customers demanded. Make money without new features! Don’t “sell” free software development.
??
Stories I’ve enjoyed this week
There has been a lot of talk about “Agile is dead” for years now. But nothing new has materialized. Perhaps Scrum is good enough. Perhaps there is nothing better. Personally I do think “Shape Up” is the better process. This excellent article argues it’s a better fit for Remote. Should I ever start as a CTO again, I’d choose?Shape Up?not Scrumban.
“Recently, OSS-Fuzz reported 26 new vulnerabilities to open source project maintainers, […] each was found with AI, using AI-generated and enhanced fuzz targets.”?I personally have high hopes on AI finding and fixing bugs. I started a small?Github project?to compare AI IDE abilities. One of them is to find bugs. I do believe, AIs will be able to find and fix most of the bugs in your codebase, drawing requirements in from their deep knowledge and not just your company.
Haven’t heard of polyworking? Polyworking is just a nice term for having two jobs. Some years ago I encountered people in our startup that had two full paying jobs. We had to let them go. I wonder how many more people in the age of remote have two jobs - or are “polyworkers”.?“How Companies Benefit From Polyworking”?not so sure about that one.
“The second issue is that no one really learns by watching. They learn by doing”?Don’t tell, let people learn by doing and help them along. One of the big problems with delegation, people do not invest enough time to delegate. For them delegation is throwing something over the fence and then being unhappy what comes back.?“At the end of the day, I hired these engineers believing in their promise, it’s high time I trust them to do their job.”?Indeed. Companies claiming to hire the best and then not trusting them to do their job. Are you one of those people? I hope not. Probably not as you read this newsletter ;-)
Some good points in there.?“It’s particularly dangerous, if a smart person gave you the requirements, because you might not question them enough.”?The five steps are:
There are many studies that show that knowledge worker productivity peaks at ~35 hours per week. If they are forced to work much more, productivity will drop the following weeks. Still, startup founders and tech giants push for longer working hours. Yes, if you only sit in meetings and had no creative thought for the last decade, 80 hour work weeks are no problem. If you need to write creative code and not make bugs along the way, like type a long novel without a typo, 35 hours is the limit. When I worked much more, half of the time I had to fix bugs I did create the previous day.?“Weekends were a mistake”?said the Pharaoh.
The argument in the article against best practices is that you need the context and a judgement. And I would agree.?"“Don’t use globals” is obviously good, but “never use globals under any circumstances” is just silly."?Judgement is what you pay the senior developer for, not for applying best practices. Which brings us to AI. The problem with AI today (will go away) is that you need to understand the results and judge them. If you’re a senior, great. If you’re a junior, it’s like best practices, you follow the AI because you have no handle to make a judgement. I’m for standards, in the way they reduce the things that are open for discussion at all time (the reason why we have processes). But too many organizations I have seen no longer know why they follow some process or follow some “best practice”. With turnover in your startup, I’d bet half of your developers don’t know the reason why things are done the way they are done. Explain more.
So there researchers work on LLMs with 1bit quantization on CPU that are faster, use less memory and are more energy efficient. No longer is the world going to end because of AI energy consumption it seems. When you want to predict the future of some technology, it needs to have stabilized first. LLMs haven’t. Otherwise, all bets are off. That’s why I like the philosopher Karl Popper. In his opinion the future can’t be predicted from the past, as new things are invented. Steve Jobs is famous for targeting a market several years in the future. Which is hard, LLMs haven’t stabilized yet. In Jobs days, the computer hasn’t stabilized, and he had the vision of everyone having one. That’s why you are a visionary. If you only think of the next quarter you are not. If you only see what everyone sees, you’re not. Today startups target a market that exists next quarter. And then wonder why they don’t become Apple. What tech are you targeting?
Decades ago there was this exiting technology in Java called?OSGi. It allowed you to hot swap code in production. But it never took off. Same here with Erlang. Both solve a problem, changing code in a mainframe while it is running that no longer existed with the rise of the internet and later the cloud. You just run dozens of servers and change their code one by one. It’s also cleaner and has no long term side effects. So while there is exiting technology, and I’m all for it, it often not useful. Developers though are drawn to it. Be careful.
“Researchers have long known that stress or trauma can lead people to fear harmless situations.”?Something I see with many CTOs. If things crash and burn, it’s their head that gets the beating. So they overreact and take fewer risks to the point of “No, no, no”. If you are aware of the psychology, you can work around it.
Sometimes we can learn from other industries. What is the Swiss cheese model of disasters? It’s from airplane security. When you have a slice of Swiss cheese, you can see through the holes. If you hold up two slices, probability goes down that you can look through. With a third slice probability goes down again. If there is a chance that something goes through one hole, there is less chance something goes through two slices - for that the holes would need to align. Every process, checklist, 4-eye principle, code review etc. is like a slice of Swiss cheese. The more you have, the less likely is something gets through the holes. Take inspiration from the airline industry on how to prevent disasters. Cheesy!
???FOR TECH GEEKS ONLY
You’re bored by all the off-the-shelf tech that is used by our developers? That’s not why you’re a tech geek? What I found most interesting over the last few years are?“Probabilistic Data Structures”?like Cuckoo Filters, Count-Min Sketch, Bloom Filters and the like. They enable you to store “Stephan has seen this article”. Well I can store this in a database you’d say! Yes, the difference: 1. Probabilistic data structures use less memory - you can store billions of facts in a small amount of memory. 2. They are privacy-friendly - while you can ask them “Has Stephan seen this article?” they can’t tell you which other articles Stephan has seen or give you a list of all people who have seen this article - privacy by design instead of privacy by law. And they are very, very cleverly done, which should pick the interest of the tech geek in you. They filled me with a sense of wonder.
The book to read is:?“Probabilistic Data Structures and Algorithms for Big Data Applications”?by Andrii Gakhov
Want the newsletter one day early? ?? Free to your Inbox every Sunday???https://ctone.ws
?
President @ R3 | Robust IT Infrastructures for Scaling Enterprises | Leading a $100M IT Revolution | Follow for Innovative IT Solutions ??
2 天前Awesome! Thanks for sharing Stephan!
Inkmi - The CTO Matchmaker
2 天前Shape up!
Tech & Product Leadership - Starting, Iterating, Fighting Bullshit. Subscribe to My Newsletter: v01.io
2 天前Amazing!
Building Inkmi only for CTOs ? #1 book "Amazing CTO" ? CTO Coach ? Keynote Speaker ? ex-eBay ? ex-ImmoScout ? Helping CTOs accelerate
2 天前What do you think about polyworking?