This post is part of my blog series: A survival guide for software engineering leaders.

In this post I will talk about establishing a rhythm of business early and evolving it. I will be honest. This is a bit of a dry topic compared to some of my upcoming posts but this is important and one of the first things you should look to put in order. Hence I feel compelled to cover it even if it is dry. I hope some of the Dos and Donts at the end are more fun read.

I have to start this post by defining what I mean by rhythm of business. Rhythm of business for me is the scaffolding the team uses to organize itself and includes but is not limited to: various team huddles, email groups, release cadence for the product, business reviews with stakeholders etc.

Why is establishing a rhythm of business important?

In the world of a v1 product often there are tons of unknowns: product direction, funding uncertainties, relationships within the team that are still forming etc.

There are always lots of ideas and opinions flying around often times diverging substantially.

A well known rhythm of business can be the light weight scaffolding the team needs to to tackle the uncertainties in an effective way. It can become the one constant the team can count on.

On the flip side if the rhythm of business itself is yet another uncertainty added to the list above it can lead to chaos and meltdowns because the team spends cycles trying to establish the rhythm while grappling with other problems.

How do you go about establishing the early rhythm?

1. Be deliberate about establishing the initial rhythm and evolving it as you go. Just by taking the time to think about discuss what the different options could be you are likely to end up with something more thought out than leaving it completely (or partially) to chance.

2. Start as light weight as possible. Add more structure, rigor as you go. Nothing kills early progress on a v1 product as processes that are too heavy weight.

3. Create a proposal yourself first but review, refine it with the team upfront. Build consensus. Strong disagreements over daily, weekly rhythm can be very disruptive and affect collaboration.

4. Last but not the least, find ways to make it fun for the team! More on that below.

No really. What should an engg leader do?

Ahh so you are like me. Theory is nor for you. You are all about the tangible and not the abstract 🙂 For you here are things I have done (or avoided) that have worked for me.

1. Do leverage daily standups. Enough said!

2. Do leverage parking lots for daily standups:

We all know how this goes. Someone goes on an on about the complexities he\she has uncovered and by the time that person crosses the 60 second mark the phones start to come out of the pockets, the eyes start to wander and before you know it everyone thinks the standups are a huge waste of time. Don’t let this happen to your team! There is an easy way to make sure the useful discussions happen with the right folks without making everyone start hating the daily standup. It is called the parking lot list.

3. Do demo Fridays every week and do them with beer:

I can’t emphasize this enough.

If there was one thing I were to point out that worked like a charm every time for all of my products it is demo fridays with beer.

I can write a post just discussing demo fridays (and I might do just that at some point).

In products I led we would take turn in the team bringing beer and munchies on fridays, go around the room asking folks to show anything they are working on. Anything was fair game. You are a backend dev and have a new API that spits out some JSON. Show it to the team! You are a UX guy and you revved the landing page. Show it and get feedback! You are a designer and want to show the latest mocks. Put them up there!

It is beautiful when your backend dev, UX dev and designers connect and start talking about integration all on their own without you having to be the go between.

Some of you are probably wondering if this is same as sprintly demos and retrospective. Yes it is similar but with some important differences.

First, I have seen teams get too caught up in formalities of the sprintly demos and retrospectives.

They get too worked up, become too technical about their velocities, burn- down charts, estimate accuracy, planning processes and somewhere, somehow along the way they forget to bond and have fun as team.

While those are certainly useful and have their time and place they are more suitable for relatively mature teams. In a startup environment an overemphasis on those can backfire.

Note my emphasis on beer above. It is no joke. There is no better way to bond in a startup team than over food and drinks.

Secondly I don’t think it is productive to do sprints shorter than 2 weeks. 2 weeks is a good start for sprintly planning but it is too long to go between fun team huddles and demos.

So to recap, plan for 2 weeks but do demos every friday.

4. Do huddle with other leaders before business reviews.

This one is small but important. In a startup setting it important to make tangible progress but it is even more important to effectively showcase the progress being made. So do think about how often you have the all up business reviews and build in a huddle with relevant folks just before the review for a dry run. You don’t want to sell your awesome team short.

5. Do commit to a release cadence early and actually stick to it.

Even for super early alpha phase you want to be clear about a few things right from the beginning. How often are you going to put out new versions of your app? How often are you going to push your service bits to PROD? How are you going to separate your dev, PROD environments? How are you going to version things, manage back compat?

Manage your limited preview alpha community the way you would manage your paying customers post release.

When you try to treat your alpha customers as you would treat them post release you will come across foundational pieces your product needs and you will get ahead of the curve in getting those baked in.

So those are a few things come to my mind as Dos, Donts when you are thinking through your rhythm of business. Hope this gives you enough food for thought and motivation for figuring out your rhythm of business early in the game.