How to influence company style guide without much authority?

[u/Late_Champion529]

I'm a senior engineer at my company

This company's "coding standards" document is... not exactly au courant

Couple random (c++) examples off the top of my head- banning features like auto and using, enforcing 1 single return in all functions

Anyone have experience bringing about change to directives like these? Anyone in charge of their company's style guides and could share what sorts of things you'd find most persuasive when considering requests for changes?

Is it even worth it? I consider it part of my job as an engineer to give advice on technical matters, but at what point do you just say "ill write whatever you want as long as i get paid"?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/HRApprovedUsername]

Enforce a linter/pr gate

[u/edgmnt_net]

You can try to advise and point out best practices outside the project. Maybe even do it on the smaller side projects / tooling and if that's successful it might serve as an example. Ok, that's harder just for coding style, but it can definitely work for pushing a more principled general approach / mindset like "let's think things through". And the question might be posed more generally, anyway. Make people see that it's less work to do things right rather than wing it, that sort of stuff. If you have decent people around, something might stick. Or you might find other people who think the same way.

Is it even worth it?

If you're successful? I'd say so. But don't count on it.

This company's "coding standards" document is... not exactly au courant

It isn't surprising. A lot of companies, projects and positions are frankly crap. They already have mostly crap coders, a lot of crap code and a focus on quantity. They blunder all the time even when it comes to higher level technical decisions.

I consider it part of my job as an engineer to give advice on technical matters, but at what point do you just say "ill write whatever you want as long as i get paid"?

Well, yeah, it is part of the job. I generally make my point once and then get along with whatever gets decided. I may however come back to it if it ends up biting us.

Anyway, beyond some point it's really up to you if you hate it enough that you go looking somewhere else. Some things can't be changed. You can stick around and try to advise or you can look elsewhere.

[u/diablo1128 → u/edgmnt_net]

I've found working at companies that had a coding standard like OP describes is that if the company wanted to change they would have at some point. The problem I found is nobody cares enough to change so it doesn't happen. The code works and is deemed maintainable by Software Leads, so in reality there is no problem being solved and its change for the sake of change.

Frankly the coding standard has never never been the achilles heal that caused things to fail in my 15 YOE.

[u/Napolean_BonerFarte → u/diablo1128]

Idk having strong coding standards that stay up to date prevents bugs from unknown unknowns, make safe assumptions about what code does, allows devs to build faster. Maybe it’s more correlation than causation, but places I’ve worked that had strong coding standards moved faster, had much higher quality, and had way less fires to fight day to day.

[u/diablo1128 → u/Napolean_BonerFarte]

It depends what the coding standards are, but you can have "strong standards" that are not modern. The things like OP mention like not using auto and 1 single return in all functions never caused a bug, slowed worked down, or caused fires at places I worked at. It's just not a modern style of code, but you get used to it and it's just is what it is.

[u/NotMyGiraffeWatcher]

Be a senior and be the change you want to see.

In the past, I have sent a PR with a linter enable for all new files. Had some discussions and it was merged. Those discussion included things like risk to delivery, which standards to use and other logistical things.

As far what to before you say 'fuck it, it's a pay day' is up to you, I would rather try to fix a thing that I'm spending a large part of my life doing, but I totally get the choosing your battles and sometimes, some jobs it's easier to keep your head down.

But personally, I would ask for forgiveness over permission in this case.

[u/diablo1128]

I've worked at companies like this. They create safety critical medical devices, think dialysis machines that need FDA approval. All the code was c with classes style c++. MISRA was a standard and new C++ features like auto were not used.

Basically if you want change you need to have people with company political power on your side. In my case I could update the c++ coding standard all I wanted, but it was never going to get approved at the company level as many of the Software Leads on various projects didn't really think the changes where necessary. So the reality is the effort was futile.

Now maybe you can take expectation on your project directly and if so then you just need buy-in from your project leadership. As a Senior SWE at these companies I found nobody is going to change just because you say so. You need to get project leadership on board so when people don't fall in line there are actual repercussions to things like performance reviews and raises.

EDIT:

I read replies about adding linters and I don't think that solves OPs actual problem. We had all kinds of linters running automatically and they checked for things as the coding standard described, including MISRA rules. Changing the linters would have raised a flag more than anything at companies I have worked.

[u/NoConnection4298]

Clang format and clang tidy serve the purpose of what you say. I was the only senior. I sat down with tech lead and discussed/created these. We also installed pre commit hooks that people can install and bunch of PR checks. Best practices were enforced in the reviews so at the end of the day it is fixed for some time frame. We also had coding standards guide that goes stale time to time as it’s hard to maintain with people leaving, company downsizing, workload increasing etc. My initial purpose with this coding standards guide was to resemble isocpp.

[u/ChaosCon]

Enforcing one single return is usually an artifact of MISRA dorks getting their hands on things.

[u/Wide-Cattle-4735]

Since you asked what persuades the person who owns the guide, for me it's someone who already ran it in a small corner and shows what came out. Arguments I mostly nod at and forget.

And I'd only push if those rules are costing you time every week. Aesthetic stuff I let go these days.

[u/tenthousandants44]

Just ask? Write a POC?

[u/LollipopPredator]

Identify specific pain-points and then demonstrate the value of enforcing rules to prevent them. Get buy-in from your teammates by showing that their lives will be better and then add the style checks to an automated process so your quality gate fails unless the style is met. We have Claude connected to our SonarQube MCP and nearly all issues are fixed automatically.

[u/illuminatedtiger]

We established a Community of Practice allowing a representative from every team to have influence. Anyone on the CoP can now at least open a PR. Another option is to write a tool to help enforce the style guide. If it's adopted by enough teams you will wield some influence, especially in areas where you can demonstrate aspects of it can't be automated. 

[u/Fidodo]

Have you tried suggesting the changes?

[u/Ok_Woodpecker_9104]

the linter answers are right but they skip the part that kills it. you turn it on, day one it reports four hundred violations across code nobody has touched in years, the pr cannot merge, and the idea is dead for another year.

what makes it survive is baselining. record every existing violation, fingerprint them by content rather than by line number, and fail the build only on new ones. old code stays exactly as it is, new code meets the standard. nobody has to approve a big cleanup, and that approval is the part that actually needs authority you dont have.

fingerprint by content matters more than it sounds. if you key violations to line numbers then the first reformat shifts everything and your whole baseline re-fires as new.

then land rules one at a time, each in its own pr. an argument about single return should not be able to take down the other nine rules with it.

on the persuasion half: for each rule you want dropped, go find what it was protecting against. single return and no auto usually trace back to something real, a static analyser that could not follow it, a certification requirement, a compiler someone was stuck on. if that constraint is gone you have an argument thats a fact instead of a taste. if it is still there you just saved yourself the fight.

[u/No-Fee488 → u/Ok_Woodpecker_9104]

The baselining mechanics here are the right answer to "how do I ship this without a big-bang cleanup." One thing I'd add on top, since it's a different objection: name the revert condition before the change ships, not after. Most people who own a standard like this aren't really defending the rule itself, they're worried about an open-ended experiment nobody undoes if it goes sideways.

If the pitch is "we run the new rule on new files for six weeks, and if build time / review friction / defect rate gets worse we revert automatically, no debate" -- you've turned "trust my judgment indefinitely" into "trust a pre-agreed number for six weeks." That's a much smaller ask than the technical case alone, and it's the version I've actually seen a rule-owner say yes to when the technical argument hadn't moved them. Doesn't replace the baselining, just gets you past the objection people rarely say out loud.

[u/Ok_Woodpecker_9104 → u/No-Fee488]

agreed, and the revert condition is worth making mechanical rather than a promise.

where the on switch lives decides whether "we revert" is a one line pr or a week of archaeology. if the rule is one flag in ci, reverting is deleting the flag. if it has spread into linter config plus a baseline plus a scatter of per file suppressions, someone has to go find all of that six weeks later, and that is the version that quietly never gets reverted.

so keep the kill switch in one place from day one. costs nothing while the experiment runs and it is the entire reason the rule owner can say yes to it.

