When working in a startup environment, everything is important, and everything has to happen now. If you let your pace be dictated by the chaotic nature of a startup organization you will quickly run out of breath and find yourself working on many things without completing any of it.

The only way to deal with this, I have found, is to take control over the structure of your work; meaning which concerns are allowed in, and which will be parked for later; the pace, making sure there is forward momentum in the work you are doing without being hampered down by unnecessary complications; and rhythm, creating an environment that is void of any surprises and that allows you and your team members to know what to expect.

These principles flow from the individual level to the team level, meaning that the better you can apply them to yourself the better you can apply them to the team. For the rest of this post I will go into further detail about each of them.

Note that, the ideas described here are far from exhaustive when it comes to a theory about leadership. They are more of a collection of thoughts, but I have tried to organize them as much as possible.

Structure

Rather than the imposition of some kind of form, structure can be better understood as the absence of clutter. I put it that way, because, as a team lead, applying structure becomes the bane of your existence. Both rhythm and pace will largely keep going once they are put in place and will mainly require that you monitor and correct when needed. Applying structure, on the other hand, is something you will have to do every single day. As such, I find it more helpful to have an understanding of structure that I can more easily activate. I find that the removal of clutter becomes easier to put into practice than imposing structure on a set of unstructured elements. It causes much less friction and it is a lot easier to break down into discrete units of work. This is very similar to cleaning up a codebase. Often, the structure is there, you just need to clear away the cobwebs and put things in their right place.

Keeping a Journal

How do you remove clutter from your day-to-day activities in an environment where everything is pressing and everything requires deep focus at the same time. You can only focus on one thing at a time and there are only so many productive hours in a day. The most effective way of doing this, I found, is by keeping a journal.

Every day I start off by creating a simple markdown file with two headers:

## Today's goals  

## As it Happened  

Under the first header I write down things that I want to accomplish, and under the second I jot down notes throughout the day. These notes can be about anything from a meeting, to an informal conversation I have had, to something I have noticed during a coding session. What this produces is:

• New Goals: often, you will find out that the notes you take are about things that should be followed up on at some point in the future. You can use these notes to mine for new goals you want to accomplish.
• Common Themes: while reading your notes back, you will find common themes that come up in different contexts. These themes can be very helpful when deciding what to prioritize, to recognize concerns that should be addressed in a broader context, and to identify when people understand things in a fundamentally different way and that alignment is needed. More in general: it gives you a way of looking back at your day and gain insights from how it unfolded.
• Closure: at the end of the day, you will read all you have written and reflect on how you set your goals, how you achieved them, and how you feel about everything. After that, you close the file and compartmentalize all your work stuff in the cold storage part of your brain so you can focus on something that you personally find fulfilling. Do not underestimate this part. Hard work is fine, but if you keep putting off your personal priorities long enough, you will royally and majorly mess yourself up in the long run. You can not lead a team if you are in bad mental shape.

Writing Stories

Stories are intended to convey the meaning behind a unit of work to anyone within and outside the team who has a stake in the completion of that work. In their ideal form, they can be understood by anyone, from the developers who need to implement the work, to the product owner who needs to understand why we are working on something, to someone from the company’s management team who is surveying what goes on in our team.

The human brain is hardwired for narrative structure. It is the single most powerful technology we have used throughout the ages to convey meaning from generation upon generation. It is, therefore, not surprising that we use the same technology, in the shape of stories and epics, when conveying the work we do.

All narrative structure includes at least the following elements:

• Context: all stories take place within some context. It needs to be made clear what that context is from the outset. Keep in mind that the person(s) you are writing the story with usually has this context as a memorized blob inside his/her brain somewhere, and that translating that blob into written text is hard. It is often tempting to assume that whoever is reading the story will also have access to the blob, but this is rarely the case. Think of the least informed reader, and imagine yourself explaining the story to this person. What does that person need to know before you can start explaining the rest of the story.
• Conflict/Problem: all stories introduce some kind of conflict that drives the story forward. The conflict is the thing that needs to be resolved, the reason we have to write the story in the first place.
• Plot: all stories describe a series of steps that have to be narrated to resolve the conflict and to reach the new, desired state. These steps are usually described in separate tasks and can be left up to the developers that refine the story. Some tasks can be known in advance, but often they are added while the story is being worked on and as developers learn new things. In their ideal form, tasks should map to integrations of work into the mainline of the codebase and should be workable in the span of a single day at most.

Generally, it is best to take the lead in writing the stories together with developers. Developers will possess most of the context, but often they have a hard time putting themselves into the shoes of the least informed reader. In addition, some developers may not be strong writers.

Exploring Solutions

Being hardwired for narrative structure, we tend to think of solutions from beginning to end. We like to imagine that solutions can be thought up in the same order that they are worked on, but alas, this is almost never the case. This is because we are almost never sure of what the first step should be. The last step, on the other hand, is often a lot easier to imagine, as it is the step that gets you to the end state.

It is often useful to ask, “why can we not take that last step now?” This will likely produce a number of answers from developers in the shape of problems that would have to be solved first. Those problems can also be hard to tackle for some reason, so we ask the same question again: “why can we not get those problems out of the way now?” If you repeat this process long enough you will eventually end up with a set of problems that can be solved and integrated in a short amount of time. Those will be the first problems you have to tackle.

