Thursday Tech Talk – Stoplights



Stoplights,  gauges, dials for project status…who thought of this?


For most projects, we do status reporting on a weekly basis.  On a  special few, we do status once or twice a day.  Somebody, somewhere, thinks by saying to the project team “if you don’t do what we tell you, we are going to turn the project red” will change how the project team will work.

Here’s the deal for anyone who cares to know.  Developers (programmers, coders, whatever you want to call them) work hard to make their code work because they feel dumb when it doesn’t work.  Calling them into meetings to tell them how important the project is, making them fill out a paper report on a frequent basis, and threatening that you will turn the project red if they don’t fix the problems won’t make them work harder or faster.  It might give them good anecdotes for their next coffee break – or for the beer after a long night – but it will seldom give you the result you are hoping to achieve.

It takes a special kind of person to know how to motivate these creative coder minds.  I am one of those people.  I can convince them to do almost anything when it comes to project delivery.  And why is that?  Because…

  1. I believe in them or they wouldn’t be on my team – people understand they earn the right to be a coder working for me.
  2. I understand them because I was a coder and I love what can be done with code.
  3. I care about them in a way that is hard to explain, but I’ll try – I want to get them to do what they do best (coding and making things work), and keep them away from things they don’t (meetings, written reports, and political discussions).
  4. I treat them with the respect and awe they deserve when they achieve great results, and challenge and coach them when they don’t.

I get the need for status and dashboards and keeping tabs on things and I am often the person creating or reviewing the dashboard reports.  I just wish we could keep the coders at their desks working while we are talking about the stoplights and coding those projects green, yellow, and red.


Tech Thursday.  Mostly green today with a slight chance of red.



About workingtechmom

busy, happy, loving life Drop by and leave a message.
This entry was posted in busy mom, corporate jobs, technology and tagged , . Bookmark the permalink.

3 Responses to Thursday Tech Talk – Stoplights

  1. Serge says:

    a. To me the question is “who do the developers feel that they fill in the report for (or go to the meeting to report on their status)?”. If the answer is – “for a project manager” then we have a 19th century software team organization consisting of exactly coders, if however the answer is – “for all of us”, signifying that developers feel the need to exchange information within the team that includes them as well as the project manager as well as testers and others then we have a team of partners co-owning the schedule as a committment and collectively reviewing options and potential roadblocks to achieve it. b. Coding away in the fastest way one can in isolation from [many] others does not require much smarts and is, to me, a thing of the past whereas achieving exactly the needed result by the date committed that fits within committments of others requires almost non-stop collaboration and, correspondingly, large and small meetings. We need to learn how to conduct ones that would be recognized as adding value; project statuses would simply be a byproduct of such meetings. c. In order to have layers of meetings where high level planning or actioning would not require every team member to parcipate we need to grow technical leadership knowing their teams, capable of producing valid estimates and suggesting valid technical as well as staffing as well as work allocation options of achieving an [often] pre-set schedule. When we find every member of the team sitting in such meetings this is an evidence that we do not have such leadership, or do not have enough of it and/or do not quite trust who we have. d. Today iterative, scrum, agile methodologies introduce a much more collborative pattern of a team build-up where peer pressure becomes a more important factor than managerial “motivation”. Building such transparent self-regulated crazy-about-collaboration end-to-end project teams is a challenge and a cultural shift especially in larger waterfall-based hierarchical organizations, but it is an inevitable one if we would like to prectibly build complex software both on [shorter] time and on [smaller] budget.

  2. Amen! I always HATED getting called into a meeting for a project I’d been pulling 12-hour work days on, just to be told we needed more than 8-hour days. “Gee, REALLY? I was just living in my cube ’cause computer printouts are SO much softer than my mattress at home!” :p
    Of course, once we figured out how to jimmy the lock on the boss’s boss’s boss’s office, with the long, overstuffed leather couch, the pool of overtime programmers enjoyed a sudden increase. 😉

    • That’s funny! Please don’t give my team any ideas though. I’m sure they have a few of their own ideas. My favourite is when someone says “this project is really important” as if we work on a lot of things that are just not needed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s