The Career Management Gorilla

There I sat, skimming through Monster job listings. "Out of state, not enough pay, under qualified, over qualified.. Ah ha!" Like it was outlined in glowing neon letters, it jumped out at me. Perfect location, good benefits, looked like it would pay just right.

I clicked on the 'apply now' button with eager glee. I browsed to my job hunting folder and found my resume, jbancroftconnors_resume. Smiling ear to ear I moved my mouse over the submit button. And that's when the smell of ripe banana hit me.

"Yur not gonna send that are you?"

Turning in my seat I looked up at Hogarth. "Of course I am. I'm perfect for this job. Heck it even ties into my old art school background."

Waving his half eaten banana at the screen my resident gorilla grunted, "Yeah but your resume doesn't mention that. And look here, the job is asking for someone who's worked with call centers in Ireland."

I grin cheerfully, "Right! And I've worked with Ireland in my last two jobs!"

"And your resume doesn't say that. Aren't you gonna customize it for this job?"

Sigh… The dreaded resume tailoring gorilla. We all know we should do it. Some of us do it, some of us never do it and others agonize for days to make each and every resume just perfectly right. Two things are a given with resume tailoring. 1- It's a good idea. 2- It's time consuming.

Regular exercise is a good idea too, want to know the last time I hit the gym?

Still, Hogarth had a point. I had fallen into the online application rut. I was using a 'good enough' resume and no cover letter. It's a wonder I got any phone calls (okay so to be fair, I was doing the networking thing and writing cover letters, but I was not customizing my resume).

Knowing I was doing it wrong but also being an efficiency minded project manager I sought a better way of doing things.

Enter the "Career Management Document". Full credit goes to Mike and Mark of Manager Tools. Their "Your Resume Stinks!" and "Accomplishments- Connecting your Resume and Interviews" pod casts gave me the idea for this. In these casts Mark Horstman describes how your resume should never be more than a single page, but your list of job accomplishments are not tied to the actual resume. Create a "Career Management" document (CMD) in which you have all the jobs you've worked. Under each job you list all your notable accomplishments, not just the ones that are current. Every three months you go through your CMD and look at all the jobs. Maybe you just got done with an ugly budget process and you remember that ten years ago you had to fix a budget on short notice. So you go back and update that old job with the accomplishment.

Then for every job you apply for, you go through and pick 3-5 accomplishments that make the most sense. Instead of manually crafting every resume, for every job, you take your 'Chinese menu' and pick what works.

Personally I use Mindmanager, from Mindjet to manage my CMD. I've got a Mind Map with bubbles for each of my jobs, career over view and my professional qualifications. I can export it to a word document, cut out what I don't need and bam! I have a tailored resume.

Here's a sample of what it looks like:

http://i18.photobucket.com/albums/b128/Welshman_BC/CMDTemplate.jpg

So with my career management gorilla appeased, I hit submit on my next great career. And a few months later, I'm very happy with that new job.

If you are interested in a copy of my MindMap template or want a PDF of the template, just send an email.

So until next time, don't forget to talk to your gorilla.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The gorilla with too many hats

"So that said, can you code?"


I look across the interview table. Well okay I look at the telephone, cause I'm in the companies office but the person I'm interviewing with is sitting in his house 20 miles away. But that's another gorilla.


So I look at the phone.


I look down at my resume.


I look at the job description for this job.


Apparently, my interviewer takes my stunned silence for a request for more information. "Cause you see, we're running lean and we need people to do more than one thing. We might have to send you out to do a customer implementation by yourself. So how's your coding?"


Now Hogarth doesn't mind that the guy is on the phone. He's taking advantage of that by taking up the other two chairs in the room. "Welcome to the Teens, dude. If you can't do it all, then you're not good enough. Everyone has to work harder these days. If you can't code, do a balance sheet, fly to Malaysia for the weekend to close a sale and then get back on Monday to make sure the 300 person software roll out is on schedule, then you're no good to them."



