Paul Tevis 
Saying someone is a manager tells you little about what they do or where they spend their time. Different companies lay out these duties differently; managers within the same company (or department) sometimes have vastly different jobs. As a manager, having mismatched expectations about your role – particularly with your boss and peers – can have unfortunate results.
“One of the people I manage is underperforming. I need to give them feedback about how they aren’t meeting expectations.”
I hear this often from managers, and I get curious whenever I do. The instinct behind it is good: Managers need to address underperformance. In my experience, however, giving performance feedback about unmet expectations is unlikely to help if you haven’t done your homework first. One of my teachers says, “80% of employee problems are due to manager neglect.” Whether you are a manager or not, when someone isn’t meeting your expectations, start by looking at what you’re doing – and what you’re not.
Conflict is a challenging topic for many people to navigate. It’s a natural part of working together in groups, yet in the midst of it, it can feel terribly dysfunctional. There’s no shortage of ideas about how to work through it, and there are lots of tools available. The choice of what tool to use when can feel overwhelming. How do you know where to get started? One of my to-go methods for engaging with conflict is the Waterline Model.
“We don’t have time for a retrospective. We have ‘real work’ to do.”
How many times have you heard this? It comes up frequently in the classes I teach, I’ve heard it more times than I care to count. It frustrates me, and yet, I understand where it comes from. This issue isn’t limited to retrospectives. One of the challenges that managers, coaches, and consultants face is helping groups and teams to effectively balance productive work with work that builds and sustains their productivity. The key to that is understanding that working on the group’s functioning is also real work.
Some of my most spectacular failures working with teams have come from going deeper than I needed to. One particularly memorable retrospective ended with a product manager declaring, “I’m done talking about my feelings.” (It was not my finest moment.) Yes, organizations are made of people. And yes, work happens inside a container of relationships. But that doesn’t mean every attempt to address a team or organizational problem must be super deep. Choosing the depth at which to intervene is critical for every manager, consultant, and coach.
“I don’t understand products vs. projects. What’s the difference?”
When I share some of my stories about working with product development teams, some people look at me as if I’m describing the impossible. They seem confused when I tell them about agile teams that didn’t have to provide story point estimates to management or normalize points across teams. What I’m talking about is so far outside of their experience, they can’t conceive of how it could work. One of the most challenging things for me to explain to people who haven’t experienced both is the difference between project- and product-based organizations.
The most common question on any project is, “How long with this take?” This question isn’t too difficult to answer when the work is small – a few minutes to a few days. Problems start when someone wants an estimate for a chunk of work you can’t complete in just a few days. Requests for estimates like this come from a need to make higher-level planning decisions. But estimates aren’t the only way to make these decisions. Over the last fifteen years of working with agile teams, I’ve seen value in exploring estimation alternatives. Two, in particular, come to mind, the first of which I’ll describe here: Shifting conversations about estimating to budget discussions.
“I can tell this is hard for you all to hear. I know it’s harder for some of you than others. It’s not my first choice, either. However, it makes enough sense, and it’s the direction we’re going now. We’ll take some time to work through how we feel about this. Then we need to figure out how to start making this change.”
Those weren’t exactly the words the Director of Engineering used to communicate the change in our team’s priorities, but they are close. It was certainly the message that those of us in the room heard when he told us about the abrupt shift in the direction we were about to make. This potentially disruptive change was one of my first experiences with communicating change effectively and humanely. Because of how the director held himself and the team during the ensuing conversation, what could have been an absolute mess turned into a surprisingly positive experience.
“I don’t want to distract the team. They don’t need to worry about this.” That’s what my boss – the head of engineering at a rapidly growing startup – told me when I asked him how he would share information from top management about our revised expansion plans. His job, he said, was to protect the engineers from things like this and to let them focus on building the product.
“What’s the secret to backlog refinement?”
Eighteen pairs of eyes turned to look at me, waiting for my answer to this product manager’s question. I’d spent the last two days with the group working through the challenges they faced using Scrum in their company. We discovered that most of their delivery problems stemmed from the teams not understanding what was needed. They’d identified with the story I’d told about the team that hated Sprint Planning and hit the reset button on their process. They knew they weren’t doing refinement and could see the effect. They wanted to know how to make it work for them.