Drive – The Surprising Truth About What Motivates Us

“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.

Go Ugly Early

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.

Rare, Medium, and Well-Done!

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!”.meat

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

Parenting In a Flash

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…”


“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 Every so often 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, 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.

The Ugly Truth About Promotions

“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.