Ancient wisdom is inescapable, especially with project management


Today was my last day with my current former employer, as you may have heard from my (also now-former) coworker.  We quit on principle after having several irreconcilable differences of opinions with our management over how to manage and execute a software project.

As you might imagine, after a rather trying and emotional last few weeks and especially day, I did a lot of reflection and introspection — trying to see where I was wrong (I admit, I wasn’t right on every point, but I’m pretty sure I wasn’t wrong on every point either).  As if by providence, when reading books to my 2 year old for bedtime, I actually grabbed a book (I swear) by total chance that turned out to be a retelling of Aesop’s fable Tortoise and the Hare.  Surprisingly, this story almost completely captures the entire point of the arguments I’ve been trying to make the past couple weeks. It’s a short one, please allow me to indulge you in its entirety:

Once upon a time a hare saw a tortoise walking slowly along and began to laugh and mock him. The tortoise challenged the hare to a race and the hare, thinking himself the fastest animal around, accepted. They agreed on a route and started off the race. The hare shot ahead and ran briskly for some time. Then seeing that he was far ahead of the tortoise, he thought he’d sit under a tree for some time and relax before continuing the race.

He sat under the tree and soon fell asleep. The tortoise, plodding on, overtook him and finished the race. The hare woke up and realized that he had lost the race.

Moral: Slow and steady wins the race.

Especially, almost perfectly, this applies to software development and project management. Any project, of any sufficient size, must achieve some sort of steady pace, a rhythym, a momentum to achieve success.  The more starts and stops, context switches, jostles, or sporadic/inconsistently-timed changes you introduce, the more likely you are to affect that pace negatively to the point where you setting yourself up for failure.

The Hare Mentality killed our project

There is a point in every project — well, every project I’ve ever been a part of in one shape or another — where panic starts. I’m not quite sure what starts it every time, but the ones that I do know of have all been about money and ‘burn rate’ and I’m willing to bet that all of them (even the ones that were not made known to me) are about that. The point of Agile, in my opinion, is to allow visibility and more frequent opportunity for decision points for the stakeholder for just these types of moments.  The appropriate response, when this moment of panic is about to ensue is for everyone, especially the stakeholder, to put on their big boy pants and start making the hard decisions about what to cut.

The inappropriate response — oh there are many, but they boil down to this — is to start mistrusting the developers and start assuming they’re lazy SOBs who have been cleverly avoiding work throughout the whole project.  Looking back, nearly every single time the panic season started, this was the demeanor the stakeholders took.  Instantly the project went sour, all pace was destroyed, morale tanked, some people went into psycho 100hr/wk work mode to prove the stakeholders wrong, others proved them right by giving up and not doing anything. Ultimately, the project died a rather undignified and flaming death. Failure resulted (or perhaps success didn’t happen to the degree to which it needed to happen), the team burned out and most left while the stakeholder was stuck with a failure product and all their critical brain trust gone or demoralized.

Leadership is about, among other things, trust

If you wish to avoid the later crash-and-burn scenario I described above, you should strive, instead, to achieve the former scenario — the one where everyone rolls up their sleeves and makes tough, but smart, decisions instead of accusing each other of tanking the project before it’s actually was tanked, thus self-fulfilling the prophecy.

You interviewed these developers, the project manager, the project lead, the testers, etc. You saw their resume, you may have even checked their references. They’re here because YOU brought them here. YOU pay their paychecks. Therefore, YOU must enable their success and let them do what they have been hired to do. If you don’t trust them to do that, then, it must be asked, why did you hire them in the first place? Or more presently, why are you keeping them on?

When you reach the crumbling precipice edge of Panic Chasm, resist the urge to accuse other people for the impending doom — thus forcibly casting the entire project, its team, and quite likely yourself into that chasm.  Stop, step back, take a deep breath. I guarantee you the 5 minutes it should take you to do this properly will be the most important 5 minutes of the project. Do the rational thing and pick up the phone or march into the team room/lead’s office/cube, etc and tell them that you’re gazing into Panic Chasm and it’s time for Plan B.  At this moment, you MUST trust the lead to do the right thing. No other choice will lead to any hope of success. Only trusting the project lead and the team will ever ensure any hope of yielding any success that matters.  That doesn’t mean it can’t still fail, but it will at least fail truly — on merit — because it simply was not accomplishable by the team you had assembled.  At this point you will have a solid failure and you will have clear knowledge of why it failed with no gray area for abstract finger pointing. A clear failure, in my opinion, is better than a fuzzy failure (for which some may declare success, take credit, and leave you holding the bad of that ‘success’).

Plan B

So the time for Plan B has arrived. This is it, there’s no turning back. Everyone on the team — stakeholder and producer alike — must trust each other to make the hard decisions and cut what they must to make the plan happen. You must resist the urge to bear down, roll up your sleeves and do everything wrong as fast as you can and ruin everything you’ve strived for. It’s during the hard, trying times that discipline pays its debt. Soldiers don’t go to boot camp to learn how to salute during peace time, they go there to learn how to be disciplined when the bullets are whizzing past your ears. The only thing that will save you know is doing what you know how to do, according to the process and procedure you’ve established and trying to eliminate as much waste and extra work as you can.  Stakeholders must make tough decisions about which of the ‘Absolute must-have’ features has to go. Producers must make the tough decisions about where they might skimp on some design discussions and sign up for some technical debt. Everyone must make decisions about where they might be able to live with a little less testing here and a little less design there. It will be hard, and it will make you cringe, but as long as you do it with discipline and full knowledge and cooperation among the team members, you can get through it and arrive with success that you can sustain going forward. You may have to cycle back and remove some technical debt, fix some bugs, add back in some tests that you had to skip, but you stuck to the process, kept the faith/discipline, and you arrived with your dignity in tact and the knowledge that you didn’t sacrifice the whole project for the sake of one deadline.


