Montague.tv

PM:  You want estimates?
Mgr:  I think I’m entitled to them.

PM:  You want estimates?
Mgr:  I want the truth!

PM:  You can’t handle the truth!!

Son, we live in a world of computer applications and those applications have to be built by people who write user stories. Who’s gonna do it? You? I have more responsibility than you could possibly fathom. You have that luxury. You have the luxury of not knowing what I know. That Version 1’s existence, while inexplicable to developers, helps project teams build applications. And that my profession, while incomprehensible and grotesque to you, also helps build applications. We use words like user story, range based estimates, and done criteria. We use these as the backbone of a life spent building and defining something; you use them as a punchline. I have neither the time nor the inclination to explain myself to a person who develops and tests off the well written stories we provide, and then questions the matter in which we provide it. I prefer you said “thank you,” and went on your way. Otherwise I suggest you log into Version 1 and update your story estimates; either way, I don’t give a damn what you think you are entitled to.

Mgr:  Did you under-estimate that story?
PM:  I did what I had to.

Mgr:  Did you under-estimate that story!?
PM:  You’re God damn right I did!

(Via Andy Sargent, Project Manager)

I cannot tell you how often I hear the term “guideline” these days.  It seems to creep into every other meeting or so, especially when “new and improved” concepts are being discussed at the management table.  In my eyes, even if you substitute the word “guideline” for rules, you still view them as rules.  Why do I think this?  Well, just like in Texas Hold ‘Em, there’s a tell.

When someone begins their explanation about a new process (that has taken weeks to draw in Visio or to create in Power Point slides) by saying, right out of the gate:

“OK.  This is a guideline, not a RULE…but a simple GUIDELINE”

…then you know it’s a RULE.  Period.

This substitution is transparent & disingenuous.  Please don’t hide behind this obvious bait and switch.  If you want to create rules, say as much.  At the very least it gives the poor souls subjected to the rules a chance at an open discussion with you.  I have been guilty of this misdeed in the past, and my main motivation was to avoid difficult discussions.  To create a culture of openness and trust, I feel we need to relish the opportunity to open a dialogue.  It might be more painful (especially if you feel a specific RULE is critical), but the team will be stronger if you hit this challenge head on.

I have been thinking a lot lately about how I might go about working with teams to ensure they understand the main message behind agile engineering practices. In many ways, the knee jerk reaction of many managers, including me, is to edict the use of common practices and skills. In my past, I have heard many many reasons for why people don’t want to unit test, setup build automation, peer review code, and refactor. What I haven’t heard is a GOOD reason. This has made it even tougher to refrain from handing down a set of criteria to the teams on “how to code”. After all, for me these practices “just makes sense”.

“What” vs “How”
A lot has been said about internal versus external system quality and I think this concept has helped me teach the difference between “what” systems teams deliver, and “how” those systems are built.  When starting a conversation with teams about learning the well tested agile engineering practices, I typically hear a common refrain.

“We are senior developers.  We don’t need to improve quality. We’re doing great…just ask the business!”

In one way, they are RIGHT. The business loves what they are seeing. But quality to a user of a system is only skin deep. They see half the equation (arguably the most critical) but half none the less. They see the working system. They see the new feature they requested and by gosh it works exactly as expected!  The system is performing as expected.  There may be a few lingering issues, but 95% of the system is awesome.  It supports the business just fine.  Mostly, we just need more features, faster!

Lurking Under the Surface
So what don’t customers see?

• They don’t see the manual jobs we kick off behind the scenes every morning to ensure the data “looks right”.
• They don’t see the delays to building products because only one person knows each individual part of the system, and if they are busy (or even worse on vacation), then nothing in that specific module can be delivered.
• They don’t see the painstaking manual testing efforts that go on before we push to UAT.
• They don’t see the manual roll out, roll back, roll out dance we do simply “moving” code to UAT and PROD.
• They don’t see massive nested If-Statements that look like Japanese word art.
• They don’t see the 12 year old version of J++ that their core processing engine is built with, and that if Christy loses the J++ disk she has in her desk drawer, we’re screwed.
• They don’t see how difficult it is to add simple logic to the system each time they ask for something new.
• They don’t see how often even simple changes strike fear into the hearts of anyone relatively new to the team.
• They don’t see the 18 month ramp up time it takes skilled developers to “learn the system”.
• They don’t realize that “regression testing” really means “test whatever we can for the 2 weeks we have left”.  (hint: ~10% of features)
• Etc, etc, on and on, ad infinitum -1.

