Cracking A Thick Shell…

A couple years ago, I read an article from Eric Sink called "How would you reach YOU?" and a recent conversation reminded me of it.  A friend recently sent me a soft pitch on a project/idea that he was contemplating.  He was in the early "please burst my bubble!" stage.  While I thought the product had great value, reaching his target market was going to be difficult at best.  The situation reminded me of this quote from Eric:

I was sitting in my office chatting with my coworker Jeremy Sheeley. Jeremy leads the dev team for Vault and Fortress. In the course of our discussion, I suddenly realized that none of our marketing efforts would reach Jeremy. He doesn't go to trade shows or conferences. He doesn't read magazines. He doesn't read blogs. He doesn't go to user group meetings.

Jeremy is a decision-maker for the version control tool used by his team, and nothing we are doing would make him aware of our product. How many more Jeremies are out there?

While Eric talks specifically about marketing and individual decision-makers, what happens if this is organization-wide?  What happens when an organization doesn't look outside its own borders for new ideas and perspectives?

I've seen at least two organizations face this sort of dilemma:

The first chose a technology stack in 1998 and – as of 2005 – hadn't updated anything (even software versions!), worked to learn better practices, or even evaluated other options… and the worst thing is that they didn't realize what they were missing.  When I first joined the team, they were a 1 on the Joel Test.  There was no "issue tracking" or source control or anything similar because "there wasn't time".  The team had grown from one to ten members during this time, so things were good, right?

During my tenure, I worked to implement some of the Joel Test items.  The first was source control, then issue tracking, and then estimates for proper scheduling.  For a brief period, we reached a 6 on a number of projects but still 1 one organization-wide.  More than anything, I noticed a change in the team members… solid people who were overworked and miserable before were still overworked and miserable, but now they spent more time on the properly spec'd projects.  Even better, we were able to track progress and actually track and close issues once they were reported.  By no means was it perfect, but it was significantly better than before.  Unfortunately, at every step of the way, the management resisted, belittled, and criticized every effort regardless of the result.

Obviously, once a better opportunity came, I left.

Unfortunately, in the following months, the management commissioned the development of a new issue tracker – ironically barring use of the old one in the meantime, then made version control optional, and finally ignoring estimates in task scheduling.

Within three months, the data was unused and out of date.

Within five months, team members started leaving.

Within ten months, only two of the original team members were left.  Yes, 80% of the team left!

While I don't want to be considered the cause of this turnover, I firmly believe it was due to the change in perspective.  By having new ideas injected, evaluated, and used – and don't get me wrong, easily half of my ideas were killed – they saw things could work differently.  Information, articles, books, and ideas were passed back and forth.  We saw some ideas that worked, some that didn't.  We saw a management not open to evaluating new options.  They saw that some tools – eg. issue trackers – don't need to be developed in house, there are options out there.

Most importantly, the team realized that things could be done better… and left to seek it out.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub