Mar 042014
Agility 2008 May 04

Agility 2008 May 04 (Photo credit: Cynthia Blue)

Mere days ago, Mike Cottmeyer wrote an article called “Managing Risk and Uncertainty in Agile.”  I think the main ideology is captured in the following quote:

I think [treating software as inestimable] is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing [sic] credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll [sic] can talk about how to move these folks, but for now we have to figure out how to commit. (Emphasis mine)

In other words, since most organizations aren’t ready to be agile, we need to ditch agile presuppositions and practices that would make them scared or uncomfortable and treat software development like deterministic work.  He also explains how the metaphor of building a house should inform our understanding of agile software development and what an impact that metaphor has had on his own understanding and practice.  Ultimately, what he wants agile teams to do is give up-front project commitments and estimates.  He (rightly) anticipates that people will say this is not agile, but answers this objection with something along the lines of, “Yeah, so?”

I certainly agree with Mike that just because something doesn’t line up with Ye Olde Agyle Orthodoxye, that’s not a reason to reject it out of hand.  “That’s not agile” is actually not a valid criticism of anything – you have to go on to explain how the idea or practice would hamper agility or has some other harmful impact.  But my interest here is not to refute the practice of up-front project estimates, commitments, or explain the dozens of ways in which developing software is completely unlike a house and why that is a very wrong-headed and misleading metaphor for software development.

My interest is in those emphasized statements: the idea that we have to learn to cater to an organization’s established, outdated worldview and practices until they change into an agile organization – somehow.  This kills me, and it’s disappointing to see it coming from a company that purports to train people in agility and transform their organizations (who’s transforming whom, exactly?).

It’s like that John Mayer song, “Waiting for the World to Change.”  That song has the worst message, which is, basically, “There’s a lot of institutionalized power opposing good social change, so I’m just gonna quit trying until something changes that situation – somehow.”  When you try to shape agility into the old processes and expectations, that’s basically what you’re saying.

Agility is a challenging and transformative force.  It’s meant to create pain points.  It’s meant to challenge processes and how we think about creating value.  This is what’s supposed to happen.  If greater agility is difficult to manage with an existing budgeting process, guess what’s supposed to happen!  The budgeting process needs to be examined.  If greater agility is difficult to manage with your established project management practices, then you need to look at how your PM processes should change.  Agility is something that affects an entire system.  You can’t just agile up a development team, leave everything else intact, and call it good.

So, I call upon agile coaches, consultants, advocates, and well-wishers to challenge rather than accommodate.  Don’t look for ways to make agility more palatable.  That doesn’t mean everything needs to be uprooted all at once, but it does mean that greater agility should be pushing outward to change existing structures, not the other way around.

If you make agility work in the ways an organization is used to, then you’ve made it irrelevant.  You are an enabler.  You are part of the problem.  They have cancer, and you’re trying to get them to smoke a nicer brand of cigarettes.

If you think you won’t be able to get clients if you rock their boat too much, then do us all a favor and let the market naturally select you out of it so people who can actually help your clients can pick them up.  Nobody needs you to institute daily standups and a backlog and allow them to think they’re ready for unbridled productivity.  Some of you are CONSULTANTS for Thor’s sake.  CONSULT!

All of you who, even now, are thinking of how to change your practices around to fit better with older presuppositions forged in an older business environment – all of you who think agility needs to learn to deliver what project managers expect in order to be viable – all of you who think scaling agile needs more command and control – all of you who have never stood up to a client because it’s in their best interests – I call you to courage.  I call you to challenge those presuppositions instead of accommodating them.  I call you to war against high-risk delivery, false and harmful metrics, misanthropic management philosophies, and waste rather than collaborating with the enemy.

As you work with your organizations, ask yourselves, “Am I doing this because it improves the value delivery process, or am I doing this because it’ll work more easily with the way things are?”  In most organizations, if it isn’t subversive, it probably isn’t agile.

Enhanced by Zemanta
Feb 172014
lol on a candy heart

lol on a candy heart (Photo credit: Wikipedia)

I spent Valentine’s Day re-enacting all the Hoth scenes from “The Empire Strikes Back” trapped in a hotel/airport in Alexandria, VA.  That lady sure got upset when I sliced her luggage open and crawled inside.

