My manager doesn't know anything about the code, my project, or the release project.
IOW, your team has no leadership and no management. Your team lead may be called that, but sounds like he doesn't lead at all. Your manager may be called that, but he doesn't manage either. This happens a lot when people are given responsibility without any authority (probably the case for you "team lead"), or authority over things they don't understand (probably the case for your "manager").
The bad news is that you're part of a disorganized mob. The good news is that there is a leadership vacuum that, if you play your cards right, you could fill. If you want. Of course, even if you succeed, it's possible no one will care about your accomplishments. And you will probably make enemies. It's possible you'll be rewarded but given your description, I view that as unlikely.
As a side note, suggesting to the team lead that he lead and do X, Y or Z may appear to him as if you want him to take on risks with little upside. He's probably thought about doing those things anyway but just decided it's not worth the trouble. It's not all that surprising that he doesn't want to rock the boat.
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.
If you don't want to become a leader, what do you do in a disorganized mob situation? Leave?
If you have to stay, it helps to try and make your team a nice place to be. I remember a manager that would organize team lunches and would give Fridays off (unofficially) making the team an oasis in the middle of a corporate desert. But I can’t imagine it was easy for him to deal with a dysfunctional leadership and coworkers…
So either you become your island and power on from your base, or you become part of the dysfunction as a leader. Leaders who succeed in this are rare enough they write books about it, most of it fiction..
They asked what can you do besides leaving.
Should just leave.
> The other team doesn't know how to do the release.
> He wants to be a "team player" so he can't deny the release.
> Project managers will never allocate time to improve the release process.
and your good reasons not to push internally for a better system?
> My manager doesn't know anything about the code, my project, or the release project.
> He may assume it's complaining for the sake of complaining.
> It has been used as ammunition in reviews against me.
In fact the team leader is a "hero" who extinguished a fire caused by other department.
There is a self-reinforcing aspect to learned helplessness in teams, as you've pointed out.
No, don't bring the company to a halt with a tantrum. Just insist on getting one thing fixed a month and nine months from now everyone will be a lot happier.
Being able to say "no" is absolutely critical.
Of course, you do incur a risk and you may fail or hurt your career in that org up to the point of termination even if you're "right". Moreover your follow-up after saying "no" will be judged harshly and silently for every little snag, real or not.
But that's part of the deal, right? It's not easy, if it were easy you'd have dream-teams all over the place rather than an industry where occupational dysfunction is normal.
> Just insist...
Some companies work like this, but many don't. Such utterances could be charting a course to the door for you.
Learned helplessness, indeed.
Yes, there is 1% who can't follow that advice for various reasons of desperation. Not enough to continue arguing this thread.
I learned pretty early on that I have political capital, and very little of it. Instead, I have to have a manager that's pretty buck wild when I tell them I need them to be, and I have to deliver them some wins that will grease their wheels too. Good managers are hard to come by though, and if they get noticed they're promoted and gone in a couple of years.
Personally, I think the transactional nature of software positions is what largely holds us back. If I get promoted, then there'll be a new lead, and this cycle will start all over again.
Everything I suggested was just flatly
denied as impossible
[...]
I feel strange because I've seen this same thing
for my whole career and I still try fight for
what's right when others appear to moan and carry on.
I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole. Management will never let individuals waver from their short term goals.
The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.
(Although, the issues you ran into are kind of an org issue in addition to a developer experience issue)
I came to this conclusion after watching the place I work at for 2 and a half years fail to implement any of the grand ambitions management had in their heads. We wanted code review, pull requests, build pipelines, automated releases, updated OS's, logging, disaster recovery, you name it. No one had the experience, time, or energy to implement it, so it falls on one or two juniors (me) to quickly learn and implement while learning. No one is hired with experience in any of these topics, only fresh-grads that will replicate the garbage you're trying to get away from are hired, because they will on paper be producing more features for less financial cost.
Similarly to your org not having a dedicated DX team being the reason, dedicated teams will happily dissapear into a void of non-delivery as their purist vision, unconnected with reality, will simply never apply to your stack, and thus you'll never use it.
End of the day, different things work and fail. The key is almost always the quality of people, their motivation and how many road blocks you put in front of them.
dedicated teams will happily dissapear
into a void of non-delivery as their purist vision
1. Rotate team members onto and off of the DX team, so they don't lose touch with reality.
and/or
2. Have the rest of developers vote (or otherwise have direct input on) on the DX team's priorities and products. The other developers are the stakeholders here.
> because they will on paper be producing more features for less financial cost.
So make a better business case. Inform them that after investing Y hours on refactoring X, future development is expected to happen M% faster with N% less bugs. New features can be expected to be developed, tested, and shipped to production in S% less time.
But be realistic. Don't make promises that you won't actually meet when the time comes.
Inform them that after investing Y hours on
refactoring X, future development is expected
to happen M% faster with N% less bugs.
(I chose 10% because we had 30 developers at the time and generally had teams of 3 developers. So, one dedicated DX team...)
Do you have any articles, case studies, etc of how to express this to management that is generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
The best thing I could think to do is have the team minutely log all lost minutes productivity caused by delays and inefficiencies that the proposed fixes could address.
But even that's tricky. For example, at one of my previous positions, the build pipeline could take hours and could randomly fail.
The only way to maintain any semblance of productivity would be to juggle 3-4 tickets at once. This was incredibly challenging, and productivity took a massive hit due to the frustration and context switching.
However, even if I had logged those experiences down to the minute, there weren't any literal downtime minutes. It was more a matter of juggling five tickets at once that should have taken one hour each, but instead they took five hours each because I was context switching faster than the Linux kernel itself.
New features can be expected to be developed,
tested, and shipped to production in S% less time.
Scrum and its much-maligned "story points" are a possible solution here, as far as management is concerned, assuming both developers and management have bought into that concept and are using it correctly.
> Do you have any articles, case studies, etc of how to express this to management that is
> generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
> What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
> The best thing I could think to do is have the team minutely log all lost minutes productivity
> caused by delays and inefficiencies that the proposed fixes could address.
I'm a manager. Please. PLEASE don't believe this. In-the-trenches folks ARE powerful. Really. I promise. I can't implement change if YOU don't do it. I don't know what sucks if YOU don't tell me.
I NEED you to help me make things better.
Seriously, though: I firmly believe that most managers do think and act like you do.
(I've been in lead and/or management-lite roles myself; I don't view management as some weird or evil "other")
But, I think it only works if that sort of change is valued all the way up the org chart and folks at each level are empowered, incentivized, and motivated to address the pain points of the folks below.
If the org chart is more than N levels deep, then I think this becomes practically impossible. Managers feel the pain of their direct reports deeply and acutely and absolutely want to make things better: after all, it is in their best interests as well. But a manager won't feel or even understand the challenges of folks N levels below; it's probably not even practical to expect this.
(I'll let others argue over the exact value of N above)
That's why I don't think the situation can be resolved without some sort of dedicated resources allocated to developer experience. The most obvious answer (for engineering orgs big enough to support it) would be dedicated developer experience teams. For teams that lack the headcount to dedicate engineers to it full time, an alternate solution could be dedicated chunks of time -- "hackathon Fridays", etc.
I‘m working in a strongly hierarchical org,
whit very high N number
The persons in charge, empowered to make
decisions are so far from reality
I think it's inevitable, honestly. I think it's fundamentally impossible for management to really understand or respond to in-the-trenches stuff. That's like tasking the mayor of a large city with sweeping the streets or physically fighting crime themselves, in person. They literally cannot spend enough hours in the shoes of the folks under them to understand that stuff.
And, that's fine. Management just needs to have the humility to understand that, and has to empower people/groups that do have their boots on the ground to fix those problems.
It's not unique to this industry, although I do think the newness and explosive growth of our industry may make it particularly prone to this kind of thing.
My dilemma should I leave or not? Is it better or worse in other place? My helplessness is, I reached limits where I know I can‘t improve the situation anymore. But I see a general pattern and so I am pessimistic to find a better place…
If you however, do something about it, that counts for something. Not just asking others to do your job for you, without even asking them.
Social tissue is a strange medium and most of the time it's a friction generating engine. People complain, time passes on, nothing happens, repeat.
You can change things but you must do it. You must put your reputation at risk, expense time that you wont be compensated for, go through conflicts you'd rather avoid, make lifelong enemies wether you succeed or not. Then, you changed the rigid structure once more and the next guy will either try to put it back where it was and face less resistance or fold it one more time and face even more.
You cannot teach a rigid structure agility just like you cannot teach iron to be silk, and the structure is rigid for a reason: size, cost, regulation, cultural beliefs, rot due to time, past mistakes (in my experience the largest factor: a mistake 10 years ago can justify 3 days a week of useless processes today) etc. You can change the structure but it's CEO-level work to change its rigidity.
And reputation, enemies.. all of these are absurd notions to me. It mostly shows immaturity in our notion of work and society. And I'm not asking for people to find solution to state finance, but even for changing the simplest thing, people will resort to primitive behavior. It's child like behavior mostly.. and the bad side of childhood, not the "let's make something fun for everybody" more like "boss doesnt like me so i wont move a finger". In those structures everybody becomes everybody's enemy, and it's a super sad sight.
Ironically, the only way to minimize the "game playing" is by mastering them. There will always be people out there whose only real skill is manipulating the people around them, and who will deploy that skill at full force.
I'm not saying you should manipulate the people around you... but the twin powers of, "understanding whats going on around you" and "documenting everything", go a long way.
I also try to distill good vibes and motivation, bit by bit. Listening, suggesting, showing.
I've asked a few places but I've been looking for the social dynamics of work groups.
I'd love to poke in people's head to be sure what are the motives behind their behavior (the main one I assume being a balance of respect/equality and money).
I suspect you're approaching things too logically. In my experience most people do something then rationalize why they've done that later, if at all. And that's without any perceptive, or memory problems or anything like that, and assumes good intent-- which a lot of people don't have.
I also suspect some people's brains work so differently from my subjective experience that there's effectively no way to understand them.
A very hard lesson for me was "don't try to use logic to understand irrational people."
I now tend to think of people in terms of, "can I predict a response or action by them?" By observation, you can kind of build a set of rules and start hypothesizing about them and update your model when you get more evidence. But you still need to be mindful that different conclusions can be reached with different or conflicting information.
It worked so well on an ex of mine that she thought I was spying on her somehow, because I often had reasoned out things I shouldn't have known. The most terrible example-- that she was cheating on me. I came to this conclusion from a few bits of evidence-- she wasn't really the curious type. Most of the film, music, etc she knew about were from me. And then one day, she started talking in detail about a film I knew she hadn't seen, and she used a word I had never heard her use before.
This lead me to think, "She's having some sort of social interactions that I'm unaware of, and they're probably watching movies together, and if its being kept secret, its probably something bad."
And I was correct.
I'd rather try to connect emotionally and see who's responding. I grew up the way you think and I'm tired of it. If someone doesn't like me (or doesn't like me anymore), no problem, then I'll find other people, all I want is honesty.
That said, I've encountered the post rationalizing lying kind just too many times.. :)
I wrote my first custom business program 40 years ago. Since then, I've only been on two teams that didn't exhibit this attitude.
At this point, I really don't want to continue programming for a living, precisely because so many people adamantly refuse to fix problems with painfully obvious (and quick and cheap) solutions.
I've given up on trying to get people to change their behavior. If I do continue programming, my approach will be to try to find one of those rare teams that actually changes and improves.
I don't introduce new information at meetings unless I am ready to back it up, which usually takes an hour of preparation for every hour of meeting. If time is of the essence, it's often better to settle things in hallway conversations or via web chat.
This.
While I currently have a manager that mostly understands such complaints, I have learned that even then, it amounts to nothing. Because he can't change material things without invoking higher-ups, and they won't be brought on board. For one thing because that would require a lower level manager to create tasks for a higher manager. And that's not how management works in many companies: A lower level manager didn't get to be a lower level manager by creating "work" for higher-ups. He got to be a lower level manager by absorbing the complaints from the ground force, assuring them that their voice is heard while at the same time shielding the higher-ups.
Maybe I've just been in sh*tty IT companies all my life, but I'm seeing this, and similar pattern for nearly 30 years now, and that's why I'm now searching for a job that is as far away from the potential to create overbearing complexity as possible. Even to be point where salary be damned.
Quit. This is a sign of a broken and unfixable workplace.
What... does he know?
Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.
Most Tech Directors or Tech Managers at my massive media company were previously front end or full stack devs who were good at coordinating (asking questions and never internalizing the answers).
Since they talk to so many people and have great rapports, they can easily manage people and conversations but they cannot manage a technical system because they think they can negotiate with it.
Usually the shit they need to know is 2 bash scripts and what build is in what env. Simple enough if you are so well educated with a degree and half a brain.
If the person hiring isn't technical, they likely aren't qualifying competancy, nor are they likely capable of building an Engineering culture.
At one point, one particularly hard-pressed user wanted to make really sweeping changes to the library and had limited time. I stalled and stalled to try and review all their changes and convince myself they were going to work, and they got more and more agitated, and my TL (who was himself frustrated by how much of my time this was consuming) told them "you can merge whatever you want if you take over maintaining it". So that's what happened, and everybody left happy.
All of these comments should be said in group setting to try and get the crowd to pickup similar views. Just make sure no one thinks of what they are doing in a positive light.
> 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.
If they’re using your valid concerns as issues on performance reviews, then the company values making low quality software, not their employees. Get out of the sausage factory and get into a place that values their employees and product. You’ll be much happier.
If the team is disfunctional or the manager bad consider changing work. Not only due to the dysfunction but because a good team and manager is part of ones' mentoring, and it hampers ones' growth. At least now you gain some reflexes that will assist you in the future, if you chose to move on.
Also these deployment tasks are quite repetitive, it's a big strain, I can understand your pain. I have managed to automate myself out of this, at my current job: most deployment tasks involve the following steps: Commit the change, open a pull request, wait for the CI build to complete and download the build log, extract an image id from the CI build log, put it in some other repository and commit the change. It is possible to automate the first three steps with the github api (if your shop is using github), I have an example here: https://github.com/MoserMichael/githubapitools . The rest of it is easily scriptable.
I'd suggest to try to see the situation from their perspective, which you maybe already did, but sometimes this helps understanding a perceived lack of action.
Dont suggest, make enemies: send emails to both teams saying now it must be like that, lay the plan, pose a meeting to go through the plan and get yelled at. Once you get yelled at by the complainypants because what you tell them to do is too hard, now you can go to your manager and explain him they complain for the sake of complaining. The tech lead will get a earful and either fight you to his grave or admit defeat and let you do your reform grumbling waiting for you to fail.
I do that in a giant bank that cannot move without 10 approvers to everything, and the more these helpless teams fight me the more management put me in their midst to reform them ... and Im just a silly dev nobody and I can tell you the wonders one can do by just bulldozing. There are things to do if you fail eventually, which is to teach the higher ups to enjoy trying and failing, but that requires a bit of weaseling charisma :D
You can try but once there’s resistance is probably a better idea to find something else. Let management figure out why people keep quitting.
I don’t like giving this recommendation out but the other way can make for a career limiting move.
I feel you, it's especially frustrating when your product has such fragile and bespoke testing that things break on a regular basis. Then, us devs have to spend valuable time just troubleshooting.
They broke it they have to fix it. You need the light shining on that team, not strive to fix it yourself.
This is called being a toxic employee, I've come to think of that as a good thing but it's definitely not a career move.
Good story though, can definitely relate
A lot of times learned helplessness is true helplessness with learned resignation.
The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary.
We've done two other releases in the past month and both required a day of troubleshooting to fix issues.
Both of us have been working at this company for about 3 years and we both have over a decade of experience in software development.
When he finished complaining, I started asking questions and making suggestions about how we can improve things. - Push back on the team that needs these urgent changes. Let them learn to do the release. - Deny the release since they didn't communicate earlier. - Improve the release process.
Everything I suggested was just flatly denied as impossible. - The other team doesn't know how to do the release. - He wants to be a "team player" so he can't deny the release. - Project managers will never allocate time to improve the release process.
I feel strange because I've seen this same thing for my whole career and I still try fight for what's right when others appear to moan and carry on.
However, my experience tells me that bringing this stuff to my manager is even worse. My manager doesn't know anything about the code, my project, or the release project. He may assume it's complaining for the sake of complaining. It has been used as ammunition in reviews against me.
Learned helplessness sucks and I wish I could do more. I don't think either of the suggestions in the article are feasible for many ICs. Teams are ambivalent to making improvements, and retrospectives carry very little weight. Managers are above the fray and won't be held responsible for by people below them.