Posted on June 3, 2013 in Uncategorized by adamNo Comments »

(This had more structure in my head before typing it out, but I’m posting it anyways.)

OK. This got enough attention that it requires some expansion.

I live in the eastern suburbs of Toronto. As part of a bit of a geography lesson, the western suburbs have been traditionally home to various large tech companies due to its proximity to the international airport (and likely tax incentives). The eastern suburbs have been more manufacturing oriented around the [once large] car plant. As such, the tech ‘community’ out here is actually pretty small and disorganized when compared to both the size of the population and even the size of the population of people in tech that commute into the city for a living. [This is in spite of large efforts by some companies around here.] The make-up of the Toronto tech scene is also interesting. Yes, there are hip tech companies like ScribbleLive around, but most of the programming jobs are dominated by the various financial and insurance organizations or provincial government agencies that are based out of the core. And with those industries come ‘safe’ development environments, and large services contracts. Both of which equate to ‘Java’ and/or ‘C#’.

So let’s pretend that I was building a ‘traditional startup’ (an interesting juxtaposition of words if ever there was one) out here. And to throw an additional twist on the scenario, that I wouldn’t be the one doing the coding, what language / platform would I use?

Its actually not so simple a choice if I want to build for the future rather than build to flip.

Actually, let’s take a step back a second. It is actually a really simple choice if I embrace remote working as a fundamental building block for my company as I would just hire the best people and have them use the best platform for the job. If I follow the 1980s approach of having everyone in the same room, 9 – 5, things harder. A lot harder.

Again, using the eastern suburbs as my example, the majority of [experienced] programmers responding to your job postings are going to be working presently in the financial industry and are interested in your gig largely because it eliminates the commute. And it brings with them the baggage of that industry; Java and C# plus a much slower release pace than what one would expect from a startup. Which isn’t to say I wouldn’t hire someone out of that situation (heck, I started at a bank), but I would be very upfront with what they are getting into. But if you want to have the largest population to pull from, then your platform is going to be one of these two.

But let’s say you want to up your change of getting funded by using some buzzwords and you decided that what you want your startup to be around is Node and Mongo. Now you have a different problem — if you are not embracing remote workers. Let’s say that there are 300 people who know Node and Mongo within an hour’s commute from my this fictitious office. Total. Of those 300, let’s say that 50 (which is likely high) are of the level you want and haven’t just run through a tutorial or two on the internets. And of those there are maybe 5 – 6 that would consider leaving their current role and if you are really lucky one might live close-ish by. Otherwise you are going to likely have to overpay to have them deal with the lack of transit infrastructure out here. But that doesn’t necessarily scale. Go back in time 6 years and see how much more Rails programmers were getting paid for just this reason.

Take a moment and read yesterday’s Do you really know the business your startup is in? as this plays into the mix here. If you decide you are a technology company then you say ‘screw it!’ and use the cool tech, overpaying for talent if necessary, but if you decide you are more of a ‘service’ company then you focus less on the platform and more about the customer experience. So if you want people in chairs in the office then you need to factor in the skills and proficiencies of the pool you are drawing talent from when choosing a platform. Of course, if you are happy to have people working from anywhere in the world, but logged into IRC when working with a VOIP line available to them at any point then your pool is nearly infinite as are your platform choices.

Posted on June 2, 2013 in Uncategorized by adamNo Comments »

Here’s a theory; most startups don’t actually know what business they are in. They do likely know the business they want to be in, but unless your company is guided towards that specific goal (and you have no small bit of luck) it is your customers who actually determine what your company is an does.

In the spirit of Ninja/Pirate/Elf/Dwarf this there is two different dimensions that go into this.

The first dimension is whether you are a ‘business’ oriented company, or a ‘consumer’ oriented company. And this is not always so obvious an answer. My company for instance is pretty easy to peg as a ‘business’ one — we help businesses do automation and continuous delivery better. Which is Google? If you answered ‘consumer’, I would argue you are wrong. The consumer usage of their properties enables their real business which is advertising — which is something businesses buy. These days ‘hybrid’ companies are developing but they are going to tend to skew more to one side or the other.

The other dimension is around whether you are a ‘service’ oriented or ‘technology’ oriented. Or put another way, which part of the business is the dog, and which is the tail. A service oriented company, which I would argue Freshbooks is one, will do things differently than a technology one. For instance, all new people at Freshbooks do a stint in the call center to learn the customer’s needs, etc. I have no idea if it will scale, but it does currently and is awesome. Yes, they have a lot of tech behind the scenes, but that enables their service. Etsy, I would label as a technology focused company. I’m sure they have support people there, but hitting a person is a last gasp event and I’m guessing (I could check, but why research something for the internets?!?!) new hires don’t do a rotation through the support team and you can find their developers at various conferences explaining how awesome their tech is. (Which it is btw!)

Sitting along any point on either axis is not in itself a bad thing — unless it counters what management and investors want. (Trust me). But where you sit on them will determine a lot of subtle things in your organization;

  • Do you have ‘client happiness’ people, or ‘customer support’
  • Do you have all-hands cheerleading meetings at the beginning of the day, or do you have remote workers with erratic shifts
  • Do you jump when a customer wants something, roadmap be damned or do you rely on your own analytics and ‘lean experiments
  • Are you going to use the bleeding edge ‘cool’ thing (these days, Node and friends I guess) with the risks that come with a rapidly evolving platform or something ‘safe’ like ASP.NET MVC or Ruby on Rails.

Coming back to the original idea, I think it would be an interesting experiment for a company to reflect on this, not just by those in management but those actually in the trenches. A mismatch means there is a problem, somewhere. A further inquiry of say, the top and bottom 10% of your clients by revenue might also be interesting. Again, if there is a mismatch, there is a problem.

(Now if only I had thought of this when building my pitch deck a couple months back — it would have made a good slide I think.)