One thing that was in abundance even in such romance-starved wastelands as the airport were candy hearts.  You know the kind I mean – the chalky, vaguely flavored candies that taste mostly like they were molded from bat cartilage.  They have the printed sayings on them like “Be Mine” or “Kiss Me” or any number of things you don’t feel like being or doing after someone has given you one of these to express their feelings.  Most of them were pretty nondescript, but I got some messages that I wasn’t sure were entirely appropriate candy heart material, listed below:

  1. Stop Crying
  3. Look Behind You
  4. Is That Your Sister? Hello!
  5. Show Me Your Relevant Genetalia
  6. Candy Organ Donor
  7. Ate the Last Granola Bar
  8. Choke On This
  9. This is the Only Hard Thing in my Pocket
  10. F = ma
  11. Help Me
  12. No Message Due to Ennui
  13. Give ‘Em Hell
  14. Settle
Enhanced by Zemanta
Feb 062014
Ed Sumerfield and Chris Nelson of Gaslight Sof...

Ed Sumerfield and Chris Nelson of Gaslight Software presenting “Why Agile Fails” (Photo credit: RubyNuby)

How the fuck is this coming around again?

George Westwater on Waterfall

Every so often, someone will put forth the idea that agile practices are great and all, but they fail at certain things like providing an up-front budget, a well-researched scope before work begins, a full project timeline with milestones, etc.  These sorts of things are such staples to the way most orgs approach their projects that there’s a certain tension to make agile practices better at providing them, and the path of least resistance to trying to supply these is to use the practices that used to provide them – typically some type of phase-gate approach like Waterfall.  You hear things like this:

  • We complete all the requirements and design up front, but then we do our development in an agile way.
  • We do agile, but in a way that can be managed with Microsoft Project.
  • We’re agile, except we do our testing at the end, but at least we release every six months.

And so on.  The basic idea is that doing a project without these traditional Waterfall additions is somehow inherently more risky or will fail to provide a company what it needs to make intelligent project decisions.

I’ve already spent a lot of electronic ink on this blog talking about how the benefits Waterfall purports to offer are largely illusory (kind of like the illusion of security offered by being employed at a large company) and how various agile methods can actually do a better job at providing intelligence to the business, so I don’t want to rehash all that.

However, the point I want to make here is that Waterfall and Agile arose from very different systems and operate off very different assumptions about the work.  For instance:

Waterfall’s Assumptions

  • The work to be done is mostly static.  Changes are rare and always occasion for re-examination.
  • Business needs / the market is not volatile; our priorities and methodologies today will be very similar three years from now.
  • The work is extremely similar to work that we have done before.  Almost everything is a known quantity.

Agile’s Assumptions

  • The work to be done changes often and progressively as more clarity is gained or needs evolve.
  • Business needs and the market is volatile.  The thing on the front burner today might be on the back burner in three months.  Our methodologies are evolving.
  • The work is to develop something new.  Similar technologies and methods might be used, but the business problems we’re solving technically have not been solved before.  Otherwise, we’d be using that.

The problems with Waterfall are not necessarily inherent to Waterfall as a methodology.  On paper, it looks all right.  The problem is that the set of circumstances under which it operates best is pretty rare in software development.  Are there software development projects where the domain is pretty static, changes are rare, and the business changes very little?  Sure, those do exist, and Waterfall would work just fine.  In fact, it or something similar might be the best choice for those kinds of projects.

However, a lot of organizations believe Waterfall’s assumptions to be true of their situation, and they are not at all.  Most real organizations have work that looks more like that list of Agile Assumptions, and in that context, agile methods will probably fare much better.

The issue with combining the methodologies isn’t a religious one; it’s that you’re trying to combine two things that are appropriate in two very different contexts.  You’ll end up crippling Agile by trying to make it more Waterfallish because you’re trying to drag in a context that doesn’t apply.  It’s like adding a sail to your car.  Sails are pretty good in their context, but they’re not objectively good for all contexts.

The fact is, becoming agile will challenge a lot of illusions and assumptions we make about our work that are not accurate.  If you’re hearing something like, “Agile makes it difficult to budget for the whole project up front,” that’s your cue to examine if budgeting a whole project up front is really the smartest thing to do as opposed to paying for value as you go.  If you’re hearing, “Agile makes it hard to set project milestones,” that’s a good opportunity ask yourself why you feel you need project milestones, what value they offer, and could you get that value in better ways?  Agile is meant to change your understanding, your values, and ultimately your practices at an organizational level.  It is not designed to accommodate them.

