Fog Creek Software
Discussion Board

attacked by ninja-mutant project managers

Here's my situation: A couple of weeks ago I was giving a little inhouse-training presentation on how to implement "WebServices" (okay, this is really a word I have to start putting in quotes now, just like "ApplicationServer", "ContentManagement"...) using a "J2EE based framework". Around the same time our Technical-Project-Manager-Department was visiting a workshop on some CMS product. The marketing guy holding the workshop was throwing around that "J2EE" buzzword until the Technical-Project-Manager-Department-Staff dared to ask him what that is all about. He really couldn't give an answer so those people noticed my little presentation lurking on our intranet. This was when things became ugly...
I was asked to hold the same presentation again for the PM's (it was intended for developers originally). I knew what would happen next, so I pretended to be really really didn't help, since they went straight to my boss.
Things developed further when somebody actually managed to read through what I wrote in my ppt. They decided that what I wrote was way to detailed and difficult and that they really need a "higher level analysis" on that "J2EE stuff". 5 minutes later I had a 15-people/2h meeting invitation in my Outlook calendar. They wanted to discuss with me what they expect from my presentation. I told them that I really have things to do, so they had to do their meeting without me. Next day they send somebody to my desk giving me the details about what happened on the meeting. The result was that basicly they need a workshop on J2EE ("we already did the B2B, B2C, B2E workshop..." :-). So they scheduled another meeting where I was supposed to be told by a "more technical orientated" PM how to put things in a way that was understandable for those people. He told me which words are okay ("database","legacy system",..) and which are not ("transactions","loose coupling","component"). I learned that 80% of the words I used belong to the words that are not okay. So we broke everything down to a 30min, high-high level, kindergarden-language-style kind of a workshop I will have to hold next friday.
Does this only happen to me? Is this "normal"? What can I do to prevent it from ever happening again? Can I stay and work at a company like this or whould you consider this place to be doomed?

Stephan Brosinski
Tuesday, January 15, 2002

I could honestly say that if I worked at a place like that the best thing about it would be seeing it in my car's rear view mirror each day.

If they are not able to understand that sort of thing, why do they need a presentation on it at all?

Robert Moir
Tuesday, January 15, 2002

This used to happen to me all the time at my previous permanent jobs. My managers were ignorant of even basic technical knowledge. Any attempt to implement a development standard required me giving (several) "briefings" on what I proposed in almost infantile terms. Ended up doing more education sessions than development!

So no, this doesn't just happen to you.  My suspicion is that it's quite common. But because something happens frequently doesn't make it "normal".

The only solution I found was to insulate myself from the higher-ups with a technically knowledgeable manager.  Let him/her give those presentations. If that type of manager doesn't exist, dust off your resume. Any company where the management is THAT ignorant of the technology will soon be in the tight spins ‘round the toilet bowl.

Brandon Knowle
Tuesday, January 15, 2002

I hope you can also see this as an opportunity to educate your co-workers and hone your own business skills.  You may have 30 more years ahead of you in your career.  You may want to run your own company or department some day.  If fact your technical knowledge will be invaluable for managing a technical organization.

But your ability to communicate with all kinds of folks at all technical and business levels is vital:  You may have to keep the marketing folks off of the programmers' back some day.  Your communication skills may help your company make a sale, they may convince your management to make changes that improve life for the technical folks.

As irritating as these presentations may be, they are opportunities for you and your profession.  This is from Philip Greenspun, “ … a professional programmer teaches face-to-face; we've not found a substitute for face-to-face interaction so a software engineering professional should teach fellow workers via code review, teach short overview lectures to large audiences, and help teach multi-week courses.”

Tuesday, January 15, 2002

Teaching is life, baby. Deal with it.

Tuesday, January 15, 2002

Whilst I have no problem with teaching people things, it really does shock me how little technology many project managers know. Most of them are paid more than developers, a lot act with a  "holier (and smarter) than thou" attitude to their developers, and yet they dont take the time to understand their own industry? Pathetic.

Quite frankly I've had enough of project managers. They love to claim they are "technical" to gain kudos with the developers, but it is all too easy to spot the clueless ones. I used to work at an OS company, and the number of clueless PM their was shocking.

The best "project managers" are those that actually are technical, and most of these are decent, experienced developers taking a team leadership role. Not just people trying to jump onto the IT bandwagon.

Tuesday, January 15, 2002

While working for a dot com that does business with several fortune 500 companies, I was given the chance to give a series of technical workshops for marketing people and project managers. We discussed transaction processing, scalability, security, XML and many other topics. It was fun.

I think I can be a good communicator, but I can understand how a technical person would rather not have to deal with teaching. However, I would suggest that technical proficiency is not what keeps a business afloat. Marketing people and project managers should be given their due. Technical people do not always understand business.

I do not think a company will go under because the PMs are not technical, but I do think a company can be hurt when PMs and technical people do not learn from each other. More to the point, a company can be hurt when technical people refuse to teach.

Jim Cassidy
Tuesday, January 15, 2002

All good points. I for one, enjoy giving presentations and teaching. Most developers aren't like this.

I also certainly dont think developers know much (if anything) about business - but then I dont many developers who claim they do and then try to interfere with the work of the biz guys.

My experiences with project managers on the whole have been poor, but I have had the pleasure of working with a few (very few) good ones. But if you are at a hi-tech company and the PM guys are slowing you down because they dont understand the heart of the business, then you are in real trouble.

If the business guys dont understand the technology, how can they come up with effective strategy? If the technical people are having to fight to be heard, to fight to get the business guys to understand industry developments, the organisation's decision making and execution ability is potentially crippled. Especially if the competition is well resourced, a monopoly, savagely competitive and smart.

Getting good business guys and PMs is essential. This means they must know about technology and the industry, and make the effort to keep up to speed. They should also be prepared to listen and learn (this goes for developers too). Anything else is a recipe for disaster.

Tuesday, January 15, 2002

Fear can be a useful motivator.  Think about it this way: people who make purchasing decisions in your company are asking for a dumbed down explanation of why you're using a technology set.  If they don't get it from you, they'll get what they're wanting from someone, quite likely an outside vendor, and your next grumble will be about how your irrational management team have directed you to use an inappropriate technology because some salesweasel sold them on it.

It can be awkward to communicate technical information to non-technical people, but it is a skill well worth aquiring.

Rodger Donaldson
Tuesday, January 15, 2002

I think it would be great to have a project manager that is also technically oriented, but it's not always possible.  What's more important (IMO) is that they can effectively coordinate their team and act as a liason to management so developers aren't bogged down.

If managers are doing this effectively, I think it's great that they want to know more about the technology their team is dealing with.  Teaching is a great link between developers and managers.

On the other hand, if the manager is NOT effectively doing his/her job, it can be frustrating and belittling to teach them things so they can spit it back to superiors and appear knowledgeable and researched. 

So, without knowing more, I wouldn't say that you are doomed, but it's good to acknowledge red flags. 

Tuesday, January 15, 2002

I'm wondering if you don't need different approaches based on what type of techno-clueless person is hassling you.
a) It's an airhead looking for words to throw around, you need to detect and defuse him. First be courteous, give him a book and say you could never explain it as well as the author. If he persists, you've detected him and now need to defuse: confuse him to hell with your explanations, go off on tangents, mix different levels of detail and overview, contradict yourself, mumble, etc. Teach him to leave you alone when it comes down to buzzwords. As previous posters mentioned, these bozos are red flags, leave your company if they are too numerous.
But in general, you'll find that the problem is:
b) Your manager is mainly business-oriented, keep him there by asking what his requirements are: "Well, I'm a tech guy, I don't understand your business and don't expect you to understand mine. So I need your help to understand your request: would you rather have downtime for the whole site for a few minutes each time we update the site, OR would you rather have limits on the flashy interaction we can have with the user in his browser?" Translate this internally to your choice of technology.
When troubled times come and the powers-that-be are asking why management chose to buy into technology A instead of B, it will not be because management did not understand the technobabble. It was because they either
1) did not follow up on the recommendations from IT (archive all your correspondence). Red flag. Leave.
2) could not formulate or have changed their requirements.

