How can I improve a dismal environment when management doesn't recognize the problems?

Question

Summary: I have started a government job as an intermediate software engineer, and the practices are very bad: no tests, no code review, we work without schedule. My manager is too busy and won't help with any changes. How can I improve the situation?

---

I recently joined a new team as an intermediate dev. I was worried about the recession, so I went from a startup to a government job and in terms of a paycheck I'm glad I did because the startup is laying off a ton of people.

However, it really does reflect many of the negative stereotypes about the government. There is no code review, very little unit testing, making decisions takes weeks, and we march along to a delusional schedule which just keeps piling more items into the new sprint and doesn't close the old sprint with the idea of finishing that sprint secretly. Realistically, we are two sprints behind where we officially are and haven't touched this sprints tickets, but on Friday will create a new sprint full of new tickets. We are simultaneously working on 7 open sprints...

We are behind because the lack of unit tests and checking leads to a lot of production bugs and we can never figure out our process of getting code to production and random features can suddenly become urgent without any real basis for it.

Another former Amazon dev says he tried to introduce changes, but they got blown away in a week as something broke and then the sprint needed to be finished. When I asked my manager about this all he had to say was "good luck". They've had high turnover, so I barely even saw him in the office as he was working on an urgent issue. I could take a week off spontaneously and I suspect he would be too busy to notice

I'm a month in and already demoralized. This job offers good pay, benefits and hours, but it's such a dismal environment. It's the first time I've wished that I knew how to be lazy...

Is this kind of thing worth trying to fix? Or will I just be making myself more miserable? How can I address these problems when management doesn't?

Answer 1

From your comments about talking to your manager:

all he had to say was "good luck.

Sorry, but that's your answer. Apparently your manager knows exactly what's going on and shares your assessment. However, the behaviors are deeply ingrained into the organization and there are no external mechanisms, incentives, or constraints that could trigger any change.

I don't think you can make a difference there: Make your peace with it or move on.

Answer 2

Good practice can't survive operational imperatives to not do it.

Good practice is very fragile in non-technical companies as it is not procedurally required, so it will disappear under the slightest of time pressures.

I'm a government worker and we have many of these same issues. My team removed unit testing from Jenkins a while back because there was some problem with it and we needed to get some fix to production. We have no timeline to address the Jenkins bug, so actually running the unit tests is on hold for the foreseeable future. There isn't any disagreement among developers that that is a big problem but getting time/resources to fix it is not realistic. I suspect that it will be a month or two before we fix it, if ever.

There was a dev who spent a lot of time trying to fix many of those issues, but while the changes were accepted by the dev team, they didn't really work with the sprint schedule and now that he has left, we are busy digging out from the chaos of how it all turned out. For example, he wanted to have sprint branches for the purposes of making master more stable. Reasonable.

Well, those sprint branches became Scrum religious artifacts and now we have a pile of old sprint branches we can't do anything with as those sprints never closed, ironically because he left and his assigned work for those sprints was not done. And people got frustrated with him as he spent time working on improvement issues instead of churning out tickets. The unburying ourselves is currently working on the missing tickets in those religious artifacts so they can be sanctified and marked "Done." We get to have another mass merging mess after that is done. It does not help that we are down two developers. We are currently in sprint 13 and just closed up sprint 10 yesterday.

Why is it this way? Because it's a business driven entity (insofar as a government agency is). Technical process cannot consistently exist when there is an incentive to override it, a strong management bias to want things done fast, and endless quasi-deadlines (from sprint, to a desire in standup to report progress, to all the little random changes throughout the sprint) that don't disappear when something breaks in production or requirements change. We used to have a meeting about technical process improvements every 2nd Thursday, but that too disappeared to a need to fix things. It is still in our calendars, but nobody bothers bring it up anymore.

It doesn't help that the average developer is an introvert and wants little to do with oral arguments so while we might gripe in Teams about problems, we aren't going to relentlessly fight about them.

Several developers have tried to steer the ship a bit further from the shore, but in my 8 months here (and in the many years back judging by what unit tests existed that were later left to rot) the boat hasn't moved an inch long term. It is a problem that has held across different team leads, technical innovation meetings, different projects, and different customers.

I'm fine with it as I am motivated by beating expectations, whatever they may be. Fast feature production is what is ordered, so I will deliver. I get why it would be frustrating to you though. Kudos for trying to change things.

The one strategy which has worked to a certain extent is just obscuring certain things. When making estimates for amount of work during sprints, include the time to write unit tests and code review it. Nobody can really question those estimates. Some weeks we get lucky and production doesn't have issues and other weeks, well, the code review disappears those times.

Recognize that you are probably fighting a culture that has been there long before you got there and will be there long after you leave. You are trying to hold back the tides from rising again. You might be able to bend it some weeks, but don't try to build a house there.

Answer 3

When it comes to addressing operational dysfunction in an existing team you need buy-in for change on at least two of these three levels:

• coworkers
• direct management
• senior management

It sounds like you likely have neither. Dysfunction has become engrained and people who've tried to address it before failed. Your direct manager has all but given up and since that's essentially dereliction of managerial duty, it would seem senior management doesn't realise the importance of having a well-run team either.

That's not even going into the topic of having a manager you can't really talk to and who presumably hasn't been monitoring your progress and tracking your goals for the year. That's a massive problem and it can have a much greater impact on you so should be addressed first. Worry about your own performance before you worry about that of the organization.

This is also why it's generally a good idea to get a sense of what the hiring manager is hoping to achieve by bringing you on. If you're early in your career it usually just means executing whatever it is you do. The more senior you become and the more you start mentoring and even managing people, the more you should focus on what your goals will be. Usually that's some version of building/maintaining a strong team, striving towards best practices and standardisation, meeting or exceeding performance goals and so on. Asking those questions also makes it relatively clear how much leeway you'd have and what your role would entail, but I'm a fan of even asking about this outright using some version of "Are you mostly looking for someone or would you expect changes/improvements in certain areas?" and "If there's one thing the person previously in this role should have done differently, what would it be?"

Ordinarily I'm not a fan of "it's government". It's a cheap stereotype and often just an excuse not to do the job you are hired for (properly). But when everyone around you is spouting that line there's a good chance

Alison Green from Ask a Manager has a go-to answer to situations involving severe dysfunction: "Your boss sucks and isn’t going to change.". In your case it sounds like it's more: Your company sucks and isn't going to change. This means that like another answer here said you'll likely have to either accept the environment you've landed in or move on. Just make sure that you don't let the culture warp your work ethic if you stay.