So, before you decide to add a sail to your car, just give driving the car a shot.  You might find that it doesn’t need that sort of improvement.



Enhanced by Zemanta
Feb 042014
  • People in Plane Crashes in the United States from 1983 to 2000: 53,487
  • Number of People Who Survived: 51,207
  • Survival Rate: 96%
Fan Death (Caution)

Fan Death (Caution) (Photo credit: kang_a_ji)

Although I can’t say every one of the man’s ideas are sound, Robert Kiyosaki taught me this great little acronym for FEAR: False Evidence Appearing Real.  It turns out that there’s actually very little connection between the things that we’re afraid of and reality.  This probably served a survival purpose way back when.  It probably pays to be a little too afraid when Uglook might kill you at any time to take your sweet pile of rocks or when roving packs of wild animals competed with you for game.  But in modern society, although technically death is still imminent, our brains have found other things to be afraid of.

  • Number of Species of Scorpion: 1000+
  • Number of Species of Scorpion with Venom Dangerous to Humans: 25-50
  • Number of Species of Scorpion with Venom Dangerous to Adults: 10
  • Odds of Dying from a Scorpion Sting: 1 in 300 million
  • Odds of Dying from Falling Down in Your Shower: 1 in 65,000

We all know this from practical experience.  We know many more people die in traffic accidents than airplane crashes, but we are deathly afraid to fly and not at all afraid of suiting up in our two ton motorized death machines.  We know that zombies aren’t real.  We know that, even if they were, the odds of the undead spontaneously appearing in our bedroom would be slim, but our pulse still speeds up when we hear an unexplained noise in the house after watching a zombie movie.

  • Number of People in the U.S. Who Die from Shark Attacks Each Year: 1
  • Number of People in the U.S. Trampled to Death by Cows Each Year: 22
  • Number of People in the U.S. Dated by Taylor Swift Each Year: 4

The implications for our individual lives are obvious.  Once you recognize there is virtually no connection between what you fear and what is likely to happen, hopefully it encourages you to take more calculated risks.  I wouldn’t jump in a bathtub full of scorpions, exactly, but if there’s a particular reward you want, but you fear the risk, you might consider acting in defiance of your feelings, because the odds are actually in your favor.

Even in those areas where the risks are real, known, and not in your favor, that shouldn’t paralyze you.  Another little nugget from Kiyosaki is that 9 out of 10 businesses fail.  You might look at that figure and decide it’s too risky to start a business.  You also might look at that same figure and make plans and prepare to try at least 10 times.

  • Number of People in America per Year Who Receive Venomous Snakebites: 7000 – 8000
  • Number of People in America per Year Who Die from Venomous Snakebites: 5
  • Number of People in America per Year Who Die from Non-Venomous Insect Bites or Stings: 7

Organizations have something to learn here, too.  Organizations are, at root, collections of people who have fears that are often way out of proportion with reality.  Having a large group of us doesn’t make us any less prone to our psychology.

Organizations have to be courageous, too, acting in defiance of their feelings when a desired reward is on the line.  That may take the form of totally overturning ensconced business practices.  It may mean rewriting a code base that has been “good enough” for years.  It may mean putting some marketing muscle behind an untried product or making a foray into a new segment.  It may even mean redefining your mission.

What good ideas have died a horrible death at your organization because of fear?

Enhanced by Zemanta
Jan 292014
Anecdotes and Data DSC_9869

Anecdotes and Data DSC_9869 (Photo credit: Plashing Vole)

I’ve started to see a statement crop up more and more in blogs, on Twitter, and in person on discussions about what does and doesn’t work in becoming agile: Anecdotes are not data.  Typically, this happens because someone is explaining their views or practices as derived from their own experience.  You’d think that wouldn’t be a controversial move, but agile coaching/consulting is one of the most armchair-dominated fields out there.  It behooves people trying to make money in this field to cast aspersions on experience in favor of their “data.”  You can tell story after story about what you’ve run into in the field, but it’s not “data,” and therefore can’t be used to establish anything.

Here’s the catch, though: where does that “data” come from?

Let me tell you where it doesn’t come from.  It doesn’t come from a researcher, an organization, or a group of peers coming up with a hypothesis, defining the control parameters to test that hypothesis, then running experiments on a broad range of companies within the confines of those parameters, observing and recording the effects every day, then publishing those results after peer review.  So, whatever agile consultants mean by the word “data,” they don’t mean what the scientific method means.  They don’t mean actual empirical data.

