Surely you’ve heard of “move fast and break things,” Facebook’s old motto. The intent behind it makes sense: too many of us allow our organizations to operate at a complacent pace rather than actually do anything remarkable. Nonetheless, it misses that mark. The best teams I’ve worked with move faster and, in fact, break fewer things.
Below, I’ve described my tenets for a team to deliver swiftly and reliably. Your team’s likely better at some and worse at others. There’s no requirement to be world-class in all, but every improvement you make to each will boost efficacy. Each one supplies your flywheel with a little more momentum.
Improving Improving
At the core of every endeavor that remains successful over a long period of time is the ability to readjust and reinvent continually. Merely sustaining your current state is not enough since teams rarely manage to remain at a standstill. If they are not getting faster, they are likely getting slower.
Improving Improving is my (weird) term for the act of regularly challenging the status quo and ensuring that the team is learning and becoming better. Some leaders are content with their teams not becoming slower as they grow. I claim that you should adopt a mentality that the team should get faster with time. The team’s growth should translate to each member individually, providing more impact and faster (more on that below), and that is only possible with a mindset of continuous learning, improvement, and tweaking.
Are you making the same mistakes repeatedly? Are you solving the root causes of issues or just the symptoms? Ongoing reviews, retrospectives, post-mortems, and so forth are immensely valuable for staying alert and not falling into complacency.
Impact Focus
The teams with the best velocity don’t merely type on keyboards faster. No matter how fast you can make it go clackity-clack (even with fancy mechanical keyboards), that is not the best way to increase velocity. Improved velocity comes from making each keystroke more valuable.
Provide your team with enough focus so that it is almost trivial for them to know which ideas are worth the investment and which should be put on the shelf for the time being. Connect them to the company’s objectives, goals, and vision so that they can voice their objections about something involving more effort than is justified for the business. Help them establish enough Product Mastery to enable effective discourse between them and their partners in the organization.
When teams are focused, each sprint moves the most critical objective forward a mile, rather than nudging a handful forward by a few feet. Overall, teams move faster when they have to spend less time on do-overs due to miscommunications and doing things that didn’t matter.
Investment in Tech Capital
The most successful people you know, financially, are not likely constantly fretting about every latte they want to drink, or talking about their credit card debt, managing their loans, and so forth. For some reason, it has become acceptable for entire engineering organizations to focus every free cycle they have on managing their tech debt. Once more, the key is to turn things around and adopt an abundance mentality. How can you create capital, which is boundless, rather than solely try and minimize debt?
Tech Capital is an investment in tech that keeps on providing you with value, as opposed to most features developed that require ongoing maintenance and make the system, as a whole, more complex. Some examples of tech capital I’ve recently seen my clients create include DevOps tools that increase the team’s engineering velocity (e.g., creating a testing environment is easy and straightforward), solving things only once (for example, taking the time to make a micro-service a truly global service that can be used by all engineers in the company), and creating force-multiplying capabilities within the organization, such as creating a framework that allows the marketing team to send emails without requiring time from engineering, or an internal tool that makes the data analysts’ work easier.
Quality Bar
Referring back to “move fast and break things,” how about… not breaking things? Startups often think that being a startup means that they have a license to create crappy products in the name of agility. That’s not what agility is about, my friends. Once you open the door for low quality, there’s no closing it again—it’s a pandora’s box. Teams that created dingy MVPs for a year until achieving the fabled product-market fit rarely stop being shabby later.
Make sure that you maintain a high-quality bar. Moving fast doesn’t mean bugs, messy code, and a constant rush. Teams that move fast do so in the grand scheme of things by having less shabby code to redo later. When something is done, it is done.
Tech Depth
In the current state of our industry, it is becoming increasingly hard to have “8 years of experience” in whatever tools your team use. It is likely those tools didn’t exist that long ago. When frontend work means using a different framework every two years, we tend to lack depth.
Nevertheless, you should set up time and frameworks that allow your people to hone their skills and really get to know their tools. You owe it to yourself to be old-school (written on my old blog nine years ago), and genuinely grok what’s available for you. We’ve all lost hours to digging through Google search pages and Stack Overflow questions trying to get something to work, only to have someone walk by, hear what we’re talking about, and casually mention an obscure configuration flag that solves the problem.
Great teams should have at least some engineers that obtain this kind of depth in their common tools. That’s achieved either by hiring or internal training. Don’t just cross your fingers and hope it’ll happen naturally.
Tech Breadth
Lastly, just as it is incredibly helpful to have a few engineers with tech depth, you should strive to have a wide variety of experiences and knowledge across your organization. It’s common in some places to have engineers teams that are almost entirely homogenous. For example, here in Israel, pretty much every cyber startup starts with teams of people who served together in the IDF. Undisturbed, those teams will continue to grow with a heavy bias towards those same kinds of people. That results in teams that think alike and have the same expertise.
Sometimes, tech breadth can be achieved by having a few people who are jacks of all trades, but, in my experience, it is much better (for this reason and others) to actively strive for diversity and heterogeneousness in your teams. When you sit down to decide on the right approach to tackle a new big feature, it can make all the difference in the world if you have three people from very different backgrounds discuss it together.
Get movin’.