As I say at the start of every podcast episode, our goal here is to triple impact-per-engineer. Many times, spotting the right steps forward for a company is straightforward. Nevertheless, not a week goes by without another startup admitting they never realized a particular mindset was bringing them down or that a low-hanging fruit was right there within their grasp before I pointed it out to them. Which of these decelerators are you currently experiencing? You just might find your leadership focus for Q1.
No Innate Urgency
This is perhaps the thing that cofounders lament the most. Once the team grows beyond a handful of engineers, it starts feeling as if things are unnecessarily slow and that the coders no longer have any rush to get things done. While rushing for the sake of rushing is useless, startups have to move fast and iterate. That doesn’t happen with an R&D organization that seems to revel in gold-plating features and needless infrastructure (I suddenly remembered reading this term in a book about 15 years ago and had to google it).
However, this lack of urgency is rarely pathological but something that emerges from a certain environment. For example, when you had a hackathon, were people lackadaisical as well, or were they engaged? When an outage occurs, do you spot a coder huddle that debugs it together quickly and effectively? My experience is that teams often have this ability, yet it becomes dormant. The difference between their day-to-day and these highly-engaged bursts is clear focus.
If programmers are treated as code factories, they’ll work like factory workers, cranking out features without much enthusiasm. That’s what happens when sprint after sprint, each member is assigned a heap of tasks without any clear motive or impact. Creating agency and autonomy around a common goal is vital for unlocking developer productivity (and, frankly, career fulfillment).
Focus on Inputs
I’m sick of reading about companies going back from their remote-first or remote-friendly modes to stuck-in-office because “it’s more productive.” Executives making these decisions are essentially saying they are bad at leading their teams or are still managing by inputs. Input tracking makes no sense, no matter whether you’re trying to count lines of code or hours-in-seats. Tripling impact per engineer is not about typing really fast.
There’s an old fable about the programmer that resisted a new Management decree: each coder had to report the number of lines of code contributed at the end of every week. Our tale’s hero wrapped up a massive refactoring and scribbled down tens of thousands of lines of code for that week, though negative (I love deleting code more than I love writing it).
When engineers know they’ll be required to sit at their desks for ten hours a day, why should they ever feel rushed to do anything? A typical day is so wasteful it hurts me to watch it, as people spend the first hour (often the quietest of the day) “grabbing coffee” and have no visible energy the rest of the day.
Instead, and this connects to the previous point, judge teams by what they accomplish. If they move the needle and reach your goals (or pretty darn close) in most sprints, who cares if only come to the office part of the week? Of course, this requires more work as a leader since you have to come up with said goals. Do the work. It pays off.
Creating Company APIs
Effective teams are not siloed. However, I regularly come across R&D organizations attempting to nail down precisely how communication should flow between them and their counterparts. While it is due to wanting to increase efficiency, it ends up creating disconnected companies more than the dreaded “remote work.”
Rather than defining APIs of communication with Product and Customer Success, your leaders should encourage open communication lines and collaboration. That is how you establish coders without borders who understand the business and everyone’s needs.
Allowing Quality to Deteriorate
It should come as no surprise that when the quality is suffering, it dramatically harms a team’s ability to deliver fast. After all, if a sizable chunk of the time has to be spent putting out fires, that’s time not going into development and improvements. Naturally, leadership is always open to investing time in fixing burning issues. However, finding time to solve the root causes of frequent issues is often more challenging.
This is where most teams start clamoring for “lowering tech debt” and lament not getting enough time to tackle it. Tech executives need to address such issues from both sides. First, work that will genuinely accelerate the team’s output and raise the quality bar is something worth fighting for. The other side, though, is about addressing why fighting is needed.
Too many product leaders and executives have been burned by teams investing in “keeping the lights on” work that seems to be never-ending and yielding low value. Long refactoring crusades that take twice the estimated time and don’t change the business’s bottom line don’t make sense to them. They’re right. As a tech leader, it’s your responsibility to help your team make a case for quality issues in business terms. That means the “fight” is easier, and it also keeps the team honest and avoids tech for tech’s sake.
All Work and No Play
Lastly, knowledge work is a creative endeavor. The difference between generative AI and your highly-paid engineers is that their work can be truly novel and not merely derivative. However, novelty is hard to come by when teams are always hard-pressed to keep pushing and never take their foot off the gas.
If I have no time and I’ve got to have something ready by tomorrow, I’m not likely to attempt anything new or let my creativity shine. I’ll go with the tried-and-true solution, which is often the right call. However, creating time for creativity, e.g., by having intermissions, is a practice that both researchers and engineers have established has a positive return on investment. I’ve heard from companies all over the globe that have successfully implemented intermissions (see the sample chapter from my book that covers it here). All are raving fans. Make time to tinker and see your engineers’ creativity peak.