Hello everyone!

Welcome to the 34th edition of It Depends. Hope you are all doing well and staying safe.

Today is a special episode of It Depends. As of last week, more than 1500 readers are subscribed to this newsletter. I want to thanks every one of you for your notes of encouragement and appreciation, and for all the times you let me know that there was an “Error establishing database connection” :). Writing this newsletter has been a transformative experience for me, and I hope you enjoy reading it as much as I enjoy writing it.

So. Onwards and upwards. Today, let’s talk about a trait often seen in tech-product teams - a constant sense of urgency to ship.

A sense of urgency in shipping features is probably the worst result of the agile mindset. While it makes some sense in absolute early-stage startups where everything has to be built ground up, but in places that have a little bit of stability, this is a vestigial mindset which causes a lot of problems. 

Delivering the right kind of product is a three-step process.

1. Learn: This is where we try to identify the customer’s problem(s).

2. Solve: We identify the best ways of solving the problem.

3. Deliver: This is where the solution is built and delivered.

While tools help, Learning and Solving can only be fast-tracked to a certain extent. These are the most valuable actions that a team can perform, so they should be given due importance. Unfortunately, the prevalent reading of move fast permeates both thinking and execution with the same level of urgency. While software engineering is an art and science by itself, seen from this level, it is operations, and operations work best when they are optimized to death. Best practices old and new create an environment where the execution pipeline can be made faster and faster. Each developer can exert a lot more technical leverage to produce a greater output. Organizations have taken this to mean that more things can be shipped out with the same amount of resources. It actually can’t, as a simple application of the Theory of Constraints can show. 

Envisioning the process defined above, the true bottlenecks in the flow of value are learning and solving. So we have two choices. One is to widen the bottleneck by short-circuiting true ideation and pushing out all kinds of ideas down the line to be executed. The other is to not widen it at all and send only the most impactful things (as best as we can tell) out. This might mean that some execution capacity lies unused at some times, but the impact of delivery is not diminished. Guess which one gets chosen way more often than the other?

I don’t think of moving fast in the sense of delivering many changes very quickly. This is a very operations-centric view of things. Looking at the entire team and the product holistically, iterating rapidly should be about buying the team as much time as possible for identifying and solving problems. It should focus on making the actual execution boring and efficient so that the time between identifying the solution and delivering the solution becomes minimal.

I think this is a better way of looking at the excellence of a team and engineering velocity because it put the most important steps of the value addition process in the spotlight. The tech-product team now has two very clear mandates:

1. Identifying and solving the biggest problem(s).

2. Eliminate everything causing friction in getting the envisioned solution in the hands of the customer.

In management terms, the first is strategic thinking, and the latter is operational excellence. At the team level, strategic thinking should come first. We should spend a lot of time figuring out where we stand and what we want to do. This phase should be deliberate, intense, and the step where the team comes together behind a shared vision. But the ability to do this hinges on making the execution process “just work”. Great teams spend time and effort populating this phase with tools and processes that remove unpredictability and turn it into a well-oiled machine.

Engineering bandwidth that is not fully occupied at all times is not a bad thing. A good team will use this time to make sure their execution phase stays smooth and boring. Paying down tech debt, adopting modern operating practices and tools, adding documentation, etc keep execution friction from rising and let small teams deliver big results. But this meta-work usually gets tagged as wasteful since it is not perceived as being beneficial to the business. In its place, teams put in unimpactful busywork in the name of agility.

There is a balance between thinking too much and not at all. At the moment we seem to be leaning far, far towards the latter. Organizations should stop trying to push ideas down the pipe just for the sake of cranking the wheel. OTOH, engineering teams need to take learning from operations methodologies to identify what is slowing them down when it comes to delivering code and ruthlessly eliminate these bottlenecks.

Ditch the urgency doesn’t sound like much of a mantra to motivate your employees, which is probably why the Zuckergerian adage has caught on much more. But ditch the urgency to move for the sake of moving. Don’t short-circuit the thinking process. Give it the luxury of time by making it super smooth to put good ideas into action. In smart teams, thinking should emerge when doing is taken out of the way.

Think about learning to play a musical instrument. The ideal goal is not to learn songs and melodies very quickly and ad-infinitum. It is to develop the skill of playing the instrument to an “unconscious competence” so that the main focus can be set on musicality. This is where the “effortless” playing of the true masters comes from - they don’t even think about the physical act of playing the instrument. Delivering software is not so different.

From the great interweb

1. If you are an AWS user but have not yet come across this “well-architected” document on building systems on AWS, I strongly recommend you read it now. This is a fantastic set of guidelines from the AWS team itself on how to build great systems using their toolkit.

2. This paper outlining the history of socio-technical system design (STSD) by F.M. van Eijnatten explains the evolution of thought processes in the field from the 1950s onwards. It is a great read if you are interested in the intersection of software architecture and organization design.

3. Is event sourcing an anti-pattern? Oliver Libutzki shares his thoughts.

4. Tom Sommer discusses the art of self-organizing teams. This is a great article on what autonomous teams are, and how to identify/build one.

That's it for this week folks. Have a great weekend!

-Kislay