In short: if you do not know how a story or epic should unfold, try telling the story from end to beginning. Throughout this process you can mine for context, risks and dependencies.

Rhythm

Rhythm can be understood as recurring motions. It is what allows people to know what comes next.

At the individual level, you will find that rhythm frees up mental space to work on complex ideas, because you don’t have to think about the next thing that should happen. When you work, reflect and take breaks at a regular interval, you can detach from a task more easily. You will find that there is no need to sink into a problem for days on end, only to come out the other side to find that you have neglected other aspects of your life. Rhythm allows you to say “I will work on this for 2 hours now, and tomorrow I will pick it up again.”

At the team level, rhythm is very important. Think of a group of jazz musicians jamming out some improvisational music. Without rhythm, they would just produce a grating cacophony you would like to get away from, regardless of the skill of each individual musician. This goes for a team of developers as well. If they do not work to a rhythm you will soon find them working on a loosely related set of projects that are difficult to integrate.

But rhythm does not imply strict rigidity either. On the contrary. Once you have rhythm, you will find space to experiment and improvise. Rhythm gives you the hooks to tie new ideas and solutions into.

Rituals

The way we apply rhythm is through rituals. A ritual can be generally understood as a sequence of activities that we perform in the same manner at intervals. A ritual can be “every day before the lunch break we come together and discuss what we are working on”, or “every first day of the week we discuss what we want to achieve and what we will focus on in the upcoming days”. We apply rhythm to the team by placing these rituals at daily, weekly, quarterly, and yearly intervals.

Rituals can be used to hook new ideas onto. If we want to try out a new way of working, we can introduce this during one ritual performance, and then reflect on it at the next performance. If we like the idea, it becomes part of the team’s way of working. Maybe it even becomes a new ritual. If we do not like it, we can do away with it again.

The word “ritual” may imply some kind of sacredness, and this only partly true. If a ritual is not held in high regard, and people show up late, unprepared, or not at all, then the ritual breaks down. It loses its strength and its value to the team. On the other hand, if rituals are held too sacred it may prevent the team from changing them when change is needed.

Self-similarity

Self similarity means that the rituals we perform at short intervals should be copied over to the longer intervals. Remember that the purpose is to allow everyone to already know what to expect. Hence, the way we plan ahead for the week, is the same way we plan ahead for the quarter, and for the year. The way we look back at the previous week is the same way that we look back at the previous quarter, and the year.

Naturally, as the intervals become larger, the level at which we are planning or retrospecting becomes higher. Also, as the intervals become larger, it becomes more important to take into consideration where the organization wants to be in the long term. But, at the core, these structures are self-similar in that we copy them over and repeat them at different intervals. It allows everyone to understand what we are doing, and what we are doing it for. Ideally, nobody should be surprised about the intended purpose of a ritual and almost no preparation should be needed. Everyone should be able to take what they already know, and apply it to a longer stretch of time, a more generalized goal, etc.

Pace

Pace can be understood as the forward momentum of the team. Much like the same concept in physical space, it is subject to inertia. If the team has forward momentum it is likely to keep going forward, whereas if the team becomes stagnant, it will require energy to get it going again. Hence, keeping the pace is important as it directly affects the team’s morale and productivity. This mostly requires addressing obstacles that can sap the energy and bring work to a halt. Here are a few things to look out for.

Uncertainty

As we are working in a complex environment with lots of legacy code and entangled systems, it is often uncertain how best to approach some matter or what the outcome will be. We often respond to this by calling for exhaustive documentation and lengthy meetings that should produce the clarity required to make an informed decision. These activities drain the team’s energy and produce mixed results, at best.

Documentation can take days to produce, often by a single developer, and is looked at once or twice. This can be a rather thankless job for whoever has been tasked with producing it. On top of that, when the team actually starts tackling the problem, it may turn out that the documentation was produced from an unhelpful perspective, or at the wrong level of detail.

Lengthy meetings can drain everyone’s energy and tend to produce more confusion than clarity. Also, not everyone is verbally inclined. Often, the best and most experienced developers take a back seat during these meetings because they are very good at solving puzzles, but not so much at talking about them. Furthermore, they have seen this type of meeting play out before and have grown wise as to where they should spend their energy.

When facing uncertainty, it is often best to just try something and learn as quickly as possible. This may sound a bit reckless, but often it is much more productive to take the best couple of ideas your team comes up with in half an hour of discussion, pick one and run with it, and see where it breaks down. Then, when you have seen it fail, you gather your data, analyze it, come up with a better idea, and run it again.

This cycle of pick a solution, try it out, watch it fail, gather data, extract lessons, refine/ditch your solution for something else, repeat can be safely performed only if you have all your pre-prod environments and rollback mechanisms in place. This motivates the team to keep those environments and mechanisms up to spec. Most importantly, it keeps the pace going. The cycle can be hooked onto your team’s rituals and discussions can be had about concrete solutions and actual data. Documentation can be short and pertaining to actual lessons learned.