Get too tactical and get set on fire

Get too tactical and get set on fire

I read Neil’s “How to do Nothing” blog article on the topic of effective management back when I first discovered his blog earlier this year (2010).  I was struck by the pure simplicity of his eight attributes of effective team management at the time.  Neil was gracious enough to comment on a recent article I published on agile project management reducing application over architecture.  I went back and re-read his article and realized it is even more impactful on successful team management than I originally thought.  I thought I would take a few paragraphs to further extend the concepts Neil outlined in this article.

Anticipate rather than react

Neil suggests having your hair on proverbial fire frequently by getting hands-on in addressing issues isn’t the most affective approach.  I agree with him that in these hair-on-fire situations, it can be exhilarating to roll-up your sleeves and jump in and be the hero that saves the project or restores production service, etc.  Once a sense of calm returns after the hero has saved the day, the hero starts itching for the next crisis to be the savior and the behavior gets repeated.  The hero may get initial fame and glory, but it is short lived.  In my experience in multiple MidWestern companies, the hero ultimately gets revealed for his/her display of reactionary management.  Senior management begins to grow tired of the peaks and valleys of crisis, pending doom, disaster avoided, pause and repeat for the next crisis.  I’ve also seen the hero scratch their heads when the next re-organization comes along and the hero finds him/herself as a technical lead over a team with a new management layer above them.

Maintain relationships outside the team

I definitely agree with Neil here.  I would even add the larger the organization, the more this is essential.  As your team provides a service to a larger project or effort, the number of ways other teams can throw a wrench in the works is almost immeasurable.  In addition, the message that gets filtered to your team and then to you may be completely disconnected from the real blockage.  Being able to pick up the phone and call a peer manager, with whom you have established a rapport, and get right to the real issue is invaluable.  Once the real issue is known, you can offer guidance to your team on how to navigate to a successful path forward.  Without this knowledge gleaned from a peer manager, you can easily get caught up in the panic the blockage creates and risk being set on fire in the process.

Big visible task boards

In a word: absolutely!  By all means, assuming everyone knows what to do is a recipe for disaster.  A disaster in a sense that tasks won’t get executed according to plan and you will be dragged back into strategizing on how to go forward while accounting for the missteps of the past.  As Neil says, use a whiteboard or in my case, use some electronic task tracking system that isn’t overly cumbersome yet makes it unbelievably clear who is working on what, doing what and when.  Have you ever considered using your bug or defect tracking system as a light weight task tracking mechanism?

Team collaboration

I’ve written on this topic in the past relative to the leveraging of self-organizing, strong teams with a focus on intense collaboration.  If you make yourself a keeper of all knowledge, you will constantly be engaged to assist with tactical decision-ing and thus at risk of again, being set on fire.  If you drive team members asking you questions back to fellow team members, they will start going to fellow team members directly.  Clearly, once this occurs, you will need to be contingent of when you will need to specifically instruct your team to collaborate with you when you are engaged in some issue that you aren’t at a point of delegating just yet.

Small incremental changes

If you are considering pitching or implementing a significant change that you have dreamed up that will get everyone working better, more efficient and at the same time cure cancer, you might want to put on the brakes.  People accept change in a variety of ways.  The more aggressive the change from the current norm the more likely you will have to invest additional time in addressing how each impacted individual reacts to the change.  If you stretch your change implementation out over time so it seems like you are providing “just in time” solutions to the ultimate problem, you will most likely achieve a more successful end result all around.  Plus, with each incremental small change, you can more easily course correct or tweak your next change to be even more effective and hopefully, even less visible.

Inspect and adapt

Getting the team to contribute ideas and suggest process improvements takes the decision-ing pressure off of you and empowers the people doing the work and most impacted by the process to suggest the most effective improvements.  Plus, if the team is on board with an improvement, they are more than likely to make the implementation successful, because it is their improvement.  On the flip side, how motivated are you if you have the ultimate “my boss told me to do it, thus if it doesn’t work, not mu problem” excuse at the ready when the slightest problem is encountered?  What motivation does anyone have in that situation to try and make it work?

