I think it’s safe to say that business and engineering teams have been butting heads since the early days of programming. For us at LawnStarter, it was relatively smooth when we were 2 semi-technical people and one CTO all sitting at the same table. But after 4x-ing both teams over the past couple months, it has become quite obvious that we need to implement a system to bridge gaps between the teams.

After consulting our investors and networks, we were able to learn a lot about how development teams are run. We learned a lot, but as in all things startups, conventional wisdom can only take you so far.

We’re in a different situation than most for a variety of reasons. As far as team size goes, we’re at that spot where we have multiple devs but our CTO still writes code (really freaking fast I might add), and also don’t yet have a product manager. The other big difference which complicates things, is that our business is super operations focused. Things happen in real-time as we grow our customer base. We often need to stop and turn on a dime much more often than most SaaS products, which might deploy updates every month or so.

So, we’ve combined the best of conventional wisdom and our own intuition to create a system that seems to be working pretty well for us. Here is the basic outline of what we’re going with:

We’re using SCRUM as our base framework. Only two people are allowed to give features to the technical team. I am responsible for all things related to ops, and Steve owns everything related to sales (these two categories cover pretty much our whole organization). Prior to implementing this rule, everyone on the team was adding features to the pool, which as you can imagine, became chaotic. This way, Steve and I – who have a big-picture understanding and are semi-technical – can decide what is worthy of even being considered to be a feature and what is not. One week development cycles. It seems short, but like I said, our business happens in real-time. On Mondays we review the previous week’s progress and plan which features and bugs we will address the following week. New features must be completely mocked up in Balsamic (an awesome tool), along with a document of inputs and outputs. This is done by Steve or I. Before work begins on a feature, our CTO calls either Steve or I in to go over the mockup and specs thoroughly. I have a feeling this step will become less necessary as we become better at writing specs, but as of now it ensures the business and technical teams have the same exact vision for the feature. No bugs on existing features can be added to the pool. This is tough to stomach, but I think it’s necessary to stay on track. But there is one exception to this… Due to the real-time nature of our business, we often discover bugs or necessary changes that happen to be both a quick fix and highly impactful. For this reason, we have one CTO “office hour” per day where we can get those issues fixed. If the issue is too big to be fixed within office hours, it doesn’t get addressed until the next development cycle. All new features must undergo “user acceptance testing” before they go into the done pool. This is done by the product owner.

This has been working out so far, and I feel good about the rhythm we have going on. I’m sure we still have much to learn, which is why this is only Part 1 of the series. Look forward to sharing more as time goes on.

If you found this article helpful, please share with a friend.