My Great Failure, Part 1: Overconfidence & a Humility Lesson

The Scenario: Overconfident

I was hired to deliver a new back office  software suite. Prior to my arrival, the project had struggled to get off the ground, so expectations were high. They placed a lot of hope in me and perceived me as the “hero” outside hire. What was worse, I knew and believed the hype (insert foreshadow music here).

After meeting with our customers, I compiled a business requirements document (to tell programmers what the software must do). Proud of myself and what I was delivering, I packaged the document neatly and handed it to our technical architect.

I felt like Moses delivering the 10 Commandments. These were gold. This was going to solve all the IT / Business conflict they’d experienced. I was overconfident.

What Happened: The Smack Down

We worked in an extremely open environment. Forget cubicles, we had desks in a giant, open room that resembled a warehouse. Therefore, as I stood before the architect, the team and many of our customers could see the entire interaction.

The architect (who was several years my senior), removed the binder, then briefly and silently skimmed the pages. I was about to head back to my desk, when suddenly the architect screamed, “These are not @$%#&*& requirements!” In a blast of flurry, the now loose-leaf stack of papers was flung in my face and fluttered into a pile at my feet.

I stood stunned, for what seemed an eternity, before getting down on all fours and collecting the mess of paper. As I gathered the sheets, I vaguely recalled the architect shouting directions about what a business requirements document should contain.

I spent the next several days nailing down every possible nuance the architect could desire. Then I studied hundreds of great examples of business requirement documents. A couple weeks later, I meekly approached the architect again, with a new version of the document.

Again, he skimmed it, this time with a growing grin. “Perfect” was all he said. I’d never been more happy to hear a one-word response.

What I Learned: Humility

Sometimes difficult situations and challenging people are needed for a lesson to really sink in. In this case, my greatest lesson was humility. I should have approached the architect for his expectations long before I submitted the document.

This was a new organization, new people and new technologies. Everything about the situation screamed I needed humility. Yet I rode the wave of hype about me. As a result, I failed to present the best solution.

Three Lessons

It may have been the hard way, but I received great lessons from this architect’s critical feedback, including:

1. Humility, especially in new settings, is important: Humility is a cornerstone of servant leadership. As the saying goes, “don’t believe the hype” – especially about yourself. The minute you start thinking you’re great, you’re setup for a fall.

2. Gather expectations from all stakeholders: I was so focused on capturing the business requirements, I failed to capture the requirements for documentation from the architect. Respect those who’ve been there longer – chances are they can teach you a thing or two.

3. Send a draft: Yes, that could have saved me from public disgrace. But in all seriousness, time and audience permitting, send a draft first. I say, “this is a first draft (or even outline), is it looking like what you expect?”

I hope you’re able to learn these lessons from my experience, before you make the same mistakes.

Question: What other lessons do you see from my failure?

Note: This post is the first of three on some of my greatest failures and the lessons learned. My hope, in exposing my scars, is somehow helping you avoid the same mistakes.