How Our Tooling Guild's 'Automation First' Mentorship Created New Staff Engineers at hqblx

The Genesis: Why 'Automation First' Became Our Mentorship North Star

At hqblx, our engineering velocity was hitting a familiar plateau. Teams were proficient at building features but increasingly bogged down by repetitive tasks, configuration drift, and 'tribal knowledge' deployment processes. Promising senior engineers were brilliant at solving immediate problems but struggled to zoom out and design systems that prevented those problems from recurring. We recognized a gap: the leap to Staff Engineer requires a shift from coding solutions to designing leverage—multiplying the effectiveness of entire teams. Our Tooling Guild, a community of practice focused on developer experience, proposed a radical mentorship premise: instead of teaching automation as a set of tools, we would mentor engineers to think with an 'Automation First' mindset as the primary lens for architectural and strategic decisions. This wasn't about writing more scripts; it was about cultivating the intuition to identify toil, measure its cost, and architect it away permanently. The goal was to create engineers who didn't just climb the ladder of technical complexity but who could build elevators for others.

Identifying the Career Progression Bottleneck

We observed a common pattern among senior engineers aspiring to the staff level. They could design a complex service but often overlooked the operational burden their design would impose. They would champion a new database technology but not the automated rollback and monitoring strategy needed to deploy it safely. Their focus was on the 'what' of the system, not the 'how' of its sustainable operation at scale. This created a ceiling. Our hypothesis was that by embedding automation thinking early in the design process—through mentorship—we could accelerate the development of that crucial, leverage-oriented perspective. We framed automation not as DevOps, but as applied software engineering for the problem domain of 'software engineering itself.' This reframing attracted engineers who wanted to solve meta-problems and have outsized impact.

The program's inception was organic. It started with a handful of Guild members running informal 'office hours' to help teams automate painful manual releases. The success stories—a team regaining 20 hours a week, a reduction in deployment failures—became our best recruitment tool. We realized we had stumbled upon a powerful mentorship vector: tangible, pain-relieving projects that also taught high-level principles. We then systematized it. The core curriculum moved from 'how to use Terraform' to 'how to conduct a toil audit of your team's workflow,' and finally to 'how to propose an automation-centric architectural standard for the organization.' This progression mirrored the journey from senior to staff: execution, analysis, then influence.

We also made a critical decision to keep this mentorship community-driven, not a top-down HR mandate. Promotion to Staff still followed the official engineering ladder, but the Guild provided the practice field, the coaches, and the playbook. This preserved intrinsic motivation and ensured the mentorship was grounded in real, daily engineering challenges, not theoretical exercises. The Guild became a career incubator, visible and valued by engineering leadership, which lent the program credibility and created a virtuous cycle of participation and promotion.

Deconstructing the 'Automation First' Mindset: More Than Tools

The 'Automation First' mindset is often misunderstood as mere scripting proficiency. In our mentorship, we define it as a hierarchical framework for decision-making. First, it's a bias for eliminating the task entirely through design. If elimination isn't possible, the next bias is for creating a self-service platform or API. The last resort is building a script or tool, and even then, the tool must be treated as a product with documentation, error handling, and metrics. This mindset forces engineers to think in terms of leverage and scale from the outset. For example, when considering a new microservice, a mentee is guided to not just design the service API but to simultaneously design the automated canary release pipeline and the failure detection runbooks as first-class components of the service. This shifts the definition of 'done' from 'code works' to 'code can be safely and repeatedly operated.'

Core Principle: Measuring Toil as a Design Input

A pivotal lesson in the mentorship is learning to quantify toil. We teach mentees to conduct lightweight time-tracking exercises with their teams to catalog repetitive, manual, context-switching tasks. This data becomes a powerful input for system design. Instead of arguing abstractly about technical debt, an engineer can say, "Our current deployment process consumes 15 person-hours per week of senior engineer time, which is a bottleneck for feature work. My proposed automated pipeline design reduces this to 1 hour, with a one-time implementation cost of 40 hours." This economic framing is a hallmark of Staff-level communication. It translates technical work into business impact, a skill we actively mentor. We use anonymized examples from past Guild projects to show how presenting this data influenced architectural decisions and resource allocation, turning an automation project from a 'nice-to-have' into a strategic priority.

Another key aspect is teaching the concept of 'architecture for operability.' This means choosing technologies and patterns not only for their feature set but for their automation potential. We compare different approaches: a monolithic application might be simpler to start but often harder to automate targeted deployments for. A containerized service mesh might have a steeper learning curve but offers superior built-in automation hooks for traffic shifting and failure injection. Mentees learn to evaluate these trade-offs through the lens of long-term operational cost, not just short-term development speed. They practice creating decision matrices that score architectural options on criteria like 'ease of automated testing,' 'observability integration,' and 'failure recovery automation.'

