On building companies, open spaces and with a little pairing on the side

Here are two longish emails that I should have converted into blog posts. I'm lazy, though.

Whatever. Here they are.

Switching from a solo contractor to being a development company (full thread)

Luke,

> I like doing a range of stuff, for example managing client
So is it fair to say you enjoy managing entire projects, and that this
is what is motivating you to consider starting a company?

If yes, then here are a few thoughts off the top of my head.

Why start a company:
* You should figure out goals for your business; remember, a business
is best run based on a set of principles rather than on implementation
details. The implementations (and consequently the role you play as a
founder) change based on market situations, but principles will remain
broadly constant. What you've outlined in your response is what *you*
want to do; as someone already pointed out on this thread, as a
business owner, you'll find yourself having little to do with the
execution of projects once you grow even a little bit. Pre-sales,
sales, strategy, recruting, client satisfaction and employee
satisfaction will take up *all* your time. Hacking open source is
something I now do over weekends as a hobby. That's just how it is.

* Define success criteria. "I know my company is successful when foo
happens in a regular and measurable manner." If you don't define
success criteria, you won't know if your business is stagnating.

* You didn't mention making more money than you are now as a goal.
Even if your business isn't about increasing your income, it still
needs to be sustainable. This means that you *have* to set revenue and
profitability targets for the business, or you will stagnate quickly.
Stagnant businesses find it very hard to survive in poor economic
conditions.

* Try to play the devil's advocate; question your every motive and
decision, and come up with alternatives that provide the same outcome
without starting a business. Evaluate each of those alternatives very
honestly, because, maybe they're actually a better fit - starting a
business is a risky proposition. And if they don't, they'll help you
understand your own motivations better, which in turn will help you
understand the principles around which you want to build your company.

Sales:
* Start small, use sources that build trust like odesk and elance -
treat them as your marketing arm. The 6% to 10% you pay them is your
marketing budget.

* Your next objective should be to get *off* these sites as quickly as
possible. That way, you force yourself to do branding, positioning and
marketing, channeling that same budget toward these activities.

* How you do your marketing is a function of whom you're selling to.
How big are your clients? How much revenue do they make? Whom do you
speak to in their hierarchy - the founder/CEO, middle management, or
engineering? All of these questions will help you determine how you
present yourself and your company to them. To some prospective
clients, you'll be the experienced engineer who happens to run a
company. To others, maybe you need to be the CEO of a consultancy.
However it plays out, market segmentation is absolutely critical.

* Identify sales channels. IRC, mailing lists, meetup groups,
conferences, hoardings, TV ads - it all depends on what your budget is
and which market segment you're targetting.

* You can't be good at everything. Understand and accept that the
moment you start a company, you are a manager, and a good manager
knows when he/she needs help. Don't hesitate to hire people to fill
roles that you're no good at yourself (remember the 10k hour rule -
you just don't have the time to become good at everything). So long as
these people increase revenue and profits, you're fine. In my
experience, one or more trusted, competent co-founders who complement
your skills can make a world of difference (and make your life less
stressful).

Miscellaneous:
* Services revenue is a function of hourly rates * no of hours worked.
There are two ways to succeed at this in a financial sense - the
McKinsey model, and the Infosys model. One increases rates, the other
increases the number of hours by hiring large numbers of people. Be
clear about which model you want to apply to your company. If you do
neither, your profits will suffer, even though you may have
significant revenue.

* The McKinsey model will force you to push rates up steadily, and
also to hire increasingly better talent. Branding your business to
increase rates and recruiting top talent are the core problems to be
solved.

* The Infosys model will force you to hire more people. Maintaining
acceptable quality while keeping rates low, and recruiting sufficient
people are the core problems to be solved.

* Build up a cash buffer. Services sales (well, all sales :)) are
cyclic and if you hit a slump, it will hurt. In the beginning, hedge
by hiring contractors until you've got (say) three months salary in
the bank. Then start hiring employees. Remember, you can't do enough
to keep the people who work with you happy. Step one is them knowing
that their salaries are not constantly at risk.

