Leadership

I am seeing a trend pushing more software engineers to move into more of a product engineering role. At its core, it is about owning more of the full product lifecycle including taking a bigger role in shaping the solution, not just building it. It is being framed as a new wave. I see it differently. This is a return to form. Early in my career, there was a sharp distinction drawn between a programmer and a software engineer or developer (developer is still used in Canada due to legal reasons). A programmer wrote code. An engineer designed, built and maintained systems. I always understood it as more than this simple definition. It was all about solving customers problems. ...

Most teams are using the wrong strategy to leverage the benefits of agentic AI in software development. The two most common strategies I see are: do the same thing we always did, but faster with AI, or cut the team because we can do the same thing with fewer people. Either of these may seem effective in the short term, but the best they can do is keep you on a flat trajectory. AI-native companies will use gains made to accelerate and overtake those that maintain the status quo. ...

Interviewing is like speed dating to determine who you will marry. There is very little time to develop any deep understanding from either party. Recently, I was interviewing candidates with a colleague who had previously worked with one of them. After the interview, my colleague remarked that they knew this person could have performed better. This is a story that I have seen play out many times. The truth is, interviews are a pretty poor way to really get to know someone, but they are the system we have today. So here is my advice for candidates and hiring managers. ...

Have you ever heard something like “How did they not know about X? I communicated it last week.” I often see leaders say they have communicated something with a team, but what they really mean is that they did some talking or maybe fired off an async chat message. Think about basic radio communications. You cannot simply turn on a radio, blast some message out into the ether and assume it was heard and understood. First, you would want to ensure that the other party was even present to receive a message. Then you would want an acknowledgement for the message you sent. A message sent without someone listening and understanding is useless. ...

When you are asked to take on a task that you do not feel is possible, your instinct might be to say “no” and explain why. A more effective approach is instead to shift from “No Because…” to “Yes and here is the impact of that.” I’ve spoken with some leaders who struggle with pushing back on things or feel like they are constantly pushing back on everything. You can even end up in situations where people feel that someone is not being a team player because of how they push back. It is possible to push back effectively but remain a team player simply by adjusting your communication. ...

I predict that in the next few years, we will see a huge wave of resignations in software companies. We are in a period where the opportunity cost of leaving a role is high. There are few postings in the job market, and there are many people who are looking for work. The consequence of this is that people who are interested in moving on are sticking around a lot longer than they otherwise would. ...

My formative years in tech were in the era of Slashdot and Linux becoming mainstream. Being a Microsoft hater (aka Micro$oft) was very popular at the time. Bill Gates was on the way out, handing the reins to Steve Ballmer and the company motto, at least externally, was Embrace, Extend and Extinguish. The company prioritized lock-in and leveraging their dominance, and open-source was not part of their culture. Satya Nadella’s era ushered in a new age for Microsoft. Microsoft embraced openness. In 2014, they released their office suite for iPad, a long-time product to lock people into the Windows ecosystem. They brought Linux to Windows as WSL (Windows Subsystem for Linux). ...

Startups are under a lot of pressure to deliver fast. This often necessitates the accumulation of technical debt. Many articles have been written on why it is essential to pay off technical debt. Fewer speak to circumstances for keeping debt or evaluate what areas of tech debt should be prioritized. In my experience, software developers often overvalue the benefits and impact of fixing tech debt issues. A developer might take a full day developing a script to save 30 minutes of a one-time repetitive and menial task. Another mistake developers often make is justifying tech debt based on an ideal outcome that may not be realistic. In an attempt to simplify the code or architecture, a developer may find that the “fixed” version is only marginally better and does not yield the full benefits. ...

I have noticed a trend that many brilliant people struggle to advocate for their ideas effectively. Often as engineering or product leaders, you need to propose a technical or product solution, recommend a vendor or make some sort of choice that you need buy-in from others. In all of these cases, the ability to “sell” your idea is critical. Here are the top 4 things you can do to take your pros and cons lists to the next level. ...

I was chatting with someone from a startup last year, where it is normal for team members to put in extra long hours (60+ hour weeks). The founder and CEO said, “I wish it wasn’t like this, but it is what we need to do right now.” I was a bit shocked by this. He knew it was not healthy but did not see any alternative. Marvin Let me tell you a story about Marvin (name changed). Marvin was the model employee. No matter what the deadline, Marvin always seemed to be able to make it. He worked long hours regularly to keep up this pace. We were working in a startup environment, so some overtime was expected. ...