9 ms·

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because anothe

Just today, my team had a developer meeting. 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.

rnrnrn 5y ago
This kind of thing needs to have some exec sponsorship or at the very least awareness. Otherwise ICs just risk landing on the sword. 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.
firebaze 5y ago
Most of the time managers are trying to be helpful, and most of the time they do in fact understand quite a lot of the background of a project. 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.
- Aeolun 5y ago
  It’s not good if they’re paralyzed by this though. If the manager automatically says no to anything that may contain some element of risk, I will stop telling them.
JTbane 5y ago
> We've done two other releases in the past month and both required a day of troubleshooting to fix issues. 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.
- mek6800d2 5y ago
  Maybe I misunderstand, but if a product breaks regularly under "fragile and bespoke" testing, won't it break just as often, and probably more often, under robust and comprehensive testing? And if the product fails tests, who better to "just" troubleshoot the problems than the developers? (Perhaps you mean things break after nominal testing and subsequent release, but that's just shifting the time when the issues are detected -- the product still has the issues either way. And if the issues will adversely and/or significantly affect the customer, I imagine one's employer would prefer that you set aside your non-troubleshooting valuable time and fix the issues.)
  - Kaze404 5y ago
    I think the difference here is that with robust and comprehensive testing, it's immediately obvious when and where things break. Compared to a codebase with no testing, or fragile testing, where things break and you not only have to spend time fixing something, you also have to spend time finding what is even broken in the first place. That's where the frustration is, at least for me.
thaumasiotes 5y ago
What is the difference between your team lead's bad reasons not to push internally for a better system: > 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.
- kevinmgranger 5y ago
  The last bullet of each scenario is fundamentally different, and the ammunition bit is the most important part.
- NAHWheatCracker 5y ago
  I do push for changes, such as bringing ideas to the team lead and bringing these things up with my manager (hence being brought up in reviews). There is a self-reinforcing aspect to learned helplessness in teams, as you've pointed out.
  - afarrell 5y ago
    In my experience, this sort of thing is why good leadership has an outsized impact.
  - mixmastamyk 5y ago
    All you have to do is say no once in a while. 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.
    - Iefthandrule 5y ago
      Can't teach everyone to have a backbone. Heck, nerds are infamous for being easy to manipulate.
Thrymr 5y ago
> My manager doesn't know anything about the code, my project, or the release project. What... does he know? Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.
- NAHWheatCracker 5y ago
  He's the scrum master for other projects and he deals with things like hiring.
  - bmeski 5y ago
    This is the current norm. 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.
  - Jensson 5y ago
    So he is HR and not a manager? A manager can evaluate your performance, if he doesn't know what you are working on then he isn't a manager. Whoever is evaluating what you do is your manager. If nobody is doing that then congratulations, you don't have a manager, you work in a so called self organizing team!
  - ownagefool 5y ago
    Yeah, I'd hard pass on the scrum master picking colleagues. If the person hiring isn't technical, they likely aren't qualifying competancy, nor are they likely capable of building an Engineering culture.
atmosx 5y ago
The tech lead wants to be “a hero”. It’s a common theme, the problems are well known when you have ppl hero-balling.
- NAHWheatCracker 5y ago
  He actually called himself out for this during the conversation. I'm not sure how to convince someone to stop doing that.
  - tick_tock_tick 5y ago
    Demean the work, don't say anything about him but minimize the value of what he is doing. Commiserate how bad it is that he has to waste a day doing something with so little value. Be on their "side" but make it clear you "understand" what they are doing isn't valuable. 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.
    - aflag 5y ago
      That sounds like a really toxic way to handle the situation.
scottlilly 5y ago
I left my last contracting project around six weeks ago because of encountering this attitude - yet again. 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.
- kungito 5y ago
  I mean, after 40 years as a programmer, can't you retire or look for a better lower paying job?
aflag 5y ago
Can't your tech lead suggest that he'll do the release under the condition that someone from that other team pairs with him so that they learn how to do it?
- wcarss 5y ago
  This seems like a really good idea.