Sigh… The "multi-hat gorilla"

Now Hogarth is right, to an extent. 2010 will probably go down as the year of 'do more'. With the global recession we are all being asked to work harder and do more in our jobs. It's part of the downside of the recession and the trend of higher productivity.

I'm all for productivity, but there's a difference between productivity and continuous partial attention. As you might guess, I'm not a fan of the CPA concept. Studies have proven (UCSD Study, MSFT Findings, just to name the first two I Googled) interruptions seriously affect performance. A single 30 second interruption can result in a 15 minute work loss.

I look back at the phone, "I don't code, that's what the engineer is for. My value is in making it so the engineer can focus on his job and not on the surrounding project issues. If you have four engineers working on the project of this size, adding a fifth one is already starting to hit that wall of diminishing return. If you add a dedicated program manager, you can get more productivity from those four engineers, than you would from adding a fifth engineer and expecting one or more of those engineers to also manage the customer relationships, deadlines, certifications, interface with marketing, etc."

"Uh huh…." came the reply from the phone. "So you don't code?"

Some gorillas are just better to let be.

There is value in improved productivity and we're doing more with less is the new norm. But all that said, a good, solid, project manager can make a team run more efficiently than just tossing another engineer on the pile. At least that's what Hogarth and I think.

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email

Book Review- Evaluating Project Decisions

Greetings all!

 

After a long holiday break Hogarth and I are finally back. Hogarth is still getting over a banana hang over so today we'll take a break from our normal format to offer up a book review.

 

I am a member of the Bay Area Agile Planning Leadership Network. Recently BayAPLN was asked to review a selection of books. I volunteered, hoping to learn about some new tools and pass on my review for others at the same time. Now, Hogarth and I do not take our commitments lightly. So when we agreed to review "Evaluating Project Decisions - Case Studies In Software Engineering" by Carol L Hoover, Mel Rosso-Llopart and Gil Taran, we were bound and determined to read the book and provide the best possible review.

Well you know what they say about good intentions? Over the course of a month, I attempted to complete the book. I actually ended up scheduling time on my calendar and even using self rewards for every section I finished reading. In the end I was only able to plow halfway through the book before I finally gave up.

So to start with the bottom line up front, I give this book a failing grade. The only place I would recommend someone read this book, is if they are taking a course that it is required reading and they do not know anything about project management what so ever. There were several things that culminated in my rating of this book. A number of these so grievous, to be enough to prevent me from ever recommending the book on their own. Together they compile up that I can't in good conscience recommend this book at all.

The highly academic bent of the book is not in and of itself a bad thing. There are many well written text books out there. The thing is, they are supposed to be Text books and are tied to a course that will fill in the missing information. "Evaluating" did not actually give you answers or final solutions to the case studies. Instead the case studies all ended with a Case Analysis section that asked a bunch of questions. This is fine for a text book that leads to a class lecture, but as a business book on project management it failed to deliver. I was left wanting to know the analysis, but instead was faced with a homework assignment.

The explanation portions of each chapter were likewise difficult for me to absorb. The authors provided what I found to be simplistic overviews of what I consider basic foundational project management. For a computer sciences bachelor student the overview is probably helpful, likely having minimal exposure to project management principles. For anyone with even a few years in the software industry, the text would have been a very dry review.

After the third chapter of project management for dummies, capped by case studies that didn't actually give suggested solutions I finally set the book aside. The flavor of the book and the errors I had run head long into had finally built up to make it impossible to complete the book.

Speaking of those errors, those are perhaps the single largest contributor to why I finally gave up. Faced with text that was dry and offered little new concepts was difficult enough. But when I was questioning every fact in the book, it just made it impossible to continue.