The latter situation is common even for competent people of good will. This is where efforts should be redirected to. They will need all your help to understand what is this actually need (which is completely different from what they say they want). Technically savvy managers help, but are not mandatory.

To get back to your original question, handle it with requirements / priorities as above:
"Would you like me to finish this product on time OR would you like a 2-hour presentation which will make us 2 days late?" "Would you like me to explain the implications of J2EE using the words 'transaction' and 'component' OR would you rather have me organize a session that explains the words I am not allowed to use?" Make it clear that it's an either/or choice, not a have-your-cake-and-eat-it-too.

Wednesday, January 16, 2002

One of the best experiences I've had as a Project Manager/Product Manager (yeah, one of the bad guys) is when my company was on a private investment generating tour. 

I was the manager for the lead product, so it was me and the CEO on the road show.  We did 50 presentations in 4 months and raised 2.5 million dollars.  The beauty of it was that I was presenting our product to people ranging from the CEO's of high tech companies, to dentists.

The ability to present a technical product to people ranging from no technical experience to in depth experience is extremely valuable.

In fact, this skill was one of the keys that helped be beat about a dozen other candidates for a new job, recently.

It can also be very rewarding.  When you help a non-technical person understand technology, they feel like one of the "insiders." They often turn into one of your best evangelists.


Bob Crosley
Wednesday, January 16, 2002

>When you help a non-technical person
>understand technology, they ... often
>turn into ... your best evangelists.

This is a brilliant statement.  So true.

DB Cooper
Thursday, January 17, 2002

If they can't understand what "transactions" and "component" means then your company is in trouble.  I'd be embarrased to be around people with that sort of IQ.  Those are almost common everyday words that are used by IT managers all of the time.

Instead of holding pointless presentations trying to bring them up to speed on the latest buzzword craze, you should hold a presentation on how to use resources such as a search engine to find information.  If they had just spent a few seconds typing in J2EE or surfing on the Sun website they would've come up with tons of white papers written for execs that don't know a "transaction" from a "transistor" or a "component" from a "computer".  They need to be able to research this stuff on their own and THEN if they still don't get it should they go to a more technical person for assistance in explaining the concept.

My $0.02 :)

Saturday, January 19, 2002

Be careful what you ask for, because you might just get it.

I think that project managers that come from a technical background are not necessarily a good thing. In fact some of them can be the worse project managers than the technicaly clueless.

I once had a project manager that was a system administrator in a previous life. Sure he knew about networking protocols, server setups, strong skills in shell scripting. This was early in my career, I was involved in implementing an invoicing system that I didn't design and this guy was my manager.

Two days before final delivery the guy comes to me and says that the customer just noticed that they bill differently depending on certain categories of clients. Since that wasn't in the requirements, the design didn't support it. Yes, it was "Waterfall" hell.

When I said that implementing that feature would mean a rewrite of the core of the billing system, my manager went mad, saying that I was stupid for requesting so much time for something that he knows he could do in a day.

Just because he suppossed software development, was similar to writing shell scripts, he assumed everything really was that "simple".

I think I have learnt more things in that job than in any other. It's been a long time since then, but getting a job that teaches you what NOT-to-do is almost as beneficial to your career than to get one that does. That, or I am a masochist...

Beka Pantone
Tuesday, January 22, 2002

"But getting a job that teaches you what NOT-to-do is almost as beneficial to your career than to get one that does."

I kinda agree with that, I got a lot of education just watching the screwups at my last job.  Of course now I gotta find a way of putting "labored in vain with idiots" on my resume in a manner that sounds good ...

I think technical ability is a necessary, although not sufficient, prerequisite to becoming a project manager.  There's a certain amount of people skills that need to be involved.

Wednesday, January 23, 2002

*  Recent Topics

*  Fog Creek Home