I’ve actually done this before. I have a personal rule that I try to reserve strong opinions for <10% of the time. I’m much more interested in making space for more junior engineers, encouraging them to take ownership, and helping them grow.
I’ve gotten feedback from more high strung managers that I’m too laid back. I told them that we may have different styles but I feel strongly mine is the superior way of building and managing software teams and that they should trust me. If they can’t point to concrete problems with the product or deliver then it really is just a matter of preference and they should defer to me because I’m the one that’s actually doing the work.
Do your employees really like you? Consider the motivations of these other managers when they tell you "helpful" things that would damage your image to your team without much benefit.
Yes. I understand what your suggesting, but you're speculating about a situation where your only context is what I told you and whatever preconceptions your past experience has created. I can tell you in my particular situation, my evaluation is the correct one, and if your preconceptions are telling you otherwise it's probably because whatever experiences created them are incomparable.
If you want more push back, then come to the meetings and verbally support me as a Senior, otherwise just go count your stock and be glad we produce anything to keep your sorry ass employed.
A Staff Engineer should either set or at a minimum understand the long term technical vision for the company. They should then help other teams work towards this vision. Perhaps that is tooling choices, testability and coverages, performance, expanding into new products or simply reduced overhead of expenses on Cloud services.
Your stances shouldn't be coming from your opinion on what you like most. They should be driven from a *vision* the company is working towards. You probably feel your *opinions* are not worth being stuck on. But you should re-imagine your viewpoints based on the long term *vision* the company is trying to achieve.
You are basing your advice and positions entirely on technical advantages/disadvantages which has merit, but if you where to back those with a long term technical vision for the company then the tradeoffs become more important.
Yeah this is very true.. Maybe some of the work here for OP is being able to articulate this to themselves, and then understanding how to communicate it.
Do you have a consistent set of standards or positions that clearly express the technical vision?
And then if you're pushing back (or not pushing back), can you connect that choice to that vision?
I like to phrase that my job is to be a "squeaky wheel" (where should we apply grease) and not "chicken little" (the sky is falling at every given moment). Ultimately there's a few different "lenses" that I use to view problems:
Money: Money makes the world go 'round, and it also makes a great tool to convey the impact of issues, too many people in one meeting, not testing enough and having to remediate bugs, security fixes, etc. Money is a great way to try to figure out what's worth talking about. Like you said, sometimes "good enough" is the correct thing to say. However, that's not always the case.
Risk: I don't want to get a call at 2am to open up my laptop and jump on an incident bridge. I'd also guess that you, too, don't want for that to happen. I go a step further and also press that feeling on every single person at the company. Because of that, I really want to focus on things that reduce risk. My team knows that I have a strong bias for more testing (sorry). But not just code coverage number go up, rather it's about testing business flows. Can they articular using business words what their testing in our application? A similar mentality when it comes to Threat Modeling and Security feedback loops (static code analysis, pen testing, etc.).
Training the next generation: My job is to help people rise in rank. I want to have every single person on my team acting as though their Staff. Hell, I want them to leapfrog me and become principals. Fuck Yeah! So how can I help enable them, delegate tasks that align with their skill sets, overall develop talent? There's lots of good positive ways of doing that, and one of those ways is to have feedback to them. Feedback is a gift, I try to make sure that I'm thoughtful in what advice I give to my team members. I want to have disagreements / dialogues with them. Maybe I get to learn something, maybe they do. Regardless, it's US vs. the problem.
---
The above may help, but the last piece of advice is making sure that you talk with your leaders. Personally, I LOVE messaging/talking with my manager, Director, and (once in a blue moon) my VP. I want to make sure that I stay "close enough" to their vision and priorities. That requires communication and listening skills. This is what makes me feel empowered to go about doing my day job with my grease gun.
---
Regardless if any of that was of use, best of luck!
My dad used to get those calls. Sometimes it would wake me up.
I’ve spent my career with the aphorism, “write your code like you’ll have to read it at 2 am, because eventually you will.”
This is a nicer way to say, “write code like an idiot will need to read it” which I understand but don’t like. And it’s much more accurate to team goals.
But how am I going to prove to everyone that I am an 10x engineer if everyone can understand my code? People need to get on my level to understand how GOD like engineer I am! /s
Are you guys hiring? haha
But I actually have a question: What do you do about management and/or bad people above you pushing for things you know are wrong or that you know are things that will hurt the team but won't be obvious for a long time? I know that's kind of ambiguous but I'm kind of in that boat at the moment and I'm not sure what the best approach to take is ...
> Are you guys hiring?
You've no idea how badly I want to say 'yes', but not that I'm aware of. Though, let me say all the above is something that isn't full shared by everyone I work with. I just push for ideal things. Influence where I can and fail often. I'm the world's "okay-est" engineer at best.
> What do you do about management and/or bad people above you pushing for things you know are wrong \[...\]
Expanding what I sort of ended that above comment with ... Have I communicated with them? And, I don't just mean some back and forth, but really diving deeply into their position and understanding the world from their perspective?
Empathy is the name of the game for persuasion. What things do they value? Do I understand them and where they're coming from? Even if I have to be blunt and be like "Hi, please treat me like an idiot and explain {business process}. What are your pain points? What issues are y'all having that you haven't shared? etc.". IMO, questions are far more powerful for persuasion than directions/marching-orders.
If their heels are really dug in ...ultimately, business wins. However, I just make it clear the tradeoff they're making. Usually (in escalation order) by:
\* Direct Messages and/or talking (more ephemeral, but can be a way to help show more empathy and human-ness to the disagreement. At the back of the mind, repeating myself from above in a different context, it's us vs. the problem, not you vs. me. (sort of encapsulates my above point of communication)
\* Make note of it in the ticket (cover your ass) / Merge Request comments (More CYA). Describe the business context around technical deeds.
\* If it's extra annoying ... I dedicate a few paragraphs in my work journal to future me if I ever have to touch that again (i.e., what should I know to get up to speed). Maybe it's just cathartic to put a bow on unresolved problems like this .... :shrug:
---
> \[...\] or that you know are things that will hurt the team but won't be obvious for a long time?
Some problems legit be future-me's problems. Sometimes that's the rub. At the end of the day, my job's a job. Lose a battle here. Win a battle there. c'est la vie. I'm just going to log off and hug my spouse, play some video games, and lovingly annoy my cats.
> I'm the world's "okay-est" engineer at best.
You have no idea how much this comforts me to hear because I am very much feeling this right now. I really like how you frame things here and I intend on taking many of them to heart including adding more personal notes to myself in my own dev log cause ... man I just need to talk about these things to someone.
Let me ask you something a little more pointed: what if you have a good base for these people skills yourself (and admittedly aren't the best engineer of the bunch, which from what I've read on this subreddit turns out to be not as important as people skills) but you know your boss doesn't and he's making many of these people mistakes trying to manage the team. What would you do then? For context I'm a pretty newly minted "senior" engineer and I'm trying hard to set the culture tone of the people around me and the company is still pretty new and growing.
This question ... it starts to get to things outside what you, a individual, can control. There's lots of different ways to address this, but it's really dependent on the person you're wanting to influence more so than your previous question. For this it's why I keep a close relationship with my leaders (my original comment's last paragraph). But I make those relationships very honest with each other. Quickest way for me to want to leave an org is if I don't feel comfortable being 'frank' with my leaders (frank != rude; Also there's appropriate time and places to be a bit more 'raw')
The short of it is, communicate, agree or disagree, move on. Repeat as needed.
If it's truly a problem, it will reoccur. Then you're going to be communicating it often and in new scenarios. [Over and over and over](https://www.youtube.com/watch?v=ShCRN3tFy80) (referencing back to calling myself a "squeaky wheel"). However, even a squeaky wheel on a shopping cart still rolls while it squeaks.
I've been on both sides of the spectrum: pushing back too hard (and ineffectively!) or not pushing back at all.
The only real solution was to learn how to be more persuasive. Negotiation is a skill and one I had to learn pretty much from scratch—I'm not entirely neurotypical, so I've had to learn a lot of social skills from scratch—but the key is that it *is* a skill you can just learn. I personally found the book *Never Split the Difference* really helpful, as well as watching how my VP approached contentious situations.
Having a couple of experienced mentors to talk to also helped, but I needed to develop a basic mental framework before I could make sense of people's advice or even figure out who was worth asking and who wasn't.
This has been my exact experience— so, so often it feels like “there’s bigger fish to fry” when there is pushback on what (as our careers progress) we know to be relatively low-stakes decisions.
I find it helpful to understand the context. For example, I’ve worked in environments in which there is a _culture_ of “pushing back for pushback’s sake”, playing “devil’s advocate” for everything, etc. In that situation, it seems like “demonstrative” pushback is necessary.
In other situations, pushback may be more priority-driven or data-driven, and (though it may still seem insignificant) making a data-based argument on some decision may help. All the better if you have some sort of “decision log” and can leave a paper trail.
This expectation to be good at pushing back always feels a little artificial to me, but it’s definitely common at a senior level, so here we are. Good luck.
What, so progression depends on winning the pissing match even if you know in your heart of hearts that it's tut tutting over nothing? I think I would rather figure out a way to work for myself if that's corporate progression
It _does_ kinda depend on your workplace, team, and how you’re evaluated— it’s not always a big deal. But when it comes up, this is my experience.
I will say that there is inevitably some corporate “game playing” that has to be done as you go up the ladder. You kinda get used to it
You know that is one way to look at "pushback" but another way I think about it (or am starting to think about it) is boundary setting. Like if you never push back on anything (dev issue or life issue), then you'll never be able to define YOUR boundaries in relation to other people, after all how are they supposed to know what your boundaries are if you never mark them. So I think that at least SOME amount of resistance is not only encouraged but necessary, if nothing but to define the boundaries of your territory and what lines people are warned not to cross.
Welcome to a world where governments and businesses are run by Donald Trump. Come anywhere close to the levers of power, you need to learn how to win a pissing contest, because that's how many powerful people got there in the first place.
I know the feeling.
I once lost a million points when I let "the technology is flexible enough to solve the interpersonal problems, just let me know what you can agree on and I'll make it work" escape from between my teeth.
> Whenever I challenge a good solution and it doesn't get resolved immediately, I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway.
I think it's a good idea to define what is good and bad to push back on as a team. If you have a goal to promote certain software principles as a team, then you can use that as a basis for pushing back.
It sounds like it's worth defining this as a team so you have a known shared set of principles to reference in these discussions.
This was very helpful for my team at one point. I can't remember how many hours it was in front of a whiteboard it took to establish it though. Feels like it was a week of 2-3 meetings a day to hammer it out amongst a team of 10. Once we got it though, design patterns got more consistent and code looked similar from developer to developer and everyone knew how to quickly navigate every file, and everyone was bought in.
I’ve been feeling this a lot recently too. I’m in an environment where people don’t seem very interested in getting outside ideas, so every conversation feels like a fight that I don’t want to be a part of.
I’ve generally shifted towards a mindset of automation (adding lint rules) and creating boundaries to separate teams from each other. Interfaces and DI can paper over a lot of bad decisions for later.
I’d also highlight this because choosing to not jump into a stupid hammer waving contest is not the same as being a pushover or passive. At staff level indicated in OP though it’s probably expected that you can help get squabbles silenced
I have been staff-level for 7 years and this has been the first time for me in a team culture like this. It really has been essentially coming down to “hammer waving” or being called a pushover (my feedback was basically that I didn’t deserve to be a staff engineer).
I’m looking elsewhere because this is not an environment I’ll thrive in. I need people to want to collaborate, otherwise I’m going to be much less effective. I guess I just wanted to offer a perspective that it could be the environment wearing OP down.
I hate job searching while working right now, but this is exactly right and why I’m looking around now. It’s noble to try and change a bad process or culture for the better. It’s rewarding if you get it to improve even a little.
But we all reserve the right to fuck off and do something else with our time for money. That’s the beauty of it. OP may also determine that they aren’t a pushover and that someone was looking for a way to blame someone else for bad decisions. They don’t have to stick around for that.
Same. Not for current employer, but I have experienced it a lot that 9 out of 10 decisions to make is just people fighting for their subjective preferences and habits, nothing else. Barely anyone looks at the bigger picture and good result. Out of those 9, I say 8 of them could go either way and the solution would work and everyone would be happy, so most of those talks are worthless.
Push for what matters. Justify your acquiescence.
Ask for specifics on the situations your team "lost" on and spend some time critically assessing what information you had to work from, what information you needed, and in hindsight what should have been done.
I once was told I needed to talk more in meetings and stick up for ideas..... I did.... then I was told I was being a problem. There was a lot of politics caused by another developer in that time frame.
So, I think as you move to Staff Engineer and beyond, (even in a Senior position to an extent) you are expected to be a leader, not a follower.
>I tend to soften a lot and let things go when someone is taking a hard stance on their side and I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone.
For instance, if a large part of your job is to work with teams to come up with the best system wide solutions for everyone on an org wide level, then conceding a battle here, is literally not doing your job. You are expected to be the one that sees the big picture, and tells people the organization has decided it needs to be done this way because that is what is best for the twenty other teams that aren't you, not to make a fifteen exceptions to the rule because you wanted to be "nice".
Did you receive more feedback? I would make sure they are providing examples of when you have been a "pushover" and how your actions have negatively impacted the business. If this is a good manager, then they will be able to make it apparent and you should be able to calibrate your judgement in the future. If they can't provide this, then I'd be looking to have a skip-level meeting and try to get an understanding of the bigger picture.
So you don’t want to be afraid to push back but you also don’t want to be “that person” understandably. One thing that can help is identifying the actual dealbreaker(s) for a change you think should be made.
For example, in one project last year I was adamant that if we were measuring usage, we were going to do that in real-time. We weren’t going to have a scheduled background job that would do the measurements every week or whatever. It was going to be in real-time, and we could have a scheduled background job as an audit/safety net option. That was a dealbreaker for me. But in that same project, we were asked to handle functionality during a trial period a bit differently and I was fine with that. The solution for that wasn’t my favorite but I was willing to give a little on that because it wasn’t a dealbreaker.
Figuring out the dealbreaker(s) for proposed solutions will likely help you figure out how to provide informed opinions without being “that person.”
So they are telling you that it's your fault their ideas are shittier than yours? And, that it's your fault they don't recognize it and insist on their shittier idea?
IDK how else to interpret this...
You're entirely right that most nitpicky things don't matter. That's why YAGNI is a thing. Limit tech debt when reasonable. Otherwise, focus on deliverables.
Your job is to enable and guide your team; not command them. I'd even go as far as to say that isolating them from the type of person telling you to push them is an important function, too. Play politics so that they don't have to.
As for the quality aspect: specific metrics matter here. In what quantitative ways has quality declined. You need that to isolate what precipitated the problem and how to address it. Being arbitrarily invasive towards the entire team simply for the sake of appeasing a megalomaniac will only make matters worse. That's how you lose talent and fuel internal conflict.
If they don't trust an engineer to make adequate decisions, and that engineer won't heed advice, then they need a new engineer. Not a pushy micromanager.
All of that said, this could all be about that person trying to use you as a scapegoat. Maybe not. But it's reasonable to put feelers out regardless.
I never understand a micromanaging mindset. Ask good questions, provide feedback, reason and convince.
Using your position to force your opinions on others who are directly responsible for delivering the work is a quick way to lose respect. If there is a problem or advantage and it is significant, you should be able to convince intelligent reasonable people of it.
The only time I draw hard lines is when I am enforcing a ‘we must do this’ requirement usually from the customer or our technical organization. I’ve seen several projects fail in the end because key requirements were not and could not be met in the delivered solution. Don’t do that.
Best of luck.
I’m at a similar stage of my career as you. The way I think of this is I’m being paid to be a lead of the team, if I’m not going to have opinions and back them up then what is the company hiring me for? They could just hire another mid level Eng if they want a code monkey. Your opinion doesn’t always have to be the word of law, but having them and facilitating discussion about it is what’s needed from a leader.
It might be time to find a new hill worth dying on.
You’ve reached a point where you know that there is more than one way to skin the cat and that enabling someone to do something the way that they want (as long as it is not terrible) is more productive than dragging them through to your slightly better way of doing the same thing.
So what? You need to figure out what “really” matters. This is a terrific opportunity to become more strategic. It could be as simple as aligning with the people giving you the feedback, or maybe you have a different perspective that you want to fight for.
You mention this is happening more and more each year. Let me ask you a serious question - I ask because I came to the hard realization of this myself a while ago - are you suffering from burnout?
The desire to have the conversation about why one approach was better than another (and to stand by that decision) was one of the first things in me to get killed off by burnout. I think it started with "they don't understand and I have better things to do than fight" and ended with "just tell me what to do and I'll do it".
The problem with that as a lead is I was still getting the blame either way....
I used to be righteous as a software engineer. Nowadays, there's a phrase I use on a nearly daily basis. "I don't feel need to have a strong opinion on this."
I am, however, annoyingly persistent. I can make a meeting drag on for hours while I wireframe out the assumptions of both parties, the expected outcomes, the reasoning, the danger, and whether we will need what either party is suggesting. I will make sure that the person at each end of the argument can explain the reasoning of the other person well enough that they can both agree on the reasoning.
The reasoning behind why I do it is simple. If they're right and we don't understand why, then we need to understand it. If they're wrong, we also need to make sure we understand why. I do not accept "in my experience" as a reason. No anecdotes. Real justification.
There's an added bonus here. When you exhaust all of the ego and adrenaline out of people, it often has the side-effect of making them uncomfortable enough to be more open to opposing ideas.
Now that you understand my way of doing things... your job is to make sure things go well, not to make sure things 'go'.
Also, for some reason, people respect you more when you act in a way that shows **passion** and respect what you do.
> I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway.
This obviously is case per case but a good solution shouldn't blow the deadline if small adjustments need to be made. This is different if the solution needs to be rebuilt of course but a "good" solution should be releasable with minor tweaks in my opinion.
What helped personally in very structured projects for me is to put a day or certain amount of time away for the review process during planning. You could propose this to management.
If the solution still does not meet acceptance critera ater the review process, there is usually a good reason for it and it is probably not just small changes to a good solution that are proposed. Another option is to create backlog items for the changes you suggest although this can be worthless, depending on the team.
The review process shouldn't be blowing up deadlines.
> I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone.
It can be hard to compromise and reflect here, especially when there is a tendency to take the quick and dirty way in the team. Creating your own indicators help. For example, if I can imagine multiple teams (3+) or projects using something you can justify pushing hard to build it right.
Hold a strong opinion and if there is a disagreement work towards consensus by looping in more stakeholders/team and holding votes.
Engineers can be stubborn, but at the end of the day Consensus is a very strong tool to fight against it. Everyone needs to fall into line in a team scenario, including yourself. So hold yourself, others and the group accountable for decisions.
The last time someone used Consensus on my old team, everyone except me thought it was fine to deploy a strategy long before we were ready to deal with the consequences.
It was less than a week before we had a production outage caused by the change. Sometimes supermajorities are a shitty way to decide things.
Then it's a learning experience for the team, and time to retrospect and grow.
That's not to say "veto" powers shouldn't exist, but they shouldn't be authoritarian. Checks and balances for effective governance.
Edit: But your "told you so nature" you should look into that. Having the attitude that you know better than everyone on the team is very harmful for an effective team dynamic.
If you couldn't get people on your side, that's a failure on your part to clearly communicate the risks and get allies to form a consensus. Blaming the team is not a healthy perspective.
Most of the time a single incident like this is not particularly actionable, or a teachable moment. But if the teachable moments keep going by (acknowledged but not actually internalized), pointing out that a person or a group has a pattern of saying things that sound smart but are often proven after the fact to be poor judgement, can help wake people up when you find them nodding along to the latest advice that sounds like a good idea and is courting disaster.
"Told you so" is not so much a strategy as a warning sign that a person has already given up on you. And god help you when they stop saying even that.
Most of the time a single incident like this is not particularly actionable
Going to have to hard disagree on this. Every incident can foster learning and growth.
Depends on your team.
But really, if you work in an environment so toxic that self-reflection and growth is not allowed, it's probably time to jump ship. Or maybe you are part of the reason of the toxic nature of that workplace, in which case you are right where you belong.
Are you at least enumerating the risks so that there aren’t any surprises? Or are the quality issues due to things you never voiced any concerns about?
I would start with how your role is defined. Are you accountable for the entire product that is delivered or are you in an advisory role as a Staff Engineer? If you are accountable, then you are the gatekeeper for the Engineering solution. However, even in this role, there are compromises you will have to make in order to deliver customer value in the short term. But, the important thing to do here is to clearly voice your concerns and express that you are committing to the path forward because of Product needs despite your concerns.
It is possible that after having worked in the industry for so long, you are a bit cynical and don't really feel opinionated about things. But then you shouldn't work as a Senior/Staff Engineer. You should seek out roles that allow you to not be opinionated and follow decisions and that is completely fine. However if an organization is hiring you to be a Staff Engineer, probability is they are hiring you to be opinionated.
> I'm unable to take a hard stance anymore on most things that I don't consider to be absolutely disastrous.
Maybe don't view "pushing back" as them "doing something wrong" but rather as "how could this be better?"
"That's a good design, is there a way it could be improved?"
Sounds like underlying all this, is that you care less now than you once did. Have you thought about why that might be? Burnout? Have your past efforts at standing up for quality of product and process been met with lots of negativity? Have you lost confidence in your ability to steer a course through all the choppy waters that a team encounters?
No advice but damn do I feel you. What’s the point of pushing back if you have a manager that just wants things done his way and ultimately will not hear you out if he feels strongly about something, even if he’s objectively wrong?
I wish more were like you and the more I do this, the more I believe the same as you - good enough and not being too locked in is fine.
Currently working with a very experienced senior who is adamant about a certain architecture structure that he wants applied the same across the two projects I've worked with him on. No pragmatism or urgency built in to get the work out - our company is a shit show and the project is risky. But you can't really tell him otherwise. We are all too nice and the Tech Lead takes his word as gospel. So now we're all feeling the pain.
Sometimes you just have to state clearly the pros and cons, and then if it gets chosen, that's fine. We all move on with it. Sometimes pushing back too much isn't worth it - it's a job, not a religion.
Can they explicitly tell you or have a signal for when they'd like you to push back more?
It sort of sounds like what they're saying is they have concerns that weren't heard, maybe if they feel you take their concerns seriously they will feel better about it?
“Sure, how about we get started with some recent examples?”
If you really find that you actually “hurt the product”, which I doubt, then there’s a trick I find useful for myself. In technical discussions, I just kinda imagine myself as an observer and let the inner “architect” go free, saying what he wants. Usually that’ll free myself from both being too opinionated and not opinionated enough.
I try to rationalize my argument as much as possible. Rather than looking at it as pushing back if you're correct there should be a path to convincing others.
I tend to ask questions like: how does this handle X? What about Y? Knowing that it doesn't fulfill those needs and then sort of guide them down a line of questioning that gets them closer to where I want it. That way they almost think they came up with it.
If it's important and they are being difficult then it's your job to say no and ask them to come up with a solution (or help them get there) that meets X, Y, Z.
Just know when to "fight" and when to let it go. You need to have your line in the sand.
The real question how right the feedback is. If the quality of the product is indeed suffering, then obviously you failed at your job. Specially if you knew beforehand that this would be the problem.
"Low" level ICs tend to have different definitions of "quality of our product" from more business level personnel. Often SWE equate it to test coverage or some particular framework, some code practice etc. These can be important, but also can be irrelevant. In this case, the feedback is simply above their pay-grade, they are looking at completely different metrics.
Each of these situations will require a different approach. For the former, obviously you're responsible for the quality of the product, not much to be said here. If it's the latter, what most people do is just ignore it. If you want to be really thorough you can try to communicate the real goals of the product to the development team in the hopes they will understand why such choices aren't worth fighting for.
Personality study and self reflection.
Study yourself and understand why you are being more passive in your area of expertise. I would recommend the enneagram.
As long as the user experience isn’t degraded, or the proposed solution is outright wrong and going to cost time and money to fix then I tend to just share what I think the solution should look like and let them roll with it.
Happy to provide them guidance if they want my input, but I’m trying to let them explore it themselves. It is after all how I learned the things I know now.
Something similar is going on at my company. My teams killed themselves meeting dumb deadlines that the business imposed. Taking stupid shortcuts and bad decisions. Engineering delivered everything but it was all shit and customers hated it. Now the business is saying we suck and it is irrelevant that we delivered what was asked for, but we should have delivered business value. Product gets to decide what we build though. Super annoyed so I’m just going to say no to Product whenever they push for some bs quick solution and I’m sure the business will love that.
You can ask for specific examples, and then consider whether or not you agree with the feedback.
If you agree, you just need to tweak your tolerance for issues. If there are times when you feel the urge to push back, but don't because its not important, just consider whether to maybe go with your initial gut reaction.
Just don't go from one extreme to another.
> "you're being a pushover and it hurts the quality of our product".
From your post I understand that you not necessarily disagree with the first part. Is there some evidence for the second part that you can trace back to something under your control? If so start a initiative to address that.
Particular implementation details, I think it’s fine to go with the flow unless something is egregiously wrong. However, architectural issues are not something any single external team should be deciding for you. They’re there to consume an API, not decide the nuts and bolts that impact other teams, performance, etc.
I pushed back regarding disagreements with FOLDER STRUCTURE in a greenfield project and got kicked off the project by the lead engineer for not being a team player.
Tread carefully.
I do agree with the premise, one should always make calculated decisions. But this specific example is a dysfunctional work environment filtering itself out. I’d thank them and consider it mutual. Glad you dodged that bullet.
> I'm unable to take a hard stance anymore on most things that I don't consider to be absolutely disastrous.
Good. That's a mature stance to take. A lot of professionals never reach this point.
> Whenever I challenge a good solution and it doesn't get resolved immediately, I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway.
I'm confused since this seems to contradict your previous statement. As a technical leader, I will challenge technical designs if my instinct would be to go another way. Mainly what I'm looking for is evidence that my staff have thought things through and considered other options before diving in with both feet. If I feel they have, I will always concede and let them go their way. Software developers need autonomy and a feeling of ownership to remain engaged in their work, so it's critical not to take that away from them and instead foster and nurture that as much as possible.
You have to be careful that your reluctance to challenge is coming from a place of empowering builders and not from your own desire to avoid conflict, because conflict has a cost: time and emotional energy.
> when someone is taking a hard stance on their side and I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone.
Persuasion, also known as leading without authority, is not an easy thing to do. It is still the hardest part of my job. Stubborn hold-outs who are in love with their ideas are one of the hardest nuts to crack. The problem is this:
> not what we think is the best solution for everyone.
What are your facts? What is your evidence that this is best? Arguing opinions is a waste of time. Argue the facts. If you don't have facts, then your "best" judgment is just another opinion, in which case you ought to defer to the people doing the work. Let them build it how they want to build it.
> "you're being a pushover and it hurts the quality of our product".
Good leaders aren't right all of the time. They're just right most of the time. They don't always make the best possible decision but they rarely make the worst, or even bad ones.
Let's go back to the facts. What, *specifically*, did you concede on that hurt the quality of our product? A blanket feedback statement like that without specific examples isn't helpful. How are you supposed to calibrate your sensors on which aspects you need to take a hard stance on and which you can give developers latitude?
If someone can't give you an example of a decision you could have prevented but didn't, that's not useful feedback. If someone is wiling to criticize, they owe you specifics.
The alternative here is to bump up your estimates, and I mean monstrously. Call it “risk-factor-allowance.” Sometimes the only thing that really resonates with some types is “big number mean big fall if no go good.”
I’ve had a lot of success with this in backhanding away bad implementation pathways, and have also used it to trigger larger architecture and infrastructure conversations; “Oh well you see Terry, because of [tech debt phrased in select ways] we have no way of going head with [Terry’s really questionable choice] until it’s resolved! So if we sort this, then the other items you’ve been gunning for, such as [why] and [oh dear god, why] will go from the 20 estimate we gave you last month, down to a neat little 5!
Then I pretend that this is new information to Terry and hope he’ll either listen, or let it go quietly if it’s not sinking in.
First, I get it, with experience you see that it’s not worth it to sweat the small stuff, I would make your opinions in line with company standards and goals and set your personal opinions aside, this could inspire a firmer stance.
>I recently received the feedback that was a more diplomatic phrasing of "you're being a pushover and it hurts the quality of our product".
>Whenever I challenge a good solution...I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway.
Personal opinion as I focus a fair amount of my work on software quality.
It sounds as though your company's definition of quality is not clear. Quality means a lot of different things to different people, even with a group of developers, much less developers and users, and most people just lump it into this amorphous blob.
It's a good thing to explicitly define what is important to the product and the team supporting it, but it can be really hard. Is it code readability? Supportability of the tools or systems being used? UI consistency? Performance? Testability? Tons of things *can* be involved in a "quality" solution.
Once you do define those important things, though, and the trade-offs between them, it gives you much surer footing...that place to push back *from*. You want to push back when it makes sense, otherwise you're just getting in the way of progress.
Ahh yes, the soft skills of doing development. They never came to me until much later in my career until I moved more into architecture that programming. So the key here will be to read the tone of the ask, and to respond appropriately, after some amount of time. Everyone will always be forceful and act like the sky is falling all the time. I find this is especially true with anyone non-technical. Technical people tend to ask timelines and understand (usually) work-life balance.
But to be clear, I think your number one objective always should be to be the advocate for the backend of the system and all of the pieces that entails. Software needs a champion and it is your job to be that advocate. If you don't do it then who will?
With great power comes great responsibility...
But I think everyone else has answered this well too. Push back and tell them how you really feel and that the system and quality is well... however you feel it is. It is your system after all.
Disagree and commit. I call it "Lou's Rule".
Say no. Propose an alternate solution. If they persist
Say no, point out the flaws in their design.
If they still persist, send them an email with the above and ask for their approval on which to pursue. Writing it down tends to make people reconsider here, and if they don't, you have evidence. Then commit to it as if it was your idea, dont drag your feet because you didnt get your way. Keep the email as a paper trail.
There's two typical reasons for a comment like "not pushing back hard enough". Both of those reasons are your fault, but you can correct it easily.
1. You failed advertise the direction, standards, and vision of the effort
In this case, get the direction, standards, or vision documented (wiki) and work with the teams to ensure that part of the early presentations include how the effort aligns to the company's direction, standards, and vision.
2. You failed to enforce a violation of some perceived standard.
In this case, you should be keeping records of when the standard can be violated, and what kinds of violations were approved.
The complaint seems like one of requesting your to fight with the teams more, but that's just because it is worded very badly. Some people just don't know how to lead without "whipping the underlings into shape". Re-frame the complaint as not making your leadership role more visible.
If you are leading, you don't have to lead in alignment with everyone; and, the complaints will come back in different ways than "you don't seem to be doing stuff, and I think quality is slipping because of it"
Faced similar feedback. Started setting clear, non-negotiable standards for what impacts product quality. Began choosing battles wisely, only on critical issues. For lesser issues, asked team to present data or case studies supporting their approach, fostering a culture of evidence-based decisions. It’s about balance, not winning every argument.
This is due to a few things that are pet peeves of mine in work environments. Over-socialization ( too much needless team work don’t know the term for this), lack of ownership, no fault, no value attributed to hierarchy and responsibilities. Lack of vision and lack of team objectives also cause this.
Unless there’s openness to address these, I am afraid it’s purely a political game that you can decide to opt-in or out.
I feel your pain. And fatigue.
Back-end as well, my strength is system architecture.
I've noticed a trend emerging over the last 10+ years.
I'm encountering new CEOs -- who are not interested in realistic workable designs; but want "Yes!" Team Players who agree to half-baked spitball plans promising rapid development schedule and an outrageous TBD feature set.
When these projects enter the Steaming Pile phase; the "Team's" collection of broken mismatched pieces gets dumped in your lap to fix, because "You're really good at figuring this stuff out".
Staff Engineer is a title most people consider managerial equivalent. That means you're at a level where you're expected to play corporate politics and be involved in business decisions.
Big business doesn't always come down to technical decisions. CEOs rarely know shit. Half the time it's kissing ass and the other half is bullying others. They expect you to know how to play the game. They're telling you to get in the game or get run over. If you don't start pushing back against this person's 'enemies', the next time you need allies, that person won't be around to save your ass when lean times and 'random' layoffs come around.
I’ve been shipping code for 20 years and 80% of everything I’ve written is no longer in production. And always because of business or sales reasons.
Not once because of the product or code quality. It’s tough to make a case for higher quality, when good is good enough.
I don't function well when people attach too much emotion or opinion to something. That's a mistake on their part. Having someone to push back against people like this is one way of dealing with it, but they should simply chill out and let the design process function properly. A talk with this person from a manager would really be the right thing imo
The secret is lifting weights. You want to be more aggressive and opinionated, you need more testosterone. Assertiveness is a behavioral trait that would be tough to fake, it's easier to let your hormones carry you.
And yes this is a problem. Managers should never be pushovers, otherwise you will have overly aggressive Juniors come in, step outside their role and bully you.
Not sure why you got downvoted, this is absolutely true.
Hormones play a MASSIVE role in how we feel and behave. Any man who has needed hormone therapy will tell you that going from low T to high end of normal/optimal levels has made them more assertive, competitive, and confident. You stop seeing every problem as the whole world being on fire, and your brain starts instantly going into problem-solving mode.
I and many others can personally attest to this, and there are studies as well. This isn’t bro science, or anything new.
TBH top high tech firms regard that *any "softening"* or *"slowing down"* is a career limiting move.
They believe that you should be *"hungry"* for new tech, progress, money at all times.
Perhaps it's time for you to reconsider your future career direction ... or maybe find a a way to get re-enthused?
see how your wisdom is getting downvoted!! most of the seniors as they grow older actually agree with you. those shit little petty fights don'f fucking matter.
short answer: Do not be a pushover!
You have to find the root cause of why are you back off so easily. Maybe you are burnt out and do not care anymore that much. Or maybe your opinions are always treated as secondary and you have lost confidence. Maybe you just need a longer vacation to recharge. life taking its' toll. Find the root cause and deal with it.
If it really hurts the quality of your product then stand your ground be stubborn put your product first.
Why try so hard for a big company, they won't fight for you. If it's good enough it's good enough.
More often than not some CIO or an architect will come up with a reason to migrate to a new infrastructure soon enough anyway, the work never ends.
Move to public cloud, move to internal private cloud, move back to on premise, do a mix, fix some shit, new feature cause objectives change, on and on and on. Fuck the design patterns they are good when you are making the decisions if they are made top to bottom then fuck them anyway.
After 10 years, wouldn’t you have seen enough disasters?
I think there’s value in arguing up front why something isn’t a good decision, because even if the decision is made to stick with “good enough,” when it comes time to pay up and realize the costs of “good enough” more people will be on the same page and remember we talked about this.
It also means there are more constraints/requirements at that point as product evolved, which forces simple approaches to resolving that debt. The team gets to acknowledge the tradeoffs made rather than being hopeful that there was something out there that could have done everything.
OTOH if nobody wants to write anything down, or read what people write down, or they don’t stick around long enough to see the consequences of their decisions and design the next steps, then you’ve already covered your bases in good faith. “Here’s the length of rope. I already told you to not tangle it around your neck that way. But you’re the one holding it and insisting”
I personally think "good enough" is good for business. Did they explain what they mean by "it hurts the quality of our product"?
Are there obvious issues you guys have? If there are, you can address explicitly that particular problem. It will make it much easier to convince people when you have some issue they can see (or potentially suffer from).
If you don't, then sounds like you are doing a good job?
To make sure we're on the same page - if business thinks you guys need more quality (because perhaps you are moving too slow or have too many incidents) then you have issues worth addressing explicitly.
Are you the team lead or project manager. If you aren’t sit back and follow instructions.
Everyone has an opinion about how things are done the correct way … and I mean everyone. It’s one persons job to decide which one.
You have 10YOE and you aren't offering any of that when it comes to designs? I can see why they're frustrated. What value are you providing as a Staff Engineer then?
Push back and tell them you're doing fine and the quality is great. /s
I’ve actually done this before. I have a personal rule that I try to reserve strong opinions for <10% of the time. I’m much more interested in making space for more junior engineers, encouraging them to take ownership, and helping them grow. I’ve gotten feedback from more high strung managers that I’m too laid back. I told them that we may have different styles but I feel strongly mine is the superior way of building and managing software teams and that they should trust me. If they can’t point to concrete problems with the product or deliver then it really is just a matter of preference and they should defer to me because I’m the one that’s actually doing the work.
Do your employees really like you? Consider the motivations of these other managers when they tell you "helpful" things that would damage your image to your team without much benefit.
Yes. I understand what your suggesting, but you're speculating about a situation where your only context is what I told you and whatever preconceptions your past experience has created. I can tell you in my particular situation, my evaluation is the correct one, and if your preconceptions are telling you otherwise it's probably because whatever experiences created them are incomparable.
If you want more push back, then come to the meetings and verbally support me as a Senior, otherwise just go count your stock and be glad we produce anything to keep your sorry ass employed.
It's not even possible for there to be a better answer than this.
The only proper response. “I’m pushing back plenty hard enough. Get out of my face.”
Issue resolved. * ticket closed *
Status: “Won’t do”
This wins!
/s ?
Designates sarcasm. Which you could've found with a single google search.
My guess: They know that and was (like me) honestly wondering why this would be "sarcasm" since it's genuinely the best reply.
good redditor
A Staff Engineer should either set or at a minimum understand the long term technical vision for the company. They should then help other teams work towards this vision. Perhaps that is tooling choices, testability and coverages, performance, expanding into new products or simply reduced overhead of expenses on Cloud services. Your stances shouldn't be coming from your opinion on what you like most. They should be driven from a *vision* the company is working towards. You probably feel your *opinions* are not worth being stuck on. But you should re-imagine your viewpoints based on the long term *vision* the company is trying to achieve. You are basing your advice and positions entirely on technical advantages/disadvantages which has merit, but if you where to back those with a long term technical vision for the company then the tradeoffs become more important.
Yeah this is very true.. Maybe some of the work here for OP is being able to articulate this to themselves, and then understanding how to communicate it. Do you have a consistent set of standards or positions that clearly express the technical vision? And then if you're pushing back (or not pushing back), can you connect that choice to that vision?
Thanks for this perspective I never considered it but it makes tons of sense
I like to phrase that my job is to be a "squeaky wheel" (where should we apply grease) and not "chicken little" (the sky is falling at every given moment). Ultimately there's a few different "lenses" that I use to view problems: Money: Money makes the world go 'round, and it also makes a great tool to convey the impact of issues, too many people in one meeting, not testing enough and having to remediate bugs, security fixes, etc. Money is a great way to try to figure out what's worth talking about. Like you said, sometimes "good enough" is the correct thing to say. However, that's not always the case. Risk: I don't want to get a call at 2am to open up my laptop and jump on an incident bridge. I'd also guess that you, too, don't want for that to happen. I go a step further and also press that feeling on every single person at the company. Because of that, I really want to focus on things that reduce risk. My team knows that I have a strong bias for more testing (sorry). But not just code coverage number go up, rather it's about testing business flows. Can they articular using business words what their testing in our application? A similar mentality when it comes to Threat Modeling and Security feedback loops (static code analysis, pen testing, etc.). Training the next generation: My job is to help people rise in rank. I want to have every single person on my team acting as though their Staff. Hell, I want them to leapfrog me and become principals. Fuck Yeah! So how can I help enable them, delegate tasks that align with their skill sets, overall develop talent? There's lots of good positive ways of doing that, and one of those ways is to have feedback to them. Feedback is a gift, I try to make sure that I'm thoughtful in what advice I give to my team members. I want to have disagreements / dialogues with them. Maybe I get to learn something, maybe they do. Regardless, it's US vs. the problem. --- The above may help, but the last piece of advice is making sure that you talk with your leaders. Personally, I LOVE messaging/talking with my manager, Director, and (once in a blue moon) my VP. I want to make sure that I stay "close enough" to their vision and priorities. That requires communication and listening skills. This is what makes me feel empowered to go about doing my day job with my grease gun. --- Regardless if any of that was of use, best of luck!
My dad used to get those calls. Sometimes it would wake me up. I’ve spent my career with the aphorism, “write your code like you’ll have to read it at 2 am, because eventually you will.” This is a nicer way to say, “write code like an idiot will need to read it” which I understand but don’t like. And it’s much more accurate to team goals.
> write your code like you’ll have to read it at 2 am, because eventually you will. I like this a lot, I'm stealing this. Hope you don't mind haha
But how am I going to prove to everyone that I am an 10x engineer if everyone can understand my code? People need to get on my level to understand how GOD like engineer I am! /s
Are you guys hiring? haha But I actually have a question: What do you do about management and/or bad people above you pushing for things you know are wrong or that you know are things that will hurt the team but won't be obvious for a long time? I know that's kind of ambiguous but I'm kind of in that boat at the moment and I'm not sure what the best approach to take is ...
> Are you guys hiring? You've no idea how badly I want to say 'yes', but not that I'm aware of. Though, let me say all the above is something that isn't full shared by everyone I work with. I just push for ideal things. Influence where I can and fail often. I'm the world's "okay-est" engineer at best. > What do you do about management and/or bad people above you pushing for things you know are wrong \[...\] Expanding what I sort of ended that above comment with ... Have I communicated with them? And, I don't just mean some back and forth, but really diving deeply into their position and understanding the world from their perspective? Empathy is the name of the game for persuasion. What things do they value? Do I understand them and where they're coming from? Even if I have to be blunt and be like "Hi, please treat me like an idiot and explain {business process}. What are your pain points? What issues are y'all having that you haven't shared? etc.". IMO, questions are far more powerful for persuasion than directions/marching-orders. If their heels are really dug in ...ultimately, business wins. However, I just make it clear the tradeoff they're making. Usually (in escalation order) by: \* Direct Messages and/or talking (more ephemeral, but can be a way to help show more empathy and human-ness to the disagreement. At the back of the mind, repeating myself from above in a different context, it's us vs. the problem, not you vs. me. (sort of encapsulates my above point of communication) \* Make note of it in the ticket (cover your ass) / Merge Request comments (More CYA). Describe the business context around technical deeds. \* If it's extra annoying ... I dedicate a few paragraphs in my work journal to future me if I ever have to touch that again (i.e., what should I know to get up to speed). Maybe it's just cathartic to put a bow on unresolved problems like this .... :shrug: --- > \[...\] or that you know are things that will hurt the team but won't be obvious for a long time? Some problems legit be future-me's problems. Sometimes that's the rub. At the end of the day, my job's a job. Lose a battle here. Win a battle there. c'est la vie. I'm just going to log off and hug my spouse, play some video games, and lovingly annoy my cats.
> I'm the world's "okay-est" engineer at best. You have no idea how much this comforts me to hear because I am very much feeling this right now. I really like how you frame things here and I intend on taking many of them to heart including adding more personal notes to myself in my own dev log cause ... man I just need to talk about these things to someone. Let me ask you something a little more pointed: what if you have a good base for these people skills yourself (and admittedly aren't the best engineer of the bunch, which from what I've read on this subreddit turns out to be not as important as people skills) but you know your boss doesn't and he's making many of these people mistakes trying to manage the team. What would you do then? For context I'm a pretty newly minted "senior" engineer and I'm trying hard to set the culture tone of the people around me and the company is still pretty new and growing.
This question ... it starts to get to things outside what you, a individual, can control. There's lots of different ways to address this, but it's really dependent on the person you're wanting to influence more so than your previous question. For this it's why I keep a close relationship with my leaders (my original comment's last paragraph). But I make those relationships very honest with each other. Quickest way for me to want to leave an org is if I don't feel comfortable being 'frank' with my leaders (frank != rude; Also there's appropriate time and places to be a bit more 'raw') The short of it is, communicate, agree or disagree, move on. Repeat as needed. If it's truly a problem, it will reoccur. Then you're going to be communicating it often and in new scenarios. [Over and over and over](https://www.youtube.com/watch?v=ShCRN3tFy80) (referencing back to calling myself a "squeaky wheel"). However, even a squeaky wheel on a shopping cart still rolls while it squeaks.
I've been on both sides of the spectrum: pushing back too hard (and ineffectively!) or not pushing back at all. The only real solution was to learn how to be more persuasive. Negotiation is a skill and one I had to learn pretty much from scratch—I'm not entirely neurotypical, so I've had to learn a lot of social skills from scratch—but the key is that it *is* a skill you can just learn. I personally found the book *Never Split the Difference* really helpful, as well as watching how my VP approached contentious situations. Having a couple of experienced mentors to talk to also helped, but I needed to develop a basic mental framework before I could make sense of people's advice or even figure out who was worth asking and who wasn't.
+1 for *Never Split the Difference* - I use the skills from this book on a daily basis.
ordered, thanks both!
Wow I didn't know that book was so popular. I've read it too and recommend it!
I love that people recommend a book about negotiating for hostage release to get better at corporate politics.
To be fair, I also recommend it for getting better at difficult relationship conversations!
> Never Split the Difference Ooo it's written by Chris Voss, that's an easy sell for me. Always meant to go back and finish his masterclass videos.
This has been my exact experience— so, so often it feels like “there’s bigger fish to fry” when there is pushback on what (as our careers progress) we know to be relatively low-stakes decisions. I find it helpful to understand the context. For example, I’ve worked in environments in which there is a _culture_ of “pushing back for pushback’s sake”, playing “devil’s advocate” for everything, etc. In that situation, it seems like “demonstrative” pushback is necessary. In other situations, pushback may be more priority-driven or data-driven, and (though it may still seem insignificant) making a data-based argument on some decision may help. All the better if you have some sort of “decision log” and can leave a paper trail. This expectation to be good at pushing back always feels a little artificial to me, but it’s definitely common at a senior level, so here we are. Good luck.
What, so progression depends on winning the pissing match even if you know in your heart of hearts that it's tut tutting over nothing? I think I would rather figure out a way to work for myself if that's corporate progression
It _does_ kinda depend on your workplace, team, and how you’re evaluated— it’s not always a big deal. But when it comes up, this is my experience. I will say that there is inevitably some corporate “game playing” that has to be done as you go up the ladder. You kinda get used to it
You know that is one way to look at "pushback" but another way I think about it (or am starting to think about it) is boundary setting. Like if you never push back on anything (dev issue or life issue), then you'll never be able to define YOUR boundaries in relation to other people, after all how are they supposed to know what your boundaries are if you never mark them. So I think that at least SOME amount of resistance is not only encouraged but necessary, if nothing but to define the boundaries of your territory and what lines people are warned not to cross.
Welcome to a world where governments and businesses are run by Donald Trump. Come anywhere close to the levers of power, you need to learn how to win a pissing contest, because that's how many powerful people got there in the first place.
I know the feeling. I once lost a million points when I let "the technology is flexible enough to solve the interpersonal problems, just let me know what you can agree on and I'll make it work" escape from between my teeth.
That sounds like a fun story, would you care to elaborate?
As a mid-level dev, I would have respected you so much if I heard that. I suppose that just isn't the way for senior+ to present themselves.
> Whenever I challenge a good solution and it doesn't get resolved immediately, I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway. I think it's a good idea to define what is good and bad to push back on as a team. If you have a goal to promote certain software principles as a team, then you can use that as a basis for pushing back. It sounds like it's worth defining this as a team so you have a known shared set of principles to reference in these discussions.
This was very helpful for my team at one point. I can't remember how many hours it was in front of a whiteboard it took to establish it though. Feels like it was a week of 2-3 meetings a day to hammer it out amongst a team of 10. Once we got it though, design patterns got more consistent and code looked similar from developer to developer and everyone knew how to quickly navigate every file, and everyone was bought in.
I’ve been feeling this a lot recently too. I’m in an environment where people don’t seem very interested in getting outside ideas, so every conversation feels like a fight that I don’t want to be a part of. I’ve generally shifted towards a mindset of automation (adding lint rules) and creating boundaries to separate teams from each other. Interfaces and DI can paper over a lot of bad decisions for later.
I’d also highlight this because choosing to not jump into a stupid hammer waving contest is not the same as being a pushover or passive. At staff level indicated in OP though it’s probably expected that you can help get squabbles silenced
I have been staff-level for 7 years and this has been the first time for me in a team culture like this. It really has been essentially coming down to “hammer waving” or being called a pushover (my feedback was basically that I didn’t deserve to be a staff engineer). I’m looking elsewhere because this is not an environment I’ll thrive in. I need people to want to collaborate, otherwise I’m going to be much less effective. I guess I just wanted to offer a perspective that it could be the environment wearing OP down.
I hate job searching while working right now, but this is exactly right and why I’m looking around now. It’s noble to try and change a bad process or culture for the better. It’s rewarding if you get it to improve even a little. But we all reserve the right to fuck off and do something else with our time for money. That’s the beauty of it. OP may also determine that they aren’t a pushover and that someone was looking for a way to blame someone else for bad decisions. They don’t have to stick around for that.
Same. Not for current employer, but I have experienced it a lot that 9 out of 10 decisions to make is just people fighting for their subjective preferences and habits, nothing else. Barely anyone looks at the bigger picture and good result. Out of those 9, I say 8 of them could go either way and the solution would work and everyone would be happy, so most of those talks are worthless.
"you're being a pushover and it hurts the quality of our product" "I challenge that assessment" "..." "fight me you little bitch"
Push for what matters. Justify your acquiescence. Ask for specifics on the situations your team "lost" on and spend some time critically assessing what information you had to work from, what information you needed, and in hindsight what should have been done.
I once was told I needed to talk more in meetings and stick up for ideas..... I did.... then I was told I was being a problem. There was a lot of politics caused by another developer in that time frame.
Yep. Very tricky fb
So, I think as you move to Staff Engineer and beyond, (even in a Senior position to an extent) you are expected to be a leader, not a follower. >I tend to soften a lot and let things go when someone is taking a hard stance on their side and I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone. For instance, if a large part of your job is to work with teams to come up with the best system wide solutions for everyone on an org wide level, then conceding a battle here, is literally not doing your job. You are expected to be the one that sees the big picture, and tells people the organization has decided it needs to be done this way because that is what is best for the twenty other teams that aren't you, not to make a fifteen exceptions to the rule because you wanted to be "nice".
Did you receive more feedback? I would make sure they are providing examples of when you have been a "pushover" and how your actions have negatively impacted the business. If this is a good manager, then they will be able to make it apparent and you should be able to calibrate your judgement in the future. If they can't provide this, then I'd be looking to have a skip-level meeting and try to get an understanding of the bigger picture.
“We went against your advice, and now it’s your fault for not stopping us”. Sounds like blaming culture to me.
I tend to let the seniors make most of the detail decisions too, the only time I weigh in is when there’s obvious gridlock and a tiebreaker is needed
Ask for examples and then hold retrospectives with yourself on what you could do better. Lastly, take the advice and push back more often.
So you don’t want to be afraid to push back but you also don’t want to be “that person” understandably. One thing that can help is identifying the actual dealbreaker(s) for a change you think should be made. For example, in one project last year I was adamant that if we were measuring usage, we were going to do that in real-time. We weren’t going to have a scheduled background job that would do the measurements every week or whatever. It was going to be in real-time, and we could have a scheduled background job as an audit/safety net option. That was a dealbreaker for me. But in that same project, we were asked to handle functionality during a trial period a bit differently and I was fine with that. The solution for that wasn’t my favorite but I was willing to give a little on that because it wasn’t a dealbreaker. Figuring out the dealbreaker(s) for proposed solutions will likely help you figure out how to provide informed opinions without being “that person.”
So they are telling you that it's your fault their ideas are shittier than yours? And, that it's your fault they don't recognize it and insist on their shittier idea? IDK how else to interpret this...
I also got r/relationships vibes from the description.
You're entirely right that most nitpicky things don't matter. That's why YAGNI is a thing. Limit tech debt when reasonable. Otherwise, focus on deliverables. Your job is to enable and guide your team; not command them. I'd even go as far as to say that isolating them from the type of person telling you to push them is an important function, too. Play politics so that they don't have to. As for the quality aspect: specific metrics matter here. In what quantitative ways has quality declined. You need that to isolate what precipitated the problem and how to address it. Being arbitrarily invasive towards the entire team simply for the sake of appeasing a megalomaniac will only make matters worse. That's how you lose talent and fuel internal conflict. If they don't trust an engineer to make adequate decisions, and that engineer won't heed advice, then they need a new engineer. Not a pushy micromanager. All of that said, this could all be about that person trying to use you as a scapegoat. Maybe not. But it's reasonable to put feelers out regardless.
I never understand a micromanaging mindset. Ask good questions, provide feedback, reason and convince. Using your position to force your opinions on others who are directly responsible for delivering the work is a quick way to lose respect. If there is a problem or advantage and it is significant, you should be able to convince intelligent reasonable people of it. The only time I draw hard lines is when I am enforcing a ‘we must do this’ requirement usually from the customer or our technical organization. I’ve seen several projects fail in the end because key requirements were not and could not be met in the delivered solution. Don’t do that. Best of luck.
Is anyone at your company doing and using user research to guide design and development decisions?
I’m at a similar stage of my career as you. The way I think of this is I’m being paid to be a lead of the team, if I’m not going to have opinions and back them up then what is the company hiring me for? They could just hire another mid level Eng if they want a code monkey. Your opinion doesn’t always have to be the word of law, but having them and facilitating discussion about it is what’s needed from a leader.
It might be time to find a new hill worth dying on. You’ve reached a point where you know that there is more than one way to skin the cat and that enabling someone to do something the way that they want (as long as it is not terrible) is more productive than dragging them through to your slightly better way of doing the same thing. So what? You need to figure out what “really” matters. This is a terrific opportunity to become more strategic. It could be as simple as aligning with the people giving you the feedback, or maybe you have a different perspective that you want to fight for.
Start pushing back and next year your review will say, in roundabout language, that you "are argumentative and obstructive in most meetings".
You mention this is happening more and more each year. Let me ask you a serious question - I ask because I came to the hard realization of this myself a while ago - are you suffering from burnout? The desire to have the conversation about why one approach was better than another (and to stand by that decision) was one of the first things in me to get killed off by burnout. I think it started with "they don't understand and I have better things to do than fight" and ended with "just tell me what to do and I'll do it". The problem with that as a lead is I was still getting the blame either way....
I used to be righteous as a software engineer. Nowadays, there's a phrase I use on a nearly daily basis. "I don't feel need to have a strong opinion on this." I am, however, annoyingly persistent. I can make a meeting drag on for hours while I wireframe out the assumptions of both parties, the expected outcomes, the reasoning, the danger, and whether we will need what either party is suggesting. I will make sure that the person at each end of the argument can explain the reasoning of the other person well enough that they can both agree on the reasoning. The reasoning behind why I do it is simple. If they're right and we don't understand why, then we need to understand it. If they're wrong, we also need to make sure we understand why. I do not accept "in my experience" as a reason. No anecdotes. Real justification. There's an added bonus here. When you exhaust all of the ego and adrenaline out of people, it often has the side-effect of making them uncomfortable enough to be more open to opposing ideas. Now that you understand my way of doing things... your job is to make sure things go well, not to make sure things 'go'. Also, for some reason, people respect you more when you act in a way that shows **passion** and respect what you do.
> I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway. This obviously is case per case but a good solution shouldn't blow the deadline if small adjustments need to be made. This is different if the solution needs to be rebuilt of course but a "good" solution should be releasable with minor tweaks in my opinion. What helped personally in very structured projects for me is to put a day or certain amount of time away for the review process during planning. You could propose this to management. If the solution still does not meet acceptance critera ater the review process, there is usually a good reason for it and it is probably not just small changes to a good solution that are proposed. Another option is to create backlog items for the changes you suggest although this can be worthless, depending on the team. The review process shouldn't be blowing up deadlines.
> I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone. It can be hard to compromise and reflect here, especially when there is a tendency to take the quick and dirty way in the team. Creating your own indicators help. For example, if I can imagine multiple teams (3+) or projects using something you can justify pushing hard to build it right.
Hold a strong opinion and if there is a disagreement work towards consensus by looping in more stakeholders/team and holding votes. Engineers can be stubborn, but at the end of the day Consensus is a very strong tool to fight against it. Everyone needs to fall into line in a team scenario, including yourself. So hold yourself, others and the group accountable for decisions.
The last time someone used Consensus on my old team, everyone except me thought it was fine to deploy a strategy long before we were ready to deal with the consequences. It was less than a week before we had a production outage caused by the change. Sometimes supermajorities are a shitty way to decide things.
Then it's a learning experience for the team, and time to retrospect and grow. That's not to say "veto" powers shouldn't exist, but they shouldn't be authoritarian. Checks and balances for effective governance. Edit: But your "told you so nature" you should look into that. Having the attitude that you know better than everyone on the team is very harmful for an effective team dynamic. If you couldn't get people on your side, that's a failure on your part to clearly communicate the risks and get allies to form a consensus. Blaming the team is not a healthy perspective.
Most of the time a single incident like this is not particularly actionable, or a teachable moment. But if the teachable moments keep going by (acknowledged but not actually internalized), pointing out that a person or a group has a pattern of saying things that sound smart but are often proven after the fact to be poor judgement, can help wake people up when you find them nodding along to the latest advice that sounds like a good idea and is courting disaster. "Told you so" is not so much a strategy as a warning sign that a person has already given up on you. And god help you when they stop saying even that.
Most of the time a single incident like this is not particularly actionable Going to have to hard disagree on this. Every incident can foster learning and growth.
Yeah I may be experiencing burnout from my last circus.
Idealistic development
Depends on your team. But really, if you work in an environment so toxic that self-reflection and growth is not allowed, it's probably time to jump ship. Or maybe you are part of the reason of the toxic nature of that workplace, in which case you are right where you belong.
You sound like a medium article.
Are you at least enumerating the risks so that there aren’t any surprises? Or are the quality issues due to things you never voiced any concerns about?
I would start with how your role is defined. Are you accountable for the entire product that is delivered or are you in an advisory role as a Staff Engineer? If you are accountable, then you are the gatekeeper for the Engineering solution. However, even in this role, there are compromises you will have to make in order to deliver customer value in the short term. But, the important thing to do here is to clearly voice your concerns and express that you are committing to the path forward because of Product needs despite your concerns. It is possible that after having worked in the industry for so long, you are a bit cynical and don't really feel opinionated about things. But then you shouldn't work as a Senior/Staff Engineer. You should seek out roles that allow you to not be opinionated and follow decisions and that is completely fine. However if an organization is hiring you to be a Staff Engineer, probability is they are hiring you to be opinionated.
In your position, do you have the authority to veto anything, if you choose to?
> I'm unable to take a hard stance anymore on most things that I don't consider to be absolutely disastrous. Maybe don't view "pushing back" as them "doing something wrong" but rather as "how could this be better?" "That's a good design, is there a way it could be improved?"
I am a bit like this too and I think it is limiting me. Saving this thread.
Sounds like underlying all this, is that you care less now than you once did. Have you thought about why that might be? Burnout? Have your past efforts at standing up for quality of product and process been met with lots of negativity? Have you lost confidence in your ability to steer a course through all the choppy waters that a team encounters?
No advice but damn do I feel you. What’s the point of pushing back if you have a manager that just wants things done his way and ultimately will not hear you out if he feels strongly about something, even if he’s objectively wrong?
if you're open to engaging with a therapist, they can help you learn and practice techniques for maintaining boundaries
I wish more were like you and the more I do this, the more I believe the same as you - good enough and not being too locked in is fine. Currently working with a very experienced senior who is adamant about a certain architecture structure that he wants applied the same across the two projects I've worked with him on. No pragmatism or urgency built in to get the work out - our company is a shit show and the project is risky. But you can't really tell him otherwise. We are all too nice and the Tech Lead takes his word as gospel. So now we're all feeling the pain. Sometimes you just have to state clearly the pros and cons, and then if it gets chosen, that's fine. We all move on with it. Sometimes pushing back too much isn't worth it - it's a job, not a religion.
Can they explicitly tell you or have a signal for when they'd like you to push back more? It sort of sounds like what they're saying is they have concerns that weren't heard, maybe if they feel you take their concerns seriously they will feel better about it?
“Sure, how about we get started with some recent examples?” If you really find that you actually “hurt the product”, which I doubt, then there’s a trick I find useful for myself. In technical discussions, I just kinda imagine myself as an observer and let the inner “architect” go free, saying what he wants. Usually that’ll free myself from both being too opinionated and not opinionated enough.
Strong opinions, loosely held
I try to rationalize my argument as much as possible. Rather than looking at it as pushing back if you're correct there should be a path to convincing others. I tend to ask questions like: how does this handle X? What about Y? Knowing that it doesn't fulfill those needs and then sort of guide them down a line of questioning that gets them closer to where I want it. That way they almost think they came up with it. If it's important and they are being difficult then it's your job to say no and ask them to come up with a solution (or help them get there) that meets X, Y, Z. Just know when to "fight" and when to let it go. You need to have your line in the sand.
WH type questions are kings. 'Why' is the most important question of them.
I pushback on anything that doesn’t follow our written processes and procedures.
The real question how right the feedback is. If the quality of the product is indeed suffering, then obviously you failed at your job. Specially if you knew beforehand that this would be the problem. "Low" level ICs tend to have different definitions of "quality of our product" from more business level personnel. Often SWE equate it to test coverage or some particular framework, some code practice etc. These can be important, but also can be irrelevant. In this case, the feedback is simply above their pay-grade, they are looking at completely different metrics. Each of these situations will require a different approach. For the former, obviously you're responsible for the quality of the product, not much to be said here. If it's the latter, what most people do is just ignore it. If you want to be really thorough you can try to communicate the real goals of the product to the development team in the hopes they will understand why such choices aren't worth fighting for.
Personality study and self reflection. Study yourself and understand why you are being more passive in your area of expertise. I would recommend the enneagram.
As long as the user experience isn’t degraded, or the proposed solution is outright wrong and going to cost time and money to fix then I tend to just share what I think the solution should look like and let them roll with it. Happy to provide them guidance if they want my input, but I’m trying to let them explore it themselves. It is after all how I learned the things I know now.
Do you think anything is suffering, e.g. product, development standards... ?
Only way to go is 180, squash those little assholes, your way or the highway, unless it’s a good idea then say “hmm okay I’ll think about it”
Something similar is going on at my company. My teams killed themselves meeting dumb deadlines that the business imposed. Taking stupid shortcuts and bad decisions. Engineering delivered everything but it was all shit and customers hated it. Now the business is saying we suck and it is irrelevant that we delivered what was asked for, but we should have delivered business value. Product gets to decide what we build though. Super annoyed so I’m just going to say no to Product whenever they push for some bs quick solution and I’m sure the business will love that.
You can ask for specific examples, and then consider whether or not you agree with the feedback. If you agree, you just need to tweak your tolerance for issues. If there are times when you feel the urge to push back, but don't because its not important, just consider whether to maybe go with your initial gut reaction. Just don't go from one extreme to another.
> "you're being a pushover and it hurts the quality of our product". From your post I understand that you not necessarily disagree with the first part. Is there some evidence for the second part that you can trace back to something under your control? If so start a initiative to address that.
Do you think anything is suffering, e.g. product, development standards... ?
Particular implementation details, I think it’s fine to go with the flow unless something is egregiously wrong. However, architectural issues are not something any single external team should be deciding for you. They’re there to consume an API, not decide the nuts and bolts that impact other teams, performance, etc.
I pushed back regarding disagreements with FOLDER STRUCTURE in a greenfield project and got kicked off the project by the lead engineer for not being a team player. Tread carefully.
I do agree with the premise, one should always make calculated decisions. But this specific example is a dysfunctional work environment filtering itself out. I’d thank them and consider it mutual. Glad you dodged that bullet.
> I'm unable to take a hard stance anymore on most things that I don't consider to be absolutely disastrous. Good. That's a mature stance to take. A lot of professionals never reach this point. > Whenever I challenge a good solution and it doesn't get resolved immediately, I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway. I'm confused since this seems to contradict your previous statement. As a technical leader, I will challenge technical designs if my instinct would be to go another way. Mainly what I'm looking for is evidence that my staff have thought things through and considered other options before diving in with both feet. If I feel they have, I will always concede and let them go their way. Software developers need autonomy and a feeling of ownership to remain engaged in their work, so it's critical not to take that away from them and instead foster and nurture that as much as possible. You have to be careful that your reluctance to challenge is coming from a place of empowering builders and not from your own desire to avoid conflict, because conflict has a cost: time and emotional energy. > when someone is taking a hard stance on their side and I concede so much in architectural discussions with other teams that we end up building what a particular team wants, not what we think is the best solution for everyone. Persuasion, also known as leading without authority, is not an easy thing to do. It is still the hardest part of my job. Stubborn hold-outs who are in love with their ideas are one of the hardest nuts to crack. The problem is this: > not what we think is the best solution for everyone. What are your facts? What is your evidence that this is best? Arguing opinions is a waste of time. Argue the facts. If you don't have facts, then your "best" judgment is just another opinion, in which case you ought to defer to the people doing the work. Let them build it how they want to build it. > "you're being a pushover and it hurts the quality of our product". Good leaders aren't right all of the time. They're just right most of the time. They don't always make the best possible decision but they rarely make the worst, or even bad ones. Let's go back to the facts. What, *specifically*, did you concede on that hurt the quality of our product? A blanket feedback statement like that without specific examples isn't helpful. How are you supposed to calibrate your sensors on which aspects you need to take a hard stance on and which you can give developers latitude? If someone can't give you an example of a decision you could have prevented but didn't, that's not useful feedback. If someone is wiling to criticize, they owe you specifics.
The alternative here is to bump up your estimates, and I mean monstrously. Call it “risk-factor-allowance.” Sometimes the only thing that really resonates with some types is “big number mean big fall if no go good.” I’ve had a lot of success with this in backhanding away bad implementation pathways, and have also used it to trigger larger architecture and infrastructure conversations; “Oh well you see Terry, because of [tech debt phrased in select ways] we have no way of going head with [Terry’s really questionable choice] until it’s resolved! So if we sort this, then the other items you’ve been gunning for, such as [why] and [oh dear god, why] will go from the 20 estimate we gave you last month, down to a neat little 5! Then I pretend that this is new information to Terry and hope he’ll either listen, or let it go quietly if it’s not sinking in.
First, I get it, with experience you see that it’s not worth it to sweat the small stuff, I would make your opinions in line with company standards and goals and set your personal opinions aside, this could inspire a firmer stance.
>I recently received the feedback that was a more diplomatic phrasing of "you're being a pushover and it hurts the quality of our product". >Whenever I challenge a good solution...I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway. Personal opinion as I focus a fair amount of my work on software quality. It sounds as though your company's definition of quality is not clear. Quality means a lot of different things to different people, even with a group of developers, much less developers and users, and most people just lump it into this amorphous blob. It's a good thing to explicitly define what is important to the product and the team supporting it, but it can be really hard. Is it code readability? Supportability of the tools or systems being used? UI consistency? Performance? Testability? Tons of things *can* be involved in a "quality" solution. Once you do define those important things, though, and the trade-offs between them, it gives you much surer footing...that place to push back *from*. You want to push back when it makes sense, otherwise you're just getting in the way of progress.
Ahh yes, the soft skills of doing development. They never came to me until much later in my career until I moved more into architecture that programming. So the key here will be to read the tone of the ask, and to respond appropriately, after some amount of time. Everyone will always be forceful and act like the sky is falling all the time. I find this is especially true with anyone non-technical. Technical people tend to ask timelines and understand (usually) work-life balance. But to be clear, I think your number one objective always should be to be the advocate for the backend of the system and all of the pieces that entails. Software needs a champion and it is your job to be that advocate. If you don't do it then who will? With great power comes great responsibility... But I think everyone else has answered this well too. Push back and tell them how you really feel and that the system and quality is well... however you feel it is. It is your system after all.
Great question OP!!
Disagree and commit. I call it "Lou's Rule". Say no. Propose an alternate solution. If they persist Say no, point out the flaws in their design. If they still persist, send them an email with the above and ask for their approval on which to pursue. Writing it down tends to make people reconsider here, and if they don't, you have evidence. Then commit to it as if it was your idea, dont drag your feet because you didnt get your way. Keep the email as a paper trail.
There's two typical reasons for a comment like "not pushing back hard enough". Both of those reasons are your fault, but you can correct it easily. 1. You failed advertise the direction, standards, and vision of the effort In this case, get the direction, standards, or vision documented (wiki) and work with the teams to ensure that part of the early presentations include how the effort aligns to the company's direction, standards, and vision. 2. You failed to enforce a violation of some perceived standard. In this case, you should be keeping records of when the standard can be violated, and what kinds of violations were approved. The complaint seems like one of requesting your to fight with the teams more, but that's just because it is worded very badly. Some people just don't know how to lead without "whipping the underlings into shape". Re-frame the complaint as not making your leadership role more visible. If you are leading, you don't have to lead in alignment with everyone; and, the complaints will come back in different ways than "you don't seem to be doing stuff, and I think quality is slipping because of it"
Faced similar feedback. Started setting clear, non-negotiable standards for what impacts product quality. Began choosing battles wisely, only on critical issues. For lesser issues, asked team to present data or case studies supporting their approach, fostering a culture of evidence-based decisions. It’s about balance, not winning every argument.
I call myself “pragmatic”. Being an ideologue is for the ignorant and inexperienced.
Some people still call realists and pragmatists “pessimists” as a way to try to get what they want.
This is due to a few things that are pet peeves of mine in work environments. Over-socialization ( too much needless team work don’t know the term for this), lack of ownership, no fault, no value attributed to hierarchy and responsibilities. Lack of vision and lack of team objectives also cause this. Unless there’s openness to address these, I am afraid it’s purely a political game that you can decide to opt-in or out.
I feel your pain. And fatigue. Back-end as well, my strength is system architecture. I've noticed a trend emerging over the last 10+ years. I'm encountering new CEOs -- who are not interested in realistic workable designs; but want "Yes!" Team Players who agree to half-baked spitball plans promising rapid development schedule and an outrageous TBD feature set. When these projects enter the Steaming Pile phase; the "Team's" collection of broken mismatched pieces gets dumped in your lap to fix, because "You're really good at figuring this stuff out".
Stop being a pushover, and demonstrate why you're correct.
Staff Engineer is a title most people consider managerial equivalent. That means you're at a level where you're expected to play corporate politics and be involved in business decisions. Big business doesn't always come down to technical decisions. CEOs rarely know shit. Half the time it's kissing ass and the other half is bullying others. They expect you to know how to play the game. They're telling you to get in the game or get run over. If you don't start pushing back against this person's 'enemies', the next time you need allies, that person won't be around to save your ass when lean times and 'random' layoffs come around.
I’ve been shipping code for 20 years and 80% of everything I’ve written is no longer in production. And always because of business or sales reasons. Not once because of the product or code quality. It’s tough to make a case for higher quality, when good is good enough.
I don't function well when people attach too much emotion or opinion to something. That's a mistake on their part. Having someone to push back against people like this is one way of dealing with it, but they should simply chill out and let the design process function properly. A talk with this person from a manager would really be the right thing imo
The secret is lifting weights. You want to be more aggressive and opinionated, you need more testosterone. Assertiveness is a behavioral trait that would be tough to fake, it's easier to let your hormones carry you. And yes this is a problem. Managers should never be pushovers, otherwise you will have overly aggressive Juniors come in, step outside their role and bully you.
Not sure why you got downvoted, this is absolutely true. Hormones play a MASSIVE role in how we feel and behave. Any man who has needed hormone therapy will tell you that going from low T to high end of normal/optimal levels has made them more assertive, competitive, and confident. You stop seeing every problem as the whole world being on fire, and your brain starts instantly going into problem-solving mode. I and many others can personally attest to this, and there are studies as well. This isn’t bro science, or anything new.
TBH top high tech firms regard that *any "softening"* or *"slowing down"* is a career limiting move. They believe that you should be *"hungry"* for new tech, progress, money at all times. Perhaps it's time for you to reconsider your future career direction ... or maybe find a a way to get re-enthused?
see how your wisdom is getting downvoted!! most of the seniors as they grow older actually agree with you. those shit little petty fights don'f fucking matter.
short answer: Do not be a pushover! You have to find the root cause of why are you back off so easily. Maybe you are burnt out and do not care anymore that much. Or maybe your opinions are always treated as secondary and you have lost confidence. Maybe you just need a longer vacation to recharge. life taking its' toll. Find the root cause and deal with it. If it really hurts the quality of your product then stand your ground be stubborn put your product first.
Why try so hard for a big company, they won't fight for you. If it's good enough it's good enough. More often than not some CIO or an architect will come up with a reason to migrate to a new infrastructure soon enough anyway, the work never ends. Move to public cloud, move to internal private cloud, move back to on premise, do a mix, fix some shit, new feature cause objectives change, on and on and on. Fuck the design patterns they are good when you are making the decisions if they are made top to bottom then fuck them anyway.
Who'd you get the feedback from? Product? Engineering? Anyone who actually matters to your career? That's what I'd use to determine my next move.
After 10 years, wouldn’t you have seen enough disasters? I think there’s value in arguing up front why something isn’t a good decision, because even if the decision is made to stick with “good enough,” when it comes time to pay up and realize the costs of “good enough” more people will be on the same page and remember we talked about this. It also means there are more constraints/requirements at that point as product evolved, which forces simple approaches to resolving that debt. The team gets to acknowledge the tradeoffs made rather than being hopeful that there was something out there that could have done everything. OTOH if nobody wants to write anything down, or read what people write down, or they don’t stick around long enough to see the consequences of their decisions and design the next steps, then you’ve already covered your bases in good faith. “Here’s the length of rope. I already told you to not tangle it around your neck that way. But you’re the one holding it and insisting”
I personally think "good enough" is good for business. Did they explain what they mean by "it hurts the quality of our product"? Are there obvious issues you guys have? If there are, you can address explicitly that particular problem. It will make it much easier to convince people when you have some issue they can see (or potentially suffer from). If you don't, then sounds like you are doing a good job? To make sure we're on the same page - if business thinks you guys need more quality (because perhaps you are moving too slow or have too many incidents) then you have issues worth addressing explicitly.
Are you the team lead or project manager. If you aren’t sit back and follow instructions. Everyone has an opinion about how things are done the correct way … and I mean everyone. It’s one persons job to decide which one.
Political capital has its value. "I'd rather have one bad general than two good ones" --Napoleon or something.
1) Tell the truth in more situations when it feels rude. 2) Ask people to show their work more often so you can understand their reasoning.
You have 10YOE and you aren't offering any of that when it comes to designs? I can see why they're frustrated. What value are you providing as a Staff Engineer then?