Architects of Happiness
If you care about preserving your builders’ morale and retention, stop downplaying the importance of internal-facing engineering disciplines.
The concept of “internal-facing engineering” generally in the tech industry can encompass an exceptionally broad range of roles. In this article I’m focusing on Developer Experience (DevX) engineers who provide platforms and tools to accelerate engineering teams and Quality Assurance (QA) engineers who play a pivotal role in ensuring software quality during the development of new features.
I suspect, though, the sentiment expressed in this essay will resonate with all internal-facing teams.
Underlining the profound impact of the less-frontline, internal-facing engineering team is ultimately quite simple. Their suite of technical responsibilities includes mitigating convoluted complexities, which, when executed effectively, powers a higher-functioning pipeline. With these teams building and maintaining strong and stable pipelines, product-facing developers can more effortlessly overcome entrenched roadblocks allowing them to build and launch higher-quality products faster. These internal-facing engineers dedicate their careers to the success of a broader team, directly influencing the final product’s success for their users.
How powerfully mission-driven of a chosen discipline to invest ones’ technical focus and career growth powering optimal infrastructure that directly influences the health of the team and company. It generally feels like this altruistic choice — sure, partially selfish, as it involves pursuing an interest in fundamental technology or problem-solving scope — empowering the technology to reduce complexity for the engineers building what the user sees, interacts with, and recognizes as the brand. In my personal experience within this domain, I and my colleagues who are deeply dedicated to enhancing internal infrastructure and processes are propelled by a profound commitment to the product and its users. Not only do internal-facing engineers provide substantial nourishment to Engineering operations, keeping everyone optimally propelled with intensified momentum and sharper focus, but they do so fueled by one of the most significantly sustainable motivators: passion.
When we conceptualize Engineering operations theoretically excluding this described nourishment provided by QA and DevX disciplines, we’re imagining an Engineering organization that requires their frontline backend and product builders to own every comprehensive aspect of software development. To fully appreciate the weight of these responsibilities, let’s consider a single engineer tasked with creating and managing their own test environments and data. They must also scaffold and build their CI/CD infrastructure, ideate, execute, and automate expansive testing — manually and in automation — that accurately represents users. On top of this, they handle the instrumentation and monitoring of system health, addressing emergent alerts to maintain accuracy, stability, and overall system health.
Beyond the technical aspects, their work extends to forging strong interdisciplinary bonds when developing new features, significant investment in documentation for future reference, staying attuned to user happiness, and discerning defects post-launch. The responsibilities on that single engineer to steward stable software development removes potential for deep focus making forward-progress incredibly unrealistic.
I intentionally enumerate these requirements as essential considerations for the software engineer in this hypothetical scenario. In this world without internal-facing teams, the engineer not only struggles to build the product swiftly, hindering a crucial competitive edge, but also lacks the capacity to fulfill the myriad other requirements necessary for maintaining high-functioning and stable systems — both figuratively within the team and literally within the technical pipelines. Without embracing these requirements properly, the product’s quality degrades while concurrently damaging user happiness. Without embracing them properly, the engineer’s lack of focus would ultimately also diminish the users’ happiness irreparably. It’s a failing scenario.
It’s clear that demanding builders to unblock and guardrail themselves while sustaining enthusiasm for their ownership and thrive as a competitive product with loyal customers is, respectfully, absurd. Prioritizing QA and DevX teams within an Engineering organization, who wholeheartedly take on these responsibilities crucial for the product’s optimal health and the company’s success, is an undeniable benefit. By delivering powerful tooling that guards developers and empowers high-speed productivity, these internal-facing engineers offer more than invaluable internal tooling.
💥 Expert architects within their technical domain, QA and DevX engineers also emerge as passionate architects powering morale within the organization, subtly yet profoundly influencing the entire team (and oftentimes the entire company).
The subtle organic characteristics of internal-facing engineers contribute to high-morale organizational cultures, with an even more intense impact on each individual builder. Product-facing engineers anticipate daily reassurances and genuine comfort from their counterparts, who are able to empathize with the pressurizing expectations projected onto these builders from leadership. The support network within the team dynamic of peer product-facing engineers is evident. However, a deeper symbiotic relationship emerges when internal-facing engineers, driven by a deliberate desire to reduce technical overhead and accelerate progress, work ruthlessly to unblock and provide guardrails for safe product-shipping. This dynamic amplifies an unmatched emotional connection specifically between that product-facing builder and the internal architect.
The development of this emotional bond occurs naturally, requiring no active effort when companies effectively nurture radically committed QA or DevX engineers (along with broader internal-facing engineering disciplines akin to these). The efforts expended aren’t exclusively aimed at nurturing these teams for the sake of this advantageous relationship, but rather because of the incredible myriad of impact these teams provide for the ultimate synergy of highest-quality software development operations. Consequently, this supportive relationship emerges effortlessly as a valuable byproduct.
💥 This symbiosis strikes an invaluable intersection improving velocity, product quality, and developer happiness collectively.
Reflecting on this hypothetical of the imaginative software engineer forced to own their own quality and velocity at the cost of the product’s success while maintaining a sustained morale to avoid irreparable burnout is a little radical. Transitioning from this hypothetical to actual reality, we accept massive costs when organizations neglect to recognize the value of QA and DevX teams (or any internal-facing engineering team). Tactically failing to prioritize their initiatives or processes within the broader company goals and inadequately resourcing these teams has a downstream impact on overall developer happiness. Failing to support these teams forfeits (or severely neglects) that allocated focus of responsible champions who own culture of continuous improvement and fervently advocate for individual developer needs. The costly elevated pressure and diminished reassurance introduces unavoidable risk to an essential sense of security within the broader Engineering organization.
Avoiding risk that overextends product-facing developers, which inevitably leads to straining pressure undeniably difficult to sustain, can be achieved by fostering a culture of respect and recognition for both product contributions but also the critical internal contributions powering this work. This necessitates an investment in resourcing, technical infrastructure and communicated value — all amplified by respected leadership. Such an investment materially elevates the entire Engineering organization acting as an infectious force that magnifies development speed, product quality, and overall morale.
My impulse to enumerate the reasons I feel leadership perpetually falls short investing in these critical engineers thrusts me into an angsty attitude that requires it’s own dedicated essay for deeper analysis (therapy?). Instead articulating three common leadership failures that prevent recognition of talent across QA and DevX teams, thus stunting the technical and emotional-value they bring to teams, feels appropriate here.
1️⃣ Limited, Limiting Measurement
Instrumenting less thoughtful performance measurement within Engineering and overly prioritizing the pace of feature development can lead to a severe oversight of signals within an organization. The inclusivity of core values within QA and DevX contributes to an awareness of each engineer’s impact on operational stability, scalability, external user happiness, and the promotion of collaboration, rigor, and a continuous improvement mindset among peer engineers. This not only expands the nuance beyond stereotypical measurements of an engineer’s success but also ensures leadership consideration of profoundly impactful values. Thoughtful analysis of each engineer’s impact is crucial, and it significantly benefits the broader intention of investing in tracking the holistic function of the company.
Ignoring these values during performance measurement not only severely neglects Engineering disciplines who aren’t exclusively shipping code, emphasizing established optics of less importance, it also signals to your product-facing engineers their value is completely restricted to staying head’s down and shipping as quickly as possible — so pressurizing and morale-damaging to both.
Including metrics that extend through holistic values of internal multiplying through smart collaboration or thoughtfulness and impact to external user happiness through a rigorous attitude helps prevent this limiting environment from manifesting.
2️⃣ Economic Ignorance
The cost of excluding QA and DevX disciplines during planning initiatives, however structured for the company, unfortunately sabotages the team’s success and security of progress. Missing active consideration of experimentation and testing requirements, environment changes and infrastructure impact caused by new or changing dependencies, or perception from existing user demographics, the roadmapping and predicted estimations are stunted with inevitable downstream disruptors. These factors are essential to feature-development and will eventually surface with reported defects, broken systems, customer escalations— all impacting now or future timelines.
When teams observe perpetual indicators that their target launch dates were missed or delayed, even if this was the direct cause of ignorance during leadership planning, this looming “explanation-burden” (a phrase I feel properly defines the doomed feeling of reporting unfavorable circumstances to leadership) really damages morale. The value of QA and DevX currency, when emphasized and considered top-down, limits the risk of spending even more (time, resources, money, happiness) from uneducated estimations.
This is easy to avoid— keep internal Engineering managers included in planning conversations. Simple.
3️⃣ Superiority Complex
Leadership’s exclusive focus on the impact of product perception and competitiveness within the problem space, while neglecting internal-facing disciplines, hinders collective growth and overlooks powerful strategic factors. Passionate QA and DevX teams, empowering faster development and delivering higher-quality experiences to customers, realistically contribute to evident improvements in overall customer satisfaction. However, when leadership frequently attributes these positive effects solely to smart product management, accurate market-fit, or an astute leadership strategy, critical factors from these internal-facing teams are often suffocated and overlooked.
This again perpetuates an ignorance of the significant value that internal-facing engineering disciplines bring to an organization and hinders the necessary investment required to continually empower the impact generated by these engineers. For leadership to avoid neglecting these disciplines, it’s as easy as maintaining a mindful pulse on the output and impact of these teams. This benefits the potential for both recognition and an even stronger, refined strategy.
Recognizing and sufficiently prioritizing internal-engineering disciplines is absolutely imperative for preserving builders’ morale and maintaining expert ownership over the technical architecture that powers high-velocity, high-quality product development. Acknowledging the often overlooked and undervalued disciplines, especially from essential precedents set and reinforced by leadership teams, organizations reap organic reward from this stewarded culture of quality, continuous improvement and a true care for their peers. This manifests in an unmatched and tough-to-manufacture collective synergy that propels company success. Without this intentional acknowledgement, the damaging neglect felt by these internal-facing engineers absolutely extends through to product-facing engineers and risks overall attrition across the broader Engineering organization, materially damaging the product’s potential success, sure, but also risking career-damaging emotional turbulence of your most passionate people.
In essence, the architects of happiness reside within these internal-facing engineering disciplines, and their value is integral to the success of the entire engineering organization.
