Recently, I have been helping my team hire a few people with deep technical experience. That made me think again about two articles I read years ago. Their ideas came back because hiring the right people can fill gaps in the areas I work on and give the team room to take on more ambitious problems.
More precisely, I work across GPU incidents, developer productivity, and infrastructure components, provide technical guidance in those areas, and help my team find the people it needs. I am also exploring what future AI Infra work may require.
In these areas, I join technical discussions, review designs, help analyze incidents, and share what I have learned. I also offer advice when an important technical decision needs another perspective.
I used to think hiring meant posting a role, screening resumes, and scheduling interviews. After taking part in the process, I realized that it is closer to systems work: first understand what is missing, then find someone who can fill that gap. A polished job description is not very useful if it does not explain the actual problem and its boundaries.
Two old articles that came back to me
One article is about team management. The other is about spending two years getting to know a candidate. Together, they point to the same idea:
Make the goal clear first, then let real work reveal how people think and operate.
In hiring, that means explaining what the team is missing and what problem needs to be solved. In day-to-day guidance and collaboration, it means making the problem, boundaries, and reasoning explicit, then letting the person responsible keep moving.
I work in a domain and help guide the work
The things I work on may look separate, but they usually connect. A GPU incident reveals a problem. A repeated problem may become a diagnostic tool or an infrastructure component. Developer productivity determines whether the fix moves through the organization without unnecessary waiting. Those real problems also give us better questions to ask about future AI Infra.
GPU incidents: understand the failure and make it less likely to return
GPU incidents are the most concrete and operational part of my work.
When a node fails, a job crashes, or training stops, I look at logs, metrics, context, and the impact before deciding where the problem actually sits. Recovery is only the first step. I also want to know why we did not detect it earlier, whether it can be diagnosed automatically, and how the next person can handle it faster.
A GPU incident is the problem itself. If the same failure keeps returning, I do not want to fix it by hand forever. The investigation may become monitoring, a diagnostic tool, or a reusable component.
Infrastructure components: keep the solution usable
Infrastructure components are where those solutions become durable.
A component is not finished just because it runs. Someone has to be able to use it, observe it, roll it back, upgrade it, and understand what happens when it fails. I focus on shared capabilities connected to GPU incidents, infrastructure operations, and AI Infra, such as monitoring, diagnosis, scheduling, automation, and service integration.
Business systems, vendor-side operations, and components owned by other teams still belong to their respective owners. I am not trying to own every piece of infrastructure.
Developer productivity: remove friction from the path to a fix
I think about developer productivity in very practical terms. When a problem appears, does someone pick it up? Does the context reach the people who need it? Can engineering, operations, and other partners see the same facts? After the fix, is there a verification step and a retrospective?
If every handoff requires another round of questions, waiting, or manual synchronization, the incident may be fixed while the overall process remains slow. Tools and process should make that path shorter and clearer.
Future AI Infra: explore what is not settled yet
Future AI Infra still has more questions than answers.
New compute shapes, training and inference infrastructure, and scheduling models may change how we use resources and handle failures. The useful response is to look, try small experiments, and decide which directions deserve more investment. An idea that has never met a real incident or delivery constraint is still only an idea.
Put simply: GPU incidents show where the problem is, components preserve the solution, developer productivity helps the solution move through the organization, and AI Infra exploration uses those real problems to find the next direction.
In these areas, I join technical discussions, break problems down, review designs, and pass on experience. I also offer advice when an important technical decision needs another perspective. The project owner and system owner continue to drive the work.
Make the boundaries clear before starting
When I work with someone on an important project, I would rather discuss the goal, boundaries, design, risks, and acceptance criteria before everyone starts typing. Otherwise, people can spend half the project discovering that they meant different things by “done.”
After that alignment, the person responsible should make the execution decisions. I can help analyze a technical issue, fill in missing context, and review what we learned afterward.
Align before execution, support during execution, and review afterward.
Real work reveals more than training does. A person grows through handling an incident, driving a cross-team change, or continuing to investigate when nobody has an immediate answer.
The people I am helping my team find
I am mainly helping my team look for people working on AI Infra, GPU clusters, platform engineering, and incident automation.
I am not looking for someone who knows every part of the stack. I would rather understand which capability is missing, then find someone who can go deep in that area and still understand the systems around it.
When I talk with candidates, I want to hear about work they have actually done: what evidence they checked when a GPU node failed, how they narrowed the search, whether a repeated incident became a monitor or component, how they moved context across engineering and operations, and whether they can turn an uncertain AI Infra idea into a small experiment.
Interviews only show part of that. Working together for a while shows whether someone can bring up the environment, take ownership of a problem, keep digging when the answer is unclear, and leave behind a tool, document, or more reliable way of working.
What I can contribute to the hiring process
I am not the person who makes every hiring decision. I can explain the domain problems, break down the technical work behind a role, and take part in project deep-dives and technical judgment.
I cannot promise that every project will be easy, or that every judgment will be right. I can make the context clear, discuss the real problems behind the role, and give direct feedback on designs, project experience, and troubleshooting approaches.
These things are still moving. It is difficult to make them deep by carrying everything alone. Finding strong people to work on hard problems together gives the team a chance to close the gaps and build things that were previously out of reach.
If you work on AI Infra, GPU clusters, platform engineering, or incident automation, I would rather hear about the hardest problem you have actually solved than read a resume full of keywords.
Further reading
- A Few Thoughts on Team Management: The sections on ownership, team depth, and Tiger Teams were especially useful.
- How to Spend Two Years Interviewing One Person: It made me rethink resumes, real work, and long-term observation.
Comments