Skip to content(if available)orjump to list(if available)

I'm a Tech Lead, and nobody listens to me. What should I do?

general1465

I still remember when my previous employer has lost domain for like 3 months. Boss and his business partner have setup company and I have joined later. Business partner left.

- 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.

wiseowise

This, many times this. If you encounter pushback from everywhere – leave, don’t spend your life energy fighting bullshit.

nickdothutton

I won't add much, but if this happens you must leave. Raise the risk. Document it. Document your recommendation and their decision, even if not replying or not making a decision was their decision. Tie it up with a bow on it, keep a copy, and leave.

fredsted

> After that incident, I created an incident review document and suggested a small review of the tasks that should be prioritized to prevent it from happening again. I got carried away and created an initial presentation for the other backend Chapter Leads with a backend strategy. I do not remember it perfectly, but it included hexagonal architecture, a testing pyramid with contract tests to avoid breaking APIs used by mobile apps, and more

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.

darkwater

> 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.

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.

tormeh

> hexagonal architecture

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.

littlecranky67

Sounds like a regular setup, at least this is very common in modern C#/.NET when you implement REST services. Nothing to do with Hexagonal Architecture, just inversion of control. There is a very thin DI container baked into ASP.NET and the pipeline. Do you have to use that? No, but it gets complicated very quickly if you don't. So any project that is more than a tech demo/eval uses DI. In other languages/frameworks (i.e. Typescript+NodeJS) this is not very common for some reason.

tormeh

I don't know much about C#, but in Rust this is very much not the norm. In fact, there are technical limitations associated with async traits. This sometimes allowed us a reprieve from the madness, but only sometimes. I guess you can write enterprise Java in any language.

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.

wwosik

DI yes. All the crap under the name of "Clean" Architecture - no.

socketcluster

I've been tech lead at different companies. Every time I switched companies, I started out as senior dev and got promoted into the team lead role again; each time with full support of my team.

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.

benchly

While I am not a software developer, it sounds like our career paths have had the same trajectory, and I'm wondering what the common factor is across industries.

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.

master-lincoln

I don't understand why that is a logical progression. Writing good code and leading a team needs vastly different skill-sets in my eyes.

maddmann

I was thinking the same thing. Sounds more like staff engineer not team lead/mgmt?

zelphirkalt

On the other hand, if you want to lead a bunch of engineers, you should know their work very well, otherwise you will have unrealistic ideas about what can get done and how they should do it.

Braxton1980

Being a good leader is partially out of your control. The people under you need to respect you as a leader. Working with them and showing your technical skills can gain their respect

antonymoose

I would argue that the two skills are necessary but not sufficient. If you’re lacking in the core skill, what exactly are you leading? If you’re a great coder and socially inept, good luck leading.

skywhopper

Honestly I’ve seen plenty of folks get promoted to “team lead” because they aren’t as productive with the actual coding. Someone needs to focus on the non-technical project tasks, so the boss picks the least productive team member to move to that role. Calling it a “team lead” makes it more appealing than calling it “worst coder”.

ionwake

I don't understand the point of your comment. Why did you switch companies?

zelphirkalt

I am assuming that the point is, when you start in your team's shoes and then get promoted to team lead, your team knows you are capable and that you have well reasoned opinions. Hopefully.

null

[deleted]

sam_lowry_

Because that's how Silicon Valley works?

AdrianB1

As the other commenters stated, it is not clear what is the point. Writing good code and being a tech leader are very different positions with very different technical skills. I was a tech lead in a few cases (different companies or different departments of a very large company) and I was not the top developer there, my job was not to be one. I worked with developers that were much better than me that were not a good fit for a tech leader.

tkel

Don't rely on hierarchy. Earn others' trust as you would when you are an equal. Don't expect deference just because of your position. Although hierarchical decision making may be more efficient, it's an unnatural system and anti-social and easily generates animosity. You'd do better to empower your peers instead, and show them you are able to listen to them as well. Just like you would with friends.

wiseowise

Big pile of horse shit, every word.

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”?

omgJustTest

"I'm a tech lead, nobody listens"...

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.

ionwake

2c. is there a context I dont understand?

I think its important to note in most companies I worked in, the issues were mostly political.

worthless-trash

But very useful. I would like to subscribe to your newsletter.

zkmon

> Technical influence does not start with a title. It begins with the visible impact you create.

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.

commandersaki

That Spotify squad tribe diagram makes me want to vomit.

preommr

I did a reverse image search on it, and it brought up 'vietname board game' and other war-themed images. Who thought it would be a good idea to have a corporate productivity diagram where the workers look like they're prisoners, there's shooting targets plastered all over, and the "coach" looks like a warden that's flashing danger signs (all the colors, and they choose red?). And that's not even including all the poor spacing, text formatting, color scheme, etc.

Honestly, the more I look at it, the worse it gets.

tuetuopay

This is pretty in line with the BS side of agile. How many retrospectives I've had with themed MIRO boards, from star wars to indiana jones with a step in whatever war. Par for the course I guess.

(not that I'm defending it, aside from the more than dubious theme, it's plain illegible)

junga

Same. Strong SAFe vibes. Hopefully I'll never have to 'work' in such a environment again.

Hydraulix989

You have to build / earn your influence. People listen to you after you have a reputation of being "right" enough times, and by being likeable. Abusing hierarchy isn't it.

agumonkey

That depends on the cultural / politics health of the group. The likeable right guy can end up stomped because he's a threat to the wrong dubious people. Seen this first hand in some companies.

yoan9224

I've made similar ones early in my career.

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.

ramon156

Only thing I can say is that, what doesn't work for me, is leads that just tell you how to do things. I completely agree with my tech lead, but also it just includes only his opinion and it just leaves a bad taste in my mouth.

Is this my ego? Maybe.

nrhrjrjrjtntbt

Oh my. If self-otientation is the denoninator then dont advertise your thing multiple times. Instead keep that out and Ill say cool learned something and come back. At some point ill notice the course/book/whatever and be more interested.

zipy124

This is a very long winded way of saying the phrase "respect is earned not given".