Because, as you know, after that deadline, there will be another deadline. And another. And more tough decisions and known, documented shortcuts that will have to be paid for later, etc.  As long as you have a process to keep everyone focused, a team that’s committed to not panicking, and a level of trust to carry you through the roughest times, you will be able to make it through them all.  If you do panic, and you allow yourself to descend into going off the process and ditching the discipline, you will most likely never be able to get back onto it and you will almost certainly fail the next, last deadline as there probably won’t be any more after that and all will have been for naught.Don't Panic

Final thought

If you remember nothing else from this post, remember this: DON’T PANIC

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in Agile, Mangement, Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • It’s all a fun game to play, right Chad?

    I used to love going to the “Panic Mode” meetings, where business practically wills the team into switching into death march mode. It was a curious observation of willful reality distortion.

    Devs: “We can’t finish all of these features on time. You have to make a cut. Which ones can be left out?”

    BA’s: “All of these features are Must Haves”

    Devs: “They can’t be. Something must be cut.”

    BA’s: “All of these features are Must Haves”

    And so on until the devs are forced to give in unless they want to be branded as “Not a team player”. Funny how past records of success shape future assumptions on how to succeed. If your former employer never hasn’t had a successful project in years, they won’t know how to manage one.

    Luckily the market is too good for talented folks to be held hostage by uncompromising businesses.


    All it sounds like to me is that Chad and Jeremy’s now former employer went to great lengths to scare off two of the most talented solution delivery experts in the biz. Kudos to them for that, these are folks that love challenges. But not mental bullies.

    It sounds like the former employer lost the employees, not vice versa. Either of these guys /could/ have found employment by the end of that same day. I’d say panic would lead to taking those jobs. Steady pace would invite careful consideration over their next endeavor.


    Good luck on your future endeavors, and there are great employers out there. It can be tough finding the right questions to ask to separate the wheat from the chaff. If you ever find out what those questions are, be a cool guy and let us all know what they are :)

  • @jbogard:

    The reason I wrote this post is because most of the places I’ve worked, the various stakeholders all seemed to like the idea of Agile and bought into it, even played along with it and helped to move the project along. But at the first sign of any sort of crisis or hardship, they’re the first ones to ditch the process and revert back to pre-Agile and want everyone to switch to head’s-down, everyone panic mode. In every single case, three things happened: 1.) The project failed and the hurry-up was for naught (or some temporary goal was met, but it was unsustainable and quickly fell apart shortly afterwards) 2.) the team was burnt and most of the people left, or were so demoralized that they were next to worthless after this ordeal, and 3.) the situation that caused the panic in the first place was not dealt with and persisted, causing the project (if it managed to survive, limping and bleeding) to continue stuck in Death March, crazy mode which caused #1 and #2 to repeat but with much worse severity.

  • @Chad – pretty amazing. It’s funny how companies make the same stupid mistakes over and over again. Jimmy hit the nail on the head talking about scaring off two of the most talented folks in the business. Absolutely amazing.

  • Great post, Chad. Thanks so much for sharing the lessons you learned.

    I look forward to seeing what you and Jeremy go on to next.

  • @Chad: Thanks Chad, I needed that post.

  • Amazing. Just amazing. Sorry for your bad experience Chad. Know you and Jeremy will land on your feet, but what a crummy thing to have happen to you.

  • I’ve been here. I’ve left as well.
    Sometimes when I arrive at clients I’m in this situation and it sucks. If I can, I help them see the light, but as its been documented, sometimes the manic-panic sets in with the higher ups and everything is ditched.

    Mgmt: “We dont need tests, we just need it to work!”
    Devs: “Uh.. ok, so how do you know if it works?”
    Mgmt: “Well fire up the app and test it.”
    Devs: “How about we write some re-peatable tests to ensure that …”
    Mgmt: “NO! We dont hvae time for that. I needed this yesterday! We have a conference in 2 days and this HAS to be done!”
    Devs: “Ok, well it wont work.”

    It just goes back and forth. Its ridiculous.

    Good move on leaving. I would have done the same.

  • Lee

    Thank you so much for writing this. Especially: “The inappropriate response…is to start mistrusting the developers and start assuming they’re lazy SOBs…” That sums up the CEO’s attitude at the last place I worked (and why I’m not there anymore).

    Ironically, the CEO ended up jumping the sinking ship – the only place he could get a job was the MORTGAGE industry. Too funny.

  • This and Jeremy’s posts made me think of turnover at our work, according to the way you calculate it at Wikipedia we are running at around 50% within development and support (over 2 years):


    So I’m wondering what the average is.

  • Oops I was wrong, 36%.

  • @Don: Repeatability, repeatability, repeatability. Testing it once only proves the software worked at that moment in time and the effort in testing it is lost forever.

    Write one set of automated tests and run them automatically forever and it keeps paying for itself.

    @Colin: Not sure how to answer that, lol. If you have repeatability and a good process flow going, turnover isn’t quite as devastating. If you have people turning over in less than ~2 years, that would be a warning sign to me (YMMV, of course, and certain situations come up — lottery, dream job, quitting to become a Monk, etc).