Since no one has ever done an actual scientific analysis of various agile practices, what do people mean when they talk about data in this field?  Well, they mean things like the Chaos Report or various organizations’ “State of Agility” surveys.  In other words, they are referring to collated survey data, and unfortunately for the anti-anecdote wags, a survey response is anecdotal.  People are reporting on their own experiences, and the way in which those experiences are reported is further filtered and conditioned based on things like the questions asked, the questions not asked, the answer options, the quantification mechanism chosen, the response rate, and the survey base.

So, data in the agile community is typically nothing more than a collection of anecdotes.  One might argue that these collections of anecdotes yield more certainty than, say, one person’s collected anecdotes.  Maybe that’s so, but at what point do anecdotes magically transform from “Bob’s experience” to “actual data?”  Is it five people’s anecdotes?  How about twenty?  A hundred?  A thousand?

The only difference between anecdotes and data in this context is one of degree, but not one of kind.  Critiquing someone’s anecdotes because they aren’t data is like critiquing a full bathtub because it isn’t a swimming pool – maybe you can’t fit everyone into it, but there’s still a lot of commonality.  All these various reports and surveys are just collections of stories.  That doesn’t make them invalid, of course, because these stories are really all we have to go on until a hundred corporations volunteer themselves for experimentation by the agile community.  But it does mean personal experience has both meaning and weight.

Even in what we think of as the hard sciences, the experiences behind anecdotes carry value.  Do you think a heart surgeon who has never done surgery is just as good as a heart surgeon who has done a hundred surgeries because they both learned the same material?  If the hundred-surgery surgeon started giving advice to the no-surgery surgeon about what the real deal is like, do you think, “Sorry old man, but anecdotes aren’t data” is a valid response?

If someone is being hidebound and closed-minded because of their past experiences, I think a much better observation to make is, “Your experience isn’t normative.”  In other words, people may have experienced different things that lead them to different biases, actions, and even different ways of interpreting “data.”  For instance, not too long ago, I criticized the popular use of burndown charts on the grounds of what I’ve actually seen happen.  I would never, however, tell someone that burndown charts are universally inappropriate or should never be used under any circumstance.  Why?  Because my own experiences have led me to see them as a low-value activity, but another practitioner might have experienced a lot of benefit from them, and it serves the community as a whole for us to share those anecdotes and the views they espouse so that we can improve and the people who bother to listen can also improve.

Anecdotes are data, and if you discount what an experienced veteran says because it didn’t jive with someone’s survey, you’re taking a very risky path.

Enhanced by Zemanta
Jan 282014

Galaga (Photo credits: Giphy)

Thought I’d pick up a little of that sweet, sweet physics traffic with that title.  FYI, you can increase your change in position or decrease your time.

Now that’s out of the way, this is a question that crops up every so often in different forms.  I put it in the Scrum form, but it all basically boils down to, “How can I get my developers to move faster?”  This is a timeless question that has answers that generally revolve around adding people, forcing overtime, or instituting measures to make sure they aren’t all secretly playing Galaga.  I will contend, however, that if you really want more to get done more quickly, you’re asking the wrong question.

When you first start learning to play tennis, they don’t teach you how to hit the ball as hard as possible.  You can always tell when your opponent has decided power is the most important thing to the game, because the ball ends up wedged in the fence, over the wall, out of bounds 80% of the time, and generally anywhere on the court except the places that would actually enable them to score points.  But, boy, does it get there fast!  Tennis Coaching 101 is to teach control and placement.  Power follows as a logical consequence of easily and confidently putting the ball where it needs to go.  A less powerful player with consistent placement will beat Johnny Randomcannon every single time.  The key to greater power is greater consistency.

Instead of asking, “How can we go faster?” start by asking, “What keeps us from performing consistently?”  If you don’t have a predictable flow, it’s very hard to know if you’re improving.  If speed increases, but it’s unpredictable, who knows why you went faster?  Who knows if you’ll be faster next week?  Your results don’t mean anything because the variability is high.  Although it may sound counter-intuitive or just plain distasteful, it is better to be slow and predictable than fast and unpredictable, at least in terms of getting work done.  Obviously, the ultimate goal is to be fast and predictable, but one comes before the other.  Just like you wouldn’t focus on power before precision, focusing on speed before predictability can end up with you all over the place except the targets you’re actually trying to hit.

