Leadership

Don't sweat the small stuff too early

Have you ever been in a planning meeting and everything comes to a grinding halt because someone wants to address details? There's a time and a place for the details, but not in the beginning of the creative process.

Have you ever been in a planning meeting and everything comes to a grinding halt because someone wants to address details? There's a time and a place for the details, but not in the beginning of the creative process.

-------------------------------------------------------------------------------------------------------------------

In TechRepublic's IT Leadership blog, Patrick Gray made this statement: "It is better to make an imperfect decision that moves the project forward today than to spend months vacillating and pontificating while time and money fly out the door."

If that statement weren't so long, I'd put it on a tee shirt.

I remember being in a horrendous meeting one time in which a bunch of us were discussing a new product and what the order e-form for it would look like. Three people in the room (one of whom was the project leader) "hijacked" the meeting for about 30 minutes and discussed the color the Order Here button would be. Setting aside the fact that this discussion centered around a button color (!) and that those were 30 minutes of my life that I would never get back, it really demonstrated an infatuation with details that would more than once impede the forward movement of the project.

I'm not saying button color is not important -- all you Web designers out there with your fingers poised to shoot me an e-mail can calm down -- but to obsess on a down-the-road detail like that when the parties involved could have been using that time to, oh I don't know, actually make the product, well it didn't make sense to me.

And, of course, this being corporate America and all, the three people debating the relative advantages of color #11198D over color #990000 were each passionately determined to win the "argument." And even that degree of minutiae worship could be excused -- in a different place and time. The team leader should have been the one to take the whole issue offline to discuss, but as I said, he was one of the three giving disproportionate life to it.

Look, I know details are important, and if you don't consider them before a project, they can blow up in your face down the road. But excruciating detail can also curtail big ideas and stifle creativity. One of the reasons I was never successful at creative writing is because I could never let go of grammatical rules while I was being "creative." I couldn't let my thoughts flow because I was always stopping to correct my own punctuation or unsplitting an infinitive.

Every now and then as an IT leader, you should devote a meeting to brainstorming as if anything were possible. Visualize the possibilities before you start limiting yourself with all the mundane details.

About

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

28 comments
pmwork1
pmwork1

Right On!! And what do we do about it. I have worked on a few projects where every meeting has a "facilitator" "vibes watcher" who can call the shots on the meeting. they are not dircetly technically involved so have no axes to grind . Meeting go much faster. I have also noticed that one of the reasons meetings get hijacked, is that decisions are not properly documented. Then reinventing the wheel every time would stop, when the clearly documented decision is tabled. In Australia also we are not so "polite" a person hijacking a meeting over an will often be told "not relevant at this time" let's move on. !! TONI you should also acknowledge Richard Carlson the guy who wrote the "don't sweat the small stuff" books

microbins
microbins

The T shirt would say: A little inaccuracy sometimes saves a ton of explanation. Quote from H. H. Munro

greg.hruby
greg.hruby

Part of Creativity is learning from others who've been there done that. We invited folks from other organizations to provide insight on what worked and what didn't. Not consultants, but end users - the folks who paid for and had to deal with the end-result of the project. Consultants are like hunting dogs, the fetch every duck you send them after - but they won't tell you a thing about the bag of gold they run by every time they head out.

major.malfunction
major.malfunction

That is what I use to get told when I was IT Manager at a software company. The VP of Ops went with the money making theory of "sell it then staff it then design it". So come up with an idea, sell it to a customer, and then come to a planning meeting and say we need to do x,y, and z for this customer even though we have never done it before and by the way, I didnt run any of the technology aspects through the IT manager. This was time and time again and each one was a failure..go figure. 99% of the "great ideas" that came across the table were prehistoric thinking by a core COBOL based progamming staff with no knowledge or understanding of screen ergonomics, operational man hours, and most importantly: How do we support this going forward? There are too many higher ups who are mainly concerned with keeping the cash register ringing upfront to make themselves look good NOW rather than understand long term stability for the company. So why actually look at stuff at a detail level at the beginning? I don't know...how about becuase its a good idea to turn the lights on so you can see the turd you have in your hard rather than wait 2 months.

dbecker
dbecker

Only time to do it over... and over... and over. What you might consider doing is saying, "I'm sure that we don't need to go into detail now because we can always pick that up in the second version". And don't laugh because it isn't funny. Years ago, the Development Manager made his fame here by creating a jail management system called "LYNX" single handedly. I do believe that the first version was in RBase, with further development in Cold Fusion. At the time, he wasn't yet the Development Manager, he was just a client services rep. Now he's the Development Manager. The Human Resources Director called him on the carpet for programming because he was supposed to be managing. Not to worry: The IT Director changed his official job description to include programming! (Note that he "manages" 50 people or so.) And so it is, two decades+ later, the LYNX system is being redeveloped. This time to be Java Open Source [that will be quite an "attitude adjustment" for the code, costing millions of dollars to redeploy]. It helps develop the Development Empire and keep staff during times of very tight deteriorating and disappearing budgets. And so it is: There's probably no way to do it completely right the first time. Just let the concepts flow with imperfect flawed design, because as sure as death, hell, taxes, revenge and the fury of a woman scorned, if there's any viability to a system, rewriting it has the advantage of keeping and even growing staff over a long period of time.

