The Technical Lead’s Role in Escaping the Build Trap
Back in May, VTS had the honor of hosting Melissa Perri at our headquarters for a Q&A session. Her answers to the various questions that we threw at her were sharp and impressive, and I had to get my hands on her book: Escaping the Build Trap. This won’t be a review per se, but I wanted to reflect on the book’s central ideas through the lens of being a technical lead. While the book focuses on the misunderstood art of product management, it also calls on the entire product organization to shift mindsets and change from simply producing a product to being led by it. Given that technical leads often work closely with the product side of the team, and they also have their hand in technical strategy and execution, I think they play an integral role in affecting the kind of change that she talks about in the book.
The central thesis of Escaping the Build Trap is that the organizational pressure for growth encourages teams to focus on building new features rather than deliver more value to customers. Throughout the book, output is always contrasted with outcomes, and Melissa makes the eye-opening claim that the output of new features is not correlated with more valuable outcomes for the customer. Worse, the practices and reward systems of our product teams can lead to favoring the quantity of team output instead of focusing on delivering real value to the people who pay for the product.
Simply, the build trap is focusing on constantly expanding what a product can do while ignoring the purpose of the new capabilities, and ultimately disconnecting from the value that our products promise to their customers.
Of course, holding true to the title of the book, she provides a clear vision of how to get out of the build trap. We’ll look at the ways that the technical team can contribute to carrying out that vision, but first let’s look at how a team can fall into the trap in the first place.
The Black Hole of Scrum
Recently, I’ve felt the weight of sprint planning more than ever, and it’s part of the reason this book struck such a chord with me. One of the challenges of working on the mobile app at VTS (and I imagine other enterprise B2B apps serving complex domains) is figuring out which domain use cases are most relevant for the phone. A large part of commercial real estate happens out of the office, so we’ve always focused on real-time activity and data access, but recently we’ve made a bet that users also want to enter more data on their phones. Arriving at the best solution for the problem of entering leasing activity data means a lot of user interviews, and it also means that we’re not always sure what we should build next.
You can imagine the tension that this leads to when sprint planning comes. There’s an empty board, some placeholder tickets that the product manager and I created based on some loose ideas, and there are engineers waiting to work on concrete, fleshed out tickets — tickets with design, acceptance criteria, and robust descriptions. This is the dilemma: do you flesh out some early ideas that haven’t been validated yet, or do you comb the backlog for complete but stale tickets so that the team has something to work on? I noticed this force tugging at me at the beginning of each sprint, and rather than helping the team deliver software I felt the constant sprinting of scrum turning into a black hole — a force pulling us straight into the build trap.
The realization is that there should be no dilemma. There should be no picking between equally bad choices. There are few things more costly than building the wrong software solution, and why would you spend money on an investment with a guaranteed negative return? It’s the most expensive busy work that I know of, and for companies looking to grow their revenue and cross the proverbial chasm, stale or weak product ideas are much worse than building nothing at all.
In the book, Melissa asserts that value is only created when a product removes some existing problem from a customer’s life. A feature only has value if it removes such a problem. It follows that the primary purpose of our product teams should be to seek to identify and ultimately remove the most compelling problems that customers are experiencing. She lays out an operating cadence where the whole team contributes to uncovering user problems and then creates the best solution to eliminate them. So rather than spending costly developer time on ineffective features, sprints have to equally be used for experimentation, learning, and technical initiatives that enable both of these.
This was the spirit of Agile and Scrum from the beginning, so it isn’t these processes that are the problem, it’s the idea that sprints have to be used only for delivering features into production, ad infinitum. With this in mind, I want to explore the ways in which we as tech leads can more efficiently use sprint time to identify and build valuable products, and ultimately lift the team up out of the build trap.
Technical Enablers of Experimentation
The goal is to have a team that can identify problems and turn them into opportunities. The key to finding these opportunities is to collect data, experiment, and justify the products that the team wants to build. Experimentation in this capacity requires technical investments and buy-in from the development team. Here are some areas for technical leads to invest in to enable product experimentation.
Product Usage Metrics
I think the first way to enable experimentation is to commit to owning product usage metrics. While there are some off-the-shelf tools like Pendo that allegedly allow a non-technical person to gather and interpret the desired insights, I find that it’s better to agree to have product metrics be a deliverable of the technical team. I have firsthand experience running into the limits of automatic event collection as preached by Mixpanel, and this is a great example of why the technical team is needed to effectively capture usage metrics — automatic collection simply doesn’t work for an application that is constantly changing.
There are also usage insights that you can gather from looking at the database directly, and the technical members of the team need to get the data there — planning to capture this data in a consumable way has to be a part of the development process.
At VTS, we maintain a data warehouse that combines data from several sources, and we use Looker as the interface to peer into this data. This warehouse takes developer time to maintain, but it’s foundational to the idea of empirically deciding on what to build and how to build it.
By leveling up the product usage metrics infrastructure at their organization, technical leads can provide the data to base product decisions on.
Granular Feature Enablement
There is a spectrum of fidelity to consider when experimenting to discover solutions for a particular problem, ranging from purely graphical mockups all the way to in-product beta features. The cost of each experimentation type should be considered, and the lower fidelity types should be favored when earlier in the discovery process (at VTS we use InVision to provide users with interactive prototypes so that we can get fast feedback on ideas without actually building anything).
Once an idea starts to gain traction, however, you can still improve it by building a beta version and offering it to a limited number of users. The benefit here is that you can open it up to a much larger number of users than in the prototyping phase, which often involves time-consuming calls with individual users. I have done this with every major feature I’ve shipped at VTS so far, and I can’t picture going back to releasing anything without this learning process baked in.
Of course, this ability doesn’t come without technical cost. I’m a fan of using feature flagging to run these ephemeral beta programs, and there are different levels of technical work that can go into enabling this. For example, we used to give access to a beta feature at the individual user level, but this became cumbersome for betas that involved hundreds or thousands of users. Users on VTS belong to a broader account (think the brokerage or landlord employer they work for) so we eventually built in the capability to enable a feature for an entire account. The right granularity is going to depend on your specific business, and beyond this there are more advanced capabilities that can be built into the feature enablement platform. For example, VTS users currently can’t opt in to their own beta features, but this is something I’ve wanted to add into the product for some time.
By allowing targeted cohorts to experience upcoming product solutions, technical leads can promote learning before launching.
Designing for Change
I think the great irony of Agile in practice is that it is often cited as the reason to take shortcuts and avoid “over-engineering.” Not all engineering is over-engineering! When experimenting and finding product-market fit, I have heard people suggest that delivery speed trumps code architecture or even testing for example. My mind always goes back to the actual written principles of Agile, most specifically:
Continuous attention to technical excellence and good design enhances agility.
In my experience, I find this to be doubly true — if you really want to have a changeable product, you need to do the hard work of building a well factored, decoupled system. This is not easy, especially when so many outside forces are pulling the code toward quick delivery.
As technical leads, it’s our responsibility to uphold the technical values that are necessary for building a system that can evolve. When changes to a system seem prohibitively difficult, the innovation in the product will suffer because experimentation and change will seem too costly. At the worst end of the spectrum, the engineering department can turn into a tool of execution rather than a valuable partner in identifying and solving user problems.
Show the team how to enable change via software design. Teach the team about coupling, code smells, and refactoring. Of course, build a passion for automated testing into the team, as it is the greatest enabler of change that I know of in our current technical landscape.
There are so many different strategies and approaches here, and this alone can be the subject of an entire series of posts. The point is that a tech lead has to think at a broad scope and understand how architectural decisions can affect a team that wants to experiment.
By committing to technical excellence and a well-designed system, technical leads can enable change in a product based on the learnings of experimentation.
Maintaining a Technical Backlog
I mentioned the anxiety I was having during sprint planning earlier. Luckily for me, VTS has a great team of tech leads who meet regularly to share problems and ideas. I brought this problem to them, and someone suggested holding a technical backlog generation meeting with the other engineers on the team. This is one of those ideas that worked out even better than I thought it would.
After a single brainstorming session with my team, we found that there were several initiatives that we all agreed were useful and exciting. This session birthed a technical roadmap document that outlined some key problems we were facing and some potential solutions. As an example, our iOS application has become quite large over the years, and the compile times have started to become a pain for iterative development. When changing the color of a view, it was taking 30 to 60 seconds to see that change in the running application. We had heard of other companies modularizing their application into independently deployable units, and we tried it out on a single feature to get a feel for the pain points.
This happened at a perfect time when we were at a really early discovery stage in our next project and it didn’t make sense to involve the engineering team full-time yet. We were able to work on a relevant technical project that felt like it would help us move faster when the next round of features was ready to build. It really was a win-win, and it all started from a conversation with the team.
By maintaining a healthy technical backlog, technical leads can use it to populate sprints when convenient and reduce the pressure to finalize product decisions.
The Role of a Technical Lead
The concrete definition of what a technical lead is can vary from company to company. What seems to be constant is this: they must think about the whole software lifecycle and they must align the development team on goals. They will also generally work closely with the product manager who has the final responsibility for deciding on what the team decides to build. For these reasons, a technical lead is instrumental in creating an environment where a team can experiment to find compelling value streams.
The build trap is an anti-pattern that I imagine is familiar to a lot of people. It can be demoralizing if you notice it happening, but it is most certainly damaging to the business no matter what. As I said before, a software project is an investment and it can bring either positive or negative returns. By supporting a product team in finding and solving empirical business problems, a technical lead is someone who works to maximize the return on a software project investment.
This is the path out of the build trap.
