From software developer to software business owner
This post is a result of a long search for answers to the question “How do I need to run my company? And why does it feel like I’m stuck?!” and finally getting a lot of help from a book called “E-Myth Revisited” by Michael E. Gerber. I tried re-interpreting his ideas in the context of our own software development startup, and that’s what you see below. As luck would have it, most of this stuff falls into the category of “It would have been useful to know this two F-ing years ago!”.
Code, code, code, ????, profit!
There is stereotype that goes something like this: “Programmers love writing code. Give us an interesting problem, some food and a dark room - and we’ll be happy as pigs in mud. Throw some paperwork at us or break our zen with a meeting request - and you become our mortal enemy”. Joel Spolsky wrote a great article about this a while ago, called The Development Abstraction Layer. More recently, Paul Graham from Y Combinator talked about a similar issue in his essay Maker’s Schedule, Manager’s Schedule. That same stereotype also comes into play when programmer Bob decides to start his own businesses - he is determined to write code FOR himself and BY himself. No more bosses. No more meetings. Just code, code, code, ????, and then PROFIT! (Excuse my oversimplification). Here is one recent example: iPhone game development. For a while, that industry has been a programmer’s dream - you literally needed to create a good enough game, upload it to Apple, do a little bit of promotion, and BOOM - you start getting paid. Alas, it only lasted several months and only a few people were able to hit the jackpot. Market quickly got saturated and making money in that space became a lot more difficult. Nowadays, instead of playing a lottery, which is a tactical approach, iPhone developers have to increasingly think strategically, more business-like.
Second part of that stereotype: “We hate business and marketing just as much as we love writing code. We are not good at it. We don’t want to do it. We avoid it.” A lot of programmers will agree with at least some part of that statement, even after starting their own venture. For some, it might have something to do with perceived or real lack of people skills. For others, software architecture and design problems just seem so much more interesting and pure. Some people don’t mind taking on additional responsibilities, but they don’t know where to begin.
And that mindset might work out just fine when you have an infrastructure that shields you from the realities of how the company that you work for operates and what it needs to do to survive and keep you employed. But as soon as you step out of that cocoon and start a venture of your own, you can no longer afford to “just whip out code”, at least not in the beginning.
“Business” is a system that needs to be built, just like any other
If you have been writing software for a while, you know how many different things go into developing a successful product. You have to think about the requirements, what hardware it’s going to run on, who and how will be using it etc etc. If you look at it that way, there is a lot more to it than just coding. If you never learn that simple truth or choose to ignore it, your career will rapidly hit a ceiling. But most people do learn and do become better at it as the time goes by. Any well designed software product is a system whose inputs and outputs are clearly defined and quantifiable. It’s testable and maintainable. And, more than anything, it serves a purpose and fulfills somebody’s need. Stay close, and all you see is code. Step back - and behold a machine. That’s what successful software development is all about - being able to not only build the parts, but to also switch perspective and put those parts together into something bigger.
Good news: it turns out that building a business system is not very different from building a software system. In the same way, you have to define your inputs and outputs, figure out what components you need to put in place, how they interact with one another and so forth.
The key point here is that when you are developing software, your product is NOT code, but a software system that fulfills a need. Likewise, when you start a business, you product should NOT be software, but a business system that produces money (or whatever you define as your company’s “output”). Code is just a means to an end in a software product. Software is just a means to an end in a business system.
If you look at it that way, building a business can absolutely be a fun problem to solve. Sure, you’ll have to step out of your text editor for a moment, but the nature of the challenge is the same - to define a system and make it work. You’ve been doing that kind of stuff all along: putting puzzle pieces together, figuring out the flow and connecting the dots.Want more proof? How about some analogies. Some are better than others, I agree :-)
- Hiring employees = Looking for 3rd party libraries/components.
- Figuring out marketing strategy = Designing a UI.
- Market research = Figuring out software requirements.
- Funding your company = Making sure you have enough resources for your code/software to run.
- Running your company = Maintaining your software and making sure that it runs properly.
It’s just another level of abstraction. If you start a software company, you’ll be building two systems in one: a business system that makes money by fulfilling somebody’s needs with a software system that has code as it’s basis. How awesomely recursive is that?!
Yes, I know, not all software companies are created equal. Some build and sell software products on CDs or via Internet. Others offer software-as-a-service. But that’s what other businesses do, too - some build and ship products, and others provide services to consumers.The main lesson here is that you, the software developer, already have most of the skills that are required to build complex systems that produce something. If you decide to start a business, you need to learn how to abstract those problem solving skills and apply them on a higher level.
But I just want to write software!
Nobody is asking you to give up your trade. You can be a business owner and still write code - after all, that’s why you decided to start your own company in the first place. At the same time, what you don’t want to do is start a business, hire “a business person”, dump a whole bunch of responsibilities on her and lock yourself in the room so that you can concentrate on the code. That would be the same as a software project lead telling somebody “go design a UI for me and don’t come back until it’s ready”. How do you know that the UI will work with the rest of the project? What if the artwork doesn’t fit? What if you change the functionality but nobody tells the “UI guy”? Just like in a software project, activities in your business must be interconnected. Somebody needs to make sure that everything works together. In other words, somebody (and it should really be you, maybe with some help) has to design and maintain the blueprints, the overall architecture of the business system. After that, you can delegate the actual “running” part of it and go write some code. Just make sure that whatever you do fits into the overall system. And don’t forget to check up on the “architecture” every once in a while to make sure that it still does what it’s supposed to (or, you can even delegate that and hire a CEO/COO/president type - in which case you become a shareholder-and-an-employee).
The main lesson here is that you cannot afford to abdicate yourself from managing your company just because you are only interested in writing code. You can only “design and delegate”. Create the blueprints (“architecture”, in the software lingo), figure out what roles and responsibilities should be in place (“design each component”), and find the right people to fill the roles or take on some or all of the responsibilities yourself (“get some 3rd party libraries or write the necessary code yourself”).
“E-Myth Revisited”
Obviously, there is a lot more to running your business. I highly recommend that you read “E-Myth Revisited”. Digest it and interpret it. Re-read it and apply it.
(And don’t let the idea of “building your business as if it was a franchise” and comparison with McDonald’s put you off. Think of it as a way to resolve scalability and maintainability issues).
