How learned helplessness happens in engineering teams

Perhaps. I thought so once in exactly this situation, and it led to an incredible amount of frustration, and burnout. And others were hurt the same way. That leadership vacuum was very real, but nobody wanted it to be filled by anyone already in the company, it turned out.

Eventually we got a very competent new team lead from outside and he was accepted by everyone immediately. For one of the teams anyway; the other one is still a complete mess. I just make sure I'm on the right one.

> It is your life. You own it. You run it. You create it.

> Many developers we talk to are frustrated. Their concerns are varied. [...] And the answer we give is always the same.

> "Why can't you change it?"

> But, for some reason, developers seem to resist change. They hunker down, and hope things will get better.

> [...]

> So here's the most important tip in the book.

> Tip 3: You Have Agency

> Does your environment suck? Is your job boring? Try to fix it. But don't try forever. As Martin Fowler says, "You can change your organization, or you can change your organization."

When I read the situation you describe, the best thing would be to acknowledge where the tech lead is emotionally, and sympathize, because it sounds like they simply wanted to sound off about it, not actually change it at all. It's always easy to say no to why something won't work, and it sounds like a classic drama triangle situation, with someone coming in as a persecutor, you stepped in as a potential rescuer, then you became a victim because obviously your suggestions won't work.

You, however, don't need to accept the situation, and you can try to change it if you wish. Too many people (including myself, hence why I always re-read those few lines) fall into the trap of thinking that someone else should make this or that change, make a decision, or that you require approval or authority. This is far less true than people believe.

As someone who has stepped into a software manager role for the first time from being a software engineer for most of my career, my view is that I'm not always there to solve the problem, but to give space for people to solve the problems themselves. It helps if I know what's going on, or understand the issues, but I trust my team, and those I work with, and would rather get them together with the right people to discuss it through, and work out a way forward.

I appreciate I don't know the situation at your organization, the battles you fought, the things that have been said. Change is never easy, and there's always resistance, but you do have agency, as does your tech lead. Never forget it. Good luck.

I (not that long ago) worked at a company that kept all their data in MySQL. Sounds fine. The bad part was all their user-facing stuff was written in Microsoft Access.

This didn't make any sense and was the main thing that prevented them from moving to a web-based or API-based interface. They had written some code here and there that would cobble a few things together but it wasn't the right way to do it.

During a discussion, I asked why there were 2 MySQL servers. They held different databases, but it would have made more sense to have them both on one server. I assumed that at some point in the company history, the data got too big to fit on one server, so they split it up, and that ended up being true. And ever since they had some misguided sense of safety having two different databases, even though if you were missing the other, all functionality would break.

At the current time, the databases weren't large enough or accessed enough to require being on separate hardware. It seemed simple enough to just import one into the other and then get on with modernizing the rest of the code.

"We would have to re-write the entire codebase since it's based on having two servers"

Access lets you basically do joins etc on two separate databases. So this was used heavily. Whenever they tried to duplicate this functionality in PHP or whatever they would try, it turned into a nightmare.

I would imagine if they had spent another $10k on hardware back when they first had this problem they would have saved a lot of future troubles. Imagine running legacy versions of Visual Basic, developers needing Windows XP VM's, end users needing two copies of Microsoft Access installed...