September 6, 2012

Software Engineering Priorities for Early Stage Companies: Put the Team First

Team first.

Earlier this week I made a pilgrimage up to the Bay Area to visit some mentors – I came seeking advice from entrepreneurs who’ve done work relevant to our interests at MarkedUp, mostly to learn how to address some “known unknowns” that have been keeping us up at night.

One of the people I had a chance to speak to is an experienced CTO and we started talking about development priorities in early stage companies like ours. Mid-way through our meeting we had the following exchange (paraphrased:)

Me: so I’m trying to figure out my priorities in terms of what I personally spend my time working on – I have to juggle recruiting, product, fund-raising, customer development, project management, and working on the actual codebase all myself until we start expanding our team.

CTO: what have you been working on most recently?

Me: this weekend I learned how to script against a build system we want to use to help automate the complexity out of our deployment process; I prioritized that ahead of working on MVP features and am not sure how I feel about it.

CTO: two startups ago, we were building a service in the telephony space. We had a lot of trouble recruiting engineers who knew anything about low-level telephony protocols – they were hard to find, thus we had trouble expanding our team.

Ultimately what I decided to do was to build an abstraction layer on top of all of the telephony protocols themselves, our goal being to simplify the amount of work a developer on our team had to do to make things happen with our service.

What this allowed us to do was recruit younger, smart people who had no prior experience at all with telephony systems – and they were able to be successful in our development team because they could get the work done without the overhead of having to learn these telephony protocols. And this solved our recruiting problem.

The lesson here is fantastic, and I suspect lost on a lot of engineering team leaders: if you have only one place to spend your (development) time, spend that time on tasks that increase the effectiveness of everybody else on the team.

So this past weekend, I spent my time:

  1. Developing a component that takes an easily-fuck-up-able task from our application runtime and makes it more predictable and reliable and
  2. Learning a build system that we are going to use to make our build and deployment process standardized, predictable, and less dependent on human factors.

 

Turns out, working on those things instead of developing a handful of features necessary for our MVP was the right call – even though it’s painful to defer work on the product with impending deadlines looming. It was the right call because it eliminates errors and speeds up the work of every person on the team, including me!

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..