For the above reasons, we need to be better.  As technologists, we need to be stewards of our systems.  And in many ways, that means protecting both “external” and “internal” quality.

Stewards? What does that mean?
It means if there are time bombs in our code, we have to make those time bombs REAL to the business and advise them how to prioritize up what is critical and to prioritize away what is not. In technical debt terms, pay down your high interest technical debt quickly by prioritizing it as high up in the backlog as possible. Business people will never do this on their own. We have to help them toward this decision.

It also relates to “how” we build systems.  As professionals, we need test automation, build automation, refactoring, pairing, peer reviews, patterns, etc.  This is where my brain and my emotions clash.  On one hand I want to pass down upon high an EDICT, “Thou shalt unit test!”  I would say this is my emotional, impatient side.  Intellectually I understand that I need to lead these teams toward these principles.  More “supposing” and less “proposing”, as they say.  The minute I create the rule, the simple and powerful act of automated unit tests lose their power.  People begin to test in haste.  They write tests that assert nothing so test coverage reports show arbitrarily high numbers.  They write tasks for testing and never get them written.  They come up with every reason in the book why testing isn’t that valuable for them, in their system. And when rules are imposed, any shortcomings, difficulties, roadblocks, or otherwise ill will surrounding the approach are attributed to external sources…namely, me. After all, this is Jason’s RULE. He owns it, not us.

Grass Roots
So, I am back to the grass roots. I want to rebrand engineering principles (and the stewardship it implies) as a virtue, not a rule.  I am back to the task of building a ground swell in our culture.  I am back to focusing my efforts around a few key (and critical) early adopters who have seen the value of software craftsmanship.  With these progressive folks, I hope to create a magnetic pull.  A “why aren’t we doing that” effect that emanates.

With the rest, I have but one request:

“If you don’t think that these principles and techniques are valuable, so be it.  In the absence of using these techniques, please show me how you can assure consistent, sustainable, internal and external quality of the systems in which you have been granted stewardship.”

I am being sincere when I say I am open to being wrong about this.  If those principles I have come to lean on are of low value for these teams (and in their context), I am anxious for a better answer.  More to come!

I recently re-read The 5 Dysfunctions of a Team. I am through it for the 2nd time and find that I have gleaned so much more this time around.

The Role of a Leader: (A look back at 5 Team Dysfunctions)

1. Absence of Trust – Avoid Invulnerability
2. Fear of Conflict – Avoid Artificial Harmony
3. Lack of Commitment – Force Clarity & Closure
4. Avoidance of Accountability – Confront Low Standards
5. Inattention to Results – Focus on Collective Outcomes

In my first foray into this book, I found many insights useful, but not particularly familiar. I read the book quite a few years ago and really didn’t have the background to understand the content that the book addressed. I just hadn’t faced those types of team building dilemmas (or maybe I just hadn’t thought about it that way). Even in an Agile coaching capacity, I find many small teams quickly gel and find a rhythm, building trust, managing conflict with help, and holding one another accountable. I think software teams are, in the end, really good at this given some subtle guidance.

Fast forward to 2010
I’m currently part of a management team that displays many of the detrimental failure modes that the book describes. Sadly, I’ve come to realize over the years that this is more the rule than the exception. The team members are all, individually, extremely talented.  They are also great people.  I mean that sincerely.  This fact makes me both hopeful and fearful at the same time.

It’s great news because it’s obvious that my current challenge is unambiguous and squarely in front of me:  work on building a dynamic and healthy TEAM.  It’s also scary because I now know what I need to do: work on building a dynamic and healthy TEAM!

This supremely simple concept, the one that eludes 95% of leadership teams in all types of organizations, is one of the most difficult experiences teams can go through. Knowingly embarking on that journey is a sure-fire way to bring emotional exhaustion and short-term discomfort to your collective lives.  But alas, like many things in life, I know it’s critical and completely necessary. There is no exception.

Mentally I know that this hard work and emotional discomfort will be the only way to long-term fulfillment and happiness in a collaborative endeavor like building great software for customers.

Outlook
I’m growing more encouraged day by day.