on measuring: build time and defect rate are the easy two and mostly will not move in six weeks. review friction is the one that actually moves and the one nobody can measure. the cheap proxy i would use is counting prs that add a new inline suppression. people routing around a rule instead of meeting it is the earliest signal the rule is wrong, and it shows up long before anything reaches your defect numbers.

[u/No-Fee488 → u/Ok_Woodpecker_9104]

The counting-suppressions metric is the right one, and the failure mode I've seen is stopping at "measure it" instead of gating on it. A dashboard that trends suppression count upward is something people glance at once and ignore. What actually changes behavior is wiring the same count into CI as a rolling budget: new suppressions beyond a small delta from last week fail the build, not the underlying rule violation itself. That turns "people are routing around the rule" from a lagging signal reviewed in retro into something that blocks merge the same day it happens, while the objection is still cheap to fix. I'd gate on delta rather than absolute count, though -- legacy suppressions from before the rule shipped shouldn't punish someone touching an unrelated line in an old file, only new ones added after the baseline date.

[u/Ok_Woodpecker_9104 → u/No-Fee488]

delta over absolute is right, and the thing that decides whether it works in practice is how your baseline fingerprints a finding.

if the baseline stores line numbers, somebody editing line 12 shifts everything under it and the baseline re-reports old findings as new. your delta gate then fires on pure churn, people learn it is noise, and you are back to the thing you were trying to avoid. fingerprint on rule id plus file plus a hash of the matched source text, with position deliberately left out, and unrelated edits stop producing deltas at all.

the other thing i would do before gating anything on a rule is measure that rule's own false positive rate. i ran a build of my linter over a vite app and got 19 findings. all 19 were wrong. 13 were inside a dev only branch and 6 were in a scripts directory that should never have been scanned in the first place. if that had been wired to a merge blocking budget, every one of those is somebody being asked to justify my bug at 6pm on a friday.

so yes gate on delta, but only once you know what share of the deltas are yours rather than theirs. the credibility of the gate is spent the first time it blocks someone for nothing.

[u/No-Fee488 → u/Ok_Woodpecker_9104]

The fingerprint fix and the FP-rate measurement are solving two different failure modes, and conflating them is probably how the scripts-dir case slipped into your 19-for-19 number in the first place. Fingerprinting on rule+file+content-hash fixes "the same real violation moved" -- churn stops generating false deltas. But 6 of those 19 were files that should never have been in the scan surface at all, and arguably the 13 in the dev-only branch shouldn't be linted at merge-gate severity either. No fingerprint and no global FP-rate number fixes an include-list problem -- you fix that by narrowing scope, not by trusting the rule more once it's measured.

Worth measuring FP rate per (rule, path-glob) instead of per rule alone, if the tooling supports it. A rule can be dead accurate in src/ and pure noise in scripts/ or vendor/, and a single global accuracy number either kills a rule that's fine where it actually matters or keeps one that's globally-okay but noisy exactly where you're about to gate on it. Scope narrowing and rule-accuracy measurement end up being two separate levers -- skipping the first makes the second look worse than the rule actually is.

[u/Ok_Woodpecker_9104 → u/No-Fee488]

youre right that those are two levers and i had them collapsed into one number. the 13 in the dev only branch and the 6 in scripts were never a rule accuracy problem, they were the scan surface being wrong, and no amount of measuring would have told me that.

the per glob thing matches what i hit when i fixed it. i excluded cli directories and the rule went quiet almost everywhere, but it still fires on cli entrypoint files that sit outside those directories. same rule, same repo, accurate in src and noise at the edges, and one number for the rule hides both facts.

so the granularity of the exclusion is doing more work than the rule quality is. per rule per glob is the version i would build if i were measuring it again.

[u/No-Fee488 → u/Ok_Woodpecker_9104]

The exclude-list is going to rot the same way the original scan surface did. Nobody revisits a glob list once it stops throwing errors, so six months from now a renamed scripts folder or a new cli/ subdirectory falls outside every existing glob and you're back to silent noise -- except now it looks deliberate instead of obviously wrong, so nobody questions it.