Finally, we stress that 'Automation First' is inherently collaborative. The best automation solves real pains felt by a team. We mentor engineers on the soft skills of this work: interviewing teammates to discover hidden toil, building consensus for a new automated workflow, and creating documentation that empowers others. A successful automation project is one that gets adopted and maintained by the team, not just built by a lone wizard. This focus on enablement and influence is the bridge from senior individual contributor to Staff Engineer, whose success is measured by the output of the entire organization.

Structuring the Guild Mentorship: Community as the Catalyst

The structure of our Tooling Guild mentorship was deliberately designed to mirror the collaborative, cross-functional nature of Staff Engineering work. It is not a lecture series but a participatory studio. The core unit is the 'Pod': a small group of 3-4 mentees from different product teams, guided by 1-2 experienced Staff+ engineers from the Guild. Pods form around thematic challenges, such as 'improving developer onboarding' or 'building a chaos engineering pipeline.' This cross-pollination is crucial; it breaks down silos and exposes mentees to diverse problems and tech stacks, broadening their perspective beyond their immediate team. The Pod works on a real, scoped project that benefits hqblx, ensuring the work has stakes and relevance. Mentorship happens in weekly working sessions where the guide doesn't give answers but asks probing questions: "What's the manual step you're automating? Could you eliminate it instead? How will you know if your solution is successful?"

The Role of 'Showcase' and Open Critique

A key ritual in our program is the bi-monthly Guild Showcase. Here, Pods present their work-in-progress to the entire Guild—a audience of peers and other senior engineers. Presentations follow a strict format: problem context, toil measurement, design alternatives considered, implementation choices, and, most importantly, metrics of success or failure. The ensuing Q&A is a practice ground for Staff-level defense and reasoning. Mentees learn to handle challenging, cross-examination-style questions about their architectural trade-offs, much like they would in a formal architecture review committee. This transparent, peer-review culture builds intellectual rigor and collective ownership. The stories that emerge from these showcases become part of the Guild's lore, providing concrete, relatable examples for future mentees. It turns abstract principles into lived experience, reinforcing the community's knowledge base.

Beyond Pods, the Guild hosts 'Deep Dive' workshops on specific automation domains, like infrastructure-as-code advanced patterns, or designing for graceful degradation. These are often led by mentees who have developed expertise in an area, flipping the traditional mentor-mentee dynamic and reinforcing the principle that everyone teaches, everyone learns. We also maintain a central 'Automation Pattern Library'—a living wiki of solved problems, code snippets, and post-mortems. Contributing to this library is a milestone for mentees, signifying their transition from consumer of knowledge to curator and contributor for the wider engineering community. This ecosystem of pods, showcases, workshops, and a knowledge base creates a self-sustaining career growth environment that formal training cannot replicate.

The Guild's leadership also works closely with engineering managers to align mentorship activities with career development goals. Before joining a Pod, a mentee and their manager define what 'success' looks like for their participation, often tying it directly to competencies on the Staff Engineer ladder. This ensures the mentorship is not a side quest but an integral part of their professional development plan. Managers are encouraged to protect time for Guild activities, treating them as high-value investment work. This organizational buy-in is essential; it signals that the skills developed here are valued and recognized in the promotion process, closing the loop between community learning and career advancement.

Real-World Pathways: Composite Stories of Career Transformation

To illustrate the impact, let's examine anonymized, composite stories of engineers who progressed through the program. These are not singular case studies but representative patterns we've observed multiple times. The first story is 'Alex,' a senior backend engineer known for deep domain expertise and reliable feature delivery. Alex's team was struggling with database schema migrations, a process that was manual, error-prone, and required off-hours work. Alex joined a Guild Pod focused on deployment automation. Through mentorship, Alex learned to frame the problem not as "writing a better migration script" but as "designing a database change management system." The Pod guided Alex to research and propose a toolchain that included automated rollback safety checks, integration with the CI/CD pipeline, and a self-service portal for other teams.

From Project Lead to Platform Influencer

