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

Every engineering organization wants more staff engineers — those seasoned contributors who can design systems, mentor peers, and drive technical strategy. But growing them internally is hard. At hqblx, our Tooling Guild discovered that coupling automation-first projects with a formal mentorship program accelerated that growth. This guide shares what we learned, what we got wrong, and how you might adapt the approach.

Where Automation Mentorship Shows Up in Real Work

The idea is simple: pair a senior engineer (the mentor) with a mid-level or senior engineer (the mentee) on a project that automates a painful manual process. The mentee leads the automation effort while the mentor provides technical direction, code review, and career coaching. The project itself becomes the curriculum.

At hqblx, we saw this play out in three common contexts: CI/CD pipeline improvements, infrastructure provisioning scripts, and developer workflow tooling. In each case, the mentee had to understand the existing manual process deeply, design an automated replacement, and then sell that change to the team. That combination — technical design, stakeholder communication, and execution — is exactly what staff engineers do daily.

One composite example: a senior engineer named Alex (not their real name) spent years writing deployment runbooks by hand. Their mentor, a staff engineer, challenged Alex to automate the entire deployment pipeline. Over three months, Alex built a CI/CD workflow, wrote documentation, and trained the team. By the end, Alex had not only delivered a working system but also gained confidence in cross-team communication and technical leadership. Six months later, Alex was promoted to staff engineer.

We saw similar outcomes in other teams. The common thread was that the automation project forced the mentee to think at a system level, not just at the code level. They had to consider failure modes, rollback strategies, and how their work fit into the broader developer experience.

Foundations Readers Confuse

When we first designed the mentorship, we assumed that technical skill was the main gap. We were wrong. The real gaps were often in judgment, communication, and the ability to prioritize work that benefits the whole organization, not just one team.

Many engineers confuse "automation" with "scripting." They think writing a Python script to replace a manual step is enough. But staff-level automation requires thinking about reliability, observability, and maintainability. A script that works on one machine but fails silently on another is not automation — it's a new source of toil.

Another common confusion is between mentorship and sponsorship. Mentorship means teaching and guiding; sponsorship means advocating for the mentee in promotion discussions. Our program included both, but we initially focused too much on the technical project and not enough on the sponsorship piece. Mentees who had strong sponsors were far more likely to be promoted.

We also saw confusion about the role of the mentor. Some mentors thought they should write the code themselves and let the mentee watch. That approach defeats the purpose. The mentee must drive the work, make mistakes, and learn from them. The mentor's job is to provide a safety net, not to do the work.

Finally, teams often confuse "automation first" with "automation only." Automation is a means, not an end. The goal is to reduce toil and free up time for higher-value work. If the automation project itself becomes a burden — requiring constant maintenance and generating more work than it saves — it has failed.

Patterns That Usually Work

Over two years, we identified several patterns that consistently produced strong outcomes. These are not silver bullets, but they are reliable starting points.

Pick a Painful, Visible Problem

The best automation projects are those that the entire team complains about. A deployment process that takes four hours. A manual testing step that everyone skips. An on-call rotation that gets paged for the same false alarm every night. When the problem is visible, the mentee's solution gets immediate attention and appreciation. That visibility helps build the mentee's reputation.

Set Clear Boundaries for the Mentor

We asked mentors to commit to one hour per week of dedicated coaching time, plus async code review. They were not allowed to write production code for the project. Instead, they could suggest approaches, point to documentation, and ask probing questions. This forced the mentee to own the implementation.

Include a Stakeholder Presentation

At the end of each project, the mentee presented their work to the broader engineering organization. This was not optional. The presentation covered the problem, the design decisions, the trade-offs, and the results. It gave the mentee practice in technical communication and helped them build a cross-team network.

Measure Outcomes, Not Output

We tracked not just whether the automation was delivered, but whether it reduced toil, improved deployment frequency, or decreased incident response time. Those metrics made it easier to justify the mentorship program to leadership and to identify which projects had the most impact.

Pair Mentees with Different Mentors Over Time

One mentor can only teach so much. We encouraged mentees to work with two or three different mentors over the course of a year. Each mentor brought a different perspective — one might be strong on reliability, another on communication. This variety helped mentees develop a more rounded skill set.

Anti-Patterns and Why Teams Revert

Not everything worked. We encountered several anti-patterns that caused teams to abandon the approach or, worse, to produce automation that created more problems than it solved.

The Mentor Takes Over

The most common anti-pattern was the mentor who could not resist writing code. When the mentee struggled, the mentor would jump in and fix the problem. The mentee learned nothing, and the project became the mentor's project. We had to explicitly coach mentors to step back and let the mentee struggle — within reason.

Automating the Wrong Thing

Some teams chose projects that were too small or too rare to justify automation. A task that happens once a month and takes ten minutes is not worth a week of automation work. We started requiring a simple cost-benefit analysis before approving projects: estimate the current time spent per year, compare it to the estimated development time, and only proceed if the payback period was less than six months.

No Maintenance Plan

Automation code needs maintenance. Dependencies change, APIs break, and requirements evolve. Teams that did not plan for ongoing maintenance found their automation rotting within months. We eventually required each automation project to include a maintenance handoff document and a scheduled review every quarter.

