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 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
Dec 272013
A Garlando style table with a game in progress

A Garlando style table with a game in progress (Photo credit: Wikipedia)

I’ve been pretty quiet after Samhain this year, maintaining a laser-like focus on getting version 1.0 of one of Netchemia’s new products ready for the new year.  My birthday (Scorpios UNITE) and Thanksgiving slipped past with barely a nod.  Originally, I meant for my return to social media to be a Christmasy post, but the sad truth is that I was sick on Christmas and celebrated the incarnation of our Lord by eating reheated pizza by myself and watching Family Guy.  This is not the stuff of which epic posts are made.

In the absence of holiday-related material, I spent some time reflecting on why I enjoy working at Netchemia so much.  After all, I’ve worked in almost every .NET development shop in Kansas City either as a consultant or a full-time employee, so what makes Netchemia different?  There are many reasons, but most of them boil down to three, main ones.

NOTE: None of these reasons have anything to do with foosball, which is a game specifically designed to lower my self-esteem.  My only notable foosball tactic is to throw a spare foosball in my opponent’s face and hope that gives me enough time to score.

3. Kaizen

Netchemia has been up and running in some form or another for about ten years and has racked up around 80 employees (probably 90 by the time I finish writing this if the growth rate holds), but if you spend some time there, it very much feels like a startup.

Everyone in every department is constantly working to hone their craft, including upper management.  There are no sacred cows.  There is no “this is how we’ve always done it.”  Running lean, being agile, and continuously improving are elements baked into the culture long before I got there.  This has ramifications for software development, definitely, but it also rigorously applies to sales, marketing, customer service, and operations.

Challenging others (respectfully) is encouraged and sought after in employees.  Passionate debate is frequent and welcome, all done in an atmosphere of trust and mutual respect.  You can march over to the CEO’s cubicle and tell him you don’t believe we’re making good decisions, and you’ll get treated to lunch instead of fired (this is how I get my lunch these days – inventing challenges).  When was the last time your company shared its financials compared to its goals with all the employees?  Netchemia does that every month.  Ideas and innovation about any aspect of the company from any quarter is much desired.

2. They’re a real team.

Although most companies would say they operate as a team, they really don’t.  Most departments in companies would also say they operate as a team but don’t.  What you usually have is a group of silos in a company that hand work off to one another, and you have a department where everyone is doing the same kind of thing, but they do it separately.

Netchemia is perhaps the only place I’ve ever worked at where I would call the entire organization a legitimate team.  Everyone from every department routinely communicates with the others on virtually a daily basis to move company goals across the finish line.  Almost daily, I talk with someone in sales, marketing, customer service, and upper management for the specific purpose of helping each other accomplish our work.  Within my own department, any feature of reasonable size typically has two or more developers on it working together and collaboratively to complete that feature.

I realize this may not appeal to everyone.  Some people like to be off on their own working alone, and I sometimes like that as well for a change of pace.  But generally speaking, complexity in delivering business value is best addressed by teams, and I love the level of collaboration and teamwork that doesn’t just exist at Netchemia but is intrinsically required to do your job and help others do theirs.  The environment is hyper-collaborative.

1. The people are awesome.

This is not to imply that there aren’t awesome people all over Kansas City, because there are.  The people I consider colleagues, friends, and enemies are all high-caliber types and work for or run a wide variety of companies.  But there is something about the crazily intensive hiring process at Netchemia that has produced a certain characteristic batch of individuals.

First of all, the overwhelming majority of employees are attractive.  Now, this fact doesn’t really mean a lot to me, but the implication does.  This means that, statistically speaking, my employment at Netchemia provides very good odds that I’m also attractive, so that’s an ego boost right there.  I may be one of the exceptions, but it would be really rude to point that out.

The main thing, though, is that most of the people who make it through the hiring gauntlet turn out to have several of the following characteristics: entrepreneurial, intelligent, articulate, energetic, thoughtful, sacrificial, dependable, competent, tough, hilarious (sometimes unintentionally), and they love the company as much as you do, if not more.  They are the kind of people that motivational authors encourage you to surround yourself with.  Being around them is a motivation to go to company events outside of work hours.

Sure, the organization has its weaknesses and some days you may not like everyone equally well, but for me, the company is a perfect fit.

Enhanced by Zemanta