This book by Seth Godin works because it “tells a story”. It’s about the power of marketing if your savvy enough to tell a story and be authentic about it.

What Would you Pay for a cup of Coffee?
Think for a moment about your morning routine. When you walk into Starbucks for example, you are walking into the middle of a story. What is it? It’s that Starbucks feels, smells, and exudes comfort. The “barista’s” are all friendly (and many times remember your name and your special drink). Even the small fact that they are called “baristas” tells a story. They don’t just pour coffee and fetch scones. They are actors helping tell you a story.

The big chairs and wi-fi access, the fireplace, and the friendly people are all there to tell a story….and it’s not, “our coffee beats all others in blind taste tests”. In many ways, the coffee is only a small, well placed treat in the bigger context of the story you walked into. Why else would people pay $4.00 for a $.038 cup of coffee?

Mickey Mouse Punched Me in the Face
I have recently been smacked squarely in the face by the concept from Godin’s book…by Mickey Mouse. My family and I just returned from Disneyland in Southern California and I have to say I was shocked. I don’t want to over sell this point, but everything about Disney tells an authentic story to its customers. From the minute my family got on the bus (in the remote parking lot) to the moment we reached the Magic Kingdom, my 2 kids mouths were agape.

In the park, there were thousands upon thousands of patrons. Shockingly, nothing was out of character. Everything in the park, right down to the lamp posts told me a story. Disney understands this so well that all employees are considered “cast members” including the folks walking around picking up the trash. (An interesting note: I don’t recall seeing a shred of trash on the ground. At the same time, I don’t recall seeing more than 2 people cleaning anything up. How can that be? ) The result: my kids were transported to a place that truly “seemed” magical, right down to the last fireworks display over the castle as we left the park. For me, this was priceless.

The Value of Authentic Storytelling
No matter what business you are in, creating stories about you and your product or service is critical. I help organizations build software solutions. Even there, the value of selling “experiences” is critical. I will be trying much harder to craft stories (and teach storytelling) that help us give our customers a fantastic experience. I want to create raving fans for our service and storytelling can help. Godin does a fabulous job of distilling this concept to its essence. He helps you understand that you don’t have to be Walt Disney to see value in telling stories to your customers and the benefit of making it authentic. Every business has a chance to differentiate itself in this way.

“Drive”, by Daniel Pink answers plainly the omnipresent question “What will make me happy and engaged in my life and  career?”. What I have felt so strongly throughout my career is confronted head on in this book and the answers you uncover will likely surprise you.

Like many, I typically would fall back to standard, cliche’ answers:

• “I want to be promoted. If I just moved up, I would be happy.”
• “I want to manage people. The more in my organization, the happier I will be.”
• “I don’t have enough money. I really just need more money to be happy.”

 
All of these things have come pretty quickly in my career, and I can tell you without doubt, they do not ensure sustainable engagement, motivation, or happiness. The things that have motivated me seem to be the residue of having a persuasive personality and organizing my work (come hell or high water) to give myself the three things Dan Pink describes as critical. 

1. Autonomy – being self directed and interested
2. Mastery – being great at what I do
3. Purpose – what I do “means” something and makes a difference

 
Not only does the book describe those motivators, it also explains the incredible disconnect employers of “thought workers” have had (and still have) related to what motivates their teams and workforce. I happen to work with teams that create art for living (software systems). These people spin value out of whole cloth. They essentially take concepts and thoughts and turn them into tangible goods for others to hold, interact with, and use. I cannot think of a better definition of a “thought worker”, can you?

Yet, nearly every employer of software developers I encounter has had it wrong in some form or another. To begin the journey of trying to satisfy the needs of those team members, you first must understand what motivates them. The book has moved me a bit closer to that understanding. This video, brilliantly produced by RSA Animate, gives you some of the shocking truth behind what motivates us.

Adopting an Agile methodology blindly is hazardous. This post will describe my belief that “going Agile” requires a thoughtful, long term, evolutionary approach. To make my case, I want to discuss an Agile Adoption Failure Mode (or anti-pattern) that I’ve experienced and have come to call “Go Agile Early”.