Ignoring the Human Side

Some automation projects failed because they did not consider how the change would affect the team. A deployment automation that bypasses a manual approval step might be technically sound, but if the team is not ready to trust it, they will revert to the old process. We learned to involve the team early, get feedback, and roll out changes gradually.

No Career Path After the Project

The worst outcome was when a mentee completed a successful automation project, got great feedback, and then had no clear next step. They felt stuck. We addressed this by tying the mentorship to the company's staff engineer promotion criteria, so the project directly contributed to the mentee's case for promotion.

Maintenance, Drift, and Long-Term Costs

Automation is not a set-and-forget activity. Even the best-designed automation drifts over time. Dependencies change, usage patterns shift, and the original assumptions become outdated. We saw several projects that were celebrated at launch but quietly abandoned six months later.

The main cost is ongoing maintenance. Every automation project adds to the team's technical debt. If the team does not budget time for maintenance, the automation becomes unreliable. And unreliable automation is worse than no automation, because people come to distrust all automation.

We also saw a social cost: teams that over-automated lost the tacit knowledge of how the manual process worked. When the automation failed, no one knew how to fix it manually. We started requiring that at least two team members understand the manual fallback procedure.

Another long-term cost is the opportunity cost of mentorship. The mentor's time is not free. A staff engineer spending one hour per week on mentorship is one hour not spent on other high-leverage activities. We had to be intentional about which mentors we asked to participate and how we balanced their other responsibilities.

Finally, there is the risk of automation becoming a crutch. Teams that automate everything without understanding the underlying process may miss opportunities to simplify or eliminate the process entirely. Automation should not be a substitute for thoughtful process design.

When Not to Use This Approach

The automation-first mentorship is not for every situation. We learned to recognize conditions where it was unlikely to succeed.

First, if the team is already stretched thin and cannot spare time for mentorship, the program will fail. Mentorship requires slack. Without it, both mentor and mentee will feel pressured to cut corners, and the project will suffer.

Second, if the organization does not have a clear staff engineer career path, the program will feel pointless. Mentees need to see that the work they are doing leads to a tangible outcome — promotion, recognition, or new responsibilities. Without that, motivation drops.

Third, if the automation project is too complex for the mentee's current skill level, it will overwhelm them. We learned to assess the mentee's readiness and choose projects that were challenging but achievable. A project that requires deep knowledge of a system the mentee has never touched is a recipe for failure.

Fourth, if the culture does not value automation, the program will be an uphill battle. Some teams prefer manual processes because they feel more in control. Trying to force automation on such a team will create resistance and resentment. It is better to start with a small, low-risk project that demonstrates value.

Finally, if the mentor is not committed, do not start. A reluctant mentor will do more harm than good. We learned to ask for volunteers and to give mentors a clear description of the time commitment and expectations.

Open Questions and FAQ

We still have unanswered questions about the program. Here are the most common ones we hear from other teams.

How do you measure the success of the mentorship?

We track three metrics: promotion rate of mentees within 12 months of completing a project, reduction in toil hours for the automated process, and mentee satisfaction survey scores. But we also look at qualitative feedback — whether the mentee feels more confident and whether they are taking on more leadership roles.

What if the mentee is not ready for staff engineer work?

Not every engineer wants to become a staff engineer, and that is fine. The program can still be valuable for developing technical leadership skills, even if the mentee stays at the senior level. We do not push anyone into the program; we let people self-select.

How do you handle conflicts between mentor and mentee?

We assign a third person — usually the mentee's manager — to act as a mediator. If the conflict is about technical direction, we let the mentee make the final call (with guidance). If it is about communication style, we have a frank conversation and, if needed, reassign the mentor.

Can this work in a remote-first organization?

Yes, but it requires more intentional communication. We use shared documents, regular video check-ins, and asynchronous code review. The key is to over-communicate and to create opportunities for informal conversation, like a weekly "coffee chat" between mentor and mentee.

What is the minimum time commitment for a project?

We found that projects shorter than six weeks did not provide enough depth for real learning. Projects longer than six months risked losing momentum. Our sweet spot was 8–12 weeks, with the mentee spending about 20% of their time on the project.

Summary and Next Experiments

The automation-first mentorship at hqblx has created a pipeline of staff engineers who are not only technically strong but also skilled in communication, stakeholder management, and systems thinking. The key ingredients are a real, painful automation project, a mentor who coaches rather than does, and a clear link to the promotion path.

If you want to try this approach, here are three specific next moves:

• Identify one manual process that your team complains about weekly. Estimate the time it consumes and the impact of automating it. Use that as the candidate project.
• Recruit one mentor who is respected across teams and willing to commit one hour per week. Brief them on the coaching-only rule.
• Set a 12-week timeline with a mid-point review and a final presentation. Make the presentation a public event to give the mentee visibility.

We are now experimenting with shorter, two-week "automation sprints" for smaller projects, and with cross-team mentorships where the mentee works on a project outside their immediate team. Early results are promising. We will share what we learn in a future post.