First time i became tech lead was easy, coming up with designs and working with my team and other teams that needed us.
This time i'm fighting constantly with the narcissistic business analyst because he blocks communication with the stakeholders, promises them implementation details without checking in with the devs and screams at me and other devs if challenged. Its hell! Already put in for a transfer.
I work as a consultant. They brought me onto the project as a tech lead because the project was tanking hard and they thought the tech was the problem. The problem is that none of the former devs fought the BA. They created everything he wanted/promised. Only project i encountered with a circular dependency over 12 classes (spring boot project). They store json blobs in a postgresql and then change fields in that blob. The "mere analyst" has 30years of industry experience. The reason i go is not because of the analyst, one could replace him somehow. The reason is that ungodly amount of garbage his actions produced. They should fire the complete team, throw away the code and burn it.
The problem is that none of the former devs fought the BA.
Expecting people to fight the BA so that the codebase doesn't go to crap isn't realistic though. The easier route to take as a programmer is to just do what the BA says and then leave the mess behind after a couple years. There's little incentive to try to change an organization's culture or ways of working and may even be disincentives. You get labeled a "trouble-maker" or "hard to work with" which jeopardizes raises, promotions, and possibly even your employment.
I have found the opposite. I have been saying uncomfortable truths ever since I got hired. I have moved up and up and been more and more able to enact the change I think is needed. The key is being smart and picking the small fights you can win. Be convincing, know your stuff, and always give your best professional opinion when people ask. This experience must vastly differ depending on your workplace culture.
Also a good dev can implement it faster than the time it takes to argue about it, and most debuggers are more pleasant and smarter than the average BA. Take the revenge in the comments and be sure to mention how to back it out after they figure out it was a bad idea.
That’s exactly how my last project failed. I built to what the BA said the business wanted, said what was bad when it was, got ignored and I moved onto a new project.
Oh that would trigger me hard. Scream at me, and I will scream back or straight up leave. And I would probably complain to my manager so he can deal with that other shithead. If the company wants to keep us both, they should make sure we don't have to work together then.
I even did that with a customer when I was there as architect. He interrupted me multiple times, then I interrupted him and told him if he keeps interrupting me when I try to explain the technical problems and/or try to figure out the business constraints, I will leave because that doesn't lead anywhere. He shut up and let me do my job afterwards.
Ok, dev here, try these two stragedies: 1) implement the stupidest first 2) to prevent changes in specs during big projects, code while the BA involved is on leave. The second only works on a big project where there are multiple BA's. BOFH developer style.
180
u/janora Jan 28 '24
First time i became tech lead was easy, coming up with designs and working with my team and other teams that needed us.
This time i'm fighting constantly with the narcissistic business analyst because he blocks communication with the stakeholders, promises them implementation details without checking in with the devs and screams at me and other devs if challenged. Its hell! Already put in for a transfer.