Hire great people

These almost goes without saying … hire great people and then just get out of their way so they can do good work.

Commit to personal development

If don’t have the flexibility to move poor performers out and attract in top performers, and let’s face it, MidWestern companies don’t always have the most flexible staffing models nor the local talent pool to quickly make team changes happen.  Bringing up the level of your current team is more than likely your best option.  Take advantage of any tuition or training bugets available to strongly encourage folks to get away from their desks and get exposed to some additional improvement perspectives.  Consider incremental “stretch” assignments to use as opportunitties to challenge those that have a weakness in a certain skill set.  Catch up with them “offline” and chat with them about what problems or challenges they are facing and offer some tips to help them get over those hurrdles.

Summary

In summary, the concept that a strong manager is precieved to be “doing nothing” is a compelling goal for any team manager to attain.  By essentially making it a top priority for you to empower your team to function as autonomously as possible, it allows you to focus on inter-company relationship building and other functions only you can do.  It also allows you to identifying process and skill set weaknesses without being tactically involved in the work to consider small, incremental improvements and then absorb the result.

  • Share/Bookmark
, , , , , ,

From both an IT engineering and management perspective, I find it very easy to fall victim to groupthink.  Groupthink is defined by Irving Janis as “A mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members’ strivings for unanimity override their motivation to realistically appraise alternative courses of action.”1 To illustrate groupthink in the IT world does a team meeting scenario like below sound familiar?

Impromptu Team Meeting in the Conference Room

Is venting starting to turn everyone too negative?

Is venting starting to turn everyone too negative?

Bob the Engineer <very agitated>: “Geez, that project ‘critical path’ regroup meeting was a huge pain!”

Sally the Engineer <visibly frustrated>: “Yah, if only the project managers were listening to us all last month when we were telling them their schedule was ridiculous!  There was no way back then the work was going to get accomplished when their fancy project plans said it would and we told them!”

Joe the Engineer <rolling his eyes>: “How many times are we going to have to attend these silly ‘we knew were going off track a month ago but we did nothing so now we need to have a meeting to chat about why we are suddenly off course  …’”

Bob the Engineer <speaking over Jo>: “We are going to have these meetings as long as the PMs keep ignoring our work estimates.”

Sally the Engineer: “Yah, when will they ever learn?”

Groupthink is any easy trap to fall into.  Yet, in my opinion, fostering a team climate for which there is an opportunity for such venting provides benefit to the entire team.  With a team sense of shared success and shared pain, the team climate evolves to allow team members to be open with their teammates and their manager on problems, issues, challenges and successes with more candor.  The openness breeds more open communication and cooperation plus ultimately leads to high quality output in less time with problems surfacing and resolving earlier in the work processes before they become disasters.  Yet, left unchecked, this venting can take the team as a whole deeper into the short term comfort of the shared pain and away from the need to look at opportunities to avoid the situation that causes the pain in the first place.

It is time for someone to be a leader and jump in and pull the team back from the precipice of groupthink.

Boss/Engineer: “OK, OK, ok … we all know the PMs get themselves into this situation more often than seems warranted.  How about we brainstorm on some creative ways we can do things differently going forward so we don’t have to sit in these useless regroup meetings?”

As an Engineer, this is a great opportunity to demonstrate leadership skills in front of your boss with real credibility.  As a Manager, if no one on your team is stepping up and the level of negativity is rising, you may have to step in with similar comments to redirect your team to focus on positives before the negatives further spiral the team down a bad path.

Anyone have any perspectives to share on groupthink?  Anyone have a technique or example where groupthink was avoided or not avoided resulting in a bad situation getting worse?

  1. Janis, Irving L. Victims of Groupthink. Boston. Houghton Mifflin Company, 1972, page 9.
  • Share/Bookmark
, , , ,