I call it this because of a sweatshirt (yes a sweatshirt) that I see quite regularly on the campus of Purdue University. You see, a large percentage of my family live, work, and were born in West Lafayette, Indiana (Home to the Purdue Boilermakers). I happen to be an Indiana University graduate. If you’re not a Big Ten fan, you might not understand the pain I experience every year as my Mom, an immigration counselor at Purdue, drapes my kids in Purdue garb and fills their toy chest with black and gold basketballs and soccer balls. <yuck>

Anyway, a bar happens to grace the campus of Purdue University called Harry’s Chocolate Shoppe. This bar has a short (dare I say unsavory) slogan that seems to be printed on the back of every 3rd sweatshirt in West Lafayette: Go Ugly Early. Not surprisingly, the Purdue contingent at my family Christmas each year think this is hysterical.

OK, before you accuse me of being unsavory, let me first apologize. I’m sorry for tricking your “Id” into reading my blog post. There. It’s said. As I write this, I keep changing words and phrases because of all the sleazy double entendres that keep popping up (see what I mean). For the record, I’m ashamed of myself.

So now the hard part… <ahem>

Tiptoeing Around the Correlation – Going Agile Early

Wouldn’t it make you feel good if someone said to you, “We love these changes you’ve suggested! Agile makes so much sense. I think we should make this the standard around here”..?

Yes…? Well, it does me as well. So good in fact that it has allowed my ego to blind my better judgment. I think, “Sure, that’s a great idea! Let’s force them to do it! This will be so easy. That’s half the work gone with the snap of the CIO’s fingers. These people don’t REALLY know anything about Agile. That doesn’t matter though. I must be so persuasive. What could go wrong?”

Before I can get my hips back around from patting myself on the back, the long, slow, painful journey toward — complete — process — meltdown — begins.

Tell me if this sounds familiar. You are introduced to a shiny new framework (or process, or methodology, or technique, or yes…(person) if you happen to be at Harry’s Chocolate Shoppe at 12 AM) and you get the feeling almost immediately that this could make all your problems disappear. It seems so easy, so attractive and well packaged, so obvious! There are no noticeable sticking points. No gotchas. No downside. Could it really be this easy? What could go wrong? (I think we all know the answer to this question.)

EVERYTHING can go wrong! The mere fact that you know NOTHING about it (at the very least) should give you pause. Here is a modified timeline of a predictable outcome if you allow this train to leave the station. I’ve left out some detail but you will get the picture.

Hypothetical Failure Timeline

1. Agile edicted to the organization with no significant understanding
2. Projects begin and teams are organized
3. Scrum (easily understood mechanics) is chosen for its simplicity
4. All teams, regardless of work type or need, are forced to “go agile”
5. The PR machine spins up in the organization and business partners are introduced to Agile (typically aren’t impressed)
6. Burn downs and hyper planning starts (teams wonder if they’re doing it right)
7. Managers and project managers misinterpret Sprint backlog detail as a new ability to tightly control projects
8. The awkward transition to stand-ups, chicken/pigs, prioritization, and transparency begins
9. Team struggle to deliver “working features” in a single iteration
10. “Scrum-But” attitude overtakes some teams. Those teams start to sing a resounding chorus: “yes, but Agile won’t really work with MY projects”
11. Results are misinterpreted again by management resulting in more edicts and tightening control
12. Teams begin to look at estimates and hours as their ONLY deliverables (they forget about the business value and point at the zero next to their name in the sprint backlog)
13. Worsening results blamed on overwhelming meetings, planning, and detail “required” by Agile
14. Retrospectives begin to dull (no one brings anything “real” to fix any longer)
15. Organizational impediments are now viewed as “immovable” as early efforts to remove them went unresolved or ignored
16. Business starts to comment on “the stifling bureaucracy and controls”
17. Someone says “Agile just doesn’t work here. We need to be more flexible and responsive.” <WHAT!>

Agile change activities go through lots of stages. Some teams adapt swimmingly. Especially when they know what the phrase “inspect and adapt” means. The problem is that most teams, when thrown into the deep end and don’t “get it”, tend to blame the process. Change agents <you> begin to slowly lose their leverage. No longer can you slowly grow understanding. You are now faced with rampant disinformation and ill-conceived management impositions. Agile starts to “get away from you”. You no longer have the ability to grow and evolve.

Be the Grown Up

To be sure, the responsibility can (and should) be shared on all sides of the decision to Go Agile Early. However, as a leader and change agent in your organization, it is your responsibility to be the grown up. When an unsuspecting client, executive, or team jump at an opportunity to dive headlong into a “methodology one night stand”, use it as an opportunity to show patience and maturity.

