Written by Saverio Morpurgo, Senior Engineering Manager @ HubSpot.
In numerous conversations with engineers and engineering leaders, I've repeatedly encountered questions about what truly drives success, growth, and career advancement. My responses' common thread has always centered around delivering impact that solves for the customer.
However, this raises many important questions:
- What does being impactful as an engineer mean?
- How do we determine when we are truly making a difference?
- How does it correlate with our performance evaluations?
- And what about factors beyond engineers' control?
In this post, I will delve into these queries, exploring the nuances of engineering impact and its profound influence on personal growth and career development.
As a passionate motorbike enthusiast, I often cruise the open roads on my trusted KTM 1190.
In between rides, while sipping a good cup of coffee, often the funny debate happens around how powerful this machine is. "Should I spend my money on a mighty bike? Will its power be fully utilized? Will it translate into powerful accelerations, smooth, safe rides, and exhilarating experiences on twisty roads?
Debates can get very passionate, and I understand that fellow bikers are eager to join the discussion, ready to express their agreement or disagreement, so I won't even try to respond to those questions for the motorcycling world directly.
However, I've realized the handy metaphor this conversation offers. I want to stretch the boundaries of the metaphor and use it to explain how I think about driving true impact.
Picture this: as an engineer, you've designed and built a robust 150hp motorcycle engine, showcasing your expertise. Let's reflect on what impact means in our work. I want to share my vision of impact beyond the engine, extending beyond construction and focusing on tangible outcomes.
When we are NOT impactful
We've built this powerful 1200cc, 150hp engine. Will the frame withstand the torque or break under strain? What if the brakes aren't powerful and calibrated to ensure safe and prompt stops? Furthermore, what if the operating system fails to handle acceleration, resulting in unwanted wheelies?
As engineers, what does it mean for us when we're not genuinely driving impact?
Let’s start with what might not be.
- Building an architecture that doesn’t generate customer value is not impactful.
- Conducting experiments and A/B tests but failing to extract valuable insights, leading to a product release of a feature, is not impactful.
- Releasing a product's alpha (or even beta) version is not impactful (yet).
- Does our responsibility end once the product is in production? ( spoiler: no )
Looking at this through the motorcyclist lens would be like building the engine and leaving it sitting in the factory.
These objections may arise:
- Sometimes, our solutions do not immediately provide a visible impact on customers. What do we do then? How will our success as engineers be measured?
- Not all experiments will lead to a successful production release. Sometimes they fail. As engineers, our primary role is building things, while Product Managers, Designers, and Customer Experts ensure the usefulness of our creations.
- Once a product is in production, have I had an impact as an engineer?
I will utilize these examples to express my thoughts and propose meaningful actions.
While I acknowledge that they may not cover every aspect comprehensively, nor do the examples encapsulate the entirety of the topic, I aim to convey the essence of going beyond the engine and driving solutions. By suggesting practical actions, I hope to illustrate how we can make a tangible difference in our work and create impactful outcomes for our customers.
When we ARE impactful (and some examples)
Overhauling your codebase
Imagine you're knee-deep in designing a new architecture, immersed in diagrams, flowcharts, and building proof of concepts. As you sit before your team, engaging in debates about adding queues and implementing failover mechanisms, you can't help but ask yourself: What is the true purpose behind refactoring an old solution or creating a new one? Don't settle for a simple answer like 'It's a better, modern solution.'
Instead, challenge yourself to consider how it will enable the customer to achieve better outcomes. This may only sometimes be evident, especially when it involves rebuilding underlying infrastructure. However, it doesn't mean you can't establish a connection to customer impact—it just requires a few more leaps.
Let me provide an example.
Approximately a year ago, one of the teams I had the privilege to work with embarked on a complete overhaul of the signup codebase, codenamed 'Lego Blocks.' (If you're curious, I recommend reading 'Rearchitecting Signup for an Improved Customer Experience.') The existing solution wasn't broken, so why fix it? It was functional, so why change it?
However, the impact on the customer wasn't immediate. The initiative centered around delivering a new, enhanced user experience. Still, the underlying architecture remained a parallel and, to some extent, unrelated work (it would have been possible to build the new user experience by modifying the existing codebase).
So, how did it ultimately impact the customer, and how was it achieved? The new codebase proved easier to maintain, reducing pain points for engineers when modifying, fixing, and identifying bugs. The 'Lego Blocks' concept empowered us to swiftly implement changes and customize the experience, allowing us to showcase the actual value of HubSpot to potential customers at an early stage. What once took several weeks to build a new signup flow can now be accomplished in a few days.
- Make that chain of connections
- Do that through every step of your design, build, and rollout process.
In every stage, ask yourself if you can (still) roll up to a customer impact. It’s easy to lose track of that, even from a project that started with the most explicit intentions.
It can be contentious to claim that you're not driving impact if an experiment you run fails. After all, experiments are designed to test hypotheses and uncover learnings, which inherently means they can yield both successful and unsuccessful outcomes.
As an engineer, it becomes challenging to measure your performance against something that, by definition, may or may not succeed based on the quality of the hypothesis or other qualitative/quantitative factors. It's important to recognize that only some experiments will go into production (sometimes, even if successful). What truly diminishes the impact is stopping at a 'failed' experiment without extracting valuable insights from it.
When your experiment doesn’t get you to release a new feature to production, consider the following:
- What new knowledge do I gain about the customer?
- Should I conduct a follow-up experiment that can lead to a series of iterative tests, ultimately driving impact?
- How do I recognize when to abandon a particular path (and the reasons behind it) to redirect focus onto more promising alternatives?
As (Growth) engineers, we mustn't settle for merely running experiments; we must strive to understand their implications and outcomes. What did these experiments ultimately lead to? How do you get the power of those learning onto the ground, onto the customer?
Actions to Drive Impact:
- Raise your hand if an experiment lacks the following explicit action: Ensure each experiment has a defined next step or actionable outcome.
- Clearly articulate the reasons for not pursuing a particular path: If a team abandons a specific approach, can you concisely state the "why"? What’s the alternative path to explore?
- If an alternative path is missing, work to identify it.
Building new apps & features
As engineers, we find fulfillment in seeing the outcomes of our hard work, even before a feature is in production. While reaching milestones like alpha or beta releases is gratifying, the true impact extends beyond these checkpoints. When showcasing your work, emphasize what you built and its impact on customers.
Remember that a production release is not the endpoint; stay curious about customer feedback and collaborate with cross-functional teams. For example, beyond signups, delve into understanding the end-to-end customer journey.
Actions to Drive Impact:
- Plan a timeline for the General Availability release following the beta stage. Engage with your Product Manager to outline a well-defined roadmap. If that needs to be clarified for you, ask the question to the team.
- Implement comprehensive metrics to measure customer experience and behavior in production. If you don’t understand those metrics, raise your hand to learn about them.
- Ensure you have systems to collect feedback and be curious about them actively.
As engineers, we recognize that we don't operate in isolation within the product development landscape. We collaborate with talented individuals providing the product with direction and a crafted experience and supporting us in understanding our customers' needs and problems.While we don't need to take on every aspect, we should strive to comprehend the connections and the true impact when our work hits the road.
“With the collective efforts of the entire team, the engine becomes meaningful.”
While reaching intermediate milestones is valuable for career progression, imagine how easier those conversations would be if you could say something like
Example: "I've been able to showcase HubSpot's value to 5,000 new customers monthly, helping them overcome their daily challenges after Signup"
You don’t know what exactly that measurable impact is yet? If you're uncertain, don't hesitate to address it, disrupt the artificial harmony, and engage with your team, team leaders, and group leaders. Ensure you can articulate your primary metric and North Star at any given point. Ensure you let these guide your decision-making throughout the design and coding process.
Above all, ensure that you care.