- msteffen 5y ago
  Yeah, at a previous job, I had inherited responsibility for maintaining a particular poorly tested (and hard to test—lots of API dependencies), widely-used library. Most changes were contributed by users and I managed by reviewing new code and tests as carefully as I could. 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.
agumonkey 5y ago
This is why I .. struggle to function in society. There are tribal forces at play that are beyond me. Or require me to play games I don't want to play. 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.
- secondaryacct 5y ago
  None of these are games: they're really just an expression of the energy you need to spend to change a rigid structure. And the more rigid, the more energy, just like a metal bar you'd be trying to fold. 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.
  - agumonkey 5y ago
    Well first of all I don't consider work groups as solids, it's more like a non newtonian fluid. 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.
- oceanghost 5y ago
  This strikes a chord with me. 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.
analog31 5y ago
A hazard of meetings is that the best debater owns the show. It's quite possible that the tech lead thought his idea was straightforward enough that he didn't expect it to be debated, and wasn't prepared for it. 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.
deleted 5y ago
[deleted]
bedobi 5y ago
Oh man this is a punch below the belt, perfectly describes some of my previous gigs. I'm so grateful my current team is NOT like this.
secondaryacct 5y ago
What you're doing wrong, very honestly, is you suggest and 2 of your suggestions are losses (denying release). 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
- vimwizard 5y ago
  It's a fun game to play, until you realize it's not your job to manage the managers and your co-workers, and that you're underpaid for having that extra headache :)
kodah 5y ago
I've worked on a good number of teams just like yours. I always told myself things would be different when I was in charge. Then I was in charge. 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.
- _carbyau_ 5y ago
  Doing a good job - and staying where you are - doesn't get you more reward. And people generally want more than they currently have.
- newswasboring 5y ago
  Did you make your situation clear to your team? I find that is the biggest source of frustration.
  - kodah 5y ago
    Yes. Most of my leadership skills come from the Marines. I'm a fairly blunt leader, so if we're facing something the team is aware of that I can't do anything about then I'm pretty frank about it. Some folks don't like that too much, but I'd rather not have those kind of secrets on a team.
junon 5y ago
> It has been used as ammunition in reviews against me. Quit. This is a sign of a broken and unfixable workplace.
- xwdv 5y ago
  You don’t know other aspects about his job. If the work is easy and the pay is good there’s no point in quitting unless you aren’t working from home or there’s a substantially better offer.
  - junon 5y ago
    They're mentioning it here as though they're unhappy. Doesn't sound like someone that's beneficial for them outside of funds, if anything.
rmah 5y ago
The tech lead started out by complaining about...When he finished complaining... 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.
- nickthemagicman 5y ago
  This resonated strongly with me. If you don't want to become a leader, what do you do in a disorganized mob situation? Leave?
  - newswasboring 5y ago
    Sometimes there is someone else who wants to lead but can't due to political reasons. You can try supporting them. Little things like seconding someone's ideas can go a long way. At least in the place I work at.
  - tata71 5y ago
    Find the/a leader, make sure they can secure your interests, empower them?
    - alxlaz 5y ago
      Unless you're being paid to coach the leader, this is just work their boss should be doing and which you're doing for free.
yyyuutt 5y ago
> 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. They broke it they have to fix it. You need the light shining on that team, not strive to fix it yourself.
- simmerup 5y ago
  Sounds like they might not even know they broke it
JohnBooty 5y ago
This hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over. 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. For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consistently praised in reviews as a good communicator (2) I always operate by the maxim "don't just complain -- instead, offer solutions" and I see that you do too. (edit: That's not to say that I couldn't be communicating things better. Certainly, I don't believe I've reached some level of perfection there) 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)
- geoduck14 5y ago
  >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. 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.
  - JohnBooty 5y ago
    Hiring Rails devs? I'll work for you! 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.
