Acting as the architect without the authority
Posted by nettrotten@reddit | ExperiencedDevs | View on Reddit | 70 comments
I work on a team with no clear technical arch ownership. Decisions that affect the whole system get made in small conversations without enough context.
I often see the problems that one decission can lead to early than others and say it, but it gets ignored until it breaks.
Then I get pulled in to participate inna lot of meetings because I have the full context usually, so they need my criteria.
I end up doing architecture work without the role or authority, and when I speak up I get jokes about being the “first of the class.”
It’s frustrating to be relied on when things go wrong but not heard when it matters.
I'm really frustrated rn
MaleficentCow8513@reddit
Proper ADR procedures would solve this
PositiveUse@reddit
Then go to your boss and get the authority or promotion. Make sure to document all decisions correctly, do your architecture work and present them to your boss.
gibdimkoofchji@reddit
Authority doesn’t come from your boss.
It comes from your colleagues trusting your instincts because you’ve repeatedly demonstrated competence and you effectively communicate the reasoning behind your opinions on these things
engineerFWSWHW@reddit
However, i would argue that there are some people who are hard to work and with and even if you demonstrate competence, some won't listen because you are in the same hierarchy/title.
I had been on the same/worse situation. There are times that i had demonstrated competence than the senior on my previous job, but because i don't have the senior title, my suggestions are overridden. Then time will come that they will say that I'm right and why we didn't do my suggestion. It demoralized me and i made a move to another company with priority on the job title and it was a great decision.
PositiveUse@reddit
Correct
gelatineous@reddit
Draft an RFD for a new process.
lokaaarrr@reddit
Granted authority is rarely effective.
I suggest you sketch out an open, light weight design process. With guidelines for when it is needed, and how it works. Focus on being very light weight and fast, but still transparent. Things move ahead when the team is informed, and there are no longer strong objections. The plan and resolution get recorded in a central location.
Don’t give yourself any special role. See how it goes for 6 months.
PositiveUse@reddit
You’re absolutely right. What I thought was more like „get the backing so people don’t laugh at you“ but you’re absolutely right. If you introduce light weight processes that really benefit the teams, then it will carry more weight than anything else.
nettrotten@reddit (OP)
Im not the responsible of design those, we have a tech lead and a PO who does.
lokaaarrr@reddit
Be of service to the team
nettrotten@reddit (OP)
My boss is Ok with the situation.
ZunoJ@reddit
Then either live with it or change jobs
nettrotten@reddit (OP)
I know, I recently switched It.
johnpeters42@reddit
You recently switched to this job? If so, then maybe you haven't done enough to convince the others that they'd be better off letting you make these calls.
nettrotten@reddit (OP)
Yeah. I did, but I think they dont need to propose any promotion because I'm always there anyway
diablo1128@reddit
I have no real advice for you, but I worked on a team where it was basically architect by committee. That is to say management wanted the software team to "own" the design themselves. This lead to lots of I think we should do it this way and somebody disagrees and thinks it should be done that way.
At the end of the day I just stopped caring if I had no responsibilities in that part of the code. I et the people that had skin in the game hash it out even if the outcome as something I found suspect.
When I did have responsibilities then I just approached it with an open mind and picked my battles carefully. If I could not show there were actual issues then I would generally let it go, even if it didn't optimize for the things I thought was more important. I knew the other person was going to dig in to their stance because that's what everybody did.
For example one time it was decided that that subsystem A was going to get a a large refactor / rewrite. A constraint was it would take many months to get it all done and subsystem A couldn't stop working. So I suggest using the Strangler Fig Pattern such that we could migrate functionality over slowly and get the benefit of using the new design sooner than a all in one big bang approach.
Well people said it would make the code too complicated and had every excuse in the book. They vehemently vetoed doing it that way so much that I just gave up and let them deal with their choices. The big bang rewrite never got done and they eventually just delt with the poor design of subsystem A.
Who knows maybe even using the Strangler Fig Pattern it would only get half done and now SWEs had to support both ways of doing things for eternity. So yeah working on safety critical medical devices at private non-tech companies didn't allow me to interact with the best SWEs in the industry, lol.
nettrotten@reddit (OP)
I can’t just let things slide naturally, it doesn’t come to me.
It’s stronger than me. Why not say it? Why not fix it when you see the problem? Why adopt that passive attitude? I don’t understand it and I don’t want it for myself.
diablo1128@reddit
I see it less as letting things slide and more let people fail and maybe they will learn something. If they are not going to listen to what I have to say I'm not going to waste my time arguing about it. I say my piece and if they don't want to listen that's on them.
nettrotten@reddit (OP)
Yeah, I get what you’re saying, but even if I try to not care and think fine, if you don’t listen, it doesn’t matter,” the problem is that later that decision ends up breaking for some reason, and I’m the one they come to.
Imoa@reddit
Decline to fix small issues they bring on themselves and prioritize your own work. It sounds like they keep you busy, so for non-critical issues just decline because you’re too busy with other work, and link them appropriate resources.
For critical issues, put out the fire and then get the team together in a call and put it back on them. “I fixed X issue Y way. Issue X occurred because of Z root cause, which is systemic in nature. What are you going to do to make sure this doesn’t reoccur?”
Massless@reddit
Where I work, I explicitly don’t have authority and I’m expected to lead with influence. Being right is necessary but not sufficient.
Cultivating influence involves a lot of human relationship/trust building so your voice carries weight. It’s also about having the relationships in place so you know who to tell to get the best outcomes
Imoa@reddit
A part of this is understanding why things are the way they are. People don’t go around making bad decisions for the sake of it.
If you’re right and people push back, try to understand why. Being able to articulate why the current approach is problematic, how your method is better, and demonstrating that it either doesn’t cause anyone extra work or that the extra work is necessary - they’re all communication skills that matter.
Like you said, being right is necessary but not sufficient. Reddit gets mad about it, bitches about it, and loves to focus on just being right / having the most right answer. In reality that’s just the beginning, and it’s not other people’s fault if you’re incapable of communicating why you’re right convincingly.
nettrotten@reddit (OP)
Yeah, its a good point of view, but there are decissions that need senior criteria, not a 1h 30 call, a crash or a blocking problem snd then me rethinking it alone.
znick5@reddit
The comment is right. Even with an official title you will be working with other teams sometimes and you won’t always have authority.
Take in context, have an opinion, and speak to your opinion confidently with supporting evidence. This is how you take control of situations where there is no direct lead. The other members who are less informed or less confident will follow.
And finally, know how to lose. Sometimes others will have just as strong of an opinion as you. You have to make judgement calls about the situation and decide if conflict is worth it. If it’s not, gracefully bow out and get on board with their plan.
Often having the most optimal perfect plan is not a requirement. A good enough plan that everyone is on board with is usually sufficient.
Massless@reddit
This is all pretty reactive. The point of my comment is that you lay the interpersonal foundation so “when I speak up I get jokes” becomes “when I speak up, people stop and listen”
nettrotten@reddit (OP)
Yeah I get you, Its a good advice, thanks
lokaaarrr@reddit
Yeah, somehow forcing the team to listen to you won’t accomplish what you think it will :(
Aleks_Zemz_1111@reddit
I've seen this pattern in 16 different workplaces, from roofing to high precision industrial presses. If the boss ignores a leak in the roof, you don't keep putting buckets under it. You let it rot.
When your team makes casual decisions without context, they are betting that you'll be the one to fix the fallout later. You are subsidising their laziness with your own sanity. They mock you as top of the class because they need to keep your status low so you don't demand the authority that matches your responsibility.
In the factory, if my machine tolerances are off, I don't guess. I stop the run. You need to stop the run.
The Actionable Commit: Stop knowing the answer for them. Next time they push a half-baked decision, send one cold email similar to this: "This decision creates X risk. I am not available to fix the consequences when this fails."
Then walk away. Use the time you save not fixing their predictable failures to build your own asset. Why rent your brain to people who treat your expertise like a joke?
Material-Smile7398@reddit
What has your manager said about the situation?
nettrotten@reddit (OP)
They have no problem.
I started to point to this lack of a more centralized architechure decission process and I got a "its democracy" message and a Hitler meme.
Independent-Newt2009@reddit
Kinda based tbh, they won that interaction
nettrotten@reddit (OP)
🤣
Independent-Newt2009@reddit
Sorry that does sound frustrating though, I basically keep notes and backup documentation or project plans even when leadership rejects my ideas.
During the bugfix or postmortems I usually bring up the project plan doc on a shared screen, to demonstrate a possible solution in the future. I do this very diplomatically and I haven’t been fired for it yet, I have probably done it 10 times in the last couple years when I was right but they ignored me
clickrush@reddit
That’s not how democracy works. Democracy has processes for decision making, conflict resolution, and for raising issues. It’s about sharing responsibility and fair representation.
What you describe is ignoring responsibilty when making decisions and then exploiting those who can patch over them.
CodelinesNL@reddit
This is so disrespectful.
thy_bucket_for_thee@reddit
Unless this is a literal workplace democracy [1], please smack your manager in the head for being a bellend for me please. Something tells me if you start openly talk about unions that suddenly this democracy becomes a real animal farm quickly.
[1] https://en.wikipedia.org/wiki/Workplace_democracy
Just-Ad3485@reddit
That’s ridiculously unprofessional
gadfly1999@reddit
Sounds like you got the go-ahead to stage a Reichstag Fire in your org.
dbaeq90@reddit
Hitler meme? Seriously?
nettrotten@reddit (OP)
Yep, seriously.
And its not the joke what bothered me but the lack of vision related to our architechure decission process.
ClideLennon@reddit
Document, document, document. This is definitely not appropriate. It could constitute a hostile work environment.
Material-Smile7398@reddit
Ok, thats pretty disappointing, it sounds like you are working with 12 year olds.
I think you may have to pull back from helping when things go pear shaped, although it may be not in your nature to do so. Meanwhile maybe polish up the CV with the work that you have been able to pull off.
Best case scenario, they make you team Architect, but it seems like your colleagues like to push back because 'not their idea' so you are never really going to win, unless your manager actually decides to support you.
nettrotten@reddit (OP)
Its all on my CV, take that for sure.
Yep I'm really not looking for the position actively, but its my role..
johnpeters42@reddit
Godwin's Law, whee
CodelinesNL@reddit
I was pretty much in this position in my previous role; implicit architect "lead" together with another engineer. They even had plans to make it "explicit" eventually, but the non-technical managers who could make that happen, chickened out, because they had a very strict "top down" hierarchy in that organisation and everything we wanted to accomplish, we needed to do so through (almost unanimous) approval between all 5 teams in our department.
We did get quite a lot done by setting up "guild meetings" where we together showcases ideas to get people on-board. But we only had a carrot; not a stick. We were explicitly told that we were not allowed to "police" teams. So when they flat out ignored sensible rules (like versioning external APIs), that led to actual customer impact (prod broke because they ignored schema testing), management was still to chicked to allow us to enforce these systems.
Same. And I only noticed how much it did, when I left that role. I'm not the "head" of our entire engineering department, still almost always build structure through consensus, but I also have the mandate to well...mandate things when needed.
I'm a "servant leader" 99% of the time, I've been doing a lot of the shitty work modernizing our CI/CD so the other devs don't have to, but every now and then I need to say "no, we really need to do it this way".
xelah1@reddit
Distinguish 'authority' and 'leadership'.
You want authority because you see having and using power as the way to get things done, but it's often a bad way to get things done.
A leader is (by definition) someone who has followers, people who freely choose to be influenced by you without being forced. This is much better because people will incorporate your ideas into their thinking, adapt them to their context, ignore or challenge the stupid stuff you come up with, etc.
You don't need a lot, you're not trying to be the next Gandhi, Hitler or Jesus and you're not even trying to be thought of or called a leader, just get boring things done in a narrow corporate sphere.
I'm no expert on the behaviours needed to make this happen, but at the very least you're going to need demonstrated technical competence and credibility and a level of trust from those people that if they choose to take your ideas seriously it'll work out well for them - not just technically but in terms of how they're viewed and how they feel about it.
Beware that corporatespeak heavily misuses the word 'leader' as a synonym for 'manager'. It's much more useful to see it as simply someone with followers as this really is qualitatively different and there isn't really another good word for it.
nettrotten@reddit (OP)
I’m not looking for authority nor chasing the role itself. You missed the point of the post. My decisions are already being adopted, but only after long discussions. And many times, things break, come back to me, and then either my original solution gets adopted or I have to come up with a new one myself.
So all that work ends up falling back on me, so they follow me.
That’s what’s actually happening, and that’s what I was trying to express.
saposapot@reddit
Having full team discussions on architecture and making a team decision seems fine and normal. Even encouraged I would say.
What doesn’t seem normal is you doing the work and then get mocked by it. Either you are just a participant on the discussion or if you are the lead on it or even the only one that can do it then you deserve the role. If that’s the case and your manager doesn’t want you to have the role, stop doing it.
nettrotten@reddit (OP)
The project started from 0, no previous code base, 6 months for an MVP.
When all started, I asumeD a lot of the design and decisions because of the lack of technical view, if the project fails, then I can get laid off, and is not gonna happen.
adhd6345@reddit
Encourage doing RFC docs
Person puts an idea in a doc that others comment on. It’s all visible, all the time.
rm-rf-rm@reddit
This is a common problem in the modern workplace.. My opinion is that orgs like this are going to get decimated with the advent of agentic coding
kagato87@reddit
Agentic coding accelerates these bad decisions. It will make them worse and, yes, push these kinds of companies into fafo territory.
Effective-Eagle5926@reddit
saw this from the PM side. the person fixing it usually flagged it first. anyone log the flag moment somewhere durable?
EgoistHedonist@reddit
I'm on the spectrum myself and feel that it comes with extremely good pattern recognition. It can definitely be a curse as you see the systemic problems before anyone else, and it's very difficult to communicate them clearly enough that others understand. This also works in politics etc and makes staying informed a hell during these times...
Sometimes the problem is that you're just not communicating well enough to get through, but more often it's that the others just don't care and feel intimidated that someone does and is right too, as it makes them look bad. I feel that you might be in the second kind of organization and there's not much you can do about it, other than leave.
Pristine_Crow6357@reddit
so devs are just traffic managers now huh
nettrotten@reddit (OP)
They are devs.
rcls0053@reddit
I hear you. I was the lead architect at a company where senior developers has absolutely no vision or understanding of modern development practices. Somehow everyone still treated me like any developer, and people came into meetings saying they're dismantling a service and merging it to the monolith because it keeps going down, but the reason it was down was because a downstream integration was unstable and they failed to know about circuit breaker patterns.
When I voiced my opinion that I can't do this job like this, having people just willy nilly going and doing architectural decisions without proper understanding and me knowing about it (so I can discuss it), the CTO just decided that instead of one there was now six architects in a team of 30 developers and one monolith.
Yeah, that was about the time I left the company because I realized my growth was gonna be capped there and this was no way to run a tech department. Sometimes people above you are just that incompetent.
nettrotten@reddit (OP)
I switched recently (1 year) so I need some time to think about switch again, but believe me I feel you too
trg0819@reddit
I've been an architect for 7 years and I've never had actual "authority". At best, if I wanted to get in a pissing match, if I reject a PR for architectural reasons, they have to complain to their boss's boss just because of different reporting structures. But I've only had to pull that card once with a real stubborn dev that wanted to turn everything into a pissing match.
Everything else is done through influence, not authority. Architecture is a type of thing that everyone should be involved with because it affects everyone. This requires explaining the problems and context at a broader level that devs only seeing their teams perspective might not have the opportunity to think about. Getting them involved with the discussion and working on solutions together. At best I'm a tie breaker when multiple solutions with relatively equal trade offs are difficult to chose between.
If one tries this approach and it doesn't work out the way you want to, it's either because you're not explaining your reasoning well enough, your reasons aren't good enough, or you're in the rare case where the entire rest of the team is a bunch of immature and difficult to work with people (judging from some of your responses).
Using authority alone to tell people "this is the way" doesn't work, because you can't be the sole gate keeper of everything to enforce the decision. You have to convince the rest of the group that it's also the way so that they're bought into the decision and self enforcing because they agree with it. If people don't agree or don't understand, forcing them to do something "just because" doesn't work out.
nettrotten@reddit (OP)
I often feel like what happens is that people get tired of my ideas being the ones that end up getting adopted.
It’s gotten to the point where I feel uncomfortable even giving my opinion.
I normally hold back and let others speak, but at some point I see things going in the wrong direction and I step in and say something like “I think this should be done this way.”
And most of the time I end up being right, and I think that creates some friction.
I just hope I’m not coming across as arrogant, but that’s honestly how it feels to me.
Skullclownlol@reddit
Adapt your work to your actual role/authority, or find a better job elsewhere.
Recent_Science4709@reddit
You have to find a way to not give a shit, and/or look for a new job. Most of us experience this to some degree. Personally, most of my career has been like this.
There's been lots of "I told you so" moments in my career, but I've never said it once, you just let it go and deal with it.
Few_Policy7210@reddit
sounds like a classic case of shadow architecting
Spirited-Camel9378@reddit
Glad to have you on the team
Acrobatic-Ice-5877@reddit
Leadership sets the standard. If management is okay with mediocrity, nothing will ever change. I would just use good design patterns on the stuff that you touch and let the rest of the codebase rot. That’s what I do on my team and it works because I don’t get paid enough to care.
vansterdam_city@reddit
Even when you have some official architectural authority, it tends to feel this way. Nobody wants to have to "talk to dad for permission" really. You can institute arch review / TDD processes but effective participation will be mixed unless all the ICs are experienced with this type of setup.
So basically, this is preparing you for future architectural / tech lead roles. Welcome to the pain.
nettrotten@reddit (OP)
Its a good point of view.
Obvious-Treat-4905@reddit
that’s a really frustrating spot to be in, you’re carrying the responsibility without the authority, which is the worst combo, the fact that they pull you in later means they do trust your judgment, just not proactively, one thing that can help is documenting your concerns clearly so when things break, there’s a record, also worth having a direct conversation about roles, not emotionally, just who owns system level decisions? you don’t have to keep absorbing that stress without recognition or clarity
Temporary_Bench_254@reddit
As I see it you have two options.
spez_eats_nazi_ass@reddit
Congrats. You are now an architect. Usually this is where architecture is done. The guys with the titles in my experience tend to not have any actual involvement beyond holding meetings about updating confluence/ardoq and stopping me from keeping my tools up to date. Now the opposite can be true too. Titled and then you get some of the worst slop projects ever and told "all the other devs are busy - you do it". So architect title while in the code mines like a dev.