tfinch
tfinch

I really enjoyed this article. I hate meetings period! But I feel people that focus on time-wasters like button colors, are just looking for ways to get out of doing actual work. Just move along people....

scook
scook

Rolf Cook used to have a very discriptive term to describe just this issue. And it goes like this: "We are pole vaulting over mouse turds here people".

Charles Bundy
Charles Bundy

Move or Die... or It's an imperfect world, deal with it!

DN99
DN99

Reminds me of the 'meeting from hell' I had the 'joy' of attending about 15 years ago. It was one of the hottest days of the year (yes, we occasionally have hot days here in the UK too) and the office had no air-conditioning. The meeting degenerated into two engineers arguing for over an hour about the colour of a label while the rest of us fell asleep. Ever since then I've resolved to intervene with the mantra "We're not designing it here!" as soon as things get too detailed - unless, of course, the purpose of the meeting was to produce a design.

michael_poplawski
michael_poplawski

As Patton said, "A good plan today is better then a perfect plan tomorrow."

Osiyo53
Osiyo53

Certainly most of us who have been around for a while have seen this sort of thing happen. Someone should have interrupted that circus and reminded everyone that the color of that button was a detail which should be addressed, LATER. Write that down, now lets move on. Seems to me that the meeting you refer to should have been one whose objective was to set the GOALS to be achieved. That is, the final desired result. After which one then typically sets up objectives. These are simply clearer statements of the specific activities required to achieve the goal. Once those things are clarified and agreed upon, one then typically sends everyone away and back to work to create their individual action plans. Which are the individual steps/actions which need to take place in order for each to meet their respective, assigned objectives. Somewhere in that action plan development is where the discussion and final decision decision making process about the color of that button should be. Maybe a little refresher training in basic management theory is in order for some of those folks? Seems a bit early in the process for everyone's time to be wasted in a discussion of button color. Shouldn't all of you have been clarifying the goal/objective, and then subjecting the plan to a SMART analysis? SMART = Specific, measurable, achievable, realistic, and time based.

carlos.antenna
carlos.antenna

How about this for your tee shirt... "Don't Sweat the Petty Stuff and Don't Pet the Sweaty Stuff"

phyrefly.phyre
phyrefly.phyre

One of the worst meetings of my life was an early planning meeting on a big project I was leading. I had written a quick, first-draft spec, and the meeting was to discuss it, and see if there was any extra functionality we would need from the project later before any in-depth work went into it. Unfortunately, it was also the first time the company's new template spec doc had been used, and we spent TWO HOURS discussing the breakdown of information into chapters, and what order the chapters should be in. This meeting happened three times, and not one word was uttered about the functionality of the app I was trying to get written. This only ended when I swore at the MD and walked out of the last meeting. I wonder why my job there never went anywhere? :P

cmaritz
cmaritz

Thanks Toni for a snapshot of real life there. I'm guilty of this myself. In my programming days whenever someone wanted a new database developed to plan or track x, y and z, I would be thinking about table design and relationships in the first meeting. In fact, I would want to get OUT of the first meeting just to get back to my desk and start creating tables, fields, keys, relational links, etc. Trouble was, pretty soon I'd be sitting down a SECOND time and RE-designing tables ... Now, if it's a database that needs designing, I ask what are the reports that the person would like to see at the end of it all that supposedly are going to make his/her life so much easier. If it will really benefit, then we brainstorm a bit more about additional reports or useful information that could be gleaned from such a system, and even then suggest additional functionality that MAY be useful at some later time, which would be good to build in now as a mild future-proofing. And this whole process should be done on paper or whiteboard, i.e. far away from a computer. And then it's time to create tables. (Or, for someone else better skilled to create them, as my Access 2000 knowledge is rather useless now!) Sometimes the reverse also happens. What I mean is, in the OP there is someone raising concerns about details right in the beginning stages where there should be brainstorming and creativity instead. Another possibility is that AFTER all the brainstorming and planning is done, and the project is near the date for go-live (or comissioning or hand-over or whatever the critical date is), and then someone stands up and says, "Hey but what if we do it THIS OTHER way?" Equally bad timing. Hey, it might be a great idea, but chances are we can't divert all the effort to date and do that new thing now. Or perhaps spin-off a pilot from the current project and try out the new idea. Whatever. Point is, there is benefit to separate out thinking processes (just like De Bono said) instead of mixing them all up at once. In a typical project, the beginning chunk should be rampant creativity, where the more ideas there are, the better, and nothing is 'wrong', and the ideas don't necessarily have to 'work', because we suspend judgement at this beginning stage. Then most often comes an analysis stage where current knowledge and real experience are consulted and the vast number of options and ideas generated at the beginning are trimmed down to a list of more doable things, given certain budgets and time-frames. Then lastly comes a necessary decision stage where we have to narrow down the options to only the one or two that we will commit on. Here we (have to) apply judgement and criteria, because now it has to actually WORK. Something like that, anyway. Thanks for a useful diversion to the daily tech grind :-)

