I'm a Tech Lead, and nobody listens to me. What should I do?
Posted by joaoqalves 11 hours ago
Comments
Comment by general1465 9 hours ago
- I was trying to figure out who have access to domain X? It is not on AWS and by whois it is under some random registrar in Europe. I got just shrug from boss. Everything works so why bother?
- After 3 years of scratching my head and try to repeatedly get it to attention we finally lost the domain (card probably expired), everyone is panicking, because emails has stopped working, so email based 2FA are not working either which has cascading impact on all services. And I am just raging in my office because I was trying to prevent this situation for 3 years to no avail.
- The European registrar did not cooperate at all. We have offered them good chunk of money, no response (weird?), eventually domain got moved around and reregistered by various bots and domain companies and I was able to get it again via domain backorder.
I have left shortly after because this was just ridiculous lack of care with good amount of reactive behavior as a cherry on the top. My take away from this is that you can't change the culture. If top is bunch of sloppy clowns, whole company is going to be the same.
Comment by braza 7 hours ago
I've seen the culture changing in some special circumstances a couple times in previous companies, and honestly all of them were ugly: 1) Demographic replacement (having more people saying yes and out-vote the legacy employees)
2) Hired guns from the top to the bottom to shake the system (we called in a company those managers "007" because they used to have licence to fire).
3) Non-compliance stable as a discipline method for the "legacy employees" (very adopted in Central Europe)
4) "Train-your-replacement" as a coercion method for collaboration
5) Some modified version of the "madogiwa-zoku" but instead of looking to the window, they push people to go for the "metawork," like organizing events, being a developer advocate in conferences, assuming roles as "community managers," or being used as a "donkey token" to be used in conferences or panels of "_______________ in tech."
Comment by NalNezumi 7 hours ago
Comment by anal_reactor 7 hours ago
Comment by QuantumGood 2 hours ago
Comment by franktankbank 5 hours ago
Can you expand? I don't understand what this means.
Comment by braza 5 hours ago
Once we had a German colleague that was not so collaborative in sharing the knowledge about some specific parts of the application, and the Tech lead replaced her MacBook with a Windows 10, and she only can write PRs related with DocStrings.
Comment by zenethian 5 hours ago
Comment by Bratmon 2 hours ago
Comment by dust-jacket 4 hours ago
Comment by franktankbank 4 hours ago
Comment by msdz 3 hours ago
So I’m guessing that’s the reason for this “passive firing” method.
Comment by ksec 7 hours ago
This happens a lot in large company. And isn't just a singular case or a company, but any organisation or even countries. Just look at governments around the world.
You cant help those who dont want to be helped.
The biggest problem of any problem is people dont think it is a problem.
And may be controversially, you cant stop the pendulum from swinging and change its direction. The only way to fasten the cycle is to help it swing to its extreme before it swings back.
Comment by dust-jacket 4 hours ago
Sure, in this instance, they prioritised the wrong problems. But perhaps the case wasn't made clearly enough to make it apparent why this was as big a deal as it was.
Comment by Draiken 3 hours ago
People get to positions of power through many means and very few of those are related to competence. Be it nepotism, boot licking, friendship, inheritance, people failing upwards or just plain luck, these all lead to the same result: incompetent people making decisions.
Add to that the fact that it's very easy to hide incompetency in large organizations and we have the perfect recipe for these kinds of disasters.
Even on small organizations this is common. I've seen plenty of incompetent people getting funding for startups making all the wrong decisions. They're good at selling some BS to investors and that's about it, but now they're at the helm of an organization with people under them. Another good example is people opening businesses from their successes in other areas (I made money here, now let me open a restaurant with zero experience in this industry) or even out of their parent's pockets.
Incompetence is almost always the culprit.
Comment by kamaal 7 hours ago
This happens so often at big companies as well. Management is always assumed to be correct, and the pay grade argument always kicks in(They are paid more because you are beneath them). And this starts to show up everywhere. You can't take any initiative without sanction from the top, and they are often clueless as to what the ask is. Most of the times its rejected just to assert authority, and not on the grounds of merit.
Top bosses are also very envious and proactively trying to kill rising talent out of fear- people better than them, will replace them. To that end no good thing ever happens, if you push too hard you will be eliminated in interest of self preservation.
So by and large no good thing is ever suggested, or tried or happens. Eventually until whole business(es) die out. This happens in every company, no matter what companies claim about hiring, retaining and promoting talent. This is just how every place works.
Comment by IAmBroom 7 hours ago
Comment by wiseowise 8 hours ago
Comment by nickdothutton 8 hours ago
Comment by fredsted 10 hours ago
Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens.
Comment by tormeh 10 hours ago
God help me. Was on a project where this was used to justify so much extra boilerplate. Every class had an interface, and then we used dependency injection to supply the class to something expecting that interface. Actually, it was in Rust, so there were no classes, but that didn't stop us. Absolute waste of time.
Comment by humanfromearth9 8 hours ago
Check the Independent Variation Principle paper for more info: https://doi.org/10.5281/zenodo.17677316
The IVP provides two directives that help evaluating objectively design options, based on actual business decisional authority structure, not some guy's intuition. With the insights of the IVP, you'll be able to decide effectively.
The paper is long, but you can skip to the parts that you find interesting
Comment by littlecranky67 9 hours ago
Comment by tormeh 9 hours ago
The entire idea was to make it easier to mock components and therefore easier to test code, however all the code connecting the components became untestable, so we were back to square one, struggling to meet our test coverage quota because of the massive amounts of boilerplate.
Comment by zelphirkalt 9 hours ago
Comment by MangoToupe 7 hours ago
Testing how IO composes makes up most of what you want to test because it's such a difficult problem. Reasoning about this in terms of size of the codebase doesn't make sense.
Comment by ffsm8 3 hours ago
Personally I'm just doing web api dev/backend atm and have to say that at least in this domain, pretty much everything actually hard is solved.
The only difficulty is the "interesting" architecture decisions people like the OP introduce, making inherently trivial problems into multi week endeavors which need coordination between dozens if not hundreds of devs
Comment by MangoToupe 2 hours ago
Color me extremely skeptical!
Comment by tormeh 7 hours ago
Comment by 9rx 6 hours ago
Granted, it appears Rust gets a lot of use as a cross-language library provider, where the application glue is written in other languages. Perhaps that's why?
Comment by littlecranky67 9 hours ago
Comment by tormeh 7 hours ago
Comment by littlecranky67 6 hours ago
Comment by tormeh 4 hours ago
Comment by wiseowise 8 hours ago
Comment by wwosik 9 hours ago
Comment by ericmcer 3 hours ago
Being all or nothing with it can be tedious though. Like if you are using Postgres... you probably don't need have abstracted adapters that makes it easier to run on some other DB later.
Comment by darkwater 9 hours ago
This is probably the single, most important advice for any new person joining a company in a (technical) leadership position. There are going to be missing things in any org, and bad mistakes, and people needing to learn new things. But also there are going to be tons of decisions that make "no sense" on first look that do have a reason behind, and to fix that "root cause" you probably need a 3 years plan and buy-in from C-level. So, trust the team you are going to lead.
Comment by greenie_beans 6 hours ago
starting with a presentation that nobody asked for is a good way to be ignored.
Comment by socketcluster 9 hours ago
I don't look or act like a leader and this has been a hurdle for me. But what typically happens anyway is; within a few months, my code ends up being a core part of the project; my modules become heavily depended upon and somehow I end up maintaining all the config files and guiding architecture decisions. One of my team members joked that I "conquered everyone's code." I probably write fewer lines of code than everyone else but somehow those lines end up heavily used. So then I basically just ask the big boss for a team lead position.
Comment by benchly 9 hours ago
I work in automation (mostly) as a lead tech and professional troubleshooter because I am familiar with a wide and varied amount of automation technologies. I've met plenty of people over the years who have much more advanced skills than myself, but never go beyond doing more than parts swapping on a workbench, which leaves me scratching my head.
Over the last few years, I have listened carefully to what people around me say about my work, and while it is good gas for the ego, I have notice that's not the likely reason I get promoted so quickly. While I can walk into a problem and know how to apply different processes to figure out what to do almost reflexively at this point, the real focus seems to be that I take ownership of the process.
Bit of a buzzphrase, "ownership of the process," but the short explanation is that a little planning, accountability, resourcefulness and communication seems to get you a lot further than just knowing what to do in any given situation. Employers like that because they now have department manager they can rely on, and team members like that because someone else is taking responsibility so they don't have to.
You're good at code, obviously, but if you zoom out on your work a bit, are you also bringing a bit of accountable authority to the table? That may be the real reason why you move up so quickly, or at least something that greases the gears so that can happen faster for you than, say, an equally skilled colleague.
Comment by master-lincoln 9 hours ago
Comment by ryandvm 6 hours ago
To really build great software, you need time and space to git your head around the problem. This is obviously not possible if you're spending most of your week in meetings and tracking the work of 7 or 8 team members.
In my experience, you can be a great IC *or* a great tech lead, but you cannot be both at the same time.
Comment by kaffekaka 6 hours ago
Comment by zelphirkalt 9 hours ago
Comment by ericmcer 3 hours ago
Comment by maddmann 8 hours ago
Comment by baby 7 hours ago
Comment by antonymoose 9 hours ago
Comment by Braxton1980 9 hours ago
Comment by skywhopper 9 hours ago
Comment by baby 7 hours ago
Comment by ionwake 9 hours ago
Comment by zelphirkalt 9 hours ago
Comment by sam_lowry_ 9 hours ago
Comment by ionwake 6 hours ago
Comment by mixmastamyk 2 hours ago
Comment by andrewstuart 6 hours ago
In what way?
Comment by AdrianB1 9 hours ago
Comment by mixmastamyk 2 hours ago
Comment by sceptic123 4 hours ago
Comment by MyHonestOpinon 3 hours ago
Comment by omgJustTest 10 hours ago
1. Listen to what other people say and what they think the problem is, or what the problem "says".
2. Think, ask questions to clarify and repeat step 1. Is the problem actually technical? branch a. otherwise branch b.
a. have you considered the problem is mostly not technical? then proceed to branch b.
b. what miscommunications are keeping the solution from being implemented?
3. Change minds with the words that are convincing to others. Dont be so convinced of your solution that you wouldnt take a better one, return to step 1 unless the problem is "solved"
My blog would be uncompellingly short.
Comment by ionwake 9 hours ago
I think its important to note in most companies I worked in, the issues were mostly political.
Comment by worthless-trash 9 hours ago
Comment by tkel 11 hours ago
Comment by jcalvinowens 36 minutes ago
Comment by wiseowise 8 hours ago
Wasted years in previous company under narcissistic manager with the same mindset. The guy had official senior lead title and was calling the shots. When ther team became too big, he assigned most senior people as “leads” without the official title. You had to perform as a team lead in an environment where your decisions do not have authoritative power, so every small task became negotiation with every member regardless of their seniority. Also no salary bump either. The “teams” quickly collapsed and they hired official team leads from there, with a real authority.
> Although hierarchical decision making may be more efficient, it's an unnatural system and anti-social
Where did you read this? “Empowerment management for empowered to empower #21”?
Comment by Hydraulix989 10 hours ago
Comment by agumonkey 9 hours ago
Comment by RickyLahey 9 minutes ago
Comment by commandersaki 10 hours ago
Comment by azangru 7 hours ago
Comment by franktankbank 4 hours ago
Its a great soup, apart from the turds floating in it.
Comment by junga 10 hours ago
Comment by preommr 9 hours ago
Honestly, the more I look at it, the worse it gets.
Comment by tuetuopay 9 hours ago
(not that I'm defending it, aside from the more than dubious theme, it's plain illegible)
Comment by andrewstuart 6 hours ago
Makes me think of Ninjas and Rockstars.
Comment by zkmon 8 hours ago
That visible impact need not be entirely from your technical work. It is mostly from your relations, communications, the way you present yourself and the perceptions that you can manage to get from others. Infact, technology component is very little.
Comment by yoan9224 9 hours ago
The formula of Trust + Intimacy + Credibility is solid, but I'd add: solve one painful problem first, then earn the right to propose architectural changes. Ship something valuable in the first month, even if it's not perfect. That builds more credibility than any presentation.
Comment by zipy124 9 hours ago
Comment by mixmastamyk 3 hours ago
Reminds me of an old post by Joel, “fixing things when you’re a grunt.” His advice was similar.
Comment by pico303 9 hours ago
Edit: accidentally hit update instead of scrolling…
One thing missing from the article that I don’t think has been mentioned is confidence and setting expectations. I’ve found if I expect certain results and convey confidence, people are more likely to follow your lead, or at least listen to you. Don’t act like a know it all, and be sure to encourage and question others so the environment is collaborative (solve problems as a group; don’t be a hero). But set expectations.
Also, I don’t think you mean “intimacy.” Do you mean “empathy?”
Comment by 9rx 6 hours ago
The words that follow support it being "intimacy". That is what intimacy is — being close enough to someone that you can be open without a feeling of being left exposed. How would empathy fit?
Comment by lsofzz 7 hours ago
TL;DidntRead
Precisely. Take the `TL` title out the door. Take the `ego` out the door.
Then, step in the door - as a friend, with empathy, proactive listening and support the engineers.
Round-table `discussions`. Not Waterfall.
My 2 cents.
Comment by ramon156 9 hours ago
Is this my ego? Maybe.
Comment by FroshKiller 7 hours ago
I don't do this because I don't trust them but because I have different requirements. What matters most to them is completing their work items according to specifications. What matters more to me is long-term maintainability of our projects for the rest of the team.
Some of them have the long-term needs in mind. Some of them just don't think that way. I try not to make them feel like their work can't be trusted or like my demands are arbitrary. I think they are more receptive to my demands when I can at least provide context for them. That seems absolutely necessary to me.
I ask myself all the time whether I'm insisting on too much control. I appreciate you asking of yourself, "Is this my ego?" It can definitely go both ways.
Comment by 9rx 5 hours ago
Ugh. I recently found myself working with one of those people. What a horrid experience. We waste days trying to reverse engineer out of him what the business problem actually is, and then, once we finally figure that out, even more going over all the things he failed to consider.
Software isn't the technical Olympics. It sole purpose in life is to solve human problems. You must work from understanding the human problems. "This is how we are going to do it" obscures all of the information that is necessary to write good software. I have no qualms about pushing back to ensure that we start from the right place, but it is so draining when it happens over and over. Building software doesn't have to be so stupid.
Don't be that guy.
> I ask myself all the time whether I'm insisting on too much control.
No. You're not. Someone has to wrangle those who are not providing positive contributions (without a forceful hand). But your job is to figure out why they are not providing positive contributions and solve for that problem, not to continually tell them how to do their job. You are no longer in a technical role. "Lead" means you are now in a people role, solving people problems not suitable to be solved with tech.
If you'd rather be a software developer, consider doing that job instead.
Comment by nickd2001 9 hours ago
Comment by arealaccount 7 hours ago
Coming in with a hexagonal overhaul is a great example. At least in this case it seems the writer didn’t dig his heals in too much.
Comment by baby 7 hours ago
Comment by nrhrjrjrjtntbt 9 hours ago
Comment by rolph 1 hour ago
Comment by DoctorOW 9 hours ago
I wonder if "tech lead" coincidentally are two words that are the same in Spanish as English, or if this is considered a technical phrase.
Comment by ioma8 9 hours ago
Comment by retrocog 4 hours ago
Credibility, reliability, and intimacy all collapse without honesty — you can simulate them briefly, but they’re structurally unstable. Once dishonesty is detected, self-orientation effectively goes to infinity and trust snaps to zero.
So the equation is a trust amplifier, not a lie detector. Useful for healthy teams, dangerous if applied naively in adversarial or performative environments.
Comment by ChrisMarshallNY 9 hours ago
I was a senior manager, for much of my career, and had about a 30% hit rate, with folks listening to me. My employees had to listen to me, but I actually encouraged them to talk back, if they had issues with my direction.
My bosses and peers?
...not so much...
This was especially true of the Japanese (I worked for a Japanese company). Even though I had a pretty significant level of influence (for a Westerner), I still had to beg for folks to listen to me.
My favorite, was when my team was assigned to help a Silicon Valley startup that my company had made a deal with, after the ink was dry on the contract.
There were a lot of problems with that relationship. Most of them, were because the senior Japanese management had made some really big mistakes; chiefly because of cultural differences between the companies (the startup was actually really good, but they were a fairly typical "smoke and mirrors" Silicon Valley startup, and had a different approach to pitching that didn't work well with the Japanese. Neither side really understood the other).
We did our best, but our hands were tied. It did not end well, which was pretty disastrous.
If someone had asked me to help out, before they signed the contract, it would have been a much better outcome. I'm no captain of industry, but the problems were pretty glaring and obvious, even to us mensches in the trenches.
> I think I never read as much in my life as during the month between announcing I was leaving my previous job and joining mytaxi.
I liked reading that. I would love folks to do that kind of thing, more often.
Comment by tacone 1 hour ago
Since he looked unimpressed I asked him to hand me a pen on his desk. He promptly gave me the pen.
"See? You're already doing whatever I ask."
Comment by nextworddev 4 hours ago
Comment by rvz 9 hours ago
Comment by 28304283409234 10 hours ago
Good luck with that.
Comment by c16 10 hours ago
Comment by jmkni 10 hours ago
Comment by OutOfHere 7 hours ago
Comment by jwarden 9 hours ago
Comment by AdrianB1 9 hours ago
Comment by pixel_popping 7 hours ago
Comment by agumonkey 8 hours ago
some teams distort the meaning of things, and if you try to bring improvements (QA, velocity) they will reject it right away no matter great you are.
Comment by varispeed 10 hours ago
...and then most of best skilled people left in the following weeks.
Tech lead then hired his mates and company nose dived.
Comment by darkwater 9 hours ago
Comment by master-lincoln 9 hours ago
Comment by AdrianB1 9 hours ago
Comment by torginus 9 hours ago
Comment by wiseowise 8 hours ago
Comment by newsclues 10 hours ago