The MurkyGrey blog

Suppose we arrange the world’s software along an axis. On the one end of the axis is the ultimate shrink-wrapped product; sitting on the shelf, waiting to be picked up by a user who will rip it open, install and use it happily, never knowing (or caring) who built it or how it was built. On the other end is the definitive tailor-made solution; written from scratch to suit the needs of an individual user, commissioned to a master developer of the user’s choosing who must have spent many hours with the user to learn of his pain and design a unique custom-made solution.

It is this axis that yields the renowned divide between product companies and professional services companies. Product companies sell software, and they sell the same software product to as many clients as they can. Professional services companies sell their time and expertise developing or customizing software for specific clients, one project at a time.

Having started my career in product companies I grew accustomed to the many advantages that a product environment provides for software developers. In a product environment you can always bring an exciting technological idea to the table, a discussion of potential markets for the new idea will follow and if it makes business sense you get to build it. Product companies take technological risks and innovate; the rewards associated with bringing a new technology to a broad market justify the risk. If you are ever asked to build something that does not make sense to you (and we developers always know best…), you can put your negotiation skills to the test in a discussion with product management. With a reasonable product manager, you can impact product direction quite nicely.

In a professional services environment, a new business idea usually starts with a new project for a specific client. The project managers rule the roost, and each project is expected to be profitable or it is not worth undertaking. Much care is taken in gathering and refining requirements and design, but this process is centered around the client, not around technology. The entire project is funded by the client and sometimes the client owns the work-product completely. Naturally it is the client that impacts requirements the most, not the developer, not even the project manager. In a professional services environment developers have much less of a say, or at least so I thought.

If all had gone according to plan I would have spent my entire career working for product companies, but then there’s this pesky little thing called “opportunity” that always seems to get in plan’s way. When I made my opportunity-driven move to professional services I wasn’t sure what to expect. What I found surprised me, and eventually helped me become a better product developer than I ever was. The first thing I learned was that professional services companies are not as bad as I thought they were. They learned a long time ago that their profitability soars with repeatable projects. They don’t really take it one project at a time. If a process or a tool can be developed to serve multiple projects they dive right in and build it, in essence developing their own mini-products. The next thing I learned was quite annoying at first. It turns out that clients who fund a custom development effort are not inclined to keep paying for the promise of a product in the making. Instead, they want tangible deliverables for their continued support. Those tangible deliverables are artifacts that we are all know and love: requirement and design documents, project plans, test plans, and other such paperwork.

I was never opposed to reasonable documentation. In fact, I can rightfully be accused of having been a bit too fanatic about internal and external documentation of code, but I couldn’t help but feel that creating the level of documentation clients required was a waste of time. We have a perfectly good design that the developers understand very well, why spend more time polishing it so that some bureaucrat can read it and stamp an invoice? We test thoroughly and efficiently, why publish an executed test plan? We already know that the product is tested. These artifacts do not help us build the product, and they do not help the end-user use it, they are simply irrelevant. I was exhibiting a bias common in the product world: The product is important, anything outside the bounds of the shrink-wrap (or the tarball for that matter) is not important. Despite this minor annoyance, life in professional services was fun and rewarding and some three years later I returned to the warm embrace of a small product company.

Guess what? I’ve come to appreciate those annoying little artifacts. You see, even in a product environment you probably have important stakeholders outside the development team, prime examples are: non-technical founders, sales teams and marketing people. These stakeholders might not sign your invoices, but it is in your best interest to keep them engaged. Just a bit of effort to gather high-level requirements and design and turn it into a human-readable document will go a long way in sharing your vision of a future product or feature. Throw together an executed test plan or other evidence of testing and their confidence in your latest release will skyrocket. My foray into professional services turned out to be a rounding experience. I learned a thing or two about engaging non-technical stakeholders and lost some old biases.

Which environment do you prefer: product or services? What do you do to engage your non-technical stakeholders? Leave a comment.

Related Link: Giff Constable, When it comes to startups, products and services don’t mix

Somewhere out there is a CS student or a recent graduate who read my “Why work for a startup?” post and vowed to make a career in software startups. Well my friend, I love your style but be warned: the startup life is not all fun and games. Here’s what you should brace yourself for:

Risk and uncertainty

The fact is that startups fail at a much higher rate than older companies. It’s a risk you choose to take and you have to be prepared for. Work for startups long enough and you are guaranteed to experience painful layoffs and cutbacks, if not a complete collapse of the company. Can’t handle it? Don’t work for a startup! But remember: while startups are more risky than other companies, the illusion of complete job security anywhere is just that — an illusion.

Limited resources

Unless you plan to take my advice through a time machine back to the year 1999, the startup you work for will have limited resources. Do not expect glorious office space (that is, if you’re out of the founder’s garage and actually have an office). You’re equally unlikely to find unlimited expensive equipment or first-class travel. In a well-funded early stage startup you will have the tools you need to succeed, but in a “no frills” kind of way. You can expect a somewhat more luxurious setting once revenue from sales starts trickling in.

Stressful times

There are not too many of us and we’re running on a tight schedule with limited funding, it’s going to get stressful at times. Expect bouts of long hours, night and weekend work (but don’t let that become your long-term standard, you’re no good to anyone if you’re burned out).

What sacrifices have you had to make for your startup? Leave a comment.

The question is obviously one that I never need to discuss with colleagues, but people outside the software industry and those who found their success in large corporations often find it strange; why would anyone choose to stake their career on a string of tiny companies, each with limited funding and an uncertain future? Well, I love the startup life and I wouldn’t have it any other way. Here’s why:

Atmosphere

Ah, the startup atmosphere! The camaraderie! The sense of purpose that surrounds a small group of people dedicated to a common goal! The feeling that you hold your fate in your own own hands! You matter and you can make the company a success by doing the best job you can do. There is nothing quite like it.

Financial opportunity

If you work for a startup, you have equity. Whether it is a fat stack of founders’ stock or a modest package of incentive stock options, it means that if and when the company is successful, you will get your piece of the pie.

Variety

If you like some variety at work, you’re in the right place. With a small team, many of the business functions are performed by any team member who has some free bandwidth. That’s how as a developer, I got to do sales support, on-site customer support, collateral writing and more trade shows than I care to remember. It’s fun.

No nonsense

There are not too many of us, we’re running on a tight schedule with limited funding and a clear goal. There is simply no time for nonsense. We don’t sit through 3-hour meetings, we don’t do TPS reports and we don’t play office politics. The only reasonable thing to do is to focus on meaningful work.

Unusual perks

Startups are teeming with original thinkers and the flow of unique ideas does not stop when it comes to employee perks. While you should not expect to find on-site daycare or a company gym, other, more quirky perks are common. Think free snacks and soft drinks, gaming consoles in the break room, paintball outings and beer in the fridge for Friday afternoon happy-hour in the conference room (try to squeeze that one past HR in a Fortune-500 company), and there is excellent coffee, always.

Long-term prospects

As strange as it may sound, there are long-term prospects to be found in a startup. Regardless of whether your startup ends in an acquisition or fire-sale, one thing is guaranteed to outlive the company — the people you work with. The “startup people” will move on, most likely to another startup and if you play it right you will move right on up with them. Some of my friends have been moving around together as a group since 2003 and they are now on their third startup, having successfully sold the first two.

Also, not all successful startups get gobbled up by industry giants. While IPOs are not what they used to be, some continue to grow and evolve into privately-owned midsized companies that maintain many of the advantages of startup life for their employees.

What do you like best about the startup life? Leave a comment.

Welcome to the MurkyGrey blog!

If you’re interested in software startups, the MurkyGrey blog is for you. I will tell you how I survived (and mostly thrived) as an intern, a developer and VP of development in five different software startups over the course of twenty years. I will share what I know about the life of developers in a startup environment, as well as some thoughts and insights that are not specific to software. Whether you are a developer, a system architect, a development manager or an entrepreneur, I hope you will find my perspective useful, interesting or at the very least entertaining.

The MurkyGrey blog is not so much about code or specific technologies, nor is it about starting your own startup. Instead, my blog is about the trials and tribulations of the startup techies and the strategies they need to survive and thrive.