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.
> My take away from this is that you can't change the culture
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."
The last one made me chuckle. Worked in Japan, didn't see many madogiwa zoku (probably because I only worked at startups) although it was talked about a lot. But I guess community manager-esque position did exist, and now it makes sense why so many big company blokes that went to tech meetup came off as very incompetent
What you say and what they think are not the same, usually your meaning and intention is drowned out by their pre-existing assumptions and incentives/motivations. You have to resonate with their assumptions and incentives for them to "hear" your meaning and intention.
It's some low-risk/consequence project/initiative that is designed to receive people that will be fired due to lack of compliance and/or collaboration with the new management.
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.
Because firing people in Germany is a multi-year process that requires (among many other things) paying for a complete training course in all job-relevant skills under the assumption that any incompetence is caused by insufficient training.
I mean I'd guess it was because it's somewhere with a higher bar to firing. Redundancy or dismissal are both much more complicated (expensive) than simply making it very clear you'd like someone to leave.
As has been stated above, I’m guessing in this specific example it would’ve been due to the rather strict labor laws, which I’m not going to comment my opinion on, just to clarify/explain: Here (Germany), you can basically not fire someone if your company has >10 full-time employees, and they’re not actively misbehaving (or under trainee/probationary status). Yep, this statement means exactly what it reads.
So I’m guessing that’s the reason for this “passive firing” method.
>And I am just raging in my office because I was trying to prevent this situation for 3 years to no avail...... My take away from this is that you can't change the culture.
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.
IDK, I think this is too negative a take. It's easy to blame those in charge for not realising that your problem was the important one but ... how many problems were they being presented with?
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.
I think Occam's razor explains this: the majority of people are incompetent.
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.
>>If top is bunch of sloppy clowns, whole company is going to be the same.
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.
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.
> 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.
> 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.
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.
Interfaces are only necessary to properly abstract away from implementation details that have different change driver assignments. Else it's overkill and arbitrary.
This doesn't invalidate hexagonal architecture, it just provides the actual good guideline to know if abstractions and information hiding are necessary.
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
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.
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.
The easiest thing to test will always be pure functions. Many people don't realize this, and how clean it can make your tests look. Provide input, get return value, assert/check it. Sure, at the end of the day you have some IO somewhere. But that will usually be a smaller part of the code base. Codebases that make testing more difficult than that, are making it unnecessarily complicated. Sometimes you depend on some library that forces you or heavily nudges you into another style, that can happen. But what one wants to avoid is a codebase, where one has to know to mock 5 other things because of their side effects.
> But that will usually be a smaller part of the code base.
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.
Thing is though, most of the high level languages have that part "solved" via libraries... Hence lots of people don't see the need to test it, as they expect the library to have sufficiently tested already. That leaves your tests mostly centered around your domain/business logic
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
> Thing is though, most of the high level languages have that part "solved" via libraries...
> ...
> 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.
Exactly. Divide the code in impure and pure functions. The pure functions can be easily unit tested. The impure ones can often be integration tested. The rest you'll just have to live with (or cover with whole-process integration tests). For tests spanning larger chunks of your code base it might be worth it to mock impure code. Never mock pure code - that's madness.
Trouble is that in an application the pure functions are just implementation details that don't need to be tested. They get tested by virtue of a correct implementation being necessary to correctly run the application. A library can be a little different story, as there the public interface is quite likely to be pure, but I expect most codebases found in the wild are applications. The discussion happening here seems to be directed at applications.
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?
What is the default way in Rust to write REST endpoints and have the REST endpoint use/create handles to your database transaction that is bound in scope to the underlying HTTP request? (i.e. transaction lifetime and commit/rollback is linked to the HTTP request succeeding)
Often each API route will have its own handler function. That function will - usually through many layers of indirection and abstraction - launch queries towards your database.
That describe a REST API implementation design, but doesn't really answer the particular question: How is the scoping implemented, i.e. how would any given Rust REST API framework couple a Db transaction to a HTTP scope. I mean, I know how that would look like if the framework ofered you no abstraction or DI whatsoever. You would pass the transaction (and maybe database handle) through all sorts of functions, create some sort of context object (that holds all sort of references to the http connection, database, transaction and whatnot, and call everything manually. Eventually you will end up building a similar custom-made abstraction that the built-in DI container in ASP.NET does. But I would expect there are some frameworks for rust that already deliver that.
It is annoying when it is dogmatically followed, but for certain things it makes sense to have a generic interface between your business logic and specific library/service code.
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.
i read that and i was like hey wait a second, that's not how you do that? shouldn't you be having conversations with your team first to find common ground to help with buy in? and also learn from them about the org.
starting with a presentation that nobody asked for is a good way to be ignored.
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.
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.
I wonder how much empathy plays into it? I’ve trended towards teach lead roles and not that I feel my code is necessarily special, I think it’s clean enough and concise at times - occasionally some ASCII art slips in of course…
But what I have noticed across multiple companies is that I offer feedback for reviews that is thorough when it counts - I may pick apart a huge PR with lots of notes and suggestions, and that’s because the change has the potential to impact large systems. I also explain why, and I ask questions of the engineer to make sure I know why they did a thing because maybe I missed something.
I also talk to managers, product, and design, and do a lot of listening. Often times people are working towards a goal, or working against some barrier to getting their goals met, and being able to listen and understand them lends to a lot of credibility. And when you do a lot of that listening, you inherently gain a good amount of understanding of the systems - both technical and human.
When the time comes for someone to say “we should have a new lead on X”, the people that listen and engage tend to rise to that position naturally.
I think accountability and empathy go hand in hand to some degree - by owning something, you’re also saying “I understand how my work might impact other things, other people, and I want to reassure you that I have your back”.
Might work for some projects. For really complex projects (which is what I typically work on), strong engineering helps and so a lead-by-example approach tends to work out and it helps to motivate the team.
Also, I can give my team members detailed feedback. I think they take my constructive criticisms more seriously if I also give them praise which is detailed and accurate. You need a hands-on technical person to really understand people's strengths and weaknesses in a concrete way. Being hands-on also makes you more approachable; people will tell you things that they wouldn't tell a non-technical manager.
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.
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.
A person might very well be suited for both IC or team lead, there is no conflict in the skills themselves. But as you say, actually trying to apply them both simultaneously in practice could lead to conflicts.
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.
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
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”.
Interesting. I've witnessed this happening in the past when someone took over all the boring configuration part of the software. It's so essential to the whole thing that you just end up with responsibilities and trust really quickly.
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.
It sounds like he is implying something, as in everyone switches jobs, but he specifically points out he changes jobs after being promoted, which I assume he did for a reason. But I cant tell if its because he was unhappy and for what reason. Otherwise why would he specifically point that out?
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.
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"
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.
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”?
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.
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.
> 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.
What's wrong with it? Squads look like regular small teams. Tribes look like several teams working on the same product and having to coordinate their work. Each team has specialists, who like to hang out together and talk shop, forming different "chapters". The number of product owners and agile coaches might be excessive :-) But other than that, what's so bad about it?
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.
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)
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.
I feel terrible for the author, having to work in this kind of structure. Someone should tell mytaxi that even Spotify never got “tribes and squads” to work, it sounds like for the same reasons/problems mytaxi ran into.
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?”
> Also, I don’t think you mean “intimacy.” Do you mean “empathy?”
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?
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.
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.
I'm a technical lead, and I often tell my teammates exactly how I want them to implement something. I am not looking over their shoulders at every line of code, but I will tell them plainly that I want an interface, a concrete implementation of the interface that is up to them, and a configuration option for substituting a different concrete type.
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.
> I often tell my teammates exactly how I want them to implement something.
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.
If its any consolation, perhaps there might've been a few other highly intelligent capable sensible people in existence over the last few... shall we say, millennia, who, weren't really listened to either ? ;)
Doesn’t only apply to leads, any new employee faces the same dynamics. Honestly it takes a while to understand not just what is broken at a company, but more importantly why. Otherwise the obvious fix might be a band-aid.
Reminds me of an old post by Joel, “fixing things when you’re a grunt.” His advice was similar.
I find tech leads to be the most difficult people in any organization to work with (always with exceptions), I think it’s because they are still learning the lead part, and at the same time are trying to prove themselves.
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 think it's also that they have a vision and unfortunately this means they have to say no to landing PRs that don't make sense to the overall vision often. And nobody likes to throw away work.
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.
The trust equation implicitly assumes honesty. It’s a second-order model: it explains how trust forms among good-faith actors, not how to detect bad ones.
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.
This. If the lead has no power to suspend people without pay, or to fire people, then he is not a lead. It's okay for this power to be indirect so long as it can be wielded when necessary.
What I read in the story is the context and some action, but not the result. It is implied there is some sort of result, but it is not described, especially how the actions contributed to the result. It may be well intended, but very superficial, childish.
At previous corporation, the tech lead simply recommended for sackings a developer who was questioning his approach. Once he got sacked, everyone listened...
...and then most of best skilled people left in the following weeks.
Tech lead then hired his mates and company nose dived.
I met that exact kind of leader once. In my case, they also tend to work more on their personal brand rather than the company, and keep ship-jumping every couple of years to spread their gospel.
In most non-IT corporations, the managers are non-technical and most are idiots these days. It comes from the MBA hires getting in management roles where they don't understand the area, what Steve Jobs calls "bozos" in his interview (available online).
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.
> My take away from this is that you can't change the culture
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."
The last one made me chuckle. Worked in Japan, didn't see many madogiwa zoku (probably because I only worked at startups) although it was talked about a lot. But I guess community manager-esque position did exist, and now it makes sense why so many big company blokes that went to tech meetup came off as very incompetent
I'd love this. I honestly need to train my spirit, and "please stare at the wall" would be amazing for my dopamine-fried brain.
What you say and what they think are not the same, usually your meaning and intention is drowned out by their pre-existing assumptions and incentives/motivations. You have to resonate with their assumptions and incentives for them to "hear" your meaning and intention.
> Non-compliance stable as a discipline method
Can you expand? I don't understand what this means.
It's some low-risk/consequence project/initiative that is designed to receive people that will be fired due to lack of compliance and/or collaboration with the new management.
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.
This seems kind of childish to be honest. Why not just fire the person?
Because firing people in Germany is a multi-year process that requires (among many other things) paying for a complete training course in all job-relevant skills under the assumption that any incompetence is caused by insufficient training.
I mean I'd guess it was because it's somewhere with a higher bar to firing. Redundancy or dismissal are both much more complicated (expensive) than simply making it very clear you'd like someone to leave.
Psychotic IMO. We will fire you but only after you've been publicly humiliated? Who thinks to do this kind of shit?
As has been stated above, I’m guessing in this specific example it would’ve been due to the rather strict labor laws, which I’m not going to comment my opinion on, just to clarify/explain: Here (Germany), you can basically not fire someone if your company has >10 full-time employees, and they’re not actively misbehaving (or under trainee/probationary status). Yep, this statement means exactly what it reads.
So I’m guessing that’s the reason for this “passive firing” method.
>And I am just raging in my office because I was trying to prevent this situation for 3 years to no avail...... My take away from this is that you can't change the culture.
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.
IDK, I think this is too negative a take. It's easy to blame those in charge for not realising that your problem was the important one but ... how many problems were they being presented with?
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.
I think Occam's razor explains this: the majority of people are incompetent.
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.
>>If top is bunch of sloppy clowns, whole company is going to be the same.
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.
No one person can save a company, but... one person at the top can certainly sink a company.
No real sysops there?
This, many times this. If you encounter pushback from everywhere – leave, don’t spend your life energy fighting bullshit.
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.
> 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.
> 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.
> 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.
Interfaces are only necessary to properly abstract away from implementation details that have different change driver assignments. Else it's overkill and arbitrary. This doesn't invalidate hexagonal architecture, it just provides the actual good guideline to know if abstractions and information hiding are necessary.
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
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.
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.
The easiest thing to test will always be pure functions. Many people don't realize this, and how clean it can make your tests look. Provide input, get return value, assert/check it. Sure, at the end of the day you have some IO somewhere. But that will usually be a smaller part of the code base. Codebases that make testing more difficult than that, are making it unnecessarily complicated. Sometimes you depend on some library that forces you or heavily nudges you into another style, that can happen. But what one wants to avoid is a codebase, where one has to know to mock 5 other things because of their side effects.
> But that will usually be a smaller part of the code base.
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.
Thing is though, most of the high level languages have that part "solved" via libraries... Hence lots of people don't see the need to test it, as they expect the library to have sufficiently tested already. That leaves your tests mostly centered around your domain/business logic
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
> Thing is though, most of the high level languages have that part "solved" via libraries... > ... > 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.
Color me extremely skeptical!
Exactly. Divide the code in impure and pure functions. The pure functions can be easily unit tested. The impure ones can often be integration tested. The rest you'll just have to live with (or cover with whole-process integration tests). For tests spanning larger chunks of your code base it might be worth it to mock impure code. Never mock pure code - that's madness.
Trouble is that in an application the pure functions are just implementation details that don't need to be tested. They get tested by virtue of a correct implementation being necessary to correctly run the application. A library can be a little different story, as there the public interface is quite likely to be pure, but I expect most codebases found in the wild are applications. The discussion happening here seems to be directed at applications.
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?
What is the default way in Rust to write REST endpoints and have the REST endpoint use/create handles to your database transaction that is bound in scope to the underlying HTTP request? (i.e. transaction lifetime and commit/rollback is linked to the HTTP request succeeding)
Often each API route will have its own handler function. That function will - usually through many layers of indirection and abstraction - launch queries towards your database.
That describe a REST API implementation design, but doesn't really answer the particular question: How is the scoping implemented, i.e. how would any given Rust REST API framework couple a Db transaction to a HTTP scope. I mean, I know how that would look like if the framework ofered you no abstraction or DI whatsoever. You would pass the transaction (and maybe database handle) through all sorts of functions, create some sort of context object (that holds all sort of references to the http connection, database, transaction and whatnot, and call everything manually. Eventually you will end up building a similar custom-made abstraction that the built-in DI container in ASP.NET does. But I would expect there are some frameworks for rust that already deliver that.
Axum is the most popular web library out there, and sqlx the most popular sql library. Together they look something like this: https://github.com/tokio-rs/axum/blob/main/examples%2Fsqlx-p...
How do you fake implementation without using interfaces/abstract classes?
DI yes. All the crap under the name of "Clean" Architecture - no.
It is annoying when it is dogmatically followed, but for certain things it makes sense to have a generic interface between your business logic and specific library/service code.
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.
i read that and i was like hey wait a second, that's not how you do that? shouldn't you be having conversations with your team first to find common ground to help with buy in? and also learn from them about the org.
starting with a presentation that nobody asked for is a good way to be ignored.
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.
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.
I wonder how much empathy plays into it? I’ve trended towards teach lead roles and not that I feel my code is necessarily special, I think it’s clean enough and concise at times - occasionally some ASCII art slips in of course…
But what I have noticed across multiple companies is that I offer feedback for reviews that is thorough when it counts - I may pick apart a huge PR with lots of notes and suggestions, and that’s because the change has the potential to impact large systems. I also explain why, and I ask questions of the engineer to make sure I know why they did a thing because maybe I missed something.
I also talk to managers, product, and design, and do a lot of listening. Often times people are working towards a goal, or working against some barrier to getting their goals met, and being able to listen and understand them lends to a lot of credibility. And when you do a lot of that listening, you inherently gain a good amount of understanding of the systems - both technical and human.
When the time comes for someone to say “we should have a new lead on X”, the people that listen and engage tend to rise to that position naturally.
I think accountability and empathy go hand in hand to some degree - by owning something, you’re also saying “I understand how my work might impact other things, other people, and I want to reassure you that I have your back”.
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.
Might work for some projects. For really complex projects (which is what I typically work on), strong engineering helps and so a lead-by-example approach tends to work out and it helps to motivate the team.
Also, I can give my team members detailed feedback. I think they take my constructive criticisms more seriously if I also give them praise which is detailed and accurate. You need a hands-on technical person to really understand people's strengths and weaknesses in a concrete way. Being hands-on also makes you more approachable; people will tell you things that they wouldn't tell a non-technical manager.
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.
Indeed. Often mutually exclusive.
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.
A person might very well be suited for both IC or team lead, there is no conflict in the skills themselves. But as you say, actually trying to apply them both simultaneously in practice could lead to conflicts.
I was thinking the same thing. Sounds more like staff engineer not team lead/mgmt?
Team lead != Tech lead
It is a good way to burn out high performers haha.
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.
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
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”.
Interesting. I've witnessed this happening in the past when someone took over all the boring configuration part of the software. It's so essential to the whole thing that you just end up with responsibilities and trust really quickly.
I don't understand the point of your comment. Why did you switch companies?
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.
Because that's how Silicon Valley works?
It sounds like he is implying something, as in everyone switches jobs, but he specifically points out he changes jobs after being promoted, which I assume he did for a reason. But I cant tell if its because he was unhappy and for what reason. Otherwise why would he specifically point that out?
If you’ve been in the game a few decades, you’ll have changed jobs for all sorts of reasons. Mostly not relevant.
I cant believe noone else found that statement confusing
>> I don't look or act like a leader
In what way?
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.
I took it as good, central contributions are one path to respect and trust.
No need to answer this person's question, they are not asking for help, they are promoting their upcoming book
Or just read all the comments and you don't need to buy their book.
"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.
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.
But very useful. I would like to subscribe to your newsletter.
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.
No. Never accept responsibility without power. That is a lesson I wish I'd learned much earlier in my life.
This, and use power sparingly.
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”?
"Leading without authority"
in other words buffering of culpability.
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.
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.
> 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.
That Spotify squad tribe diagram makes me want to vomit.
Same. Strong SAFe vibes. Hopefully I'll never have to 'work' in such a environment again.
What's wrong with it? Squads look like regular small teams. Tribes look like several teams working on the same product and having to coordinate their work. Each team has specialists, who like to hang out together and talk shop, forming different "chapters". The number of product owners and agile coaches might be excessive :-) But other than that, what's so bad about it?
Too much complexity.
> The number of product owners and agile coaches might be excessive
Its a great soup, apart from the turds floating in it.
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.
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)
It’s pretty corny.
Makes me think of Ninjas and Rockstars.
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.
This is a very long winded way of saying the phrase "respect is earned not given".
I feel terrible for the author, having to work in this kind of structure. Someone should tell mytaxi that even Spotify never got “tribes and squads” to work, it sounds like for the same reasons/problems mytaxi ran into.
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?”
> Also, I don’t think you mean “intimacy.” Do you mean “empathy?”
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?
> I'm a Tech Lead, and nobody listens to me. What should I do?
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.
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.
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.
I'm a technical lead, and I often tell my teammates exactly how I want them to implement something. I am not looking over their shoulders at every line of code, but I will tell them plainly that I want an interface, a concrete implementation of the interface that is up to them, and a configuration option for substituting a different concrete type.
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.
> I often tell my teammates exactly how I want them to implement something.
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.
If its any consolation, perhaps there might've been a few other highly intelligent capable sensible people in existence over the last few... shall we say, millennia, who, weren't really listened to either ? ;)
Doesn’t only apply to leads, any new employee faces the same dynamics. Honestly it takes a while to understand not just what is broken at a company, but more importantly why. Otherwise the obvious fix might be a band-aid.
Reminds me of an old post by Joel, “fixing things when you’re a grunt.” His advice was similar.
I find tech leads to be the most difficult people in any organization to work with (always with exceptions), I think it’s because they are still learning the lead part, and at the same time are trying to prove themselves.
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 think it's also that they have a vision and unfortunately this means they have to say no to landing PRs that don't make sense to the overall vision often. And nobody likes to throw away work.
> Note: this article is a translation from the original “Soy Tech Lead y no me hacen caso. ¿Qué hago?”, in Spanish.
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.
Totally not the same. Its used as technical phrase. In europe we have many languages, but in most of them we use the term Tech lead as phrase.
Welcome to Hell, kid.
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.
The trust equation implicitly assumes honesty. It’s a second-order model: it explains how trust forms among good-faith actors, not how to detect bad ones.
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.
Leave.
make it a secret, start with "dont tell anyone else but..."
"Here's a simple formula that solves this very complex problem that is different for everyone."
Good luck with that.
The conjoined triangles of success!
I hear they teach that at business school
The overall theme there is shapes, sometimes colors. Your exam will be to draw within the lines.
thats why I decide whether to redirect through Jackson Hole
sounds like that person isn't a tech lead
One of them could be sabotaging you so he or she can take ur spot
If nobody is listening to you then you aren't a tech lead, just saying
This. If the lead has no power to suspend people without pay, or to fire people, then he is not a lead. It's okay for this power to be indirect so long as it can be wielded when necessary.
Just for the laughs, some year ago I had to remind one of the juniors that I was the one in charge, not him.
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."
Another website blocking VPN and forcing users to reveal their identity, great.
Listen to them.
What I read in the story is the context and some action, but not the result. It is implied there is some sort of result, but it is not described, especially how the actions contributed to the result. It may be well intended, but very superficial, childish.
At previous corporation, the tech lead simply recommended for sackings a developer who was questioning his approach. Once he got sacked, everyone listened...
...and then most of best skilled people left in the following weeks.
Tech lead then hired his mates and company nose dived.
I met that exact kind of leader once. In my case, they also tend to work more on their personal brand rather than the company, and keep ship-jumping every couple of years to spread their gospel.
must be an idiot that tech leads boss
In most non-IT corporations, the managers are non-technical and most are idiots these days. It comes from the MBA hires getting in management roles where they don't understand the area, what Steve Jobs calls "bozos" in his interview (available online).
there's another dimension is how ready is the group to your ideas
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.
Become a leader.