In the first place, most businesses prefer predictability to speed, despite what they say.  You can plan around predictability, even if the predictions aren’t what you’d like.  You can’t plan off variability no matter how fast you are.  If you offered most businesses a choice between a consistent amount of work delivered in a consistent time period versus a completely erratic delivery that could be much faster from time to time, they’ll pick the first one.

In the second place, there’s no way you can meaningfully measure if your improvements are helping if you’re already highly variable.  To use a Scrum example (I feel so dirty), let’s say I deliver 5 story points one sprint, 18 the next sprint, and 10 the next sprint.  My team decides on an improvement, and the next sprint, we deliver 14 story points.  Did our improvement help?  You have no freaking idea.  If you take that same scenario, but the team’s deliveries were more like 12, 16, and 14, then the next sprint you delivered 18 or 20, the odds are pretty good that your improvement is helping, or at least not hurting.

But how do we reduce variability in software development?  Isn’t it extremely variable?  Well, yes it is, and I have found the practice of trying to get all deliverables to the same “size” to do more harm than good.  It’s better to accept that some things will be big, some things will be small, and most things will gravitate to somewhere in the middle, relatively speaking.  You can’t control that.  What you can control is flow.

How fast does new work come to your team compared to how fast work gets delivered?  How many things is your team trying to finish at one time?  How often is something in progress stopped because of roadblocks?  How often is something not in progress started because of whiplash priority changes?  You can’t control the variability of what you have to deliver, but you do have quite a bit of control over the flow of these deliverables into and out of your team.

If you manage to flow instead of speed, the speed will come.

Enhanced by Zemanta
Jan 222014
Meryl Streep

Cover of Meryl Streep

Do you remember that movie “The Hours” with Meryl Streep?  Me, neither.

Last week, I was talking with some colleagues on LinkedIn about the utility of estimating tasks in hours.  For those of you with a Scrum background, you know it’s kind of tradition to estimate user stories in story points (or something like them), but then you break them into tasks.  The tasks are estimated in hours, and the total of all those hours forms the basis of your burndown chart.

I’m not saying my experience should govern everyone else’s, but I haven’t estimated tasks in hours in a very long time.

First of all, the whole thing begins with the premise that we can accurately estimate our tasks in hours, and this tends not to be the case.  There’s a common misconception that, if you are trying to estimate a smaller activity, that your estimates will be better.  This is not true.  It is true that the actual hard units of deviation will be smaller (being off by 2 hours is a smaller hard time span than 2 weeks), but there’s no reason to believe your estimate will be better just because the scope is smaller.  You might say at this point, “Well, ok, but it’s not really going to affect the project that much if I think it’ll take 2 hours to set up some database tables, and it takes 3.”  That’s a 50% deviation, but ok, sure, that extra hour may not affect much in the grand scheme of things.  But what if you’re off by an hour for all your tasks?

That’s being generous.  What is pretty common is to have a task that you think will take 4 hours, and it ends up taking 20.  You take these extremely common incidents of being wrong and you put them together, and you can easily end up with days or even weeks of error per sprint.  The absolute units of time give the appearance of precision, but it’s a false appearance – perhaps all the more dangerous for its compelling nature.

Because the units of time are small, this seems like a small problem, but that’s only because you’re thinking of one task.  When you look at the cumulative effect of this problem, it’s actually pretty serious.  It sets unrealistic expectations.  Your burndown chart whose entire raison d’être is to visually represent sprint progress is like a clock that loses 5 minutes every hour – it doesn’t take long before that clock is worse than worthless, because it’s misleading.  Have you ever had a burdown chart stay level or go up during a sprint?  More often than you’d like, right?  Maybe that’s a signal that your workflow isn’t being managed well, but those same things can just as easily happen for no reason whatsoever, just because your hours remaining started wrong and are correcting themselves.  This isn’t even taking into account the fact that, when people see hours, they expect those mini-deadlines to be hit.  Patience for spending 20 hours on a task wears pretty thin when you’ve told everyone it would take 4, initially.

This leads me to my next point – estimating in hours takes a long time to do.  All that time spent on being wrong could have been spent coding, getting acceptance criteria, or anything that would have moved toward delivery.  Hell, even using that time to make the world’s longest paper clip chain would have been at least as profitable.  Note, I’m not saying it’s a waste of time to break stories into tasks.  That process helps you understand what’s expected of you, ferrets out oversights, and helps in swarming.  But what are you getting by putting hours on those tasks?