Errors ranged from obvious grammar errors, ones I could spot and I'm known for my own poor grammar to basic fact issues like you don't take a few days to "Jaunt on the San Francisco Bay". SF Bay is the kind of bay you go out for a few hours and then go home. It was however the Earthquake fiasco that so irreparably shook my faith in the authors ability to fact check that I began to question if they were not just making things up to fit their findings and premise.

For those who really want to know I've included my rant (I can't justifiably call it anything else) about the Earthquake fiasco below.

For the rest, I must again advise against the reading of this book unless assigned by your professor. And even then, I'd reconsider that class if the professor is using this as their source material.

For Hogarth and myself I bid you happy project management dreams,

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

The Earthquake fiasco:

I made it only as far as page ten before I found myself deeply questioning the book. The authors created a case study called the "California Bridge Problem". So wrought with errors was this case study, that I immediately found myself questioning everything else I read. This wasn't some minor little error, this case study was so rife with errors the facts presented almost seemed to be 'adjusted' to fit the needs of the story. Anyone who spent even a twenty minutes with Google will note the massive errors. Having lived in California all my life I didn't even need twenty minutes to question everything this book had to say.

"It can't be that bad you say?"

Well let's see:

• 
  
  The Authors merged the 1989 Loma Prieta and 1994 Northridge earthquakes into a single event.
  
  
  They said it occurred in 1991 (This is the date of yet a third somehwhat famous quake called the Sierra Madre quake).
  
  
• The ascribed the quake as an 8.49. The Loma Prieta quake was a 7.0 and the Northridge a 6.7. The Richter scale is a logrithmic scale, so an 8.5 quake would be equal 5.5 gigtons of TNT a 7.0 only 32 gigtons. Just a little off in the power. There are only 7 recorded quakes of 8.1 or greater in known history. One of them is the one caused by the asteroid that killed the dinosaurs!
• The stated the quake lasted two minutes. Both quakes were around 20 seconds. Quakes of two minutes in length are incredibly rare and usually much stronger.
• They claimed the Bay Bridge collapsed because of inadequate concrete columns. No the bay Bridge is a metal structure. It was freeway overpasses that collapsed in both the 89 and 94 quake.
• Even the proposed new way of building bridges missed the mark. Encasing in steel sleeves was a suggested retrofit for existing highway bridges that could not be built to the new recommended spiral reinforcements. 

Yeah it was bad... And you know how I feel about not addressing the Gorilla in the Room.

Every project is a screwdriver - or the process inflexibility gorilla

[Thanks to Phillip Chen, for the inspiration for this blog. His discussion thread on "Do you tailor PMBOK or other PM methodologies for your projects?" in the PMP LinkedIn group, sparked a reply by myself that spawned this blog. ]


Things are really looking up. Just got transferred to the newly formed product incubation group. The company is finally putting innovation up as one of the top three business goals for the coming year and you're on the bottom floor of the new team.


You were worried for a while there, market share was slipping and it just didn't seem like anyone was willing to break the cycle. No one wanted to point out the Emperor had no clothes and winter was coming. But the board did. Now you've got a new CEO and he's shaking things up. What could go wrong?


"That is not how we do it."


"But this is totally new product line, it's nothing like our existing products. If we follow the same process we won't get to market for two years."


"No exceptions, we have a process, it works and you will follow it."


Welcome to the PIG:
And wham, you run right into the Process Inflexibility Gorilla. Hogarth and I have talked about his cousin, PIG, on many occasions. As Hogarth oft recalls "He makes the immoveable object look like a hockey puck in the Stanley Cup."

PIG generally hangs out in larger, more established companies. He's at home in long standing businesses that have managed to keep doing what they do, with the minimal amount of change. It seems that sometimes that success is in spite of themselves. As often happens, the process inflexibility gorilla is so firmly entrenched, that he is all but invisible to those around him. He is not just ignored but not even seen. It takes a business change, or a new set of eyes to see him. The challenge that then comes, is how to get those entrenched with him, to actually see him.

