The role of the CTO when a company enters “crisis mode”: what really changes Sooner or later, it happens. It doesn’t matter how solid the company is, how competent the team is, or how good the product may be. At some point, something stops working the way it should. A key client leaves. Margins start shrinking. The market shifts faster than expected. Or problems simply surface that had been hidden beneath the surface.

Why Teams Become Slow (and How to Unblock Them in Real Situations) It almost always happens the same way. At the beginning, the team is fast. Decisions come quickly. Features get shipped. Retrospectives are full of ideas. Then, slowly, something changes. Pull requests stay open longer. Decisions get postponed. Meetings become more frequent but less useful. And every task seems to take twice as long. The team hasn’t become less competent.

Incident Analysis: How to Turn a Disaster into a Team Accelerator Incidents don’t destroy teams. The way we react does. In complex systems — distributed software, cloud infrastructures, third-party integrations, high-volume logistics — incidents are not exceptions. They are structural variables. The difference between a mediocre team and a mature one is not the absence of problems. It is the quality of the response. Over the years, I’ve learned that an incident can become a cultural, technical, and organizational accelerator.

How to Manage Uncertainty When a Product Changes Direction Mid-Project Anyone who works on real products — not demos or proof of concepts — knows it: sooner or later, that moment comes. The market shifts. A strategic customer asks for something different. A core assumption turns out to be wrong. And the product, halfway through, changes direction. From a technical perspective, this is already complex. From a human perspective, it’s even more so.

Giving Technical Feedback Without Destroying Motivation and Autonomy In the technical world, feedback is a double-edged sword. It is essential to improve code quality, systems, and decision-making, but when delivered poorly it can destroy motivation, autonomy, and trust in a very short time. The paradox is that the most competent people are often the most fragile when it comes to feedback: their personal value is deeply intertwined with what they produce.

How I design an architecture to grow without rewriting everything after a year If you’ve worked in a startup, an SME, or a team that’s “always in emergency mode”, you already know how this goes: at the beginning you move fast. It works. You ship. You close tickets. Then after 6 months (sometimes 3) you realize every new feature costs double. After a year, every change feels like open-heart surgery.