astatine 5y ago
I have seen this happen (and in a few cases the cause for this to happen as well). All code (or releases, for that matter) are not created equal. There are some teams which are working on something which is more critical to the business of the company, at that moment, and there are other teams which may be able to absorb some tasks to let the first team focus on what's needed. Not saying that this was the situation with the OP, but this usually falls in the "greater good" category. I have seen organizations where inter-team boundaries are fought over and defended vigorously and others where these are more fluid and accommodative. I am not sure that the firm boundary teams end up doing better work or be happier overall.
MichaelMoser123 5y ago
>He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. 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 https://github.com/MoserMichael/githubapitools . The rest of it is easily scriptable.
aunty_helen 5y ago
>fight for what's right when others appear to moan and carry on 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
amitport 5y ago
From my experience you need to play a small political game, no way around it, what you want to do costs money and presents risk. If you believe it is necessary you need to find supporters in the management floor. Convince someone who can actually give you backup and help you get this done. If you can't find anyone like that, then either work on the project underground (risky, more work and less credit for you) or let it go (or leave).
antman 5y ago
For a person of many years of experience your friend is the problem. He has agreed to push untested code which is his responsibility, enabled other teams to work out of schedule and him producing dangerous results. All these without any indication that he sought approval from upper management. Why would you use the word "complaining" when communicating an issue? State the facts and how they diverge from the formal process, flag parts of the process that are problematic due to lack of resources of consistency, put them in an email with a "default" course of action if not answered and without using "I" or "They", use passive voice (tone). Keep the score in writing as an informal calendar linked to the respective communications. Cc the manager. Obtain bliss, people will fret then they will forget. 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.
julian_sark 5y ago
> that bringing this stuff to my manager is even worse ... 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.
spadros 5y ago
I’ve been there. It sounds like you’re starting to blame yourself for their failings. You’re not sure if you’re a little crazy or they are. They’re gaslighting you. Get. Out. As. Soon. As. Possible. 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.
cmsefton 5y ago
I regularly re-read the opening few pages of the Pragmatic Programmer as a mantra to myself, because what you have written here is very relevant. > 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.
blindmute 5y ago
It may be, based on my experience as that tech lead who declines everything, that the tech lead has already thought of all this many times over many years, has tried to implement the required changes, yet gets blocked by higher ups. And it may even be that those higher ups sometimes know it too, and deny him based on their higher ups. A lot of times learned helplessness is true helplessness with learned resignation.

rnrnrn 5y ago

This kind of thing needs to have some exec sponsorship or at the very least awareness. Otherwise ICs just risk landing on the sword. 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.

firebaze 5y ago

Most of the time managers are trying to be helpful, and most of the time they do in fact understand quite a lot of the background of a project. 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.

Aeolun 5y ago
It’s not good if they’re paralyzed by this though. If the manager automatically says no to anything that may contain some element of risk, I will stop telling them.

JTbane 5y ago

> We've done two other releases in the past month and both required a day of troubleshooting to fix issues. 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.

mek6800d2 5y ago
Maybe I misunderstand, but if a product breaks regularly under "fragile and bespoke" testing, won't it break just as often, and probably more often, under robust and comprehensive testing? And if the product fails tests, who better to "just" troubleshoot the problems than the developers? (Perhaps you mean things break after nominal testing and subsequent release, but that's just shifting the time when the issues are detected -- the product still has the issues either way. And if the issues will adversely and/or significantly affect the customer, I imagine one's employer would prefer that you set aside your non-troubleshooting valuable time and fix the issues.)
- Kaze404 5y ago
  I think the difference here is that with robust and comprehensive testing, it's immediately obvious when and where things break. Compared to a codebase with no testing, or fragile testing, where things break and you not only have to spend time fixing something, you also have to spend time finding what is even broken in the first place. That's where the frustration is, at least for me.

thaumasiotes 5y ago

What is the difference between your team lead's bad reasons not to push internally for a better system: > 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.

kevinmgranger 5y ago
The last bullet of each scenario is fundamentally different, and the ammunition bit is the most important part.
NAHWheatCracker 5y ago
I do push for changes, such as bringing ideas to the team lead and bringing these things up with my manager (hence being brought up in reviews). There is a self-reinforcing aspect to learned helplessness in teams, as you've pointed out.
- afarrell 5y ago
  In my experience, this sort of thing is why good leadership has an outsized impact.