Explain that, while you think Agile is a brilliant choice, it won’t (and can’t) work without a reasonable understanding of all its virtues, mannerisms and short-comings from its practitioners. Explain that a slow, measured, evolutionary relationship with Agile will help determine Agile’s “Fit For Purpose” on their teams. If you don’t evolve slowly, you will lose the leverage you need to make changes and prove worth. If you can lead small teams to a level of understanding that is sustainable, then you’re chance for success is drastically improved. If you lead them half way there and set them loose, they will capitulate when things get complex and the failures immediately become YOUR problem. After all, you’re the one who suggested Agile, right? <get him!>

Relationship Advice

Don’t subvert your ability to affect positive, sustainable change. Don’t forget that you are going for a long term relationship here.

Don’t “Go Agile Early”. That’s when it really gets Ugly.

Do your teams use the term “done”.  Does it mean something?  Does capital “D” (Done) mean more than small “d” (done)?  Or do you use the dreaded (done-done-done) to indicate “done”?

Here at GHQ, we have actually uncovered 3 states of “done-ness” on our Agile projects:  Rare, Medium, and Well-Done. I’ve noticed that without exception, every team I have helped adopt new Scrum principles uses the dreaded “done-done-done” moniker, or some such,  to describe a state that essentially means “there’s nothing left to do so we can ship it!”.

In my first coaching endeavor, I thought, “what a unique way for the team to express itself!  That’s so quaint.”  Now, when I hear teams say, “Are you done-done-done?”, a shiver goes up my leg.  This is not the kind of leg shiver Barack Obama gives Chris Matthews.  It’s the bad kind of shiver.

Now with more experience, this phrase (and other like it – see meat analogy above) mostly make me feel like I haven’t done-done-done my job.  At the very least it makes me think that somewhere along the line, I have neglected to describe why DONE needs to stand for something, and why “done-done-done” screams “we still don’t know what DONE means!”

The reason, I believe, this word should mean more is the message it conveys to our customers and our partners.  Applying the reasoning of a lawyer, it doesn’t pass the “reasonable person” test.  If I say the term, “it’s done” to a reasonable person, do they think:

• It’s DONE….

or, do they think

• It still needs to be checked in, unit tested, QA tested, promoted to UAT, UAT tested, validated, blah, blah, blah, etc, etc, etc

As Agile has gained momentum and customers have made their way into our stand-ups, design sessions, and overall daily lives, we as software development organizations need to be cognoscente of the messages we send.  Scrum has done a pretty good job of making us realize that demo’s mean something to our business partners.  So if you show the “happy path” of a feature, they don’t SEE the happy path.  They see their system…and it’s working!  Yahtzee!  Ship it!

The first time you pull back the curtain and show them why you can’t just ship it (the broken links, the hacked supporting pages, the hardcoded breadcrumb, the broken buttons, or the fact that it doesn’t work anywhere but Sam’s developer machine) the sadness and disappointment sets in, and the terrorists have won.  You may not know it now, but Trust (capital “T”) is starting to erode.

“But, don’t they know that it’s just a demo?”

No.  They don’t.  Just like they don’t understand that done (small “d”) doesn’t mean DONE (all caps) either….because no reasonable person does! 

Some small advice that turns out to make a BIG difference in the long run. 

1. Treat the language you use with your partners carefully 
2. Apply the “reasonable person” test.  Would a reasonable person understand your intent?
3. Make the word “done” mean something in your organization before one of your teams creates multiples meanings for it.  Once “done-done-done” emerges (or Rare, Medium, and Well-Done in my case), it’s much harder to regain lost Trust (and the appropriate meaning of our words)
4. Lastly, teach your teams the power of Trust

Over the past year, my wife and I have shared idea – upon idea –  about how we as a couple should be parenting our kids.  In my house, I tend to generate ideas at breakneck speed. From how we speak to one another in front of the kids, to how we might engage the kids in intellectual endeavors (over Wii baseball), to how we react when our oldest pulls his pants down in the back yard to take a potty break (yes, sadly this happens frequently enough to address).   I tend to generate ideas around “interactions” within our family.  My wife tends to generate ideas around “organizational” detail.  Not only that, she typically “implements” these ideas concretely.  Consequently, this is one of the reasons why I love her…she knows how to “implement” her ideas.

