Where Saying 'No' Is An Option.
Do you know who the 'idea man' in your project is?
Usually this is going to be a manager who doesn't do any real work or a business analyst who doesn't do any real or even un-real work.
Identifying the idea man is easy:
- Idea man does not like to be associated with one project for a longer duration.
- Idea man is bubbling with ideas that he 'thinks' your clients 'must have'.
- Idea man understands the culture chart and knows the people high up in the pecking order well enough to pull a few strings and get his ideas of '(not so) nice to have' features or suggestions magically transformed into 'must have' requirements overnight.
Now; the idea man might work with multiple motives; some of which include:
- Working for the best interest of the organization and the client --- You may have click the link to capture the underlying tone of sarcasm here.
- Desperate attempts of finding his place in the larger scheme of things --- and an inability to find healthy ways to over come his insecurities.
- Showing those pesky programmers their real place.
One of the major thing that differentiates a remarkable environment from a mediocre one is the number of strings the idea-man can pull on genuine builders and story-tellers.
Joel Spolsky's rather famous post on the topic; where he talks about his experience of being attacked by a bunch of these idea-men as a manager on the excel macro team; is rather fascinating. Joel uses his post to tell a fascinating real story:
My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.
I asked around. Who's the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.
"Blah blah!" said one of them. "Blah blah blah, blah blah blah!" said another. I don't think they quite had anything interesting to say. They were very enamored of the idea of sub-classing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, "Well, this is all very interesting. What's next? Who has to approve your spec?"
I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec.
The same story describes the whole string pulling exercise which is a rather common trait amongst idea-men:
This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him.
Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?)
My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.
Joel effectively goes on to describe what made Microsoft a special environment to work at in the very same story:
I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office -- I knew who he was, of course, but didn't expect that he knew me very well.
"How's it going, Joel?" he asked. "I hear you've been having some issues with the App Architecture group."
"Oh no!" I said. "Nothing I can't handle."
"Say no more," he said, "I understand." He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.
While the story is a fascinating example of a work environment where eventual builders are given room to maneuver it is also an interesting case-study of what results in the development an environment where genuine builders who indulge in the act of building stuff can flourish and innovate.
If you've been in the business of building software for any period of time; you've probably found yourself demoing your product to the-idea-man.
The idea-man is usually not an involved client; he is not a regular user; he is not even an active team member --- because all three of these require time and commitment and a typical idea-man has neither time nor commitment.
Chances are; that the idea-man will not even log-in in to your application after you are done with demoing your application to him --- but based on his infinite wisdom and experience --- he is going to leave you with a few ideas that your 'absolutely must' implement.
Once you spot an idea-man; be informed; that he will pull any strings he can to get his ideas implemented.
When that happens:
Does your work environment leave you with no other option besides; dealing with the idea-man diplomatically?
Do you have enough genuine builders or story-tellers around you who are masters in the art of sedating monkeys and getting them out of your way?
Is saying 'no' even an option in your environment; dear reader?
Discuss.
@BuildersAtWorkBookNotice
Comments are closed.