Proactive versus reactive product development
Field notes from an engineering team lead
Intro to the field notes
A couple weeks ago I took a step back from fintech for rest, reflection, and to invest in personal projects. I’m taking advantage of the time to put down some thoughts about engineering team leadership and product development. I had a great run as CTO of Credijusto.com and VP of Engineering at Capital Technologies, and am enormously grateful to both founding teams for giving me a seat at the table. Please don’t construe anything I write here as specifically relating to either company. Rather, I’m distilling hard-earned lessons received over a couple years of iterating, failing, tuning the team, and ultimately notching up a few successes.
If there’s one overarching message that I’d like readers to take away from this it is that the team is everything. My friend Matheus Pedroso gave me the best advice I’ve gotten to date about how to build one: Make your garden beautiful, and the butterflies will come to live in it. Make your team great, empowering and supporting the people inside of it, and that team will consistently deliver business impact while attracting and retaining talent as it grows. I hope that these “fields notes” are helpful to you in your pursuit of this goal.
I’m going to write about:
- Proactive versus reactive product development (here)
- Setting up and empowering product delivery teams
- Reflections from trying Basecamp’s “Shape Up” as an alternative to agile scrum
- A more personal reflection on where I’ve gotten it wrong and what those experience have taught me
Let’s get into it.
Order versus chaos
In my experience, executives and frontline operators live in a state of perpetual chaos. Engineers, on the other hand, tend to seek a much higher degree of order and predictability in their day-to-day. I’ve seen this tension between the two groups play itself out over and over again, and have come to believe that it is essentially “canonical” for technology startups. Organizations that can coordinate these two communities such that they are constantly at their best will unlock powerful synergies, while those that don’t will find themselves tail-spinning into frustration, mistrust, and low productivity.
Here’s a mental map that many founders and startup execs navigate on a day to day basis:
Engineers have a totally different mental map as they go through their day to day:
I’m exaggerating to make a point, of course. Many executives do a superb job of introspecting and controlling their emotional dynamic, while there are plenty of engineers who actively enjoy startup chaos and are perfectly happy to “move fast and break things.” I’m generalizing toward what I hope is a useful model. 👍
Executives tend to see the world in terms of risks and opportunities, and they subdivide those into the concerns that are real and pressing today versus those that are relevant on the scale of months to years:
This array of risks and opportunities, spread over varying timescales, makes startup founders and executives’ day-to-day incredibly dynamic. They tend to be particularly slammed by items in top half of the matrix, where everything needed to happen yesterday, and a not small proportion of those things feel existential, e.g. bringing in that last investor to close the current round, meeting the feature release timetable that was advertised to users, or just figuring out how to survive COVID-19 and come out stronger on the other end.
Engineers’ worlds (at least their ideal world) tend to be far less kinetic. They spend less time reacting to what’s going on right now, and a lot more time thinking about how to build great software abstractions or thoughtfully pay down technical debt. The key point here is that their work is generally slow. A CEO can diffuse a crisis or win over a rockstar hire with an hour-long phone call, or a sales rep can push the end-of-month goal over the line with an eleventh-hour close. It is extremely uncommon that an engineer can build something deeply consequential for the business on the scales of hours or days, however. Engineers are at their best when they are empowered to work on a scale of weeks and months, within the boundaries of an appropriately iterative product process. The work that engineers do to build new stuff that supports business goals is called offensive programming, while the investments they make in scalability and stack quality — or just fixing stuff that is broken — are called defensive programming. Their priorities matrix is similar to the founders’, swapping out “risks” and “opportunities” for “defensive” and “offensive:”
Executive attention and energy is constantly sucked into the short-term, while engineers achieve impact — and therefore tend to be more oriented toward — over longer time scales:
The time range that someone operates at their best within is going to depend on their role. Founders, for example, need to make sure the business lives to fight another day, and therefore can’t lose sight of what’s in front of them. They also need to think about where they want to be years from now if they’re going to build a great company. On the other hand, while engineers are able to do their best work when they’re building on the scale of weeks to months, we typically don’t expect them to have the same kind of long-view that a founder does. It is this prevailing disparity between executives and engineering teams in what feels important and urgent today, combined with what is generally a highly asymmetric power structure, that has the potential to derail an engineering team.
Consider this fictional example: A product manager, collaborating with users, internal stakeholders, and the founder and CEO, comes up with a set of features for engineering to build in the upcoming 6-week sprint and presents the plan to the team. The engineers might not have total clarity on why they’re doing these specific things, but they kick off the sprint and get going. After one week an important enterprise client threatens to cancel their subscription if that widget they’ve been asking for doesn’t get built. The founder worked for months to close that customer, and she’s not about to let them get away. They’re also 15% of monthly revenue. She informs her head of engineering that one of the product teams needs to drop what they’re doing and immediately support the new feature. The engineers phase switch and leave the previous work behind. Their colleagues on the product management/design side run ad-hoc support, but the development of the feature is fraught with hiccups because it wasn’t planned in advance and is now being hastily deployed. The CEO gets increasingly agitated as the customer gets more restless. The teams look like they’re going to struggle to meet the two-week deadline that she committed them to. Down to the wire, they start taking shortcuts all over the code base that only the developers who made them will later be able to explain or fix, and testing gets punted to whenever they have more time in the future to work on tech debt. # TODO tags start popping up everywhere. The feature ships, and although it’s a bit buggy, embarrassing the CEO in her follow-up call with the customer, the customer appreciates the effort and decides to keep their plan based on the CEO’s promise that she will “100% have this fully polished two weeks from now.” The engineers are glad that they shipped something, but are demoralized by having had to lower the quality bar, stressed about having just been booked for another two-week fire drill, and are wondering what happened to that other important thing that they were working on before.
Rinse and repeat. Four months later the business is still moving along, but the relationship between the CEO, the rest of her non-technical executives, and the engineering team has soured substantially. Engineers don’t feel empowered to do their best work, and some of them are starting to take interviews elsewhere. No one is really delighted with the product. With so many intelligent, passionate people at the company and so much VC funding it feels like things should be going better…
Breaking out of the cycle
How can you make sure that this doesn’t happen to your team? I’ll be writing more about tactics in upcoming posts, but here are a few thoughts:
- That thing that feels like a truly existential burning fire that you became aware of a couple weeks ago almost never is. While the founder’s choice to turn the team from the example above may seem like a no-brainer financially, it actually came with huge costs that reverberated through the organization for months. How an engineering team executes over the long-term is far more important than what it builds tomorrow or next week. Executives that can protect their technical teams from day-to-day chaos will reap long-term rewards of software quality and scalability. Those that don’t will create compounding problems for themselves.
- Doing this requires enormous discipline from founders in particular. It’s hard to accept that 98% of the time the right answer is to take a deep breath, write that hugely important thing down, and then trust your team to finish the build they’re on before mixing things up. To do this you’ll need an outlet on the tech/product side for all your fear, anxiety, and excitement, as well as confidence in your team’s model of execution. I’ll get into that in the next two posts.
- To the extent possible, avoid making heat-of-the-moment promises to customers or investors that pre-commit your team to building a product or feature on an arbitrary timeline. Just don’t do this. It’s all too common, and artificially manufactures a time crunch that sets you up for the anti-pattern we describe above. You have enough pressure on you without making more.
- Engineering teams should absolutely be expected to pivot dynamically to support business requirements. The ability to adapt and overcome is a huge part of what makes a startup successful. Tight iteration cycles are critical for engineers to have the confidence that they’re building the right things. The point is that those cycles should be executed in a way that doesn’t give your product builders whiplash and erode trust.
- Emergencies that warrant an interruption of your engineering team’s “execution model” are rare and expensive, but they do happen. Sometimes you actually do live or die — or make a quantum leap as an org — based on what happens next Friday. It’s the founders’ and executive team’s job to steer the organization through those moments, and when they happen communication is critical. Sit down with the team and give them the why. Take questions and listen. While some engineers may be more unsettled by this dynamic than others, it’s what they signed up for when they joined a startup. Seen in the right light, it’s also part of the fun. Founders and execs who thoughtfully share context during highly dynamic periods will be amazed by the energy that their team will put into supporting them and the new vision. Just make sure that this doesn’t become your MO: If it does, that points to a larger problem.
If you relate to this “canonical tension” I’ve described above take a moment to fill out the risks and opportunities matrix. Have someone on the engineering team do the same thing, or depending on the size of your org make it a whole team exercise. Sharing perspectives based on your matrices will be enormously illuminating for everybody. What I hope you’ll discover is how many of the things that are front-and-enter for engineers, particularly on the defensive front, are much more aligned with your own long-term goals for your company than you originally expected.
Lemme know how it goes at aaron [at] pisces [dot] ventures. I’ll post again next week. Be well as we navigate this season of big risks and big opportunities.
