Working On the Business By Working In the Business
Michael Gerber, in his treatise on entrepreneurship The E-Myth [1], makes a firm point of the dangers of working in your business when you yourself are the entrepreneur trying to run and grow it (i.e. working on your business). He makes a compelling case that the activities of one and the other are not only completely distinct, but that they are also virtually mutually exclusive.
I completely agree.
It was a watershed moment for me when I acknowledged for myself that am far more interested in being a consultant than building and running a consultancy, even though the the latter carries with it much more prestige. I love the kind of consulting and application development that I do, and at the same time I have no interest in building a team of me-clones to do contract consulting work. So when it comes to me as a free agent consultant, I am much more about working in my business than on my business, and Michael Gerber is right to say that I haven’t created a business so much as a job.
The reason this is interesting at all is because of the fun twist on the in-the-business/on-the-business dichotomy that I love to play with: for an application developer who is not afraid to get his/her hands dirty with the daily roles and work of a given business, there is opportunity to make massive improvements to how that work is done. An example will make this clear.
During my one straight job out of school at MonsterCommerce I held a number of roles and one of them was manager of the custom programming department. We were an e-commerce company selling an already spiffy, feature-loaded shopping cart software package, but that didn’t stop loads of our customers from wanting it to do more new and novel things. So we had a custom programming department that would take feature requests, offer quotes for the work, and execute the jobs when opted for. About 2-4 requests would come in per day.
The system I inherited for managing these leads and projects was a drawer of a few hanging folders, my predecessor’s email in-box, and a notebook or two of notes. The notebook system, it turns out, scaled maybe for two weeks’ worth of leads before becoming cumbersome and impossible to manage without jobs and tasks slipping through the cracks. By this firsthand experience of working in the business I knew things could be better, and with programming skills, a desire to learn web programming (new to me then), and a dash of confidence (arrogance? ) I set out to create the solution I knew I wanted.
It was fueled by a simple vision: whenever so-and-so called, I wanted to type their name in, see their job on my screen with the complete lowdown (what they wanted, the status of the job, and even when we last talked and what was said), and be able to talk intelligibly about their project within 10 seconds as if getting it done was the only thing on my mind. (I think a lot of visions are fueled by frustration of doing something a few times when you know it could be so much better.)
Taking inspiration (and the design aesthetic) from our own shopping cart software, I learned how to program web applications[2] and design databases, and built my dream system one weekend at a time. It sat there, hosted humbly on the floor within the computer in my bedroom, during a time when each subsequent week a little more of my job was managed or automated by it.
After six weekends of development (and the interim six weeks of real-world use, testing, and tweaking), I was ready to show off my baby to the rest of the company. It was well received by all the parties it touched upon: billing, sales, management, and my team of programmers, and getting adoption was quick and painless. (The greatest honor was when the Design and SEO department heads both requested a similar system: I quickly forked off versions to suit both. The second greatest honor was hearing that it wasn’t until 2009 until these systems were retired, fully 3 years after I left the company.)
Building something that good was made easy (almost trivial, it felt) because I was making it for me to solve my own day-to-day problems. When my day-to-day usage revealed something that sucked I would simply fix it that night at home, and have a better system the next day. I had bridged the creator/user gap.
Not only were the systems nice and made a manager’s job easier, it made the departments better. Communication, coordination, follow through, professionalism and the bottom line all benefited. It was the stuff of systematizing things that Micheal Gerber would classify as working on the business, and doing so happened because I was steeped a little while working in the business.
This is completely unconventional. Software development talent seldom experiences the day-to-day work of the people for whom they create software for, yet what if that experience is a shortcut to making a really great system? Though unorthodox, time spent by a developer actually doing a job for which he/she is to make a software system for may pay out overall in time saved trying to otherwise imagine, describe and communicate the software needs. Any additional unimagined solutions/shortcuts/innovations devised by the developer-turned-worker are a pleasant bonus. Furthermore it makes nice protection from rough or ugly spots in an application: if a developer is saddled with using his/her own creation (even if for a little while), they will be apt to smooth over and tidy up such unflattering features.
It may be a loophole to the notion that if you’re working in the business you can’t possibly working on it: insofar as software systems are concerned, at least, a person working the job who is able to design systems to make it easier is leveraging the former to help the latter.
Notes:
[1] It’s been 4 years since I read it, so please pardon any haziness in my recollection of it.
[2] This is the root of my [still persistent] fondness for Classic ASP, an arguably terrible and woefully outdated server side web language. There’s always something special about your first.