Good luck with that.
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.
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.
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.
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.
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.
I think its important to note in most companies I worked in, the issues were mostly political.
Honestly, the more I look at it, the worse it gets.
(not that I'm defending it, aside from the more than dubious theme, it's plain illegible)
...and then most of best skilled people left in the following weeks.
Tech lead then hired his mates and company nose dived.
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?”
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.
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.
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.
- 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.
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, more often.
Is this my ego? Maybe.
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.
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.
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.
tkel•2h ago
wiseowise•7m 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”?