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

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.

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.

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.

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.

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.

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

Is this my ego? Maybe.

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.

Reminds me of an old post by Joel, “fixing things when you’re a grunt.” His advice was similar.

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.

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.

...and then most of best skilled people left in the following weeks.

Tech lead then hired his mates and company nose dived.

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.

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.

Good luck with that.

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

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.