What kind of builder are you?
Same word, different meanings and realities.
“Builder” is part of how I describe my job and The HRBP Lab. I’m a builder. I build work, processes, org designs and playbooks. Sometimes that’s reality and sometimes it’s aspirational, a mindset shift from traditional “HR” work.
There’s also a technical meaning of the word. We can all build, in the sense of making and creating. But building an app or a capability that lives in enterprise infrastructure is very different from building a new org design. Same word, but different meanings and realities in different parts of the enterprise. It’s a topic that comes up a lot in my day to day.
So I made a map.
The world of builders is bigger
To simplify, I think about it as eight kinds of builder, in two rows. The top row builds in the business: org and process, personal AI, no-code makers and prototypers. The bottom row builds the technology: software engineers, data and AI engineers, enterprise systems teams, and the platform and security people protecting employee data.
HR can have people in every box. Most HRBPs (at least right now) build in the top row.
Zooming in: five kinds of builder
All five are building. What changes is what it touches and who depends on it.
- Org builder. Org designs, roles, playbooks, used by the business. Your role: own it fully. This is building, and nobody should talk you out of the word.
- Personal builder. Prompts, projects, personal automations, used by you. Build freely, with approved data only.
- Prototype builder. A working demo that proves a need, used by a few people, briefly. Label it a prototype.
- Governed builder. Tools on an approved company platform, used by a team. Follow the rules and name an owner.
- Production builder. Enterprise apps and agents, used by thousands. You’re the product owner, not the coder.
Left to right, the material shifts from people and decisions to enterprise infrastructure.
Where it gets tricky
The hard part is the jump from 3 to 5.
This is critical to remember as an HRBP: walking in with a prototype is not the same as doing a full requirements intake and overview session. It’s not the same as developing, launching and maintaining a tool in an enterprise environment, either.
A prototype is a visual representation of the outcome. It’s not the full set of requirements. Making an artifact in an AI assistant is not the same as a production build, and using a lot of tokens isn’t building. The assistant makes you feel like an engineer.
The trap runs the other way too. Engineers can dismiss the org builder as “not real building.” It is. The difference is how many people depend on it and what it touches.
Why this matters if you’re an HRBP
HR has to go into these conversations acknowledging its place in the ecosystem, and being humble enough to say: hey, I built this prototype, but I know enough to know that I don’t know everything that goes into actually making it live. In production. Usable, scalable and secure across an enterprise-level environment.
I’m going to create a prototype, or MVP the idea. But I still need enterprise-level support and resourcing to make it a viable tool in the environment. This is an idea, and I know there’s a lot more that goes into it. I’m open to that negotiation and conversation.
Experiment anywhere. Deploy through one door. Gate the data, not the experiment.
So, now what?
You have an idea, maybe even a prototype. Here’s what I suggest you do next.
First, place what you built on the map. Before you show anyone, answer five questions:
- Who uses it besides you?
- What data does it touch?
- Who fixes it when it breaks and you’re on vacation?
- How long does it need to live?
- What happens if it’s wrong?
If the answers are “just me,” “nothing sensitive” and “not long,” you’re a personal builder. Build freely. If the answers start to include other people, employee data or “it has to keep working,” you’re heading toward 4 or 5, and you need a partner.
Second, if you’re already going into the conversation, use AI to prep for it. Hand it your prototype and ask it to play the other side of the table: pretend it’s an enterprise product and engineering team, and tell you what it would take to actually implement this. But have it explain it to you as if you were an HR person. Use AI to explain something to you in a way you’d understand.
The “what would it take” prompt (run it before the meeting)
Here’s a prototype I built: [PASTE THE HTML, A SCREENSHOT, OR A SHORT DESCRIPTION OF WHAT IT DOES AND WHO USES IT].
Pretend you’re the enterprise product and engineering team at a company of [SIZE]. Give me a summary of what it would take to actually implement this in production: data access and security, integrations with our existing systems, testing, who supports it after launch, and a rough sense of effort.
Explain it to me as if I were an HR person. Plain language, and define any technical term in one line the first time you use it.
End with the three questions your team would most likely ask me, and what I should bring to answer each one.
You walk in knowing what you don’t know. That’s a better opening than a demo.
Which box are you building in right now? And which one are you about to walk into? Hit reply. I read everything that comes in.
-Josh
If someone you know is about to walk a prototype into a room, forward this their way. New here? Subscribe at thehrbplab.ai to get the next one.
