Last Updated Aug 27, 2010 2:02 PM EDT
I run a technology and Web applications development company. For a long time I had my hands in every part of the business, from project development all the way through to project fulfillment. Whatever needed doing followed an unwritten protocol that came out of my head. That worked well enough when things were just getting started -- in fact, it was something I thought contributed to our success -- but at some point every business owner realizes there is only so much that he can hold in his arms.
I realized things needed to change during a sales trip to New Jersey. The only hotel available had lost its Internet, and my iPhone battery was drained. I wanted to see what would happen if I was incommunicado for a 12-hour period. Well, that's the night one of our servers decided to fail. It wasn't pretty. My people called the hotel, and I spent the whole night making panicked calls to various data centers. It wasn't what I needed to be doing before a big sales meeting.
I remember wondering whether anyone else could be doing this instead of me. The answer was no, for the simple reason that I'd never explained to anyone what steps to take if the servers failed.
Input from everyone
The failed server was my wake up call. That was a little over three years ago, and shortly after I got back from that sales trip, we started documenting our procedures.
We're a totally digital company, so it was natural for us to keep this information online -- it just didn't make sense to keep it in a three-ring binder and stick it in the bottom drawer of my desk. With a living document, different people could contribute their knowledge of how the business works. We tried to create a culture where teaching someone else to do what you do is a positive rather than a negative.
I started off thinking the documentation would mostly cover how to put out fires, but we ended up covering much more -- things like how we bill clients and how we hire new people. As an entrepreneur, it was easy to think I was great at hiring because my first hires turned out so well. But eventually everyone gets unlucky. That's when you realize that maybe you're not an HR genius, and should have a system.
The documentation process yielded some unexpected returns: One employee came in on Monday having written a code manual over the weekend. I didn't ask him to do that and I didn't even know we needed it. But once I took a look at it, I wondered how we'd come so far without one.
The problem of over-documentation
The process wasn't without its hiccups. When we started writing things down a few years ago, we really ran with the idea -- and ended up running off in a bunch of different directions. We over-documented the systems and then didn't do enough to make sure that they all tied together.
About a year into the process we took the different parts of the document -- including billing, HR, project development and project support -- and transformed them into a single set of cohesive procedures. We figured we had this down cold. We didn't, at least not yet.
Shortly after the revision, we hired a new management person and handed him the documentation saying, 'This is how we do things here.' The new hire lasted less than six months. We'd let him down because we didn't provide any of the context for the documentation -- he had access to a manual but was otherwise in a vacuum.
When things were undocumented, we had to constantly talk to new people to explain how to do things. That process, though inefficient, helped them feel like they were part of a team and helped them fit in better. No amount of clearly written instructions could accomplish that, so we had to strike a better balance.
I now check in with new employees on a regular basis, to see how well they are dealing with the procedures. But more importantly, we explain why we think doing things our way will help the company be successful, rather than just say, "this is the way we do it here." The fact that it is an open process, where everyone is allowed to contribute to reviewing and revising the procedures further helps to keep people feeling included.
The written procedures have helped things run much more smoothly. Now when something happens, people turn to the document first. And if that gets them 80% of the way to a solution before they come see me, that's time I don't have to waste. And then I can go back and add a little more information to get the procedure closer to 100%.
And from a practice-management point of view, things are running more smoothly, too. For the first eight years of the business, we billed every client differently and handled the relationships differently. Last year we posted revenues of $1 million -- and that volume of business would be difficult to stay on top of without a clear set of procedures.
I used to think that an ad hoc approach set us apart from other larger companies and made us successful. But I now know that there's a fine line between flexibility and improvisation.
As founder and CEO of Caxy, Michael LaVista is all about technology. When he is not at work, he is all about rock and roll. He is an '80s and '90s music junkie, whose band, the Rock City 7, plays gigs across Chicagoland.
-- As told to Peter McDougall