A company hired a Director of QA. They had previously practiced a developer QA model, with the philosophy that the best person to test code was the person who wrote it. This director, we'll call him Saul (I just made it up on the spot folks), was given a broad charter, promises of support and let loose on the engineering organization. Now Saul was an effective executive. He knew he couldn't just sweep in and "lay down the law" no matter how much air cover he might (or might not) have. Saul took his time, he asked lots of questions, observed, got to know people and laid out his plan. He made some minor wins and changes, but for the most part he spent the first few months collecting data. All in preparation for laying out a whole new QA methodology, just like the charter he'd been given said to do.

Only when it came time to roll it out he ran into a massive wall, one that made China's Great Wall look like one of those Irish rock walls in a sheep pasture. So powerful was the institution, to the way things were 'supposed' to work, that even his powerful executive sponsors backed down. So entrenched was the "way its done", that no one was willing to consider that the business had changed, or needed to change for it to continue to compete effectively. In the end Saul left the company, unwilling to spend the rest of his career trying to get people to see the invisible gorilla.


So, how do you deal with such a pervasive and hard to see gorilla? It's not easy and it may not even be possible, but there are some things you can try.

Now one thing you may of noticed in my style, is I like analogies. I've found if you can break something out of the now and use something totally unrelated to explain it. When this topic came up in the PMP LinkedIn discussion forums I used the 'screwdriver story'.

"Yeah sure, that screwdriver is absolutely perfect for that job. But not every job is identical."

Of course many entrenched people will argue that everything is identical. Yeah that may be their point of view, but I just keep on with my analogy.

      "We both have a budget of $200. I'll take money and buy a nice , simple toolbox with all the normal tools in, you know hammer, phillips, flat head, wrench, etc. and you can use your super whiz bang phillips head screw driver that is exactly perfect for the currently defined job." "I'll do this because when you get stuck in a room (project) that has nothing but flat head screws, your fancy screw driver is just a pointy stick."

Something you have to go back to, in times like these, is the concept of innovation. If you have inflexible process you probably have one of two things. You have inflexible products, which will be unable to compete in the continuing market place. Or you have products that are not being managed efficiently because they are square pegs being shoved in round roles and shaving off parts to fit. I your company is not flexible, how long will it continue to survive?

All right, while a very satisfying conversation it won't sway every listener. The people who are inflexible in process are often not going to want to consider there might be anything but phillips screws in their company. These kind of people are going to bristle when you imply the company might fail through lack of change. "That's the way we've always done it." So what do you do? Tough question and no easy answer.
One thing you can try, is to work around the road block. If you have good cross organization and seniority relationships, you might be able to push for change from another direction. You have to be careful though, as this steps into the touchy 'going over/around someone' politics.

When it comes down to addressing the Process Inflexibility Gorilla (PIG), we once again come back to relationship and influence. While Saul failed in his endeavor, more often than not a strong and broad set of relationships should allow you to get the value benefit of making process change across to people who can affect the change.

Don't cry "The emperor has no clothes" or in this case "Look an invisible gorilla!" Instead steer people so they can't help but run into the invisible gorilla. Once you run into an 800 pound gorilla it doesn't really matter if you can't see it, you know its there.


Talking with gorillas, I'm Joel BC

The Conflict Gorilla

"Absolutely not! That would be a complete waste of resources and I won't sanction it."

Around the table feet shuffle, eyes find fascinating patterns in carpets and ceiling tiles and not a person responds to the declarative outburst. Deeply intent on your nearly empty page of notes, you try and ignore the looming form of Hogarth the gorilla.

"I thought the product manager owned the product?" he asks, munching noisily on a banana.

I direct a jail house whisper at Hogarth "She's the VP of release engineering, she out ranks everyone in the room."

"Mmh.., , but she's not on the project team, is she?"

"She doesn't have to be, she can make any of our lives miserable."

Hogarth picks a flea from his fur and flicks it into the garbage can. "So she can use her role power to cow you all into place, cause no one wants to disagree with her?"

