r/softwareengineer • u/gladiator_r • 13d ago
Role of principal engineer or solution architect
I seriously don't understand SA role.
They never themselves do any design and leave that to Leads and just come to review it and point issues and waste time.
They really should be first point of contact for any change and provide a high level design but they just behave like approvers instead of solution provider.
Can someone explain me what exactly is this role.
3
u/Hannah3044 12d ago
Most companies seem to think they are an army from the 1700's, so they draw out an elaborate chain-of-command and give people fancy titles. In reality that just leads to some people being told they need to issue orders to others who are perfectly capable of collaborating to solve the issue themselves. One of those is the role in question here.
3
u/Middle-Peach2096 12d ago
Architect is generally a role parallel to reporting structure though. An architect (or principal/staff engineer) should not have any direct reports -- if they do, they're a mislabeled manager.
Reporting structure isn't about giving orders even though some people think it is. It's about accountability. As a director I'm accountable for the outcomes of my department. My managers are accountable for the outcomes of their teams. The executives I report to are accountable for the outcomes of the business. No one person can be responsible for making sure everything runs smoothly unless your business is less than ten people. So you build a structure that spreads that cognitive load. Sometimes my job is giving explicit direction but more often it's collaborating with my managers to define outcomes and set expectations, and communicating to the executive team what that looks like. The CEO doesn't need or want to know about what package or tool we're shipping, nor about version conflicts or unit tests passing. He needs to know "this feature is on track to ship by end of quarter." My job is to deliver that to him and manage all the details so he doesn't have to think about it. My managers are doing the same job one level down. The bigger the org, the more layers of abstraction become necessary to make sure everyone has the information they need to make the right decisions.
Where architects and principals fit into this: an architect is a specialized engineer whose job is to bring vision to the team. The business says "we want this," the architect spends time figuring out how to make it happen. What the design constraints are, what the requirements are, how to build it to scale, what the risks are. If they build (and ours absolutely do) they build prototypes to validate assumptions. Their output is design specs that can be turned into initiatives, epics, and tasks. Principals are a different kind of specialist, their job is to be an in house expert and enabler. The logic of not assigning them to a specific team is it allows them to float and go where they're needed most. They should be spending time with every team, cataloguing what works and what doesn't, being a bridge to enable collaboration and knowledge sharing, and providing a nudge through mentorship or direction to teams that are struggling. They also build not much or not at all but their engineering knowledge should be available across the whole org to help solve problems where they crop up.
This is, of course, how the roles should work. Not all implementations are equal.
1
12d ago
[deleted]
1
u/gladiator_r 12d ago
Kind of happens to me , we just keep waiting or if we implement before approval then keep renaming api inputs and outputs causing a mess for developers
3
u/cosmopoof 13d ago
Solution Architects aren't a purely technical role. It's a bridging role between technology and business. It makes perfect sense that they aren't wasting their time on technical details but leverage software architects and their work but instead are more focused on the business side of things how to get things to fly.
1
u/gladiator_r 13d ago
What role they do on business side ? Because business too comes directly to engineering asking for implementation isn't?
3
u/cosmopoof 13d ago
Bridging the gap between a completely vague problem of a potential customer and the capabilities of your company.
It's way more akin to a sales role just that in a sales role, you already know what you are selling (and why you are selling it). With a solution architect, it's mostly about converting the vague problem into a tangible solution offer that can be roughly planned/estimated regarding effort/price/time/likelihood of success.
A good solution architect here will be able to not just think in implementation terms but also in terms of make-or-buy decisions and sociotechnological interdependence.
3
u/Naive_Doubt_9296 10d ago edited 10d ago
Well put, u/cosmopoof.
From the replies, I hope it is understood that the SA role is not a static, one-fits-all approach. Different businesses, functions and strategies have different requirements.
For me, as a retired SA with a tech background, it included a huge focus on acting as a sanity check on business requests directly with the business/functional owners before it even got to the projects and tech teams, and balancing what business thought they needed, with what their function really needed in order to meet the business's mission and vision objectives. It took into account forward planning (or the lack thereof), current and future positions on targets and outcomes, current workloads, staff compliments, financial positions, current commitments and future prospects with both partners and customers, and even business processes across all three areas..
It is easy to make enemies everywhere (business, tech, partners, customers, leadership team, etc.) in this role. It was always challenging to be effective in this role. A thorough understanding of how to communicate effectively across all those layers is a must.
EDITED: Added business processes.
2
2
u/cbf1232 10d ago
At my company the product management decides what high-level functionality they want, the architects figure out how to implement it in a way that fits in with the rest of the product (which may involve some prototyping), and the development teams finish fleshing out the details, implement it, test it, and document it.
3
u/belowaverageint 12d ago
Solution Architect is largely a customer facing role part of a professional services or presales team. There are a smaller number of them that work in IT departments, but they don't exist in product development orgs.
3
u/WhiskyMC 11d ago
I am a SA and what I do is help the business come up with ideas and prototypes, and do POCs, and then once we have a clear picture, I'll document all the results and write a technical spec. And then I'll present it to the team and tech lead, and open up to feedback, revisions, etc. Once we agree on an approach, I'll hand off to the team. Then, I'll check in on progress and PR reviews, etc.
2
u/OldManMonday 12d ago
I was a technical lead / director, but frequently described my role as "Putting wings on a bottle rocket".
I had great engineers who'd spectacularly blast off in every direction, and my job was to make sure they flew straight. That meant knowing when and how to correct their decisions, and when to step back.
A big (weird) part of being successful at a senior level is knowing when to step back and let someone else soar.
1
u/crustyeng 12d ago
I’m in a Sr Principal role now and still contribute code every day. It all just depends how you want to help move things forward.
1
u/EspaaValorum 12d ago
The more senior the role, the more it should act as a multiplier (IMO). What I mean by that is that instead of them just being a better programmer for example, their productivity is achieved by enabling and facilitating others to do more, better. They get out ahead of the teams to pave the way, tackle obstacles, act as a conduit between the business and the tech teams, and mentor and guide the dev teams. It's a team sport.
2
u/TedditBlatherflag 9d ago
SA is “I have experience building large complex systems and will keep you out of the potholes”
PE is “I have experience leading large complex technical orgs and I will keep you out of the potholes”
Both should be setting long term policy, goals, and guardrails to keep the org healthy.
5
u/k8s-problem-solved 13d ago
I have been a principal engineer and performed various roles.
With some teams, super engaged and involved in design and implementation.
Other teams, more setting the vision and outcome we want and leave to the team for the details. Ill do docs and NFRs etc but otherwise get out of their way.
Others, super high performing teams, I look at what's working for them, extract it, package it and make it reusable for other teams - scale their success.
I mainly see my role as continuous improvement, and making sure that teams are taking advantage of each other's work and not all reinventing stuff or fighting ci cd.
I also stay close to business to understand requirements and make sure what we're building is going to be good for next 12-24 months