* Study. There are three lines of work that (off the top of my head) I
can think of that require constant study and reflection - medicine,
programming and business. You don't have to get an MBA, but you do
need to have a steady stream of books that you read and people that
you learn from. The bare minimum I would recommend is getting a
subscription to 'The Economist' and reading it religiously every week.
Try to also find semi-formal or formal advisors with industry
experience that you meet with (say) once a month to review your
business.

Phew. Long post. I think that's a fair distillation of what we've
learned building our business over the last couple of years. Feel free
to ask questions if you want me to drill down into anything in greater
detail. I'm happy to also cite practical examples if it would help.

Regards,
Sidu.
http://c42.in
http://rubymonk.com

Some thoughts on open plan areas (full thread)

I've worked in open spaces for about seven years now across several
different physical offices with different layouts, pair programming
the entire time. Based on conversations with my colleagues that shared
the same environments, it's obvious that different people responded
*very* differently to the same setting. Also, I'm going to address
pair programming separately, as workspaces and pairing are orthogonal
and their effects shouldn't be conflated. Finally, these are my
experiences, so YMMV.

1) Large open space containing 120+ people - very hard for me to work
due to background noise, constant distractions, almost never zoned in

2) Large open space containing ~20 people - brilliant, I loved all the
space, and other teams were far enough away that background noise was
negligible, yet they were clearly in line of sight so when I wanted to
ask a question, I could see if they were free and wander over. One of
my best experiences.

3) Large open space containing about 80+ people - this was the same
space as in (1) but with fewer people in it and with our team being
off in a corner; it worked better than in (1) but not as well as (2)

4) Connected open spaces, each containing a team of 2 to 4 people -
this I think worked moderately well; the lack of LOS raised thresholds
to communication, but the background noise problems and constant
interruptions by other colleagues was reduced

Extrapolating from these, I'd say what worked best was a large enough
open space that folks didn't disturb each other, but still had LOS and
easy access. Second best is a set of connected, smaller, open spaces,
one each to a team (assuming of course that your teams are one to
three pairs).

> Indeed, a lot of old research from MS showed that when coders have private
> offices, they are 2X as productive (yeah, %100 increase)
I think we make sweeping generalisations a little too easily. Writing
Windows code is not the same as writing a web app is not the same as
writing COBOL on a mainframe. Also, perhaps if those MS programmers
TDDed their code, they wouldn't have to hold so much of it in their
heads all the time, making intense concentration less necessary and
reducing defects, making them more collaborative, resulting in a
better shared understanding of the codebase and reduced truck-factor,
resulting in better software and happier engineers. Who knows, right?
Software engineering is a complex subject and I'd be wary of any *one*
factor being touted as a productivity silver-bullet. Ultimately, it
depends on the project and the people.

Now on to pairing. Writing software alone is a completely different
thing from writing software in a team. If you work in a
self-organizing team, then it is important to realise the impact of
your social relationships on your productivity because team
productivity is everyone's problem, not some manager's. Pair
programming just increases the importance of recognising the social
aspects of software engineering. The objective is to be able to zone
in with your pair, and you do whatever suits (and this is likely going
to change with *every* person you pair with). I know pairs that shared
an iPod, that moved to a meeting room or balcony so they had less
distractions, that were heads down churning out code in the middle of
the floor oblivious to all the noise around them...

Basically, getting pair programming to work has nothing to do with
open spaces and has everything to do with you and your pair
understanding one-another's work style. And yes, it's ok to accept
that there are some people you can never pair with because you just
don't get along. It's also ok to accept that you're extremely
introverted and are only comfortable pair-programming with people
you've been friends with for years. I used to be extremely introverted
(starting two companies changed that) but it's important to remember
that team *productivity* is the goal, not pair programming, open
spaces or whatever else. These are just mechanics that facilitate
productivity, and like anything else are subject to the 80/20 (or
50/50 or 20/40) rule.

Best,
Sidu Ponnappa.
http://c42.in
http://rubymonk.com