When and how do you surface a concern to your team? We all observe risks, constraints, or areas for feedback on a daily basis: an estimate that the developers feel is unrealistic, a consensus that’s gathering momentum without a team agreement, or a process that’s become more of a hindrance than a help. But in that space between seeing a problem and raising the concern, most of us feel a pull toward silence. We’d rather not risk the tension of a hard conversation.
In my career, there have been times when I’ve avoided those difficult conversations. There have also been times when I’ve been overly eager to tackle them. But what I’m trying to learn is that calibrating the conversation is more important than simply having or not having it. Who do you have the conversation with? When? In what setting? What’s the tone? How severely do you need to portray the situation?
Here are three anecdotes that come to mind for me. As far as I can tell, I got one wrong, I got one right, and the jury’s still out on the third.
Speaking Up About an Estimate
My first consulting experience was a rewrite of a large app. By the time I joined the team, an estimate had already been presented to the client.
As I onboarded, I remember thinking, “This is intense. I’m not sure that it’s realistic.” My tech lead felt the same way. But as far as I can recall, neither of us ever called out our concerns to the project lead in a way that communicated their severity. We may have shared some tentative feelings, but we hedged them: “It’ll be tight, but maybe we can pull it off.” As a result, nothing registered as, “This estimate needs to be reworked and escalated,” and the original estimate was never changed.
We ran out of time and had to shift an important milestone, which caused some pain at the account level. At the end of the year, when performance reviews came around, my manager called out this situation as a key area for improvement in the future.
I wasn’t completely silent, but I wasn’t loud enough either. I was honest with myself, but not with my project lead (at least, not at the volume that mattered). Each hedged statement compounded on the one that came before, with the result that our stakeholders never internalized the risk, to the detriment of the project.
Naming a Negative Team Dynamic
I was joining a new team and noticed some strained interpersonal dynamics. I also started picking up on some behaviors that reflected the relational strain, especially signals that not everyone felt comfortable communicating frankly with their teammates.
This was a really sticky situation. I didn’t know at first how to broach the subject with the team. I had to sit on it for a while, but eventually I decided to name the situation in retrospect. It was a bit risky to bring it up to the whole team at once, and we had to work through some real nuance in the conversation, but it was ultimately well received. I think my teammates appreciated that we used the time we dedicate for retro to tackle a difficult topic, even if it wasn’t easy.
Sharing Reservations When the Team Has Momentum
My team was considering a change to part of our development process. To explore the options, we ran an experiment where pairs of devs tried out different tools and approaches on the same problem, reconvening to compare findings.
I was out of the office on the day of the meeting where the team shared their findings from the experiment. When I got back, the momentum from the team was heading toward adopting an off-the-shelf framework. The specific framework in question is mature and not a bad choice for some contexts, but given the size of our team and the solid software development lifecycle we already have in place, I thought the off-the-shelf option would prove too constraining.
The first thing I did was bring my thoughts to the team leads. I knew that team buy-in was important, but I wanted to make sure my feelings weren’t off base before making it a wider conversation. Then, in a meeting we had already scheduled to follow up on the experiment, I brought my own findings to the team. I didn’t present my thoughts combatively or set them against my teammates’ preferences. We were able to have an open conversation where we normed around a decision that fit our team’s process and working style.
I’ll admit that I argued my position passionately, and I do wonder whether the better argument won or just the more insistent one. That’s the direction I tend to err in when I do decide to speak up. It’s something I’ll try to keep in mind for next time.
Keep Calibrating
I don’t have a formula for any of this, and I’m not sure one exists. But when I feel that pull toward silence now, I try to turn it into the calibration questions instead: who needs to hear this first, in what setting, and at what volume? I’ll probably keep getting the calibration wrong in one direction or the other. Still, in my experience, the recoverable mistakes are the ones where you raised the concern imperfectly instead of burying it.