saqgoku
saqgoku

When brainstorming and idea, go over the overall basis of the idea outlining what it is and its purpose including its impact, cost, time and materials. Once that is complete, and you are in the development stage then perform details as to how it should be assembled.

paul.huber
paul.huber

Planning sessions from the best of the best play out like: Questions, issues, concerns, facts that become findings and conclusions for a CIO, the statement of work, and the start of a detailed project plan. HOWEVER, this requires a PM as a SME (subject matter expert) with the discipline at hand so that each decision of what is in and out of scope is not flawed. If they are flawed decisions you have already failed to cover all the possibilities and how to prioritize them so you fail, no discusion, you failed.

mbm29414
mbm29414

I will admit, I don't know how it works at big companies. My dad owns the company I work for. My mom is HR; my wife manages our production staff. I'm IT (yup... ALL of it ). My dad is our salesman, and he goes out and sells crap I've never thought of. (Believe me, I've had more than one "OH, CRAP!" moment!) Then he asks me to design it. Now, bearing in mind that he has SOME idea of what is possible and not with computers, he's never promised something I couldn't deliver as a 1-man shop (and I'm not the best ever. In fact, I've been trained on-the-job, and figure stuff out as I go). Sure, there have been things that are hard; some have damn near killed me. Rarely, an idea that we've sold (for which we've built a working design) won't work due to further knowledge that presents itself (i.e., crap the customer forgot to mention). In any case, we find it pretty simple. He sells the idea. I design the system (i.e., the details). Then, WE assess it together and bang out further refining of the idea/details as a whole. Then I redesign the details and we repeat until the system meets the original goal and is designed as I want it in a manner that satisfies Sales. I guess it works because I get no input on the details from "Sales" until it is already working in at least some capacity, and then the details are only critiqued as much as it relates to the overall goal/design of the project. Is this unique? It seems so natural to us.

greg.hruby
greg.hruby

Your model of the universe is more complex than the real one. Looked at under magnification, a cue ball is lumpier that the earth. Your shot.

Bixxo
Bixxo

Don't forget Richard III's famous line... "My kingdom for a horse"

jk2001
jk2001

Yes, write it down. In fact, something I've seen that works outside of a software dev context, is to have the meeting leader, not a secretary, write the issue down. The leader then does followup or delegates. This signals to everyone that the issue will be heard, even if it's not heard right now, and the key people are alerted to the issue.

downeast
downeast

Its tough to keep the top down focus, especially when you have one or more higher up executives who insist on focusing on some obscure detail that really has no relevance in such a meeting. It generally leads to analysis paralysis. We just yes them to death and move on, then deal with it later.

MyopicOne
MyopicOne

..the rub here is the definition of 'small stuff'. While Toni's example of a button color is hilarious, I've also seen the opposite - meetings to gather requirements for a corporate wide monitoring and alerting system for IT, where all sorts of decisions were made except for 'small stuff' like: 1) Who's administering it and how much bandwidth will it take? (The assigned person didn't have 1/4th of the bandwidth they needed.) 2) How will the items to be monitored and alerted upon be maintained, added and removed? (Never decided, so nothing ever got added, no new servers or processes. It was always 'phase 2'...) 3) Who's actually going to look at the output and more importantly, take action? (Saved the best for last - the answer was 'everyone', which actually meant 'no one'.) And oh, we app side folks have thingys we want monitored and alerted on too, like database processes and backup jobs. What, you're surprised? Should be no surprise that the installation failed completely...

Willie11
Willie11

There are two types of people. The "big picture" people who never get involved in the small stuff and the "detail people" who totally miss the big picture. A good project needs both. The big picture folks to develop the concept and sell it. The detail folks to make the big picture guy's idea work. Maybe the trick is, don't bring in the detail people until you need them to develop the details.

kferraro
kferraro

Now if we could just convince the perpetrators of this behavior of how much they are costing the project. But wait, they are too busy derailing another project while worrying about some small detail.

freaknout
freaknout

What color should the horse be? What type of horse? What feeding facilities do we have for the horse? What storage are we going to utilize for the horse? Yea, yea, details I know, but still pertinent to the issue at discussion

jk2001
jk2001

People need to learn to do both, even if they can't do the other well. That way, they develop respect for both the planning process and the execution process.

RC Anderson
RC Anderson

Micro-managing upper management are especially guilty of this. Dragging everyone down into the details of unrelated or unnecessary issues instead of keeping focus on the bigger picture. It's like they can't let go of yesteryear when they were the worker. Nevermind that folks like this shouldn't be promoted to management anyway. But I digress... To these folks I say "Let those of us who know how to 'do', accomplish what you hired us for!"

waynesreed
waynesreed

That's the key phrase that often works when used. There need to be a few people in every meeting with the presence of mind to recognize tangents and announce their intention to organize the smaller team session that will hammer out those details.

Editor's Picks