- mixmastamyk 5y ago
  All you have to do is say no once in a while. 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.
  - Iefthandrule 5y ago
    Can't teach everyone to have a backbone. Heck, nerds are infamous for being easy to manipulate.

Thrymr 5y ago

> My manager doesn't know anything about the code, my project, or the release project. What... does he know? Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.

NAHWheatCracker 5y ago
He's the scrum master for other projects and he deals with things like hiring.
- bmeski 5y ago
  This is the current norm. 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.
- Jensson 5y ago
  So he is HR and not a manager? A manager can evaluate your performance, if he doesn't know what you are working on then he isn't a manager. Whoever is evaluating what you do is your manager. If nobody is doing that then congratulations, you don't have a manager, you work in a so called self organizing team!
- ownagefool 5y ago
  Yeah, I'd hard pass on the scrum master picking colleagues. If the person hiring isn't technical, they likely aren't qualifying competancy, nor are they likely capable of building an Engineering culture.

atmosx 5y ago

The tech lead wants to be “a hero”. It’s a common theme, the problems are well known when you have ppl hero-balling.

NAHWheatCracker 5y ago
He actually called himself out for this during the conversation. I'm not sure how to convince someone to stop doing that.
- tick_tock_tick 5y ago
  Demean the work, don't say anything about him but minimize the value of what he is doing. Commiserate how bad it is that he has to waste a day doing something with so little value. Be on their "side" but make it clear you "understand" what they are doing isn't valuable. 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.
  - aflag 5y ago
    That sounds like a really toxic way to handle the situation.

scottlilly 5y ago

I left my last contracting project around six weeks ago because of encountering this attitude - yet again. 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.

kungito 5y ago
I mean, after 40 years as a programmer, can't you retire or look for a better lower paying job?

aflag 5y ago

Can't your tech lead suggest that he'll do the release under the condition that someone from that other team pairs with him so that they learn how to do it?

wcarss 5y ago
This seems like a really good idea.
msteffen 5y ago
Yeah, at a previous job, I had inherited responsibility for maintaining a particular poorly tested (and hard to test—lots of API dependencies), widely-used library. Most changes were contributed by users and I managed by reviewing new code and tests as carefully as I could. 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.

agumonkey 5y ago

This is why I .. struggle to function in society. There are tribal forces at play that are beyond me. Or require me to play games I don't want to play. 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.

secondaryacct 5y ago
None of these are games: they're really just an expression of the energy you need to spend to change a rigid structure. And the more rigid, the more energy, just like a metal bar you'd be trying to fold. 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.
- agumonkey 5y ago
  Well first of all I don't consider work groups as solids, it's more like a non newtonian fluid. 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.
oceanghost 5y ago
This strikes a chord with me. 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.

analog31 5y ago

A hazard of meetings is that the best debater owns the show. It's quite possible that the tech lead thought his idea was straightforward enough that he didn't expect it to be debated, and wasn't prepared for it. 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.

deleted 5y ago

[deleted]

bedobi 5y ago

Oh man this is a punch below the belt, perfectly describes some of my previous gigs. I'm so grateful my current team is NOT like this.

secondaryacct 5y ago

What you're doing wrong, very honestly, is you suggest and 2 of your suggestions are losses (denying release). 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

vimwizard 5y ago
It's a fun game to play, until you realize it's not your job to manage the managers and your co-workers, and that you're underpaid for having that extra headache :)

kodah 5y ago

I've worked on a good number of teams just like yours. I always told myself things would be different when I was in charge. Then I was in charge. 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.

_carbyau_ 5y ago
Doing a good job - and staying where you are - doesn't get you more reward. And people generally want more than they currently have.
newswasboring 5y ago
Did you make your situation clear to your team? I find that is the biggest source of frustration.
- kodah 5y ago
  Yes. Most of my leadership skills come from the Marines. I'm a fairly blunt leader, so if we're facing something the team is aware of that I can't do anything about then I'm pretty frank about it. Some folks don't like that too much, but I'd rather not have those kind of secrets on a team.

junon 5y ago

