Balancing Time and Effort as a Technical Founder

Time is finite and as a technical founder in a startup it’s difficult to spend our time wisely. There are so many things we want to do, so many things to play with and to experiment, architecture to perfect, unit tests to write, and so much more.

As time goes on, I’m starting to find the right balance for me. Everyone’s balance is going to be different, where they spend time and focus their effort also depends on who the target audience is. For example if your building a system who’s primary audience will be developer, they are going to care about how clean the system is, how the API works, technologies used, etc. But if your target audience is say homeowners, they probably don’t care about the architecture, how the API works, etc.

In late 2012  myself and a partner, Jason Jarrett (staxmanade), founded a company called Resgrid. This company is a cloud service that provides logistical and management tools to first responder organizations (career and volunteer fire departments, EMS, search and rescue, public safety, hazmat teams, etc).

The system originally started out as a few native mobile apps, and a very simple website. From there the project has evolved into a full blown logistics and management system with dispatch capabilities, lots of work, lots of new features and a lot of new code.

A balance needs to be struck if at all possible between adding new features, maintaining old features, fixing issues, writing and maintaining tests, and implementing and maintaining the overall architecture. Not to mention, documentation, growing the business, making sales calls, connecting with customers, providing support, engaging the community, dealing with legal issues and all the other issues of running a business.

Besides the important business stuff, lets focus on the technical aspect of our jobs as a founder. How do I split my time:

2/3 of my technical time should be spent on something that directly improves a customer experience, fixes an issue or helps grow the business.

1/3 of my technical time should be spent on architecture tests and back of the house maintenance and improvements.

How do I determine if a task is in the 2/3’rd time:

• Does this directly impact a customer preventing them from using the product or service?
• Will this directly impact generating new sales or getting new customers?

If one of the above questions is yes, then it’s in my 2/3’rd time. Eventually the app or service will covert into maintenance mode and this will change your outlook, at that time your fixing issues, not adding many features and the focus is getting things to run smooth. This will change the time balance and where focus is directed. But when starting out, focusing on spinning the product up and getting customers is usually the priority.

Some truths about your customers:

• They don’t care about your architecture
• They don’t care about unit test coverage
• Most of the time they don’t care about the technology used

What they do care about (besides price):

• Does it have the features they need
• Do those features work well
• Is it fast

Jason, Resgrid’s Technical Fellow, for the most part hates seeing my code and believe it or not that’s a good thing. I’m focused on getting new features out there, working with customers and trying to make the system as complete and rich as possible. Jason’s job on the other hand is to ensure the system is meeting standards, using best patterns and practices, maintaining good architecture, and so on.

Balance needs to be maintained, although your customers don’t care about your architecture, they will start to care that a new feature can’t be delivered timely because the whole system needs to be rewritten. A developer friend of mine would say “that’s an uptown problem” and he’s right. But sometimes laying the foundation now consumes very little time and pays big dividends in the future.

So here is what I’ve learned about balance in the last couple of years:

• Don’t get consumed with a perfect technical implementation, just get it out there
• Unit tests are great, but they aren’t a deliverable, get them in when/where you can
• Lay the foundation of good architecture and refactor as you go
• Focus on delivering value to current and prospective customers

If you maintain a laser focus on your customer good things will eventually happen.