I started as a developer writing Apex, Visualforce and integrations. Over nine years the job changed from "build this feature" to "decide how this should be built, and help the team build it well". Leading a ServiceMax to Field Service conversion with four developers and a QA, and working onsite with a client in the US, taught me most of what I know about that shift.
1. Your output is decisions, not code
As an architect, the most valuable thing you produce is a clear decision: which object models the data, where automation lives, what is configured and what is coded. Write decisions down with the reason and the alternatives you rejected. Six months later, that record saves days of debate.
2. Design for the people who use it
The best data model in the world fails if a technician cannot complete a job on a phone with no signal. Spend time with the end users, whether dispatchers, technicians or sales reps, before finalizing a design.
3. Make the team faster, not dependent
- Run short design walkthroughs before development starts, so everyone understands the "why".
- Use code reviews to teach patterns, not just to catch bugs.
- Give QA the acceptance criteria early. Good testers find design gaps, not just defects.
4. Communication is part of the architecture
Regular, honest updates to clients and stakeholders, including bad news early, build the trust that lets you make the right technical call when it matters. My onsite visit taught me how much faster problems get solved face to face.
5. Keep learning in public
Certifications such as Platform Developer, Service Cloud, Field Service, Data Cloud and the AI credentials gave me structure for learning, and writing posts like this one forces me to understand a topic well enough to explain it.
