Over the past few months, I’ve been developing a new muscle—one I had never consciously exercised before. In fact, I didn’t even realize it was worth strengthening. But the more I thought about it, the more sense it made. And after reading this, I believe you’ll start to see the benefits of strategically activating it as well. Chances are, many of you already use this muscle without realizing it. We’ve all heard the saying, “Patience is a virtue.”  Every time someone says it, people instinctively nod in agreement. It’s treated as an unquestioned truth. I’ve never heard an argument against it, and I won’t make one now—because I, too, believe patience has its place. But what about impatience? If patience is a virtue, does that make impatience a flaw? Is it something we should always suppress and replace with patience? That’s what I used to believe. But I’ve started to see impatience in a new light—as a force that, when used intentionally, can drive action, spark change, and fuel growth. I’ve been channeling impatience into my personal and professional development. I want to learn, experiment, and grow quickly, not slowly . While I remain patient with results, I refuse to be patient about taking action. I no longer see impatience as a weakness—it’s a tool I can hone to get things done. For too long, I blindly accepted that patience was always the right answer. But now, I’m learning to embrace the other side of the coin. Each has its drawbacks, and wisdom comes from knowing when  to lean into which. So, instead of suppressing your impatience, try harnessing it. Let it push you forward. Let it get you where you want to go— faster.

A product owner has more responsibilities today than at any point in the last ten years as more companies are consolidating the responsibilities of the project manager and scrum master into the product owner role. Ten years ago, it was common for each development team to have a dedicated scrum master, project manager, and product owner as distinct team members. Today, however, it is more common for development teams to be staffed with just the product owner. It would be interesting to discuss how and why we arrived at this point, but the more important question is: Are you, as a product owner, equipped to thrive in today’s environment? It is essential to stress that if you want to be a successful product owner today, whether at a startup or a top-tier investment bank, you need to be competent as a product owner, project manager, and scrum master. While we all can agree that each of these roles adds value to the team in different ways, what tends to go unnoticed is the stress and frustration that builds up within the team when there is an imbalance in these skill sets. Let’s explore this imbalance further. First, let’s summarize the high-level responsibilities of each of these three roles: The scrum master focuses on promoting continuous improvement around team dynamics and processes. The project manager’s attention is on managing risks and delivery timelines. The product owner stewards the priorities and product strategy. Now, let’s take a quick look at a couple of real-world examples of what can occur when there is an imbalance in just one of these skill sets: I have seen senior product owners explain that the poor team dynamics were simply a reality of the working environment due to the personalities on the team. After stepping into the situation, I quickly observed that the resentment among certain team members was due to their lack of input on the proposed solutions. It never occurred to this product owner that the poor team dynamics were actually a result of how the agile ceremonies were being run and how team members were allowed to participate. Within a few weeks, we made some tweaks to the meetings to allow others to share their opinions, which increased team morale. I have seen a senior product owner be unaware that they were not going to hit their milestones based on how they were tracking project progress. This product owner failed to create a mitigation plan to get the project back on track until it was already apparent that the milestone would be missed, resulting in the project going over budget. These are just a couple of my experiences, and I am sure you can think back on your experiences and find examples of this imbalance occurring within the development teams you have been a part of. Regardless of whether we think it is fair or not that a product owner needs to be competent across all these skills, we can agree that this skill set is now necessary to excel in this role. Even if you are among the product owners that gets support from individual scrum masters or project managers be aware that this may not always be the case. By sharpening our skills across these three pillars, we can ensure that we, ourselves, can provide our development teams with the appropriate support and, more importantly, give ourselves the confidence to excel in our day-to-day tasks while securing our ability to lead teams now and in the future. If you would like to learn more about how to improve your skill-set in these areas please reach out or you can also follow my page to continue to learn more things on this topic.

Are you aware that some members of your team might be reluctant to ask for help? This reluctance affects both your top performers and those who are struggling, although it might surprise you to hear that top performers are included. Today, we'll focus on why even your best team members often hesitate to seek help. I recall a situation with an engineering lead managing a multi-million dollar project. A couple of team members mentioned that the lead had rewritten their code during the review process. The lead was very proud, telling me about staying up all night to complete this feature. At the next day's stand-up, the lead stood tall, as if they had saved day. This lead firmly believed in the "do-it-yourself" approach to ensure speed and quality. While this method initially seemed to produce good results, it eventually led to several problems. It created a dependency where team members relied solely on the lead to complete tasks. When the lead was unavailable, progress would come to a near halt. This model provided acceptable short-term returns but it created significant long-term challenges. Ultimately, this approach led to burnout for the lead, who ironically ended up complaining about the lack of support. Meanwhile, other team members that felt stifled in their growth left for new opportunities. Those who remained relied on the lead to carry the load. This is a common situation that plays out across industries. I have learned strategies that help you avoid this situation altogether as well as strategies that can help you course correct if you are in this situation. If you're interested in learning more about fostering a more collaborative and sustainable team dynamic, please reach out. If you found this insight helpful, please like and share, and I'll continue to provide more content.

Do you recall a time when a deadline slipped through your grasp? That sinking feeling of falling short of expectations, followed by the inevitable postmortem with your team? If this scenario sounds familiar, you may have encountered the culprit: "context switching." It's a term often thrown around when tasks pile up and focus scatters. But do you remember how you tackled this issue? When team members lament about context switching, it signals a belief that shifting focus between tasks eats away valuable time, ultimately contributing to missed deadlines. The instinctive response is to remove distractions, allowing for sustained focus on primary tasks. While this is a common remedy, could there be an alternative, perhaps a more beneficial one in the long run? I propose that teams and individuals stand to gain by reframing this challenge. Consider a day in the life of a lead developer: Providing technical leadership to the team Making architectural design decisions Supporting product and design with feedback on new features Assisting with project planning Making progress on a user story Conducting 1:1 meetings with direct reports Performing code reviews Troubleshooting issues and fixing defects Now, contrast that with a typical day for a junior developer: Making progress on a user story Conducting code reviews Addressing defects It's no surprise that senior team members shoulder more responsibilities than their junior counterparts. But how does this relate to context switching? How do high-performing senior team members manage to juggle multiple tasks without stretching the workday beyond its limits? In my view, mastering the art of context switching is key. Top performers at senior levels demonstrate an ability to pivot swiftly and excel in various tasks without dwelling on the past or worrying about the future. They channel their undivided attention into the present task, maximizing productivity and efficiency. I call this "working in the moment." By honing this skill, you not only boost your productivity but also accelerate your career trajectory. Your colleagues and supervisors will take note of your ability to handle diverse tasks adeptly, paving the way for more significant opportunities and rapid skill development. If you're eager to fast-track your career or enhance your work-life balance, let's connect and embark on a journey to elevate your productivity.

If you want to be a great product owner then one skill you must be great at is managing priorities and if you would like to learn how to become better at this then I invite you to play a quick game with me: Picture a moment when you worked with a team and the priorities were unclear, muddled, or constantly changing. As you do this, try to remember who you were with, the company you worked for, and what meeting you where in. Once you have this picture take a second and think about how it felt to be in that situation. I imagine you were able to feel the frustration, confusion, and stress that you, team members, or stakeholders often feel in this situation. Unfortunately this is a common experience that software development teams find themselves in more often than they would like. The good news is that as product owners we can keep those types of situations from ever occurring by being great at managing the team’s priorities by focusing the team on delivering work that delivers wins to the business. If you follow sports then you may be familiar with the phrase “winning cures all” which means that nothing helps lift the mood more and reduce the tension more in the organization than winning. Winning makes work more fun as objectives are met and when work is more fun we are more creative, more productive, and more pleasurable to be around. I think that as product owners we can greatly influence winning by being better at managing priorities because the priorities influence future outcomes. If you want to help yourself, your team, and your company win more then we need to be great at managing priorities. If you would like to continue to learn more then follow this simple guide or reach out to me to discover a more personalized approach to learn how to get better at this skill. Four easy steps to improve how you manage priorities: Write down your desired outcomes over a day, week, month, or any time period Rank order your outcomes Analyze your current behaviors and decisions as they pertain to your desired outcomes Repeat 1 - 3 Example: My outcome for today is to keep my body in shape, nourish it, rest it, and expand my professional network. I then ordered my outcomes in the following order. Play soccer Cook a healthy meal Get at least 8 hours of sleep Grow professional network Now let’s use this real-world example to see how this works: In the middle of the workday I am invited to join co-workers for happy hour and by going I get an extra opportunity to grow my professional network. Scenario A - Prior to setting my outcomes: Go to happy hour Consume multiple drinks Eat bar food which was often fried and unhealthy food Stay out late Go home Go to sleep late Outcome A: Spent entire evening building professional connections, but did not make any progress on other desired outcomes. Scenario B - After setting my outcomes: Go to happy hour and consume a non-alcoholic beverage Leave in time to play soccer Go home Cook a healthy meal Go to sleep early Outcome B: Was able to achieve all my main outcomes and while making some progress on growing my professional network. The differences between scenario A and B stem from being able to make intentional decisions that are aligned with my outcomes. I was better at this under scenario B than scenario A because I had very explicit outcomes to help me understand the implications of my decisions as it pertained to my desired outcomes. As a result my decision making has improved significantly because I now make more choices that are more aligned with my outcomes. This skill is critical as a product owner because we frequently have to make prioritization decisions and we need our decisions to yield great outcomes. Furthermore when we put our team in a position to produce great outcomes then we then help create an environment that is more fun, creative, and pleasurable for everyone involved because we yield more wins for everyone involved. If you would like to learn more please reach out or share this with anyone that you think can benefit from this.

Product owners are the liaisons between the business and the engineering team. They are responsible for distilling business needs into product requirements. In agile settings, the user story is often the medium that is used to communicate the requirements and acceptance criteria to the engineering team. In turn, the engineers consume the user stories to understand what they need to implement. Over the course of a project the engineers will consume a steady diet of these stories and like food or entertainment or anything else we consume, the cost and quality of what we consume has a significant impact on the satisfaction that we derive from it. As such like anything that we consume, user stories can also please or dissatisfy the consumer depending on the quality of the user story. In my experience one of the most common ways that the product owner begins to lose the trust of the team is by producing low quality user stories. A low quality user story can come in a variety of shapes and sizes. For example, it can be too vague or it can be too long and detailed. It can also be incomplete because it is missing certain scenarios or it may lack corresponding artifacts such as UX designs. Engineers that consume these types of stories will begin to become demotivated as they realize that they do not have the requisite information to fully understand the work that needs to be done. They then have to spend extra energy to figure out how to improve the content of the stories to get it to a point where they have appropriate information. Implementation that proceeds with low quality stories will inevitably lead to defects which will exacerbate the distaste with the user stories and the team’s product owner. On the flipside, a high quality user story is a delight to engineers because it makes it easy to digest and understand the work that needs to be done. This plays a large role in the overall satisfaction in the relationship between engineers and the product owners. As a result, I believe that producing high quality user stories is a key component of successful software development not just because it provides the engineering team with clear directions, but also because of the emotional impact it has on them as well. As a result, this has to be a core skill of every product owner or anyone that is producing stories. If you are interested in learning more about how to ensure that you or your team produce high quality stories please do not hesitate to reach out.

For quite some time I dealt with pain in my feet due to plantar fasciitis and it wasn’t until a few months ago that I finally fully recovered from this injury. The difference between the last few months and the prior time period was that I learned that the cause of my pain was not where I felt the pain, but rather due to tightness in my hamstrings. This was hard to believe because my hamstrings felt fine, but as I learned more about this particular injury it was plausible that this was the root of the issue. Armed with this new information, I began to incorporate daily hamstring stretches into my daily routine. Within a week I started to feel a slight improvement and after three months the pain has completely gone away. Before I knew that the issue lied with my hamstrings, I spent a lot of time targeting remedial solutions at the point of the pain. I would stretch my feet, massage them, and even bought sneakers with more padding thinking that this would help alleviate the pain. Unfortunately, in the long run there was little to no benefit from those efforts. In hindsight, I wish I had spent more time understanding the actual potential causes of this issue as it would have saved me time and money because I would have been able to implement better solutions from the moment I started experiencing discomfort. When I think about this injury and my path to recovery it is hard for me to ignore the parallels with this experience and the similar experiences that I have had as a product manager on software development teams. As such I want to share some flags that you can look out for that are strong indicators that your team is experiencing pain in one area, but most likely the issue lies elsewhere. Furthermore, I want to give you some tips on how to resolve those types of issues. The following issues usually indicate that the root of the problem often lies elsewhere: Unexpected consequences or reopened defects from feature or bug changes Flip-flopping of product requirements Unexpected consequences or reopened defects: Pain area: The team frequently experiences unexpected issues due to a new feature enhancement or a defect fix which then leads to fire fighting and additional development work. Actual problem area: In my experience the common culprit of this issue is lack of team understanding of how a portion of the work impacts the broader body of work. This gap in understanding leads to unexpected consequences when those portions are introduced to the system. Resolution: It is critical to bridge the gap of understanding among all team members from design, to engineering, to QA. Maintaining up to date user journey flows and architecture diagrams help provide visuals that allow one to understand the impact a change in one area can impact the other areas of the system. Reviewing these documents prior to beginning work on a feature helps ensure that the different paths of a solution are accounted for in design, implementation, and testing which then begins to reduce the frequency and impact of unintended issues as the team broadens their awareness of the whole system. Flip-flopping product requirements: Pain area: The same feature(s) keeps getting re-worked and progress on the other items stalls as the team keeps revisiting the same items. Actual problem area: In my experience this issue often lies between the stakeholders and product and design. When we produce solutions that are half-baked, meaning that those solutions do not fully meet the needs of the business then you are likely to find yourself re-working the same aspects of the application. Resolution: The best way to prevent this issue is to be rigorous with the solutions being presented to stakeholders during the design phase such that the feedback process elicits as many possible issues with the proposed solutions so that when it is time for implementation the proposed solution has undergone sufficient iterations to capture and resolve as many possible unknowns prior to implementation.

Early in my career I wondered why, at times, a team ends a standup with more unanswered questions about the progress in the given sprint than they started with. It confused me as to how the responses to the three simple standup questions could produce such ambiguity when they were designed to give us clarity on the progress. I could not shake the feeling that something was amiss even when stand-ups were run efficiently i.e. under 15 minutes, at the same time, and the same place. After working with many different teams and running over a thousand stand-ups I learned that there is a big difference between an efficient standup and an effective standup. An efficient standup goes through the motions expediently, but an effective standup provides the insight to make informed decisions as to what are the next best steps to take as a team. Imagine that you are in standup and one of your team members provide the following update “Yesterday I worked on my story, today I will continue on my story, no blockers” versus “Yesterday I worked on my story and discovered an issue with the application unrelated to my story that impacts the performance of the application. Today I will continue with my story and I also want to discuss the impact of this performance issue with the team to see if we should prioritize it or not.” The second version of the update shares useful information that allows the team to determine the best course of action. This form of communication keeps in mind the greater good of the team and allows the team to be more effective. Unfortunately, many teams have one or more team members that resort to the first type of update when they should be sharing a version of the second one. The good news is that these issues can be fixed when you help foster an environment that promotes healthy communication and collaboration. Helping your team address these issues will bring the team closer towards operating more effectively to get the most value out of standup. Finally, I strongly believe every team can achieve both efficiency and effectiveness at standup by diligently encouraging better communication and teamwork. Improvements in this area will not occur overnight, but they will occur when there is a persistence to become the high performing team that your team knows it is capable of becoming. On this journey your team will discover that they did not need to work any harder to meet their goals, instead they just needed to work smarter by working together. Common standup issues Here is a list of common issues that I have encountered that can arise during standup and possible actions to take to resolve them. Miscommunication Lack of a common language: A common form of miscommunication occurs when team members use different definitions to define their work. I have seen team members confuse each other when using a word like “done” to describe their status when they actually meant “dev complete.” These slight differences in word choices can alter the team’s expectations about the work to be done next. One common and effective way to address this issue is to align the sprint board’s swim-lanes with the team’s workflow. Unclear ownership: Miscommunication can occur when it is ambiguous who the owner of the task is. Work can slip through the cracks when owners are not explicitly assigned to it and when a team member is asked about a given task they may respond something along the lines of “I thought they were going to do it.” Be clear and rigorous in task assignment. I recommend tracking all tasks with whichever ticket tracking you are using like JIRA. Fear of sharing bad news: Sometimes team members fear sharing bad news because they think that it will reflect poorly on them or the team. This miscommunication occurs due to omission of the issue or when the issue is shared much later than it should be. This prevents the team from taking corrective action as soon as possible. It is imperative to not delve into the blame game and instead place that energy towards the problem at hand. When team members begin to share issues impacting the team in a timely manner you can positively reinforce this positive behavior by recognizing the team members that share the issue that they observed and praising them for bringing it to the team’s attention. Lack of Teamwork Prioritizing individual priorities over team priorities: Team members that prioritize their individual tasks at the expense of the team’s priorities means that the optimal value to the customer is not being delivered. The value to the customer should always be the first priority and the team needs to prioritize that over their own tasks. Team members should feel comfortable to shift their tasks in order to maximize customer value. Raise issues that impact the team: Some team members are lazered focused on their individual tasks that they either do not recognize or forget to let the team know when they discover an issue that impacts the team. Consistently remind the team to put the team’s priorities over their individual tasks and continue to build this habit through positive reinforcement. Repetitive updates or ambiguous progress is often an issue of team members not seeking the help they need from others Rabbit holes: Team members can dig themselves into rabbit holes when team members attempt to figure out solutions to their own problems and continue to attempt to resolve the problem when they should be seeking help from the team. Sometimes a fresh pair of eyes offers a new perspective to the problem that yields a path forward to the solution. Figure out ways for your team to experience the benefits of receiving help and embed them into your team’s workflow. Delegation: Some team members have a tendency to take on a lot more work than they can do in a given sprint which increases the amount of stress those team members experience as the amount of work piles up. There are a number of benefits with delegation and one of the most important is that it makes the other team members feel valued as they are given important tasks. Extra tip: beware of frustration or annoyance in the tone of voice or the body language of your team members as these are other ways your team may be communicating symptoms of these issues. Finally, daily stand-ups are much better when we have fun and bring positive energy so bring a smile, have some fun, and try to make each other’s day just a little bit better than it was 15 minutes ago.