hedgehog lab Bug Tracking, Defect Tracking, and Issue Tracking software for the enterprise.

On founding a software company - Rules, regulations and red-tape

In my last post, I talked about the ethics and principles behind the creation of hedgehog lab. Interestingly, a year after they were formulated, the principles still stand and continue to be applied in our day-to-day operations.

I wanted to discuss the other side of the coin, which are usually "company policies" (or rules or regulations or call them whatever).

It is a given that to operate under the legal structure of a "company", there is some need of guidance and a framework of understanding between people in the company. I suspect this was the reason company policies and rules were conceived. Otherwise, let's face it; you are running a loosely held-together anarchy.

The problem with this, is that, after years of employment law and employer-employee tensions, company policies have grown to a stage where they are either impractical, irrelevant, or sometimes, plain stupid.

We can all identify working in companies where we constantly question the basis of rules and regulations. It is a pity, that it is hard to find an employee these days who does not disagree with some policy that is established by their employer.

At hedgehog lab, we do have policies. However, these policies are not set in isolation by any one person. They are a collective decision taken by the entire team (with one of us co-founders making the final vote, if collective agreement cannot be reached). Moreover, we ensure that these policies are reviewed collectively by everyone and every team member has an indisputable right to question every policy we make.

Policies that worked for us and continue doing so.

Working from home
I discussed our working from home policy in detail in previous posts. This has been an overall success for us, in the fact that we have seen no significant problems with productivity compared to companies where you are forced to "go to work".

The difference here is that, unlike some companies, we are not a remote team (and never will be). Our team enjoy human contact and the collaborative benefits of working together far too much to re-sign ourselves to working from our couch.

Developers are both the front-line and back-office staff
This one splits popular opinion, but we are strong believers that the best way to deliver both exceptional products and service, is to involve developers at both the front-line and back-office operations.

The risk here is that most developers are either not very interested in dealing with customers, or do not have the right skills to pull off customer service and sometimes, sales. Our approach to this has been liberal, where we have left the choice to the person as to whether they want to be involved or not. Luckily for us, everyone in our team has been quite enthusiastic about this.

I believe that with the right amount of support and motivation, you can turn the opinion of the most stubborn developer to get involved in customer-facing operations.

Training
The problem with running a software company that builds products, is that you tend to not have time for doing much else. With milestones to hit, features to plan and bugs to fix, there is very little time and justification for training. It is far worse if you are a service-based company.

We have made it a policy now to encourage training actively, as opposed to leaving developers to "learn in their own time". Using your "lunch break" and "spare time", for training is so 1890s! Our training policy revolves around fully-paid conference attendances, free books and our own lab days, which encourage active discussion and learning of new concepts and technologies.

Policies that didn't work so well (even we get it wrong sometimes!)

Official job titles
When we started hedgehog lab, we wasted something in the magnitude of a whole man-week, trying to come up with the structure of the company. This was when we had 2 people in the company! We deliberated (no really!) a lot on what roles we would have and what titles we would use for future hires.

This week long analysis produced gems like "Director, Technology & Products" and "Developer, Technology & Products" (I'll buy you a chocolate brownie if you have a clue what those roles mean). Suffice to say, we went down a lot of points on the cool-factor with our newest hire, Rey.

Last week, we abolished these job titles and gave the opportunity for everyone to define their own job title, that fits in with what they feel represents their role and job description. Look out for the Code Ninjas!

Business cards
As part of our week-long "formation strategy" (eat that Sun Tzu!), another stupid-genius idea we came up with (to be honest, I have to take the sole responsibility for this), was to have business cards for every employee and make sure they use them when they meet new people. Needless to say, not many of us (the single ones) were getting any dates as a direct result of this!

Ok, maybe it wasn't that bad, but don't even get me started on how stupid and total waste of time this idea was. This policy was quickly abolished, with the business cards being limited to me, for my sins of coming up with the idea (and because I am the Managing Director, I guess)!

We would love to hear about any policies that you have come across, at your present or previous employer, that you either dis-agreed with or were plain stupid/funny.

In the next post in this series, Mark Forster (co-founder of hedgehog lab), will be talking about his personal experience as a developer starting a software company and reflect on the year that was.

posted by Sarat Pediredla on May 30, 2008 at 2:54 p.m.