The magic of speed
Small high-velocity teams
Photo by Chris Peeters
This installment of Clear Thinking is free for everyone. I send this email weekly. If you would also like to receive it, join other smart people who absolutely love it today.
👉 If you enjoy reading this post, feel free to share it with friends! Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
Preface
One of the greatest pleasures I had in university was discovering programming.
The first language I learned was Fortran (I was a physics major with a minor in mathematics so that seemed a logical choice for someone in the math department). I would later go on to learn APL, C, Lisp, PL/1, Cobol, JavaScript and many more languages, operating systems and development environments.
Programming was a brain-amplifier that enabled me to go places and to do (almost) anything I could dream about.
Programming started as a personal tool and rapidly turned into a way for me to help other people do things as well. Over time, I acquired and developed soft skills to help lead teams that build software.
There is magic in a team of 5 engineers working closely together like a professional basketball team.
There is magic in the speed of how things get done. How the software ships to customers. How bugs get fixed quickly. How releases iterate fast. How customers are delighted by the simplicity of the solution. There is magic in placing cool, little, memorable features under the hood for the customer to discover.
Why is high velocity important?
There are 3 reasons why. All 3 make you more competitive
High velocity deliveries of software means faster cash flows.
High velocity brings you faster to customer feedback and quality improvement.
High velocity shipping is closely related to the mental health of the team. A team that ships often is happier, more productive and more aware.
What is flow and why is it important?
Psychologists have identified a state of mind called flow in which we're capable of incredible concentration and productivity. The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter. DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss.
Less frequently considered but probably just as important to programmers are the interruptions caused by our tools.
Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow.
Peter Seibel Practical Common Lisp
The rest of this essay will go into more detail about how to eliminate “ flow-destroying interruptions” and keep your team in the flow.
A personal and team environment of flow
There are tactical and strategic things to be done here.
The strategic and most important factor in sustaining flow is noise reduction.
Engineers work better when a boss is not looking over their shoulder. Less meetings is better. We use a very light-weight version of scrum in my small teams. Daily 5 minute meetings. Each team member has 60s to talk about what she/he did yesterday, plan for today and whether they have blockers or not. There are no other meetings. If there are questions - ask or slack.
Tactically, we’ve adopted a model of 2-person programming teams. Blocking out 2 times of 4 hours with a nice break in between seems to work well. Noise reduction means turning off phones during coding block times.
Extreme ownership for the leader and team
The biggest loss of velocity is due to changes in direction. When the team jinks around - work does not get done and product does not get shipped.
This means that the team leader explains the objective of the mission and why we are doing the mission. The team leader needs to make sure that everyone understands the objective and the why. Requirements for the mission are known in advance.
The team leader also needs to make sure in advance that the team has the tools and the training to execute the mission. This means making a team member a tool maker/acquirer. Tools need to be ready before the team needs them.
There will be surprise. With high velocity teams, surprises can be handled, prioritized and solved without tanking the mission.
Underperformers need to train-up or ship-out. There is no justification for an individual team member to consistently underperform at the expense of the team’s mission and the customer.
No black holes
A big problem with star engineers is that they like to lock themselves in a room and get work done. In this time of remote work - black holes can be a huge problem. That’s why we have the daily 5’ minute scrums.
I once had a star employee who considered himself key to the team. He didn’t see the logic behind the daily Zoom scrum updates. Before the end of his first year in the company, he was terminated.
Get and stay in a state of awareness.
High-velocity development means that the leader and the team members need to be aware. Aware of potential problems. Conceptual bugs. Design bugs. Customer interrupts. Personal issues. Hardware problems. Surprises. Children at home problems. COVID problems.
This is not a QA engineer problem. This is everyone’s problem. The leader and the team members need to constantly search out for roadblocks, build out solutions, and make sure they are implemented.
A typical roadblock is cloud resources and tooling. These need to be in place at least 2 weeks before needed.
Permission-less execution
The responsibility of the leader is to consistently shorten communications pathways.
In a small 5 person team, with daily scrum meetings this is generally not a problem using Slack.
Try to stay on Slack and off WhatsApp. I know it’s hard but you don’t want parallel or back channels.
In order to keep pathways short, we stress the importance of each team member owning his/her own piece of the mission and not needing permission from a manager to execute. If you make a mistake it’s OK.
Mistakes can be fixed. Waiting for a manager's decision cannot be fixed.
Do half the features you wanted
You will increase velocity with Newton's second law of motion.
Do half the features. Kill features ruthlessly.
Half the features are half the mass and double the acceleration.
Shipping fast - An afterword
You can develop and test quickly but it all only counts if you ship the software to a customer.
High velocity shipping is closely related to the mental health of the team. A team that ships often is happier.
A team I managed was once tasked with converting 350 COBOL programs from an old mini-computer to an IBM mainframe. The customer gave us 4 weeks. The first 3 weeks we developed an interpreter that converted the old COBOL code to the new COBOL target system. The actual conversion took less than 10’. The customer was happy, to say the least and the team remembered their success story for years.
Microsoft Visual C++ 1.0 was released in Feb 1993. Over a period of 3 years, Microsoft iterated rapidly, releasing new versions every 6 months. By Visual C++ 4.0 - Microsoft had destroyed Borland.
The contemporary parallel is Amazon AWS that has incredible product velocity translated into high performance business.