Share via

It's Not Over, Till It's Over

  • Article

The word "over" can mean a lot of positive things.  "Over the rainbow" is where you find your pot of gold.  "Turn over a new leaf" means you're changing your ways or stopping a bad habit.  And "head over heels" describes falling in love.  Yet, the word "under" usually means something negative.  "Getting under my skin" means that you are bothering me.  "Under the gun" means being pressured to get something done in a short amount of time.  And "sweeping it under the rug" means you are hiding something that is dishonest.

Ok, I'm done with my little lesson on clichés in the English language.  How does this all apply to engineering and working on a software team?  Well, given the above examples, it's natural to believe that anything that involves the word "over" is good.  But that's not the case.

Years ago at Microsoft, we had a list of competencies to describe behaviors and traits people need to have to be good at their jobs.  Some examples of competencies are confidence, results-driven, and conviction.  In moderation, all these are great to have as an engineer.  But along with each description of the competency, there was also a description of what "over-doing" it looks like.  Someone who overdoes confidence is probably a bit arrogant.  Someone who overdoes results-driven may leave "a wake of dead bodies" (another cliché for you) in order to get results, meaning they don't think about who they leave behind or what damage they inflict on the team morale to get results.  Someone that overdoes conviction may be so passionate about an idea that they can't think beyond it or listen to others' points of view.  These are just a few examples of competencies and how over-doing them can lead to a weakness and not a strength.

Another item that may seem positive but really isn't is "over-functioning".  Many times, leaders will say 'go do what it takes to get the work done'.  Again, within moderation, this works well and if it promotes teamwork then that's great.  But be careful when you cross role boundaries.  There's a right time to do this to make sure your team is successful.  But if you always cross those role boundaries and do what other people in other roles should be doing, you cause a dynamic in the team that adds more confusion than clarity.  Everyone counting on you to over-function can cause you to burn out.  Also, if you over-function to the degree that you aren't doing your own job because you are filling in the gaps of someone else's role, then you not only hindered them from being successful and exhibit the skills within their role, but you aren't exhibiting the skills within your own role.  Crossing role boundaries when needed is an acceptable thing to do.  But continuously over-functioning and doing what others should be doing can actually hinder your career.

Finally, there is "over-thinking" and many engineers do this.  I catch myself doing this.  You want things to be as perfect as possible.  So you test every possible outcome, come up with every possible scenario, or plan for every possible situation.  Someone who does this can get stuck in this cycle of never having things be good enough to move forward.  Or they think so much about something that it slows down the process.  In an agile team, over-thinking can really slow down the speed of a sprint.  That doesn't mean the solution is to just not think and do things quickly.  Once again, moderation is good here.  Think just enough, plan just enough, think through your tests and your scenarios enough to make the customer happy, but don't over-think what you are doing or you could end up spinning on something longer than necessary.

So those are examples of why "over" can sometimes be a bad thing in engineering even though it can be a very positive word.  Does that mean "under" can be a good thing in engineering?  No.  I can't think of any regular task that you could do less of and have it be good.  Don't "under-do", "under-function", or "under-think".  That will definitely set you up for failure.  Better to just focus on moderation.

Or maybe all of this is just water under the bridge.

Comments

  • Anonymous
    May 29, 2015
    Under and over are both in reference to the current state of affairs.The big opportunities for gains - in both engineering and in process - are typically not from optimizing the things that you do, but by getting rid of some of them.As an example, many teams have multi-year plans. and it's a big and involved process to create those plans. I'm convinced that if they "under plan" by only looking at the next 90 days, they will save a whole bunch of time and be just as successful.

  • Anonymous
    May 29, 2015
    For shame Anita. You forgot the first rule of software delivery: under-promise and over-deliver. :-)

  • Anonymous
    May 30, 2015
    Ken - I actually don't like the "under-promise and over-deliver" philosophy although I do see it get used a lot.  You should say what you are going to go do and then go do it.  No under or over promising.  :-)  Eric - I think the under-planning is all relative.  We went from 2 week sprints to planning them out across 90 days and people think we are now over-planning.  :-)  Thank you both for your comments!