Category Archives: management

Phrases that Raise My Eyebrows

There are certain phrases that I hear in the course of product development conversations that cause me to raise my eyebrows.  Frankly, some of them are like fingernails on a chalkboard (for those of you old enough to remember chalk boards) to me.  Some of these phrases are so ingrained in our corporate lingo that most people don’t realize they’re using them.  They are uttered by everyone from software engineers to product managers.

Here are a couple I’ve heard recently.  I’ll update this post or write more posts as more of them hit my ears.

  • “I could work on task xyz.”  The objective is never to work on something.  The objective is to get something done.  If you start something, have an idea for how you’re going to get it to done, not just work on it.
  • “I’ll be ready to push that to QA tomorrow.”  There are two things that bug me about this one:
    1. In our software development teams, nothing gets pushed to QA.  It gets to a state that it is ready to be tested.  Getting it from that state to done is a team responsibility, not a QA responsibility.  Ideally, a QA analyst or test engineer will be available to test it, but if not, the team needs to figure out how they’re going to get it to done.
    2. We want our development process to operate as a “pull” system.  When a work product is done being transformed from one state to another, it enters a buffer queue (e.g. the Resolved state in most teams’ scrum boards).  It doesn’t get pushed to QA.  The work product only gets pulled from the buffer queue when the team has capacity to perform the next transformation on it (e.g. testing).
  • “We need to move this forward.”  This is stated by someone who wants to demonstrate progress on something to a stakeholder.  It seems rather innocent, but like the first item in the list, our objective should never be to start something or do some work on something, it should be to finish the most important thing we have.  The problem with moving things forward is that it is usually at the expense of getting something else done.  Too many things are worked on at once; they all move forward, but the most important of them never actually gets done.  This means we don’t actually deliver any value.