“Well, the hours can help us verify if our sprint commitments are reasonable.”

Can they?  First of all, even the Scrum Guide doesn’t use sprint commitments, anymore, but let’s pretend that’s still a good idea.  If you can make some kind of equation between story points and hours, then why not just skip the whole story point process?  Just break everything into tasks, get your hours, and base your planning on that?

“Well, relative measurements and velocity are more accurate planning tools than hourly estimates.”

Exactly.  So how are those hours helping you, again?  You are using the less accurate tool to critique the more accurate tool?  Is there anything at all those estimated task hours help you do that relative measurements or empirical metrics can’t?

If you’re a Scrum sort, try an experiment next sprint just to see what happens.  Break your stories into tasks, but don’t put hours on them.  If you want to burn down, burn down story points (or whatever you use).  Just try it.  See if your workflow or end result is meaningfully impacted.  See if you miss them.  You might find that you’ve made a significant improvement in your practice.

Enhanced by Zemanta
Jan 062014

WARNING: This is a rarity that will probably not be repeated in this blog. It’s personal and cathartic. I didn’t get half the things out that I wanted to get out, but this is allegedly a professional blog relatively free of my feelings or personal life events, and I’d like to keep it that way. This is mostly a bit of indulgence. Please return for the typical level of brilliance you’ve come to expect.

1. Destruction is way easier than creation.

At a cellular level and beyond, we destroy entire ecosystems by taking a shower or scratching our chin.  We don’t notice we’ve done this, and we certainly don’t notice the ramifications.

In a similar way, it is extremely easy to destroy relationships, another person, or yourself.  The right words or the right actions (or the lack of words or actions) are all it takes to wipe out something it might have taken years to build.  One poorly-timed fit can lay waste to years of relationships.  One wrong email.  One overenthusiastic gesture.  One thing spoken without thinking.  One time a little too honest.  One time not honest enough.

2013 has taught me that there is nothing you do or say that doesn’t have the potential to destroy more than you ever dreamed possible with virtually no real effort on your part.  Every word and every action is worth considering before letting it loose like an arrow from a bow.  Songs, movies, well-intentioned friends, etc. will urge you to say whatever is on your mind or heart, unfiltered, but 98% of the time, this is a monumentally terrible idea.  I have lacked wisdom and discretion for miles in this department, not just in 2013, but for years of my life with the scars and disrupted relationships to prove it.  Perhaps it is just last year when these things became more directly evident.

2. There is no bottom.

Circumstantially, there is a bottom.  The circumstances of your life can possibly get to a point where things cannot get meaningfully worse.  At least, relative to your normal life circumstances.  I mean, yes, you could always be on fire or something, but people talk about hitting “rock bottom” in their lives, and I believe them.

Internally, our capacity for hurt, loneliness, anxiety, etc. is powered by perpetual motion.  It’s like a shaft you slide down, and you scrape the sides with your feet and scrabble with your fingertips looking for purchase.  You find some blessed area where the descent stops, and just that little nudge makes your foot slip, and off you go, rasping and flailing and clattering until the next respite.  You think you can’t possibly slide any further, but oh my – just wait for the next drop.

Something not a lot of people know about me is that I have a relatively high capacity for physical pain (please don’t test this).  I have run until I have collapsed from lack of oxygen.  I have had my ass kicked for hours by men much larger than myself.  I have sustained concussions, broken bones, and second degree burns, and with the exception of breaking my stitches open when I was a kid, I always just kept on trucking.  I would not stay down, give up, talk, quit playing, or go home.

Internally, I am not nearly this tough, and 2013 taught me about the difference between my capacity to be hurt and my ability to deal productively with it.  You can really only hold out for so long.  With physical pain, you eventually fall unconscious.  Emotionally, there is just no stopping point.  I am not suicidal, I don’t have suicidal thoughts, and I don’t condone suicide as a solution.  But I totally understand how people get there.

3. Being on top is amazing.

One of the many reasons suicide is a bad idea is that you can be eighty miles down the Slippery Shaft o’ Bad Feelings, today, and climbing the top of Mount Awesome three months from now.  Hopefully, at some point, you’ve experienced what I’m talking about in ways that aren’t drug induced.  That feeling when the black ice that has settled in a hard lump in your chest just begins to dissolve and effervesce, replaced by warmth, hope, and the euphoria that comes from knowing that there are things and people out there that have been put there to remind you that, just shy of death, there is nothing about your life that permanently dictates how it has to be or how it will be, forever.