That said, this post will focus on those ideas that remain squishy (think “why” over “how”).   Day after day, I start conversations with my wife that start something like this:

“Hey…when the kids are rolling around on the floor screaming at us, do you think we could try…”

OR

“Umm…when the kids won’t eat any dinner, maybe we should try…”

Most of these ideas are good ones, at least in theory.  The problem is, if you’re like me, I rarely recall any of these ideas in the heat of the moment.  At least not in any meaningful way.  Why is that?

Why don’t parents practice this stuff !?

Why don’t I practice this stuff?!

Don’t we know  it might come in handy at some point?

Doubtful any of the parents who read these lines would disagree that parenting is the hardest job ever.  For me, it’s the most exhausting, exhilarating, and emotionally challenging set of tasks in my life.  And no one trains themselves on how to do it prior to actually doing it.  I wish there was a class in school for this stuff.  There’s not.  At least not at Indiana University, or the lesser Big Ten school my wife attended   <cough>Wisconsin<cough>.

So here’s the idea, one I shamelessly borrowed from a website on Agile software adoption called AgileInAFlash.com.  Every so often Agileinaflash.com outlines some best practices for Agile Adoption on a page that looks like a note card.  It then gives you the option to print it on a page by itself.  Simple right.  I love these handy little flashcards that can be hung in your office, or stuck to your note book and walked from meeting to meeting.  The idea is so simple!

So now, when I read a pertinent chapter in a book, or get some dynamite advice, I stick a big and visible 3 x 5 flash card in a conspicuous location around the house.

Some 3×5 Notecard Examples:

• 3 Rules for Praising the Kids:
  • 1) Be specific,
  • 2) Focus praise on hard work, not intelligence, and
  • 3) Don’t overdo it!  We don’t need praise junkies!

• 3 Rules For Arguing
  • Fight fair
  • Don’t yell
  • Bring the fight to some sort of conclusion IN FRONT OF the kids

• How to Give Choices to the Kids
  • DONT respond in haste.  Take some time before you give a set of choices.
  • Ask the kids to help come up with some ideas if appropriate.
  • Give the kids 2 choices (do you want to put on your underwear first, or your shirt?)
  • Both choices are ones you can live with (not: “do you want to put on your shirt, or should I” – you will be dressing your kids until they are 9)
  • Let them decide as much as possible in this way

This technique is not new, but is effective enough to warrant consideration.  My postulate is, if practiced, these types of responses would become second nature.  Like anything else, I need to learn this skill, and if I don’t remember what I thought to say, I will never get better.  After all, it’s not terrible to have some small reminders handy when emotions have colored your thinking.  Sometimes shutting down your emotional side and “reading from the flash cards” is the best advice I could get.  This is not so different from Love and Logic or Positive Discipline.  Both of these parenting techniques recommend turning off the emotions and going into robotic-parent mode.  The more you let yourself emotionally engage, the worse off you are.

With all of this, ParentingInAFlash.com was born (not built, mind-you, but born).  Flash cards are starting to go up, and the idea is being piloted in the Montague household.  I hope to launch the site soon, and I’m thinking through ways to generate content (free of course).  I will let you know when it does and hopefully you can help pilot in your home.  It just might give you a chance to practice the hardest job on the planet, parenting.

“What can I do to move to the next level?”

“How do I get promoted?”

Two questions I hear with enough frequency that I feel compelled to have an answer rehearsed to make it through the awkward fumbling. Why is this question so difficult for me to field? This should be a question I LOVE to field…an opportunity to have yet another conversation about all the great things people are doing, how our development planning is making a difference, and how a carefully laid out plan (and hard work) will give you the outcomes you desire.

Instead, this question sends chills up my spine (in an awkward way) and in the back of my mind, I know why. Frankly, I’m finding this a tough thing to write. In the interest of full disclosure, the dysfunction of promotions in large organizations is not for a lack of trying to make the process transparent and virtuous. I think ALL managers go through this process thinking about the virtues of their employees, true value to the organization, and general fairness.

For me, it boils down to a few things. Very few on this list will shock you. Some might. Frankly,  I just can’t tell. I have had this conversation so often (and been surprised by it) that I feel like basics escape people when assessment season <gulp>  rolls around each year.  Maybe it’s due to individual contributors having not had to perform such tasks?  No matter what it is, the conversation is akin to telling your 10 year old that Santa isn’t real.