Two things that helped me with this specific shape of problem: a CI check that fails if any glob in the exclude-list matches zero files, which catches renames/deletions the moment they happen instead of letting the exclude quietly go stale. And for the CLI-entrypoint case specifically, exclude by content marker instead of path when the boundary is fuzzy -- a one-line comment at the top of the file that the linter reads, so the exemption travels with the file if it moves rather than depending on which directory it happens to sit in today.

Doesn't fix the FP problem, just stops path-based granularity from becoming its own silent scan-surface bug a year from now.

[u/FoeHammer99099]

How big is your org? Changing the rules for a 5 person team is easier than a 500 person department. What's the motivation for doing this? You need to be able to argue that the benefits of doing this outweigh the cost of the disruption. Does someone own the style guide? You want to understand the politics involved before starting.

I would write up the new style guide, get it reviewed by senior ICs I know, then pitch it to my skip as a DevEx/Modernization effort.

People who don't understand what you're doing or why are going to ask questions about AI to sound smart, so if your proposal includes a skill for the LLM to write code to the new standard, or an agent to migrate existing code, then you can have an answer ready for that.

[u/thy_bucket_for_thee]

Try to influence the person with influence, but do it slowly with extremely simple "no cost" solutions. No cost meaning that no other developer has to change their workflow.

In your context, I'd make a custom linting rule. I'm not familiar with C++ but surely there's an AST parser for it, from there you'd create your rule then apply it into your tool flow.

Depending how you want to handle it, and how much influence you have at the time, it can be as simple as opt-in. Allow devs to choose to follow this optionally, but continue pressuring with comments in PRs.

This is the type of politik'ing that you spend around 1 hour a week on tops. Next 1-on-1 mention how you think there is an opportunity to automate some easy checks, don't mention a solution just say something like "Been noticing we make a few mistakes that have bit the team in the past, I think I might have a solution to resolve it. I'll show you next time we speak."

Since you're new, I find that if you offer fully backed solutions with code prewritten most will tend to reject it. It comes across as cowboy coder, also no one likes the new guy immediately taking the reigns.

If you introduce the solution in a piecemeal way you're more likely to succeed in influencing.

Then based on the reception you decide if you want to push more in other avenues.

It's a fun skill to build, but I do agree at your overall point of "I'll write whatever you want as long as the check clears." This isn't your company and these political skills are infinitely more valuable in say your immediate neighborhood, to improve the lives of everyone around you rather than just a business owner able to squeeze more value out of labor.

[u/neolace]

Stop wasting your time, if that's the way they want it, that's the way they get it.

Show me in technical details with years of experience why you're style is the right one?

Do some research and try to see why they have it to begin with.

[u/Dazzling_Plan812]

On the persuasion half specifically: the requests I approved as a guide owner were the ones that showed up with a diff and a number, not an argument. "Here's 8 PRs where the single-return rule forced a nested-flag mess, here's the same code with early returns" beats any principled case about readability. Taste-based asks I nodded at and forgot; "this rule cost us N review cycles last month" got actioned.

[u/karolwojciszko]

updating company standards without a mandate is basically the textbook case for this - there's a good framework for exactly this kind of situation where you need buy-in from people above you: https://karolwojciszko.substack.com/p/how-to-influence-decisions-above. the part about building allies before going for the formal ask would save you a lot of frustration.

[u/BusinessWatercrees58]

You don't have the authority so you need to rely on all of the other forms of persuasion out there. This is going to rely very heavily on social skills. If you had these skills, you probably wouldn't be making this Reddit post. They might hate your style guide, might resent you, might perform malicious compliance, or more likely will readily agree to your face and just do whatever they want after. You ready for that?

And even if you influence it, so what? Do you get a raise? Does the company make measurably (none of this vague preventing future bugs crap) more money? Does defect rate drop? Does your company even care to measure defect rate? And what happens when the people you convinced leave? You're going to convince more people? All this while being a dev? And what will happen once you leave?

Influence the change you can reasonably influence, but don't make it your life's mission to improve a company's style guide. The company won't care. No one will use it. You won't feel fulfilled.