That’s a double-edged sword, of course, because it means that the things that hurt us can heal and go away, but it also means we can lose the things that keep us going.  A lot of happiness revolves around being thankful for and treasuring what good things you have just as much as avoiding or getting rid of the things that bring you down.  Granted, sometimes this pool of things that make you feel all warm and fuzzy is shallower than other times, but it does exist.  As hard as 2013 was (BTW: It sucked and is still sucking), it was never bereft of reminders that happiness is a real thing that does happen.  Sometimes, you have to make it happen, and sometimes, it happens TO you, but it is there.

4. Unconditional friendship is priceless.

Is there anything more powerful than the decision to be on someone’s side no matter who they are, what they do, or who they turn out to be?

People say this all the time.  “I’m your friend no matter what.”  But most of the time, what they mean is, “I’m your friend as long as you only do things I approve of,” or, “I’m your friend as long as you don’t hurt me,” or, “I’m your friend as long as I can defend you.  Otherwise, you’re on your own.”

If you really thought about it, how many of your friends are you actually committed to in this way?  What if they renounced their religion?  What if they punched your sister in a fit of rage?  What if they told you they hated you and never wanted to hear from you again?

I’m not saying that there isn’t some limit to this.  If your friend is a serial killer, I don’t think you should, you know, support them in that and should probably call the cops.  But outside of the whole Crimes Against Humanity category, do you have any friends that you would stand by even if they were clearly and evidently in the wrong?  Do you have any friends who feel that way about you?

2013 taught me that this kind of friendship is rare, valuable, and worth protecting at all costs.  It also taught me how rewarding it can be to be this sort of friend.

5. There is a huge chasm between affirming something and doing something, and people don’t seem to get that.

The late, great Mitch Hedberg once said, “I know how hard it is for you to stop smoking.  It’s as hard for you to stop smoking as it is for me to start flossing.”

I love that for a lot of reasons, but for the purpose of this point, I love it because it acknowledges that affirming you should do something is different than doing it, and in between can be a lot of miles of bad road.

I have a lot of Christian friends who encourage me to do what the Bible says.  They do this by continuing to tell me what the Bible says, as if hearing the statements enough and nodding my head enough is all it takes for me to do whatever it is they think I should be doing.  Well, I’m a Christian, myself.  But I also know that the statement “Just do what the Bible says” is sometimes about the same as saying “Just beat Justin Timberlake in a singing contest while gargling thumbtacks.  Then go out and hit yourself in the face with a hammer, because, well, just do it, ok?”  It’s ridiculous to think that affirming something is just a hair’s breadth away from getting it done.

Imagine how different people and the world in general would be if affirming something was virtually the same as doing it.  “I think I need to lose weight.”  So, dieting is easily done.  “I’m addicted to cigarettes.  I should quit.”  Bam, done.  “Peace is better than war.”  Bam, world peace.  This is insane.  Especially when we think about our own lives, it is incredibly clear that there is an enormous gulf between what we affirm and what we actually do, or at least actually do right away or do without significant effort.

And yet, very well-meaning people seem to lose all sense of this when advising you.  You know you should lose weight, why can’t you just eat less or eat better?  Why can’t you just stop smoking?  Why can’t you stop dating men who are huge disappointments?  Why can’t you be more innovative?  Why can’t you be more like Jesus?  Proposition X is so simple to understand, so why can’t you just do it?  And God help you if it’s an area they don’t struggle with, themselves.

2013 taught me that it’s too easy to look at someone’s failures to live up to their affirmations and label them a hypocrite, a weakling, or a moron – therefore, I shouldn’t be surprised when it happens.  2013 taught me that helping someone through their struggle is not about repeating what they should be thinking or doing over and over until it catches on.  As I get older and deal with more and more struggling people, I sometimes wonder if 90% of Things I Might Say are actually counter-productive, or would be more productive when the intensity of the struggle was lower.  Maybe I should take all that time and just invest it in trying to understand what their struggle is and be present for them as they ride it out.  I don’t know.  But what I do know is that, if I expect people to be gracious with the gap between my affirmations and my actions, then I need to be ready to do the same.

Jan 032014
Can't Sell Dope Forever