“I think they know, right?”

“They have to know this.”

“Man, I hope they know this…”

Related to Promotion Decisions (large organization):

1. You are not competing against a set of criteria in a development / performance plan (in most large organizations).  You are competing against your peers.
2. Your direct manager has little “direct” control of promotion decisions.  Management “teams” have ultimate say and even then, the decisions are mostly “recommendations” to someone w-a-y up the chain of command.
3. By the time promotion decisions are handed down (or at the EOY evaluations) there is typically nothing your direct manager can do to change any decisions that have been made.
4. If your 20 person organization busts their asses and deliver unreal accomplishments, the constraint of 2% (or some small percentage) still exists.  Not everyone will get promoted.
5. Seems obvious, but promotions are completely subjective.  Even though you have a list of criteria for promotion staring you in the face, it’s still a judgment call by a team of people.  (This one trips up technology people frequently)
6. If you have just been promoted, your chance of promotion the following year is effectively zero (another obvious one) even if you have moved Heaven and Earth in one of your projects.  This one troubles me for many reasons.
7. There is a constant PULL to minimize the number of promotions submitted.  This typically comes first from management, then from HR.  The fewer people submitted as the numbers are rolled up, the easier the decisions for managers up the chain become.
8. Every single person in this process has a world view, and every decision they make reflects it.  What your management finds valuable personally will affect decision making.
9. The last thing to note:  I HATE HATE HATE this list.

So who cares that I hate this list.  It doesn’t change the fact that these are real issues.  So what can be done?

Effective Ways to Contribute and get Recognized (as a by-product):

1. Just Get Stuff Done – Make sure others view you as a person that “just gets stuff done”.  You become the person that doesn’t require consistent hand-holding to make decisions or make things happen.  If you can take requests and “just get them done”, you make their lives so easy!
2. Understand your Teammates – Get to know your teammates and find out what will WOW them.
3. WOW your teammates! This is more important than WOW-ing your manager.  Over deliver to these people at ALL times.  This doesn’t have to be something overwhelming to YOU.  This could simply mean it qualifies as a “Little Big Thing” in the world of your peer.
4. What about BOB? A friend of mine refers to people on his projects as “BOB”.  Seems silly, but this is his way of determining his “Band of Brothers”….the people he can COUNT on when things are tough.  (BTW – his 2 most trusted BOB’s are women.  Maybe they could be his BOSs?).
5. Be Nice – Be perceived as a “nice person”.  The nicer you are, the easier it is for others to engage you.  This makes it easier to WOW them!
6. Be Relevant – Be relevant to other teams in your work unit.  The more relevant (read:  “I know Jane.  She is a dynamite data person!”) the more they will sing your praises when you OVER DELIVER for them!  (are you getting the point yet?)
7. Be a cross-functional Maven -  Ask about other disciplines most pressing issues and help guide and partner with those folks on your projects.  Be the bridge between your peers and those other roles.  This will create raving fans of those people over night.  Trust me on this one.
8. Lastly, and so importantly, be your Customers Advocate.  Whether internal or external, advocate for your customer!   Make their lives easy.  Make your interactions with these people INSANELY simple and valuable.  Cut through the mess FOR them.  Be their tour guide through your organization and take care of them.  If they are on your side, you are half way there.

To sum it all up, your ultimate goal is to take the PR of your promotion OUT of the hands of your manager.  If you are busting your ass all year, creating raving fans all over your organization, ensuring you reach “BOB” status with your peers, are a cross-functional maven, can get stuff done, and are an advocate for your customers, nothing but great things will happen.  OTHER managers will come to promotion meetings and mention your name.  Other managers will KNOW your name, as well as all the great things you are doing.  The leadership will sit up an take notice.

This is the advice I give to team members these days.  I want to impress upon them that my ultimate goal is to make them successful.  If they are, I’ve done my job.  I want to help them navigate the politics and bureaucracy of organizations (for good or bad).  That requires that I continue to tell people the reality of performance related to promotion.  You get the good with the bad.

I hope to have the promotion conversation with ALL employees one day, and for all the right reasons.  If they succeed following the steps above, then the organization will be better off.  That will be a great day indeed.