"Shut up Hogarth."

The Conflict gorilla: A more frightening and unapproachable gorilla you will likely never find. Most people inherently shun conflict. Those that do not, often tackle it head on and get swatted down for their temerity, with the same end result. The above example is a radical one. The fear of a high-ranking person's power has cowed many a bright manager to inaction. But it is not the only time we avoid conflict. How many times has someone complained about quality of another peers work, unmet deliverables or more direct negative behaviors (She's always interrupting me, I can never finish a sentence).

Yet when you ask that person (or yourself, let's be honest here) what they(you) did about it, invariably the answer is in the range of 'nothing', 'I sent an email', 'You're my boss, what can you do?'?

It's amazing in a world, so filled with global conflict, that we tend to avoid any semblance of it in our professional and personal lives. Someone, somewhere, is probably earning their PhD, studying how conflict-avoiding seeking people can have spent so many centuries in global scale wars. Well let me be the first to step up and say "Hi, my name is Joel and I'm an anti-conflicter."

As I look back on my years in Silicon Valley I cannot count the number of times I ran headlong into a conflict situation and let fear, desire to not rock the boat, not become a target, rule my actions. And to what cost? Would I have gotten that promotion, would that million dollar bug have been fixed, would the team been more productive, and so on?

This gorilla has long been the bane of my existence. I knew it was an issue, I knew it was a roadblock, but I could never get past it. Then I heard a wonderful quote. Mark Hortsman, management consultant and podcaster said "My uncle always used to say, conflict is any two people in the same county". Wow… so I can't avoid conflict. In fact conflict isn't necessarily a bad thing. Are you saying, that just as Risk Management says a risk can be a good or bad event, so is it with conflict?

There you have it folks, like it or not we are stuck with conflict. The question is, will we have good conflict or bad conflict?

Now before I give some of my own personal tips, let me advise you against what NOT to do:

Some people like to confront conflict head on. In the above example, let's say the Product Manager had gone head on with the VP, saying some thing like "That's my decision and between myself and the developers."

Now the Product Manager is technically correct, but even as nicely worded as that was, it is a slam right in the face of the VP. The entire rest of the meeting just became ringside seats to the conflict. Just because you have the will to face the conflict, doesn't mean you should charge in guns blazing. Look what it did for the Charge of the Light Brigade.

So how would I approach the situation?:

Well in the above situation, imagine if you as the Project or Product Manager has just said, "Okay", or "Okay, thanks for your input" ?

One of the first things to diffusing conflict is to not rise to it. Think of good forum posting etiquette. If you are in a hot thread, the rule is thirty minutes. After you write your post, wait thirty minutes, read it again and ask if you really need to send it.

At the highest level, dealing with conflict has to do with making a safe environment for both sides to talk freely.

Which brings us back to a theme I sense developing in this blog, relationships. If you have a good working relationship with not only your team, but your stakeholders and the extended team, then you will have less negative conflict. Get out of your cube and talk to that VP, get to know more about them than the color of their Blackberry.

Here are some resources I've found that are helpful to dealing with conflict:

• Dialogue Smarts: Skills for Mastering Crucial Conversations : Find someplace that conducts the training. One of my old companies offered it and I still have the Dialogue flip cards on my desk.
• Crucial Conversations: This is the book by the creators of the course. If you can't take the course, buy the book (or both).
• 
  
  Management-Tools.com: No I don't get paid to endorse them. I just have found they really work. I recommend the podcasts on Feedback (Especially the Feedback for Project Managers and Peer Feedback), the "Feel, Felt, Found" podcast, the Resolving Conflict podcast and their series on communicating to the DISC profile system.
  
  
  
  In the end, we can't avoid conflict. As long as we are not monks on a mountain top we will encounter conflict. The question is how we will deal with it. As a reminder hint, hiding in the turtle shell is not the solution.
  
  
  I'm Joel BC, Gorilla Talker