Highlights
- A vast majority of Salesforce Architects who responded to the SF Ben Salesforce Architect Survey 2026 said that they perform hands-on work on a consistent basis.
- Many Architects previously sat in hands-on roles, and it can be easy to fall back into “old habits”.
- Trust can be a problem as well, and there are tools that can help Salesforce Architects avoid unintentional micromanagement.
- AI has been a positive for builders but introduces new challenges for architects. Documentation is more important than ever.
Our upcoming SF Ben Architect Survey 2026 (jump to pre-registration) revealed that quite a significant majority of surveyed architects perform hands-on work on a consistent basis – as many as 92.2%! I found this quite interesting, because the general consensus is that architects tend to be off the tools and stick to design work where they can.
Sure, the occasional bit of hands-on work here and there may be required, but I expected this would be inconsistent and far rarer than the numbers are showing. This is something that I believe will shock many readers of the report as well.
In this article, I’ll explain why this may be the case, some boundaries that you can put in place to ensure you’re solution-focused, and tools to use to help protect those boundaries.
Why Architects Are Being Pulled Back on the Tools
When I think of a Salesforce Architect, there are two types that I think of. Firstly, those who have previously been admins, developers, or consultants, and have moved into an architect role. Secondly, those who were architects in other domains and have moved into the Salesforce space.
Of these two, those who have previously been in a more hands-on role in the Salesforce space are far more likely to jump back on the tools, as it would be second nature after years of working daily with Salesforce. The occasional “I’ll quickly do this part myself” quickly turns into remaining the go-to Salesforce configuration person.
As an architect, you are trained on and have experience with designing and solutioning enterprise architecture using Salesforce tools. Something many architects may not be trained on very much is formal leadership or delegation training. This makes the path of least resistance building yourself, rather than assigning tasks to others in your team (or beyond).
This, while not the sole reason, makes it difficult for architects to sit purely as strategic designers and stick to the planning. Creating boundaries, having them respected by the team, and ensuring that you also stick to them yourself is critical to staying away from building Salesforce yourself.
Staying Technical Without Building
The reality is that Salesforce Architects are extremely skilled, technical people. They understand deeply and intimately how Salesforce works and are familiar with how to configure it correctly. They’re knowledgeable about best-practice design and how to reduce technical debt in large-scale projects. All of these are valuable, and at times it may feel like building things yourself is the only way to ensure that things are done right.
In the world of agile development (even when leveraging hybrid waterfall/agile methodologies), it often isn’t as simple as putting together a design and handing it over to a team to build. Expecting a project to play out this way is foolish, as any architect will know. So, what’s the solution? What’s the correct way to look at the Salesforce Architect role?
When building a house, you wouldn’t get the house designer to also lay the bricks, pour the concrete, or connect the power. There are specific roles for each of these tasks, and none of these tasks falls into the domain of the designer. I’m not saying that the designer can’t build; I’m just saying that it’s not something you would expect them to do. Salesforce Architects should be seen in the same way. They design the Salesforce solution, identify all the moving parts that need to be built, and help in assigning those build items to the right resources.
Just as a house designer will be involved throughout the building process by reviewing what has been done and ensuring it follows the original design, Salesforce Architects will continue to flex their technical muscles by keeping the build aligned with the design. They may also update the design and plan if changes need to be made, but it should not be expected that Salesforce Architects actually perform the building themselves.
Salesforce Architects may be responsible for several other items that are deeply technical, such as leading or co-leading code reviews with the development team, working with build teams to have new features tested or demonstrated in a PoC format, or working with development teams to diagnose issues from error logs. That being said, they will typically be involved in these from the perspective of an overseer providing advice and guidance rather than the hands-on resource doing the build themselves.
Goal-Oriented Delegation Mastery
To protect yourself from falling into the trap of building, you, as a Salesforce Architect, need to master task delegation. You should make sure you’re assigning the ‘what’, the build itself, to other members of your project team. You can then remain fully in charge and plugged in to the ‘how’. Your job should be to clearly define the system constraints, outcomes, and performance metrics. You can then entrust the execution to those who are assigned to build on the project.
If you’re coming from the perspective of someone who has extensive experience working on Salesforce in a more direct capacity, you may find yourself falling into the trap of micromanaging or failing to delegate as you’d prefer to do the work yourself. I’m not judging anyone here, as I personally have fallen into this trap many times in my professional career (my wife would likely tell you I do this in my personal life as well).
To help avoid this pitfall, you should take a step back and put some new practices into place. Instead of micromanaging, you can manage the delivery output through structured tooling such as a risk register, clear specifications, and setting strategic checkpoints.
This allows you to be clear about what is required from your design and set the standards in terms of build quality and longevity, avoiding technical debt, without relying on yourself to build. Communicating these specifications with your team and making sure you give them the space they need to build will help you step back and remain a strategic resource.
Guarding the Boundary in the Agentic AI Era
With artificial intelligence becoming more and more prevalent in the Salesforce ecosystem, the question of how it impacts each job role is of utmost importance. As a Salesforce Architect who has likely worked with AI tooling, you’ll know first-hand that while AI may speed up execution, it has the opposite effect on architecture. There are more unknowns to consider, more edge cases, and governance becomes more critical than it has ever been. A human being who understands the project deeply is still required to ensure the build remains compliant with the design.
Verification is key in this new world. AI agents can speed up building and development workflows, but they can also introduce new issues or miss requirements entirely. Remember that AI doesn’t think the same way a human being would, and as such its output may not be quite what a human being would expect.
Properly documented constraints help provide AI tools with the context that they need to build effectively and do it right the first time (or, in fewer iterations). Documentation, as painful as it is to build, is critical as well, as it ensures that both humans and AI tools have the necessary context to get the job done correctly.
Summary
Salesforce Architects play a critical role in ensuring projects are designed to meet stakeholder requirements, and it is imperative that they are able to focus on their strategic designs rather than being dragged onto the tools again. Building boundaries as an architect helps to ensure this is possible, and understanding how to leverage various tools to empower other team members helps as well.
Have you struggled to avoid the build work as a Salesforce Architect, and if so, what have you put in place that has helped you move into a more strategic role?
Don’t forget to read our official SF Ben Salesforce Architect Survey Report 2026. Pre-register now to receive the report as soon as it’s live:
