hedgehog lab

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.

On founding a software company - Founding principles

A year ago, on 21 May 2007, Mark Forster and I co-founded hedgehog lab. After years of frustration working in full-time jobs that never seemed to fulfil our expectations, we decided that there was a great opportunity to build a developer-friendly company in the North East of England.

In retrospect, it was both the toughest and most fulfilling decision we ever made. Toughest because both of us hardly fit into the popular profile of software start-up founders of our time. When we started hedgehog lab, both of us were well past 25 and had considerable financial risk. Yet, nothing was more clearer in our minds than the single minded determination to create a company that lived up both to it's values and delivered the financial results to be sustainable.

In this series of posts on our anniversary, I wanted to talk about some of the key issues that affected both the founding of hedgehog lab and the journey through the past year. This one covers founding principles.

In an age when most start-ups are founded with the single-minded goal of "making lots of money", often at the expense of both employees and customers, we had a very value and principle focused approach to how we wanted to run hedgehog lab.

In no particular order, the following were the founding principles of hedgehog lab,

• Treat your employees right. In turn, they will treat your customers better.

  This is so obvious and simple, that it amazes me to see so many companies not follow it. It is blindingly obvious to me that if you want great customer service (in the all-encompassing meaning of the term), you have to start by treating your employees right.

  Why is it that "employee loyalty" is much taunted in HR circles, but "employer loyalty" is a rarely used word? An employer-employee relationship is a 2-way relationship, much like a customer-supplier relationship. Yet, companies pay far less attention and effort to maintaining the latter. Given the current supply and demand in the software market, it is high time employers started listening to their people. I understand the irony in my criticism, as I am an employer and an employee. My point still stands!

• Have conversations with your customers.

  Most companies have only 2 types of interactions with their customers, sales and support. There is nothing wrong with that, but to be a genuinely customer-focused company, you need to engage with them everyday. Listening to your customers is not enough. Talking to your customers is not enough.

  We try to reach out to our customers in everything we do. Whether it be a new company policy, the re-design of our website, or ideas for a new product, we engage with customers to gain their feedback and if necessary, make the changes that aligns us better with their needs.

• Turn your customers into fans.

  Having customers is not enough for us. We want to turn them into fans by appealing to not just their needs but their perceptions of what a great company should be like.

  You might think that this is a bit lofty for a company that produces business software. After all, only consumer companies with cool products can turn customers into raving fans. You might just be wrong.

• Eat your own dog food

  This is mostly used as a promotional strategy by product companies to prove that their product is "good enough". However, at hedgehog lab, this is our primary strategy when developing a new product and is the overarching principle around both product and feature design. We would never develop anything that we would not use as a company or endorse otherwise.

fixx beta - the first step in delivering painless bug tracking for software teams

It has been a while in the making, but I am glad to announce the beta release of fixx to the general public.

To the dismay of many of our followers, we have been rather tight-lipped about fixx until now. No doubt, I will be following up with a more detailed post on how fixx came to be, our product development process, the decisions made and lessons learned. For now, we have a sneak peek at the initial features in fixx version 1.0 and a public beta for those who prefer getting their hands dirty.

We are still looking for more beta testers and general feedback or comments are welcome in our people-powered customer forums.