> It has been used as ammunition in reviews against me. Quit. This is a sign of a broken and unfixable workplace.

xwdv 5y ago
You don’t know other aspects about his job. If the work is easy and the pay is good there’s no point in quitting unless you aren’t working from home or there’s a substantially better offer.
- junon 5y ago
  They're mentioning it here as though they're unhappy. Doesn't sound like someone that's beneficial for them outside of funds, if anything.

rmah 5y ago

The tech lead started out by complaining about...When he finished complaining... 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.

nickthemagicman 5y ago
This resonated strongly with me. If you don't want to become a leader, what do you do in a disorganized mob situation? Leave?
- newswasboring 5y ago
  Sometimes there is someone else who wants to lead but can't due to political reasons. You can try supporting them. Little things like seconding someone's ideas can go a long way. At least in the place I work at.
- tata71 5y ago
  Find the/a leader, make sure they can secure your interests, empower them?
  - alxlaz 5y ago
    Unless you're being paid to coach the leader, this is just work their boss should be doing and which you're doing for free.

yyyuutt 5y ago

> 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. They broke it they have to fix it. You need the light shining on that team, not strive to fix it yourself.

simmerup 5y ago
Sounds like they might not even know they broke it

JohnBooty 5y ago

This hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over. 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. For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consistently praised in reviews as a good communicator (2) I always operate by the maxim "don't just complain -- instead, offer solutions" and I see that you do too. (edit: That's not to say that I couldn't be communicating things better. Certainly, I don't believe I've reached some level of perfection there) 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)

geoduck14 5y ago
>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. 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.
- JohnBooty 5y ago
  Hiring Rails devs? I'll work for you! 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.

astatine 5y ago

I have seen this happen (and in a few cases the cause for this to happen as well). All code (or releases, for that matter) are not created equal. There are some teams which are working on something which is more critical to the business of the company, at that moment, and there are other teams which may be able to absorb some tasks to let the first team focus on what's needed. Not saying that this was the situation with the OP, but this usually falls in the "greater good" category. I have seen organizations where inter-team boundaries are fought over and defended vigorously and others where these are more fluid and accommodative. I am not sure that the firm boundary teams end up doing better work or be happier overall.

MichaelMoser123 5y ago

>He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. 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 https://github.com/MoserMichael/githubapitools . The rest of it is easily scriptable.

aunty_helen 5y ago

>fight for what's right when others appear to moan and carry on 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

amitport 5y ago

From my experience you need to play a small political game, no way around it, what you want to do costs money and presents risk. If you believe it is necessary you need to find supporters in the management floor. Convince someone who can actually give you backup and help you get this done. If you can't find anyone like that, then either work on the project underground (risky, more work and less credit for you) or let it go (or leave).

antman 5y ago

For a person of many years of experience your friend is the problem. He has agreed to push untested code which is his responsibility, enabled other teams to work out of schedule and him producing dangerous results. All these without any indication that he sought approval from upper management. Why would you use the word "complaining" when communicating an issue? State the facts and how they diverge from the formal process, flag parts of the process that are problematic due to lack of resources of consistency, put them in an email with a "default" course of action if not answered and without using "I" or "They", use passive voice (tone). Keep the score in writing as an informal calendar linked to the respective communications. Cc the manager. Obtain bliss, people will fret then they will forget. 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.

julian_sark 5y ago

> that bringing this stuff to my manager is even worse ... 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.

spadros 5y ago

I’ve been there. It sounds like you’re starting to blame yourself for their failings. You’re not sure if you’re a little crazy or they are. They’re gaslighting you. Get. Out. As. Soon. As. Possible. 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.

cmsefton 5y ago

I regularly re-read the opening few pages of the Pragmatic Programmer as a mantra to myself, because what you have written here is very relevant. > 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.

blindmute 5y ago

It may be, based on my experience as that tech lead who declines everything, that the tech lead has already thought of all this many times over many years, has tried to implement the required changes, yet gets blocked by higher ups. And it may even be that those higher ups sometimes know it too, and deny him based on their higher ups. A lot of times learned helplessness is true helplessness with learned resignation.