Alex's project succeeded within their team, but the mentorship pushed further. Guides encouraged Alex to present the solution at a Guild Showcase and then to evangelize it to other team leads. This involved writing a formal proposal, creating cost-benefit analyses, and addressing concerns from teams with different tech stacks. Through this process, Alex developed the influence and architecture skills of a Staff Engineer. The local tool became a candidate for a company-wide platform service. Alex's role evolved from being the expert on their team's service to being a consultant for multiple teams on data persistence patterns. This visibility and cross-organizational impact were direct factors in Alex's subsequent promotion to Staff Engineer. The key learning was that technical execution opened the door, but systemic thinking and community influence walked them through it.

The second composite story is 'Sam,' a senior engineer with a passion for performance. Sam noticed that engineers wasted days manually profiling services to diagnose sporadic latency spikes. Sam's initial instinct was to build a powerful personal profiling toolkit. The Guild mentorship redirected this energy. Guides asked, "How can you turn your personal toolkit into a platform that makes this knowledge accessible to every engineer?" Sam's Pod project became an automated performance regression pipeline that hooked into the CI system, running benchmark tests on every pull request and annotating them with potential performance impacts. This required Sam to learn about scalable data collection, defining meaningful performance budgets, and creating intuitive visualizations.

The project forced Sam to engage with teams across the company to understand their performance needs and constraints, building a coalition of stakeholders. The resulting platform shifted the culture toward proactive performance management. Sam's career trajectory transformed from a specialist individual contributor to the de facto owner of a critical cross-cutting concern—a classic Staff Engineer archetype. These stories highlight the program's mechanism: it takes strong senior engineers and places them in a structured, community context where they must practice and be recognized for the higher-leverage, strategic behaviors that define the next level.

Comparing Mentorship Models: Why Our Guild Approach Worked

Many organizations attempt technical mentorship. We evaluated and consciously diverged from several common models. Understanding these comparisons is crucial for anyone looking to adapt this approach. The first model is the Traditional Apprenticeship: a one-on-one, long-term pairing between a senior and a junior. This is excellent for deep knowledge transfer but doesn't scale well and can create dependency. It also often lacks the cross-functional exposure needed for Staff-level growth. The second model is the Formal Training Course: a scheduled curriculum of workshops and lectures. This is efficient for disseminating information but is often passive and fails to create lasting behavioral change or apply learning to real work.

The third model is the External Certification Program: sending engineers to vendor-specific or generic cloud/automation certifications. While these validate knowledge of tools, they rarely teach the strategic 'mindset' or the soft skills of influence and design. They are credential-focused, not impact-focused. Our Guild-based 'Automation First' model hybridizes the best elements: the applied, project-based learning of an apprenticeship; the structured knowledge-sharing of a course; and the community recognition of a certification, but tied to internal, verifiable impact. The table below summarizes the key differences:

Our choice was deliberate. The Staff Engineer transition is less about acquiring new technical facts and more about changing how one approaches problems, communicates, and creates leverage. This requires a social learning environment—a community of practice—where these behaviors can be modeled, practiced, and reinforced. The Pod system provides a safe space to attempt influence and architecture on a small scale before doing it for the whole company. The showcase provides a forum for recognition. The pattern library ensures contributions outlast the individual. This ecosystem is what turns a mentorship program into an engine for career transformation.

Implementing the Framework: A Step-by-Step Guide for Other Teams

If you're inspired to cultivate Staff Engineers through a similar 'Automation First' community, here is a practical, step-by-step guide based on our experience. This is a general framework; adaptation to your organization's context is necessary. Step 1: Find Your Pioneers and Define the 'Why'. Start by identifying 2-3 respected senior or staff engineers who are passionate about tooling, developer experience, or systems thinking. With them, articulate a compelling, specific pain point that automation can solve—e.g., "Engineers spend too much time on-call firefighting due to unclear alerts." This becomes your rallying cry and first project scope.

Step 2: Seed the First Pod with a Concrete Project

Recruit 3-4 senior engineers from different teams who are affected by that pain point. Form the first Pod with your pioneers as guides. Choose a project with a clear, achievable scope that can be completed in 6-8 weeks. Examples: "Create a standardized, automated runbook for our most common alert," or "Build a self-service CLI for spinning up a new service skeleton." Mandate that the project includes measurement (e.g., time saved before/after) and documentation. This first Pod is your prototype; its success is critical for generating momentum and stories to attract others.

Step 3: Formalize the Guild Structure. After the first Pod demonstrates value, formally announce the Tooling Guild as a community of practice. Establish lightweight governance: a rotating chairperson, a regular meeting cadence (e.g., bi-weekly showcases), and a shared communication channel. The goal is minimal bureaucracy, maximum collaboration. Create a simple charter stating the Guild's mission: "To improve engineering leverage at [Company] through automation, tooling, and shared best practices."

