This week's insights
Good reading, have a nice Sunday ā¤ļø and a great week, Stephan
If you only read one thingLaunch and launch again ā how to launch your products (17 minute read) Many companies I look into, underutilize launches. They often look inside-out, being proud of shipping several times a day. Which is fine for engineering. But one needs to look outside-in, from the customer. What do they see, what do they use? The article is a deep dive, and I urge you to read it and adapt your launching (also, feature flags) and your product marketing. You can build the best things, if people donāt use them, why build them? The article proposes three launches:
https://harries.co/launch-your-product Stories Iāve enjoyed this weekCareer advice in 2025. (7 minute read) Insightful as always, āFirst, managers were generally evaluated in that period based on their ability to hire, retain and motivate teams. The current market doesnāt value those skills particularly highly, but instead prioritizes a different set of skills: working in the details, pushing pace, and navigating the technology transition to foundational modelsā As an engineering manager, you need to change your core skills - something I see as a CTO coach with my clients. I did lots of hiring workshops the last five years, this has dried up. We now talk more about strategy and how to tackle the AI transformation - especially with stubborn developers at hand. Still hope Will Larson writes a book āThe Art of Engineering Managementā like the āThe Art of Computer Programmingā - he is by far the most qualified to do so. https://lethain.com/career-advice-2025/ Synchronous Work, Asynchronous Work (16 minute read) A deeper look at WFO vs RTO framed as async vs. sync. āSync and async are not binary, but a continuumā. I personally believe many companies have not solved the async vs. sync work, so they are going to fail WFO/RTO. As CTO I once at a company had to ban all phones on desks because developers were interrupted all the time - but the company didnāt want to take them back, so we unplugged all phones and put them in a drawer. Async work takes a lot of discipline. Once I āhadā an excellent engineer, whose input I valued a lot. But he was only reading emails three times a day, before standup, after lunch and 15 minutes before leaving. It took a lot of learning and discipline on my part to not expect an answer to all my questions ASAP. First solve async vs. sync, have a discussion (what to expect from Slack!), a culture document, then solve WFO/RTO. https://blogs.newardassociates.com/blog/2025/sync-and-async.html Breaking Up with On-Call (11 minute read) The article goes well beyond on-call. Interesting insights into corp world āIf I could define my experience in big tech companies with one word, I would choose the word friction. Filing for a new feature implementation would require a thorough documentation, rightfully so, followed by a political campaign to convince the political party of principal engineers and managers to accept the new feature.ā or āThereās no incentive in big tech to write software with no bugs.ā and finally on the point āHowever you must nurture a culture of engineering where the on-call is the exception to the normā For all you CTOs and engineering managers out there, fix observability and on-call today. Thanks. https://reflector.dev/articles/breaking-up-with-on-call/ Why Iām No Longer Talking to Architects About Microservices (10 minute read)
Agreed. https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices In Praise of āNormalā Engineers (6 minute read) The 10x engineer is a meme, there are some exceptional engineers, here and there, and Iāve met some, but they are way too few to worry about. What I would worry about, from my hiring experience, is the 0.1x engineer. Who does not write tests, who does not learn, who does not take ownership, who does not feel responsible, who does not drive things. A 1x engineer who takes care of all of that is fine to me, I look out to weed out the 0.1x engineer, during hiring or in my department. https://spectrum.ieee.org/10x-engineer Working with systemd timers (10 minute read) Systemd is underrated. I love it, for keeping my servers running, restarting failed services. It sandboxes my servers so they canāt read or write data outside their directory, when being hacked. Many people hate it, but I find it very useful. The reason not more people use the astonishing capabilities of Systemd is Docker - and the reason for docker is the NPM and ENV nightmare of Javascript and Python. But letās not digress. This week Iāve learned how to schedule services with systemd timers. Excellent, another simplification of the things I already use. https://yieldcode.blog/post/working-with-systemd-timers/ Why DuckDB is my first choice for data processing (13 minute read) DuckDB is underrated. It is easy to build a data warehouse on DuckDB and S3, then aggregating and cleaning with #DBT into Postgres with a columnar store (like Timescale). If you have the money, BigQuery is easier. When I had millions in the bank, Iād go with BigQuery (Iāve seen $10k/month for small data setups), if I donāt have the money: S3, DuckDB, DBT, Postgres. https://www.robinlinacre.com/recommend_duckdb/ The World of Programming Will Change But(4 minute read) āAsking ChatGPT how to write a function is like looking at a tiny, isolated planet. Creating a software product means looking at the entire galaxy.ā If youāre asking ChatGPT today (or Claude Code) to write a function, youāre doing it wrong - at least for prototypes and MVPs. But even with Cursor and AI-assisted-Coding (AIAC) you probably should not ask for a function. Ask for a restructuring of the code. Ask for fixing all bugs. Ask to find security problems. Ask for an idea of a feature. Ask for an idea of a product. With AI you have to think bigger. https://www.andrealaforgia.com/the_world_of_programming_will_change_but/ Lego is starting to bring its game development in-house, key exec says (6 minute read) There are good and bad reasons for outsourcing. Money is a bad reason. Not having the necessary skills or wanting to start without months of hiring, good reason. Looks like Lego understands this now. Y Combinator urges the White House to support Europeās Digital Markets Act (15 minute read) Unpopular opinion - and yes the EU overregulates - most regulation like GDPR isnāt big of a deal, if you do not want to do things against your customers, like selling their data. Again, most people who are rallying against the AI act, havenāt read it. A lot of EU regulation is pro user, and therefore for customer. People rallying against it, essentially want to screw over their customers. Unpopular opinion, I know. But after 35 years with startups and tech companies, thatās what I think. Practical UX for startups surviving without a designer (18 minute read) Indeed, do you need a designer? Rather have another engineer. And if you do, this will help you. Companies have no understanding in which phase they are and what employees they need. Your UX is really your selling point, and tied into your sales and marketing and DNA? Get a designer. It isnāt but you want a nice app? Go for an engineer, youāre not going to need a designer. But many companies have no clue what their unique selling point (USP) is, or where their competitive advantage lies, and then randomly hire people. https://www.tibinotes.com/p/practical-ux-for-startups-surviving Join the CTO newsletter! | |
