_edited.png)
A company with strong engineering and product teams is a force to be reckoned with. That company can more easily outrun its competition by consistently building better technology, and it can more easily stay ahead by consistently iterating on that technology. The problem is, at every single startup I’ve ever worked with, engineers have always been the most limited resource. I’ve worked with plenty of companies who had fully hired out their non-technical teams such as operations, sales, and marketing teams. I’ve never worked with a company who had reached their hiring targets for engineers. And there isn’t much of a substitute for engineers. Engineers can build things that improve customers’ and employees’ experience in a way that simply cannot be replicated by other functions.
Besides demonstrating that I clearly made the wrong career choice in not learning to code, the challenge that this situation creates is that companies have to be extremely intentional about how they use engineering resources. Not only do engineers have to be focused on only the very tippy top of the list of important problems, they also have to be building solutions in a way that is at once speedy and scalable. Move too fast and a company creates tech debt that costs even more to fix later on. Focus too much on scalability and a company risks taking too long to roll out products, likely at the expense of user experience or company growth.
Putting bumpers on a bowling lane means more pins get knocked down
One of the ways a company can ensure it is using its tech resources effectively is by making sure that what engineers are building is, from the outset, as close to the optimal solution as possible. An engineering team solving a problem from scratch with little data on how different solutions will work can be like bowling in a lane without bumpers. A bowler will know where they want the ball to end up, but pointing the ball even slightly in the wrong direction at the beginning can result in that ball hitting the gutter well before it reaches the pins. Bumpers for bowling lanes ensure the ball is more likely to head in the right direction. So how can a company create these bumpers for its engineers? Hacking.
Hacking in the startup world is (maybe a little bit counterintuitively) when non-technical teams build solutions to problems. In the early days of Uber, we didn’t have an automated way to customize text messages to a bunch of different drivers. I couldn’t use our messaging tool to send different information to different drivers unless I wanted to manually send them each an individual text. That would have taken hours. What we did have, though, was a database of driver activity and information that we could query with SQL. So I built a query that identified the relevant pieces of information we needed for each driver, and then that query spat out a custom text message for that driver. My team could then upload the results into a tool that sent out that personalized text message.
This hack was a pretty ideal solution to the problem of limited engineering resources. At the time, engineers at Uber were probably working on significantly more important things than saving a Baltimore Operations Manager a few hours a week on his driver texts. It definitely would not have made sense to have them work on a custom texting tool instead. This hack allowed me to replicate a solution an engineer could have built, but without requiring any engineering time. Win-win.
Great, hacking saved some time. But how is it like a bowling lane bumper for tech teams?
Shortly I’ll discuss how the above example led to an ideal product outcome, and thus acted as a bowling lane bumper. But to underscore the effectiveness of hacking, I’d like to first look at an example where hacking did not take place. In another organization I worked with, there was a similar problem of not being able to effectively customize messages to our users. The problem in this situation was figuring out how to send reminder messages to our users about their appointments. These appointments were virtual, so sometimes the user and the provider were in different time zones. We needed some way of sending the user their appointment reminder with the time of the appointment noted in the appropriate time zone for them. The customer-facing team sent this ask to the Product team, and the Product team filed a ticket for an engineer to create an appointment reminder text with the user’s local time zone. About a week later an engineer had built this text campaign and it started being sent.
Almost immediately, the customer-facing team started getting reports from providers that users were not showing up to their appointments, and the team also started getting angry notes from users that they had showed up to an appointment at the scheduled time but the provider wasn’t there. The engineer and Product Manager were both asked to drop what they were doing in order to troubleshoot what was going on, and the customer-facing team was also asked to look into what was happening.
Hours later, it was determined that this new automated reminder text was the culprit. It was sending appointment reminders using the time zone field from the user’s profile, as the engineer had intended it to. But it was discovered that, unfortunately, that field was often inaccurate. So users were getting texts with reminders in time zones that they simply weren’t in. In order to cut their losses both with users as well as with engineering time spent addressing the issue, the team decided to turn off the reminder text until a more accurate source for the user’s time zone could be identified.
Over the course of this saga a number of suboptimal and avoidable problems occurred. First, many users were alienated by their experience on the platform. Second, many hours of precious engineering time had been devoted to building a solution that was shelved almost immediately after it was rolled out. Third, many hours of unproductive distraction were created not just for engineering, but also for Product and operations teams, when the urgent customer problems arose from the rollout.
How could this all have been avoided? Certainly a test rollout to a small cohort of users could have helped. The problem with that is it would have required even more engineering time with monitoring and analysis. A more optimal use of time would have been to have the customer-facing team “hack” the solution instead. Instead of an expensive, time-constrained engineer building an automated solution, the company could have had the less costly, better-resourced operations team do a manual version of the test. Set up properly, the test would have surfaced the exact same problem of profile time zone accuracy. And it would have done so while alienating far fewer users, taking no engineering time to build, and requiring less time from fewer teams to troubleshoot when the issue did occur. Whereas it did not make sense to have the troubleshooting engineer try to identify alternative solutions, the customer-facing team probably could have spent more time trying to identify other sources of time zone data, tested those out, and then handed the product team a ready-to-build solution that there was already 100% confidence in. The engineer might have thrown a gutter ball on their own, but the operations team could have helped that engineer bowl a strike instead by putting up the rails to ensure the outcome was more likely to be a good one.
The virtuous cycle of Ops hacking and Product automation
When done correctly, hacking by non-tech teams can save tech teams a ton of time by essentially having all the bad outcomes happen before any engineering time is spent on a solution. Engineering time then gets dedicated to work that is almost guaranteed to be impactful. And then non-tech teams can start hacking on top of that work even faster. All told, the end user gets a better product, and much sooner. The cycle looks something like this:
I know it might be hard to believe, but I actually did not go to art school.
Hacking gone well
Back to Uber Baltimore circa 2015 for a moment. My team had come up with a hacky solution to send personalized, kind-of automated texts to drivers. After building the first version and seeing great results, we continued iterating on the texts by A/B testing additional text messages with different content. This experimentation resulted in some very optimized ways to communicate with and present information to our users, and it also resulted in some learnings about what our communications tools needed to be able to do long-term. We brought these learnings and these comms to our Product team. They were able to use these insights to create a significantly improved version of the communications tools that all Ops teams across the world used, and the tools perfectly automated every single thing we had to do manually before. Instead of a long development cycle with lots of iteration on the tech side, and likely with lots of expensive learnings along the way, we as an Ops team were able to help Product skip many steps, and the outcome was a better product done faster.
tl;dr
There are many scenarios in which a well-designed operational experiment or process can not only save tech teams time but also lead to significantly better product and user outcomes, even in the short term. Setting up your tech and non-tech teams to work on problems at different stages of the problem lifecycle, where non-tech teams hack and iterate, and tech teams automate those solutions, can yield tremendous value for a tech resource-constrained organization.