Use The Force

March 4, 2007 by
Filed under: Process, Project management 

Way back, about 20 years ago (OK, perhaps a bit further back…), I started my career working on embedded systems. At one point, I recall debugging a serial protocol between two devices. There was one particularly nasty problem, one that for quite a while simply refused to be solved. More about that nasty bug and the lessons learned next week.

The strongest memory of that experience was not the technical issue itself, but the interaction with my manager during that period. It seemed that despite the crazy hours we put in to resolve our challenges, no matter what time it was, we could feel our manager’s breath on the back of our necks, and his deep intonations of “When will you be done?”

Think James Earl Jones’ booming voice here. Behind closed doors, we called our manager Darth. In hushed tones, of course.

More recently, while running a simulated project where we set teams off to build a contraption in a finite amount of time, we observe similar results. In the first attempt, there is little chance for the management team to coordinate the group’s efforts and to break the problem down into the right approach. As the team frantically tries to build, management will weakly wander about, simply reminding the team of the time remaining.

Granted, that’s the only thing they can report on, but doing so actually increases the stress on the group, rather than decreasing it. In these same simulations, I have yet to hear management asking the team a simple question: “What could we do to facilitate your getting the job done faster?”

While this is a simulation, it frighteningly reflects the real world that I first saw 20 years ago and still see today. I’m staggered at how often managers seem to believe that asking, begging, admonishing the team to go faster will make a positive difference. Dig deeper, and we see that this is often all they are equipped to do. I have learned over time is that when all a manager can do is ask when you will be done, or tell you how late you are, the team is in serious trouble.

So what to do about these situations? How do we get that monkey, often thinly disguised as a pointy-haired boss, off our backs?

Management is best equipped to express the problem, the team members are best equipped to determine how to solve the problem. Good management recognizes the necessity of the team collaborating to decide on the best approach overall. Management’s primary value then becomes clearing the roadblocks that might prevent this from happening.

What we need, then, to allow us to simply forge ahead with our work, are three things:

  • A clear, current understanding of the activities and deliverables that everyone on the team will do and provide to achieve your project goals. With this context, you can discuss alternatives rationally. Management can track progress without having to resort to invasive tactics that make you cringe whenever they are in the area. Most of your activities should point to this clear understanding of work. This is the schedule for the project, and often is reflected in a network that was hastily constructed initially, but has since fallen horribly out of date. Trust me, the value in doing this initially and keeping it current is incredible, especially on tight schedules.
  • A list, beyond what you do know, of the things you currently don’t know and the things that might hit the project. These are the things to focus on, to narrow the scope of managing status. These represent the uncertainties that make your estimates too wide to be comfortable, and the risks that could potentially hurt the project. These are the things that should be addressed first, to avoid that “and then a miracle happens” cloud of uncertainty and stress that hits many projects towards the target delivery date.
  • A concrete list of things that management can do that will make your tasks easier to accomplish. Few developers have the presence of mind to ask for this, but most management will gladly accept this when offered and do what they can to clear those roadblocks. You don’t ask, you don’t get. If you continue to try to push your way though a difficult problem without asking for help, this area is where you are falling down. When this occurs, even the most carefully planned project can fall off the rails.

Looking back, we had gaps in all three aspects. All of these things need to be built by the team, and kept current by the team. This is the infrastructure around which the team communicates, and ensures that everyone on the team contributes most effectively towards the common goals. Call it the Force.

Monitoring progress becomes straightforward, rather than a never-ending scavenger hunt for hints of progress. The team can focus on the difficult issues, the risky parts, the surprises that will arise. Management has the tools to support the team in the most effective way possible, rather than nervously watching the clock.

And we can avoid that frightening deep voice from behind our backs as well. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    January, 2018 – A workshop series to help you develop resilience in the workplace and in your life!

    Next open enrolment sessions start soon – contact us to get involved!

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • September 19-21, 2017 – Winnipeg, MB
    • October 3-5, 2017 – Regina, SK
    • October 20-22, 2017 – Winnipeg, MB
    • October 23-25 – Saskatoon, SK
    • November 14-16, 2017 – Winnipeg, MB
    • November 20-22 – Regina, SK
    • November 26-28, 2017 – Edmonton, AB
    • November 29-December 1 – Calgary, AB
    • January 17-19 – Calgary, AB
    • February 10-11, 2018 – Edmonton, AB
  • What People are Saying

    If your desire is to effect change or have more influence on a software team, you could either stumble around in the dark for a few years, experimenting with different techniques, or you could buy, read, and apply the techniques in this book. This choice, of course, is up to you.

    — Matt Heusser