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.