In complex products involving multiple teams or vendors, troubleshooting often turns into a delicate dance. Everyone has their priorities. When something breaks, the first instinct is to react defensively and protect your domain. There were occasions where we asked a third party whether there was an issue on their end,

Have you ever had a plumber come to your house, take one look at the pipes, and say, “What on earth did the last guy do?” Software engineers often have the same reaction when looking at an unfamiliar codebase. And all too often, their next move is: “This needs a

Too often, I see founders outsourcing their software development to a freelancer or an agency—only to let them create infrastructure on their accounts. At the start, it seems convenient. But down the road, it can be a painful mistake. It doesn’t matter if you’re using AWS, Azure,

My default approach to meetings is to shield engineers from them. Engineers hate interruptions that break their flow. However, having engineers present in one type of meeting can save development time. In smaller teams I work with, we write feature passports with the client to keep meetings minimal. The idea

In my early years, I worked with some incredibly talented people. They introduced me to emerging concepts, such as unit testing, now considered best practices. Domain-Driven Design (DDD) was one of them, but I struggled. I remember finding it abstract and disconnected from the projects I was working on. What

You have a great product idea and decide to outsource its development. But how do you ensure your third-party team is doing a good job? And how can you set them up for success? Own Your Codebase and IP The first and most critical step is to own the product’

As a senior engineer, you play a critical role in mentoring and guiding junior engineers on your team. But how do you empower junior engineers effectively? Too often, senior engineers claim all the challenging, complex tasks for themselves while delegating only the more straightforward ones to junior developers. While this

I’ve heard this claim countless times, often on small teams lacking product management. Sales insist that just one more feature will make clients throw money at the product. Often, the technical team lacks the leverage to challenge this assumption or simply wants to build stuff. When the feature fails

The phrase “our team is like a family” has become a tired cliché in job posts. Too often, companies play the family card when things are going well, but when challenges arise—like financial losses—you’re suddenly a “cost center” that needs trimming. Sometimes, a company does feel like