What can I do to not try to fix every problem at my company?

March 30, 2020 3:55 PM

So, I'll start by saying I'm a software engineer. Currently, I'm working on their main product, it has more problems than they think and it is a disaster waiting to happen.

This has been a challenge for me. Although, I don't necessarily like this sort of environment working there is good for me. I've done many things that I would probably not be able to do elsewhere.

Nonetheless, it is an impossible task to fix all of their problems with this project while adding new features. Some of my colleagues are doing whatever they can to obstruct this, others do not have a clue about how to work with this and don't seem interested in learning and some think they know but they do not.

My boss is supportive, but he has a big issue with people not listening and an even bigger one with one of our team members that walks all over him.

I want to fix things, it will take a while to do so but it's not impossible. There is a time limit however, I applied to grad school and I'm waiting for answers, sooner or later someone will say yes and I'll be out of that company.

I am trying my best, but it is becoming next to impossible to fix things at this company. For one they have serious security issues, the codebase and releases are a mess and there are too many design flaws and issues all around this project. It is hampering productivity.

I want to fix all these things, but I am just one engineer, I can't do the job of a 10 person team.

What should I do? Do I continue tackling these problems in the hope that I will eventually resolve them? Should I push myself less? Sometimes this gets very stressful for me.

I've only been working for two years, but it seems like it's only my boss and I who seem to care about things.

posted by Tarsonis10 to Work & Money (18 answers total)

Instead of overworking yourself trying to fix everything, document what the issues are. Rank them according to severity, and give an estimate for timeframes to repair. Show it to your boss, and let him decide how to present the information to the appropriate people. Let him make a case for expanding the team if any of the higher ups decides to take action.

One of the things I've learned is that sometimes you have to do the job the way they want, even if it's not the correct or best way to do things. And generally, the higher up the facts come from, the more readily they will be acted upon.

Tone is super important, and pitching things in a way that execs will understand is key. Dont say 'we have to fix this or everything will break', you say 'the failure of this system could impact our customers in these ways, which would hurt our bottom line because of x'.

With your documentation, you also have a good CYA so they cant come back to you later wondering why things are a mess.
posted by ananci at 4:04 PM on March 30, 2020 [24 favorites]

So, you don't own a big chunk of the company, do you? If not, then it's literally not your problem. Document the issues, CYA with emails that you keep a backup of, and concentrate on what your boss prioritised, and what will look good on a resume 8 years from now.
posted by Sophont at 4:21 PM on March 30, 2020 [10 favorites]

Best answer: One of the interesting things about working on movies is that the 'product' life-cycle is relatively short. My involvement is generally 3-9 months right at the end of production before the film is released. After 15 years I've put quite a lot of these in the can. With very, very few exceptions they all seem like disasters from the inside. Cascading bad decisions get covered up by pointless stupid labor and the final product is a sad shadow of what it could be. Just about every time.

The other interesting thing is that we get instant feedback metrics in the form of box office numbers and film reviews. And our personal experiences of producing a film almost never correlate with these at all.

So, maybe this isn't applicable to your situation at all, but in film VFX experience teaches us that the view from the inside almost always seems dire and the view from the outside is almost always a big fat yawn. Free advice FWIW: stay the course, don't take things personally, +1 cover your ass, document everything and most importantly take a deep breath at the end of the day and keep some perspective. I've tried playing the hero that's here to fix everything and it very very much isn't worth it. My $0.02 anywho.
posted by misterdaniel at 4:43 PM on March 30, 2020 [21 favorites]

