Methodology or Common Sense?
I’ve been working for startups for about 8 years now and have worked through some rather intense and explosive growth periods. I’ve always been big on process. If something isn’t working right more than likely there’s a missing or broken process. At my current gig, I’ve had the fortunate opportunity to build quite a bit of internal business systems and processes from the ground up which is what I love to do. The most difficult thing I’ve been up against is always the fact that in a startup, your job isn’t necessarily your job. Your job is actually what you thought you were hired to do plus about 50 other things. Sorry, not a fan of the “I wear multiple hats” line. Reminds me of something you’d read in “Why Business People Speak Like Idiots” (which I’m reading right now by the way, click that link and buy the book to help with my hosting bill!)
So what’s the point?
Simple, really. In a startup, common sense goes much further than forcing yourself into the preachings of any single methodology or following standard process protocol. You don’t need fancy graphs and charts, you don’t need bloated, strict processes and you definitely don’t need idiot speak. For example, I’ve read a lot of traditional “change management” blogs/articles/books and the common sense approach will save you a great deal of agony building change management processes into your startup. Stuff is going to change. Write down what changed along with how to back out if that change breaks something. As you grow, your systems and processes will evolve accordingly due to the complexity that comes with growth, but if you’ve paved the foundation of a common sense approach, you’ll be that much more adaptable down the road.
As mentioned in my opening, I’m big on process, but having process doesn’t mean sacrificing creativity or agility. A process doesn’t need to be bloated to be effective and you don’t need to meet 20 times and write a 40 page document about the process or how to implement it. Simply put, get the cow out of the ditch (react to the problem), figure out how the cow got into the ditch (analyze your process to find the breakdown) and then prevent the cow from falling back into the ditch (adjust your process)
In the end there is no rule that says you can’t pluck parts of different methodologies or standard process protocols and use them effectively together based on the situation. By exercising a bit of common sense, you’ll spend a lot more time getting stuff done and less time trying to figure out how to pound a square into a round hole.
