In this special guest feature, Jesse Anderson from Cloudera writes about how many new companies, like the ones we see popping up in the Hadoop ecosystem, too quickly move from crawling to running, a process that sometimes leads to failure. Jesse works at Cloudera on the Educational Services team as a Curriculum Developer and Instructor.
Young children don’t ever want to walk. They want to run everywhere. This starts right in that phase between crawling and walking. The child takes their first few steps and decides that they aren’t going fast enough. And they start running. The ensuing face plant gives way to tears.
I see companies acting the same way. They aren’t going fast enough or don’t have enough velocity on their burndown charts. The solution is to go from crawling to running. The ensuing company-wide face plant gives way to failures and not knowing what went wrong.
I have a theory that all companies are working through four phases: crawling, walking, running and sprinting. Crawling is a company that can execute basic tasks most of the time. When walking, the company mastered the basic tasks and is starting to execute well on intermediate tasks, but complex tasks are just outside its grasp. Once running is achieved, the company is good at expert level tasks. The sprinters are companies that are world-renowned and masters of their trade. The other companies look to them as the leaders of their respective industries.
Like it or not, the vast majority of companies are either crawling or walking, and after many attempts to transition to another phase and then face-planting, they’ve decided that it’s just not possible. The majority of their efforts just fail or aren’t very good. Everyone is trying hard. There is just some ethereal piece that is missing that causes these projects to fail.
The analysis of the failure usually starts at the beginning of the project and only focuses on the project. But, like the young child running, there is something more fundamental that is missing.
I remember when I was the Engineering Manager at a software company that was stuck in an infinite loop of trying to move from walking to running. The company had great ideas, but the execution was never 100% and the customers’ satisfaction reflected that. There were several fundamental things missing from the company and it could never progress to the next step until it addressed those issues.
I looked around the company and identified the issues I saw holding us back. I fixed a number of the issues that were more process and people oriented. However, the company was missing an entire department that other software companies have: a QA (Quality Assurance) department. This fundamental check of software quality led us to ship software that wasn’t tested. These bugs in the field led our support resources to be over-extended and perplexed. Support escalations came to Engineering when solving difficult issues.
This cycle repeated over and over causing both departments to under-perform. In other words, we never had the time or resources to set ourselves up for success to get to the running stage. Our support could never reach out and be proactive with our customers because they were fighting fires. Engineering timelines consistently slipped because we were looking at customer issues. Engineering wasn’t spending its time creating new features to make our software better. We couldn’t spend our time improving the back end that makes a Software Engineer’s life easier and enables them to be more productive. These were the things we needed to achieve to go from walking to running.
A company that constantly tries to make its employees walk, then run, without giving them the resources to do so is never going to run. There are very definite things company must do to go from walking to running. Do you having everything that a similar company in a similar field would have (like a QA department)? Do the employees have the skills and training necessary to accomplish these goals? Are the project’s goals doable given the time constraints, staffing and technical abilities?
Very rarely will someone from the front lines to stand up and say that these are missing. It usually means their job or reputation. Managers and senior staff need to pull this information. It also takes some honest, self-assessment of the current state of the company, projects and people. Making the necessary changes to fix the issues requires effort from everyone.
A project failure may not mean that the project failed. It may mean that your company was trying to do a project that required running and you face-planted. Don’t just fall into the ease of doing a retrospective on a project. Challenge yourself to look for a more fundamental reason. That way, your company can go from crawling to walking to running to sprinting.
Sign up for the free insideBIGDATA newsletter.
Speak Your Mind