You might be asking yourself, how could there be another post on the word “just”. I’ll spare you the definition, but suffice it to say that the word is doing a lot of heavy lifting in the English language. Whether an adjective or adverb, it has 6 definitions with an additional 6 subsections.

Some of the previous posts on the word include a 2015 Business Insider article about how women should stop using the word “just”, and an almost-immediate rebuttal days later. The former explained that “just” was often used as a way to seek permission. The latter effectively said: stop telling women how to speak and, by the way, the research doesn’t back up your anecdote.

What got me thinking about the word again was a tweet from John Cutler: “If we could just stop using the word just”. At first, I assumed he was trolling, and maybe he was, but seeing the replies agreeing with him got me thinking about my hang-up with the word. One of the replies linked to another blog post that talked about how the word can diminish the achievements of a person when used. For instance, a conversation might go like this:

• “Hey, great job on that presentation.” “Oh, that? I just took a deck I already had, changed the date, and tweaked a couple of slides. It wasn’t that big of a deal” or,
• “Wow. Thanks for doing that task.” “Oh, no problem. I just had to change two lines of code.”

In general, I agree with this observation. What I’d like to add is the problem found on the other side of just’s ability to diminish effort. Specifically, its impact on the other people on your team.

To start, it can set unclear expectations for the product or project manager (or anyone communicating with stakeholders). For instance, if you’re in a backlog grooming session or an urgent bug comes through and needs to get done. When someone speaks up, and it’s often a senior+ engineer, they might mention that the task shouldn’t be too hard.

“We just have to duplicate that one class and change a few things.”

Maybe they’re right - they could have extra context, or are leaning on their years of experience. It could also be plain hubris. Either way, they think it should be super easy and now the expectation has been set. The PM is going to relay that to the stakeholder, further cementing the sentiment.

You might be saying to yourself: But in a team with a healthy culture shouldn’t someone speak up if that doesn’t sound right? One problem here is that the PM/PjM/EM isn’t always incentivized to push back on the engineer. In fact, they might subconsciously hope it doesn’t take too much time and effort.

Another problem is that the rest of the team might not be comfortable speaking up. Even when the team is healthy, if a coworker isn’t sure what the ticket/task entails, it can be tough to question someone else’s estimate.

This leads us to the second issue with diminishing the effort associated with a task. Namely, the person doing the estimating isn’t always the person doing the work. Assuming nobody feels comfortable enough to speak up, and another engineer picks up the task when they have less context or experience, they might be in a tough spot. They now have to go to the PM/PjM/EM and explain that either:

• they don’t think they can finish the task in the time estimated,
• they don’t know how to complete the problem at all, let alone in the time estimated, or
• perhaps worse, explain that the original estimate was wrong and it’s going to take X times more effort.

Folks reading this that have experience with this situation have probably identified a handful of red flags in the process and interpersonal state of things. While the word “just” isn’t responsible for all of it, I’ve come to recognize this word as its own type of flag in technical estimation.

I try to follow a rule when facilitating or participating in a meeting. It’s based on the concept of there being an “elephant in the room.” The elephant is typically a topic or issue that is large and controversial enough that nobody in the meeting wants to acknowledge it, lest everyone get uncomfortable.

Perhaps you’ve experienced this before: you head into a meeting and there’s two or three people already there. You’re aware of one elephant in the room, that Michelle and Jason haven’t gotten over an issue that happened a few months ago. You make a mental note, but you’re not too worried about it because you know these folks well enough and you think you can facilitate your way through.

The problem is, what do you do when there’s a second (or third) elephant in the room that you didn’t know about? Josh and Carlos just had an argument about how to implement an important change in the system earlier in the day. It wasn’t apparent at the beginning of the meeting, but now, five minutes into things, you realize this extra beast is present.

This is a good time to try to enact the One Elephant Rule. The overall concept is simple:

Keep the elephant count down to one (or zero) in any given meeting (or project).

More often than not, trying to move forward without addressing the elephants in the room will result in issues at some point down the road. Whether it be a delay in delivery, reduced happiness on the team or any number of other issues, now is the best time to address the interpersonal issues on the team.

As usual, the implementation is the harder part. To start, you have to determine one thing: Does this group only need to get through this meeting or are these folks going to be working on a mid to long term project?

If the answer is to make it through the meeting and no further cooperation is needed, sometimes you can simply call out the smaller of the elephants: “Hey, it seems you two are at odds about something. I don’t need to know what it is, but what we need from you both is to successfully get through this meeting.” Sometimes calling attention to the elephant will be enough to smooth things over for the remainder of the meeting. If for some reason they can’t cordially make it to the end of the meeting, you can always cut the meeting short and try to solve it another way (e.g. another meeting with different people, working through an async document, etc.).

If this meeting was to kick off a long term project, there are few other things you can do. To start, you can try calling out one of the elephants in the room as mentioned above. If the elephant turns out to be smaller than you thought, or the two people in question really want this project to succeed, that might be all it takes.

If that doesn’t work out, you can also pivot the meeting into a discussion about the elephant in the room. It might be best to ask those not involved in the issue to leave the room. Once you have gathered the individuals experiencing a conflict, put on your mediator cap and go to work. This is especially helpful if the folks having an issue are likely the only people on the team(s) who can do this work. Getting into the details of how to best mediate a conflict would be its own blog post. I would try to use this time to focus on:

• Avoiding making it personal
• Being unbiased (if not possible, find someone who can be)
• Making the expectations of them clear, particularly focusing the success of the project
• Getting both people’s account of what happened
• Understanding what each person needs to move through the issue
• Clearly outlining and agreeing upon next steps

If that doesn’t work, you may have to pull one of the people off of the project and find a replacement. If they can’t make it through a meeting about the project, or a meeting about the elephant, they’re probably not going to be able to make it through the entire project. And in the end, by removing one of the people, you’ve effectively removed the elephant from the room.

There is only so much time and effort we can spend convincing coworkers to repair interpersonal issues. If they can’t disagree and commit, then decisions must be made to ensure that the meeting or project is successful.