Can’t Sell Dope Forever (Photo credit: Wikipedia)

I’m pretty much against using my blog for an out and out promotion.  I do not sell things here, nor do I try to market any companies including my own.  The hordes of people coming to this blog all the time do so because they are constantly wondering what I think about Lean and Agile stuff, and I hate to dilute that by pushing a particular product, service, or organization even if it would be advantageous to me in some way.  I’m not trying to sell anything, including myself.  That sounded weird, but you know what I mean.

I’m going to make a bit of an exception in this case, though, partly to help out my omnicompetent buddy Risa, and partly because I have a strong sense of quality control when it comes to people that I work with.  If you are reading this, right now, then I already know a lot about your respective levels of quality.  I’m just going to leave that ambiguity there.

Netchemia is always hiring these days, it seems, in virtually every department, but we’re especially angling for Market Development Representatives (MDRs, which does not stand for Massively Dope Revenue-generators like I thought).  Our original copy for these job postings looks like this:

Netchemia is looking for Market Development Representatives who demonstrate the following characteristics:

  • Highly competitive and motivated by money
  • Ability to handle rejection
  • Relatable and outgoing personality, especially over the phone
  • Desire to build foundational sales experience

Check out our Careers page for more information and to apply!

Personally, I think the exclamation point at the end really makes the whole thing pop.

Now, you’re probably looking at this and thinking, “Those first two things sound like every guy ever, and the whole thing together kind of sounds like telemarketing.”  And I can forgive you for thinking that, because it sort of sounds like you’ll be doing some variety of sales over the phone.  It mostly sounds that way because that’s pretty much what you’d be doing.  But however it might look like telemarketing at first glance, it differs from that profession we all love to hate in a number of important ways.

1. No Cold Calling

When I think of sales and the phone, I think of someone calling me during dinner and saying something along the lines of, “Hello, Mr. Ledgerweed.  I’m Joey Bananas from Phone Company X.  I know you’re interested in saving money, and I’m not interested in pausing, so buckle in and get ready to feel several Gs worth of money-saving forces.”

In this scenario, Joey obviously has no idea who I am or even if I happen to be interested in changing phone service.  All he knows about me are: A) I have a phone, and B) I am an entity capable of speaking on one – both things he realized in the first few seconds of calling me.  It’s the verbal equivalent of getting junk mail, if the junk mail could somehow attach itself to your face for fifteen minutes and read itself to you.  You could literally be anyone.  Joey is just calling numbers, and destiny brought you together.

Our MDRs contact people at various levels of school district administration.  They are people who know us.  They are people who are friends and colleagues with other people who love Netchemia’s stuff.  They are the people we drink with at conferences and make fun of boring keynote speeches with.  They are not random people who just might randomly be interested in K-12 administration products; they are K-12 administrators, and it may surprise you to know that intensive market research has shown that K-12 administrators are the people most interested in K-12 administration software.

I’m not gonna lie – I’m not saying everyone you call be will be all, “Praise the hammer of Thor you called me!  Yes, I have plenty of time to talk!  And when can one of your Account Executives get in touch with me to begin my journey to efficiency?  My life changes TODAY!”  There’s a reason it’s important to be able to deal with the fact that a relatively decent number of people will not have time to talk to you right now, or have already completed their budgeting process for the year, or have administrative assistants with a touch of sociopathy.  But you are not calling random people who have never heard of you to create a demand that doesn’t exist.

2. Sales Experience Without Selling

Most of the actual selling, dealing with objections, and pyrotechnics are handled by Account Executives.  It will be your main job to talk to K-12 administrators and get these two crazy kids together.

If you are trying to get your foot in the door in sales, this is a way to get used to meeting new people, listening to them talk about their situation, figuring out a good fit, and making the best decision to help a prospective client, and you do all this without the added pressure of being primarily responsible for closing a sale.  Sales can’t happen without you, though, and you will be learning and developing sales chops as you go.

3. Dan’s Pretty Great

Dan is the majordomo of the MDR squadron, and several of our employees can attest to his mentorship, leadership abilities, and genuine care for the people who serve with him.  He’s a lot like Yoda, if Yoda were human, spoke normally, had no supernatural powers, was in Marketing, and was very much unlike Yoda.  You will grow as a person and a professional working with Dan, and if you are even remotely interested in a sales-based profession, the opportunity to work with him is reason enough to apply right now.

Enhanced by Zemanta