PracticeToLead

  People are undeniably more than just two dimensions. While the traditional 9-box grid measures Productivity (important for any organization) and Potential (a clear win for the organization), it often misses crucial nuances. What if that potential isn't aligned with what the organization can offer? What if a highly productive individual doesn't align with the company's core values? As a basketball fan, I've always appreciated the comprehensive scouting reports on sites like www.nbadraft.net . They provide a clear, multi-faceted picture of a player's capabilities through a detailed scorecard. It's all about individual attributes, not just fitting into a simple box. Look at an example: When it comes to performance reviews, we often simplify complex realities. Yet, career ladders, which can lead to promotions or performance improvement plans (PIPs), are inherently multi-dimensional. Even with continuous feedback, it's challenging to navigate so many categor...

  What Are Impediments in Agile? In Agile, impediments are anything that slows down or blocks a team's productivity—and ultimately affects product delivery. Agile or not, impediments are a daily reality. At PracticeToLead , we interviewed several engineering leaders who echoed the same concern: current Scrum/Agile tools don't offer a solid way to track and escalate impediments. Really? So What? Yes. If you search for solutions, the best advice you'll find is “create a separate Jira project to track them.”. Even though tools like Rally Software has a feature specifically for this. BUT Jira owns ⅔ of the market. Most organizations either: Leave it to Scrum/Agile teams to handle impediments themselves (generally the right default), and/or Rely on managers to escalate the serious ones ad hoc. But this creates real problems: Delayed visibility: Stakeholders don’t hear about risks until it’s too late. The team has likely been struggling for a while by then. No institutional memo...

(NOTE: This was written by ChatGPT) In the last few weeks, I heard detailed stories of how engineers spun up a site, or a tool, in no time or effort using tools like Copilot, Cursor, and LangGraph.. What used to take a day or two of setup, scaffolding, and hand-rolled edge case handling? Done in an hour. I wasn’t surprised. This is the new normal. And I love it. But it got me thinking—not about the end of software engineer(ing) (that story’s already been oversold), but about the role of the engineering lead who loves to tinker, who loves to hack things nights and weekends. Because let’s be real—generative AI is amazing at building MVPs, automating tedious boilerplate, debugging obscure issues, and even spinning up design patterns we once considered “architectural decisions.” It’s like pair programming with someone who read every GitHub repo and Stack Overflow answer—ever. If you’re an IC, it’s the best assistant you’ve ever had. If you’re a tech lead who thrives by jumping in, proto...

This is the first podcast episode I’ve listened to twice, and each time, I felt really torn, both during and after. For context, in case you don’t want to listen to the podcast: Niall Ferguson believes that sometimes you need a bit of harshness to be more effective—he argues that being feared is crucial. On the other hand, Adam Grant takes the opposite view, saying that he has never needed to create fear to be successful or effective. As a fan of Adam Grant’s, I find it hard to disagree with his perspective, but at the same time, I feel that fear is a major motivator for people. If you look at the political landscape both historically and today, many leaders reached their positions by generating fear and ruling through it—even in the most democratic regimes. Fear of Nazis, Communists, Islam, the West, the East… it's everywhere. However, I also don’t believe that using fear as a weapon is the right approach. If your people are walking around afraid of you, they’re not operating at t...

Leaders often grapple with the challenge of finding the right balance between micromanaging and giving their teams the freedom to learn from their mistakes. Early on, my own approach involved identifying risks, discussing mitigation strategies, and, when things went wrong, issuing the dreaded “I told you so.” Over time, I’ve learned the importance of fine-tuning my communication to make it constructive throughout the process, but it’s still a delicate balance. This dynamic is very similar to parenting. As parents, we frequently find it easier to set boundaries for our kids than for our team members. At home, things feel more straightforward—if you drop a plate, it breaks; if you touch something hot, you get burned. Consequences are often immediate and clear-cut. The longest delay might be failing a test due to a lack of studying, but even then, it’s a direct and teachable moment. When my oldest child, who has always been interested in cars, started practicing for their driver’s test, t...

For years, I’ve stuck to a simple mantra when my teams embark on something new: “Don’t name it.” The underlying premise was clear: Naming a process (the most common case for me) could lead to rigid adherence to prescriptive procedures. Whether it was about Scrum, Kanban, or Agile, I believed that empowering teams with values and encouraging creativity would yield better results. After all, a process crafted by the team, for the team, tends to be better understood and more readily adopted. Recently, though, I had a moment of reflection. While listening to the “ Founder & CEO ” podcast, Mike and Patrick emphasized the importance of defining the market and achieving market fit. I found myself completely agreeing with them, and It struck me: Why was I open to labeling and segmenting the market for a company, yet resistant to naming the processes I wanted my teams to follow? After some introspection, I arrived at a convincing answer. Here’s my perspective: Define a Label: When you’re ...