Engineering leader’s survival guide series: Have you found your rhythm?

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

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.

A survival guide for software engineering leaders

I am starting a series of blog posts sharing my hard learned lessons working as a software engineering leader on high visibility, make or break startup projects.

First things first. My creds for the topic:Ren profile

I have successfully launched 3 v1 products over last 3-4 years as an engg leader, the last one of them being – the Microsoft Band Apps for Windows Phone, iOS, Android. You can check more details on my linkedin profile. For each of these products I was one of the first engineers as well as leader on the team. I hand-picked developers and grew each team as the product evolved. By the time I was on my 3rd v1 product I had developed a template for organizing, managing v1 products and teams. As I look back at some of the patterns and practices I think sharing them and learning from others experiences on the topic will be a fun and valuable experience.

So what is life like for engg leaders these days and why do they need a survival guide?

The supply and demand for good engg leaders is heavily skewed with demand for experienced engg leaders far outstripping the supply. So it is true good engg leaders do have lots of great products, companies to choose from. However life is anything but smooth for engg leaders these days. Here are some of the reasons:

1. Product cycles have dramatically shortened and are getting even shorter.

With the help of rich cloud, mobile platforms, plethora of OSS lego blocks, tons of troubleshooting on internet software products that used to take years can now be launched within months at high scale.

Few missteps here and there, few team issues here and there and you are already behind schedule. This has reduced the margin for error substantially for the engg leaders.

2. Customers demand a great user experience

Thanks to the great Steve Jobs customers now expect a sleek user experience even if you are building an app that calls you a cab! You have designed the perfect product with all the right features, a scalable, fast backend but have a poor nav model? Too bad. Your competitor can easily eat your lunch by differentiating on simpler, more intuitive UX.

This means engg leaders need to constantly aspire for and balance best in breed user experience with functionality, features and performance. It also means engg leaders need to learn how to leverage the value designers bring to the product.

3. You need to be deliberate about bringing good leadership

See the above comment on supply and demand? Well it applies to all your developers too. They have tons of options and will stay with you only if they love working with you, the team environment you create and on your product. A lot of it comes down to your leadership skills.

Often time engg leaders overindex on being the technical experts in their domain and undervalue or worse are sometimes unaware of leadership basics.

There are more challenges but by and large this is the trifecta of themes that makes it challenging to launch great products on time for engg leaders.

What’s the engg leader to do? What resources are out there?

One of the closest and the most relevant thing is agile development patterns and the material on the topic: the scrums, the kanbans, the lean startup methodology etc.

While these are super useful they often address only one or two dimensions of the challenges as I described above in isolation and are also mostly written from the team, company perspective rather than from the perspective of the engg leader.

I think that is a crucial difference. Secondly, these do not boil down to simple, practical, battle tested tips, dos and donts for engg managers that they can apply to a wide variety of teams, products regardless of what spectrum they fall in their adoption of agile methodologies.

There is tons of great material on leadership but by and large besides Steve Jobs’s biography I don’t see engg leaders discuss\reference a whole lot of it  and I hope to contribute towards changing that 🙂

What can you expect from this series?

For each post I will pick up a topic\problem engg leaders typically encounter and some proactive ways, practical ways they can tackle the issue. I will provide simple dos and donts with anecdotes from my personal experience handling similar situations. Occasionally I will point to material I have found useful on the topic especially for leadership.

To make this more concrete here are the few next posts that I am considering. If you have a topic you want to see me cover hit me up.

1. Establishing a rhythm of business for the team

2. Leadership basics for engg leaders

3. Negotiations basics for engg leaders

4. How to decide on technical bets?

5. Effectively working with designers and product managers

6. Hiring

Continue reading