Step 4: Integrate with Career Ladders. Work with engineering leadership and HR to explicitly link participation and leadership in the Guild to the competencies required for Staff Engineer and above. This could mean adding items like "Mentored peers through a Guild Pod" or "Contributed a widely-adopted pattern to the Guild library" to the promotion rubric. This alignment is what turns the Guild from a hobby club into a legitimate career accelerator.

Step 5: Scale Through Storytelling and Decentralization. Don't force growth. Let it happen organically through the success stories of the first Pod members. Encourage them to become guides for new Pods. As the Guild grows, decentralize topics—have sub-groups focus on areas like 'Internal Platforms,' 'Observability,' or 'Security Automation.' The key is that every activity ties back to the core 'Automation First' mindset and producing tangible work that reduces toil. Regularly celebrate these wins in all-hands meetings and internal blogs.

Step 6: Iterate on the Model. Continuously gather feedback. What projects had the most impact? Which mentorship techniques worked best? Adjust the Pod formats, showcase styles, and knowledge-sharing tools accordingly. The Guild itself should be a product of automation thinking—constantly seeking to eliminate its own inefficiencies and scale its positive impact.

Navigating Challenges and Common Questions

No transformative program is without its hurdles. We address the most frequent concerns and challenges we faced. Q: How do we prevent this from becoming a 'shadow IT' or a distraction from 'real work'? A: This is a critical risk. The antidote is tight integration with engineering leadership and roadmaps. Guild projects should be scoped to solve acknowledged, widespread pains. Managers must be partners, protecting time for Guild work as strategic investment. The Guild is not a separate org; it's a service organization for product teams. Its work should appear on roadmaps as enablers for feature teams.

Q: What if engineers don't have time to participate?

This is the most common initial barrier. The response is twofold. First, demonstrate the return on time invested. A successful Pod project that saves a team 10 hours a week pays for itself quickly. Use data from early projects to make this case. Second, start small. A Pod commitment might be 2-3 hours per week, which is manageable if prioritized. Often, the real issue is not a lack of time but a perception that this work is less valuable than feature delivery. Leadership must actively communicate that developing automation and strategic skills is a high-priority form of feature work—it's a feature for engineering itself.

Q: How do we measure the success of the mentorship program itself? A: Avoid vanity metrics like 'number of Pods.' Focus on outcome-based metrics: 1) Career Outcomes: Track the promotion rate of active Guild participants to Staff+ roles compared to the broader engineering population. 2) Project Impact: Collect before/after metrics from Pod projects (e.g., reduction in manual steps, time saved, error rate reduction). 3) Cultural Indicators: Survey engineers on whether they feel empowered to automate toil and if they see a clear path to developing Staff-level skills. Qualitative stories are equally important; collect and share them.

Q: What if the Guild becomes elitist or cliquish? A: Proactively design for inclusivity. The Guild must be open to any engineer expressing interest. Guides should be trained to be welcoming and to balance high standards with psychological safety. Rotate leadership roles. Actively seek out participants from underrepresented teams or backgrounds. The 'Showcase' should be an event for learning, not a performance review. The goal is to grow the pie of senior talent, not guard a private club.

Q: Can this work in a fully remote or hybrid setting? A: Absolutely. Our program evolved in a hybrid environment. Digital tools are crucial: collaborative design documents (like Miro or FigJam), shared code repositories, and regular video calls for Pod sessions. The virtual showcase can be even more inclusive, allowing asynchronous participation via recorded demos. The principles of community, project-based learning, and transparent critique translate well online, though intentional effort is needed to foster the same sense of connection.

Conclusion: Cultivating Engineering Leverage from Within

The journey of our Tooling Guild's 'Automation First' mentorship demonstrates that the path to Staff Engineer is not a solitary climb up a mountain of complexity. It is a communal journey of learning to build bridges, elevators, and better maps for everyone. By anchoring mentorship in a tangible mindset, embedding it within a supportive community of practice, and tying it directly to real-world impact and career progression, we created a sustainable engine for growing senior talent. The new Staff Engineers at hqblx are not just experts in a domain; they are multipliers, systems thinkers, and advocates for leverage. They see automation not as a task, but as the fundamental expression of thoughtful software engineering. For any organization looking to develop its next generation of technical leaders, we believe the formula is clear: identify a strategic mindset, build a community to practice it, and get out of the way while they solve real problems. The investment in such a guild pays dividends not only in promotions filled but in a more resilient, efficient, and empowered engineering culture overall.