Best answer: I cannot recommend this blog post highly enough: OPP (Other People's Problems):

A hard lesson for me over the past several years of my career has been figuring out how to pick my battles. I’ve seen many friends and colleagues struggle with this as well: how do you know when to involve yourself in something, and how do you know when to stay out of it? How do you figure out where the line is?

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.

This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.

And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.

That kind of grinding frustration can wear you down over time. I know, because I’ve been there...

the tl;dr is this flowchart, but do read the whole thing.
posted by caek at 4:52 PM on March 30, 2020 [32 favorites]

"A sense that your job is terribly important is a sure sign of an impending nervous breakdown."

You don’t seem too far down that road, but you do seem like you’ve become emotionally attached to seeing the development environment work well and in turn the product be something that you can be proud of. In short you’re trying to control something you have no control over.

In your shoes, and I have been in your shoes several times, I would choose something I have control of and I would make that work absolutely flawlessly. Perhaps someday someone with seniority and political power will come along to clean up the larger mess, and I want to leave at least one section they don’t have to fix.

Admittedly it is very frustrating to create a pristine subsystem that you know will sit unappreciated in the middle of a large mess, but it’s the only way I‘ve found to take satisfaction in my work in the sort of environment you are describing.
posted by Tell Me No Lies at 5:17 PM on March 30, 2020 [6 favorites]

I've seen the "list of known problems" approach backfire pretty badly, so consider how mature or political your workplace is. The list is good to have, just to get it out of your head, but try to imagine the response before you share it widely. What response would be ideal? What would be likely?
posted by Anonymous Function at 5:58 PM on March 30, 2020 [2 favorites]

Here's a different perspective - the company is well aware of all the problems that you have brought up. The company is just not willing to commit the resources to address the problems because it doesn't make business sense.

The objective of every company is to make money. That sometimes overlaps with making a good product, but not necessarily. If hiring enough good people to fix the product costs more than the money that the product brings in, then no smart businessperson in their right mind would hire those people to make a loss.

Other times, the product simply may not have a future, and the number of people assigned to it represents that outcome. Even if the product is perfect, the customer base for it may be shrinking or it may be on the path of becoming a commodity, in which customers only want to pay the cheapest amount for it regardless of quality.

There are billion dollar companies who buy functioning products that are on the decline, slash the R&D budget, and ride the existing customer base until it no longer becomes profitable. I've lived this life.
posted by meowzilla at 6:08 PM on March 30, 2020 [4 favorites]

- keep a debt backlog
- summarize every risk
- send your supervisor a link twice a month
- do your tasking in the priority order of your supervisor
- sneak in a tiny refactor whenever you can

nothing changes without management buy-in; highlighting technical waste and idiocy will just get you an eyeroll.

Make any technical argument all about impact to the bottom line.
posted by j_curiouser at 7:01 PM on March 30, 2020 [2 favorites]

I was in a similar position a number of years ago, working as the only technical person in a small, family-owned company with significant technical debt and no desire to spend the money necessary to fix it. To the point where backups were done on USB-2 hard drives and the loss of any of the servers would likely have put the company under.

I came to the company after 18 months of unemployment during the Great Recession. I promised myself a year there before moving on. When I found a new job (with much better pay and a large IT department) and was preparing to leave, the company decided to move. All I could do was provide a complete assessment of the company’s shortcomings and recommendations for rectifying them. That was eight years ago. They successfully moved and are still in business, so I assume they took at least some of my advice. I’m glad I wasn’t there, though.

Document everything you see, then go on your way knowing you did your best. It is, indeed, not your problem, but you and your boss are good people for wanting to help fix it.
posted by lhauser at 7:14 PM on March 30, 2020

I have been in your shoes a lot of times and I feel just like Tell Me No Lies. Find things you can fix and be proud of, and try to ignore the rest. When you can't ignore the rest anymore, it's time to look for a new job.
posted by value of information at 7:20 PM on March 30, 2020 [1 favorite]

There are a lot of Opinions about the Agile Manifesto, so if you don't have one yet, you can start today. Here's a line from it:

Working software is the primary measure of progress.

Is unit-tested, SOLID, yada yada code better? Sure. Does that pay the bills? If building all of that takes an extra 6 months, then no, it actually does not pay the bills. Releasing garbage code today pays the bills.

There's a balance to be had there, because chasing checkboxes is a quick way to ruin things 6 months from now, but at the end of the day nothing matters if you don't ship it. Keep that in mind.

All this doesn't mean that the problems you describe are ok or acceptable (poor management and resulting burnout are all too real) but some of the conflict might stem from you setting different priorities for yourself than what other people have. Learn what their priorities are, speak their language as j_curiouser describes above, and you might be able to sell them on some of your ideas.

And probably read The Phoenix Project. Give it a few chapters and I bet it'll be like reading a fictionalized account of your day job.
posted by Nonsteroidal Anti-Inflammatory Drug at 7:21 PM on March 30, 2020

Best answer: i strongly urge you to consider if the world would be better off without this product and it's myriad security problems.

if they aren't paying you to fix their business, there is zero reason for you to think about it after hours at all.
posted by lescour at 7:29 PM on March 30, 2020 [4 favorites]

Buddhism's nice. Seriously.
posted by Leon at 8:04 PM on March 30, 2020 [5 favorites]

Best answer: You should definitely push yourself less. If you're not being paid to be officially responsible for the overall product, then you are worrying too much. The people who are actually responsible either know more about what's important to the business than you do or don't care - either way, only they have the power to fix the kinds of problems you've mentioned, and if you burn yourself out trying to fix things that they don't actually want fixed, you will regret it.

Even great code from high-functioning teams with great processes often dies of no fault of its own. It's critical to learn how to recognize and do good work without letting it affect your sense of self-worth when you find yourself hacking on something awful for a while. There are enough stories about people who had great careers because they worked on something important and did a good job, that it's too easy to focus on that. There are also lots of people who have had great careers despite working on profitable garbage piles, or perfect, gem-like obscure failures, or a mix of both - you just don't hear about them.

It's OK to just do good work on what you can control, don't burn out, then leave for school.
posted by mmc at 9:37 PM on March 30, 2020 [2 favorites]

The company does not care about you. Unless the product may kill people (e.g. nuclear power control systems) it only matters financially to the owners (who are not you, despite the fact that you may have a tiny sliver).

Take on the projects that make you happy and advance your career. If you weren't going to grad school I would advise looking for a new job.
posted by benzenedream at 2:08 AM on March 31, 2020 [3 favorites]

In a situation such as yours, the best advice is to do the work you've been tasked to do, do it to the best of your ability, and go home knowing that the work you did isn't going to show up on someone else's "problems to fix" list.
posted by Thorzdad at 5:24 AM on March 31, 2020

You've gotten lots of great advice already. I'll just pitch in two small things:

Take pride in your own work, always leave the code better (if only slightly) than you found it. It will make you feel better, improve the product and set a good example for your coworkers.

Always highlight successes that come from code or design improvements, your own or others. "You know how function foo was estimated to 13 story points? I managed to get it done in 5, much thanks to Carol tidying up that part of the code last year when she implemented function bar." Management always hear the complaints about the legacy code or bad design hampering efforts - they also need to hear the success stories from doing things right, and the potential savings etc that go hand in hand with that. You're trying to plant the seed of the idea that doing things right is a good thing. And everybody likes a pat on the back!
posted by Harald74 at 5:40 AM on March 31, 2020 [1 favorite]

On top of all the other great advice...

I have had managers say to me “Don’t bring me problems, bring me solutions!” which, at the time, infuriated me and made me roll my eyes.

But, in retrospect, some of the time, that is more than a dismissive catch-phrase. If you can come up with a way to solve whatever [terrible thing] is supposed to be doing, but in a good way, that is much better, and more likely to improve things, than only pointing out the problem.
posted by fabius at 11:40 AM on April 1, 2020