I am not even sure what I am going to write about, but I have noticed that it's more than 3 months (!) that I don't write a blog post, and not for lack of ideas, I have just been lazy.

Anyway, lots of stuff happened at work in the meanwhile, including many things that make absolutely no sense at all, so I am going to simply write a blog post as a form of therapy. I want to talk about a few things:

• The major leadership problem that exists in Tech
• The way corporate security is pathetic
• The way corporations throw away insane amount of money

In this post I will start from the first, and discuss some problems that I have personally witnessed in the leadership space in tech.

Tech Leadership is a Cult

I am not going to defend leadership in other environments, companies, areas or anything else. However, I want to specifically point out how bad tech leadership is. Some of this might resonate with you, some of it might seem completely foreign (in which case, I consider you lucky), I am just going to describe what I have seen in various companies.

The Original Sin of tech leadership is that often good engineers software developers are promoted to leadership positions based on their performance in technical work. If it sounds completely idiotic, it is because, well, it is. However, it doesn't end here. Bad leadership is like bacteria, it tends to replicate itself quite quickly, because leaders are those who ultimately decide who else gets promoted, polluting the whole culture.

Why does this happen? Well, there are many reasons I suppose, but I want to start from the most hilarious: most leaders/companies don't have a clue how to scale a technical department, how to organize it to make it efficient, so what do they do? They copy from other companies. The problem is that the companies who push out fluff about teams and organization are generally quite big, like our friend big-G. So what happens is that your 500-people company with maybe 200 engineers will copy ideas on tech hierarchy or department organization from companies with thousands and thousands of employees! Isn't that a great idea?

That's how now every company has Senior Engineers, Lead Engineers, Staff Engineers, Senior Staff Engineers, Principal Engineers, Heads of Engineering and the like. Is it a bad thing to have these positions? Of course not. What is bad is having them and not having a fucking clue of what a Staff Engineer should do differently from a Lead or from a "simple" engineer.

And yet, this happens all the time. The corporate religion always prefers form to substance, so there is this inherent belief that by forming a structure or renaming positions, the praxis of what people do will change, and the result will be similar to those who use that structure and those names. Obviously everyone who has ever done actual work knows that structure is a reflection of the way of working, not the opposite. You can be a "simple" engineer and yet be the Subject-Matter-Expert when it comes to a certain technology, and your responsibilities in the day-to-day will reflect that, compared to your peers. Likewise, you can be a lead with the soft-skill of a brick, and your job will reflect that, in the sense that you won't provide any mentoring or organization to your team, and instead you will keep doing mostly technical work (which is what you were good at, and the reason why you got promoted in the first place!).

Drinking the Team Structure Kool-Aid

It's not a coincidence that there are plenty of cults around organizing technical teams. Small teams, cross-functional, close to the business, tribes, technology guilds, self-sufficient, project-based teams, product-based teams, whatever. "In Spotify they use squads, tribes and shit - we should do the same". "No, at Google they do product teams". "I watched a talk from a Netflix guy, and they said that this team structure decreased the time-to-release 20%".

The problem with this is that it's all fucking anecdotal at best. First of all, I have never seen a company where the Structure (the one on paper or in the mind of the middle-managers, agile coaches and other taskmasters) corresponds to the actual structure of the people working. Second of all, this is completely anti-scientific. A team, a technical team, is affected by so many variables that claiming any structure has the specific results obtained in one company according to one interpretation is just silly. Resources, clarity on tasks, time available, individual qualities of people, and tons more are all factors that can affect results. Claiming that any structure works because it worked in your little corner of your unprofitable tech company or startup is complete bullshit. Sure, you get your moment of glory, you present at some conference as if there was any kind of science in your claim, you get your Ted talk, but in the end it's still bullshit.

Why I am a talking about structure when talking about leadership? First, because "leaders" (to be read as: the ones who joined the company early enough - usually this is the only merit) decide what structure to adopt. Second, because adoption of arbitrary structure "because I have seen it on a Ted talk" is the first step that creates vacuums of positions to be filled, usually by promoting people into them. Third, because structure is very often the way leaders, who clearly have not a clue on what to do, try to address systemic problems in an organization. Too slow to deliver products? It must be the structure, let's reorganize all the teams, mixing scopes and creating a huge organizational overhead for everyone, this will make delivery much faster. Or the one I love the most: now that your team owns X, you are free to do changes to it as you please. As if the formal ownership of things would change anything at all in terms of the way people work. If team A was affected by X before, it still is now that you "transferred ownership" and renamed the teams, and if I want to change X I will still need to discuss it with them.

Regarding this case, I can cite a case that happened in my company. I work in a technical security team, we have a bunch of security engineering teams with different scopes. In ancient times the initial members of the security team built a tool that allows to access our platform. None of these people is working anymore in the company, and this tool - which by now as you can imagine is technical debt bolted on technical debt, with more technical debt stuck on it with gum - has changed hands several times. At some point there was a dedicated engineering team "owning it". Then it passed to a platform team, now it might be coming back to security. Full circle. Anyway, the point is, nobody touched it, because nobody wants to touch it. Because as a "temporary/initial" solution it doesn't have a proper development environment and touching it means risking causing an outage for the whole company. Calling the code spaghetti is also a compliment, and the repository is a huge monolith whose name should be "Scope Creep", including all kind of stuff that got added there over time. Now, what is the solution of our leadership to improve this tool? Transfer ownership, of course. The reason? When engineering did the third reorganization in 2 years, they ended up with no proper team to own this thing. Nobody questioned that maybe the reorganization was made with their ass if they excluded such a component, no, it just happened. So now this tool needs to move to a 4-people security engineering team, who have barely the resources to do what they are currently doing, and surely will make great progress with this heap of technical shame.

You might think that it's me imagining things, but I actually got this spelled out to me clearly by my "leader" (head of [something]): now that we own it, we can finally do the changes we need to improve the security. Oh wow, because if this is a priority now, until yesterday we were not doing any changes to this code out of what? Contract obligations? Politeness? Once again, instead of trying to challenge the actual problems (the code is shit, it needs dedicated resources and a clear plan, etc.), the "leaders" came out with this great plan that supposedly will solve all the problems by changing a label or a diagram somewhere that moves this box from one team to another. Ah!

At this point I asked myself multiple times: why people do this? I am quite sure that even these "leaders" know that this is bullshit right? Even they can understand that this plan so far caused only a waste of work to deal with the administrative side and with multiple teams catching up (for what they can) with a legacy tool. So why they still decided to put up this act? I don't have answers here, but I am using Occam's razor and I will go for the obvious answer: because it's easier. It requires no vision, no responsibilities for choosing some work over other, no actual ideas, no negotiations for resources, nothing. Without a proper accountability system in place, these leaders will also never have incentives to actually take responsibilities and therefore to "risk" taking a bad decision.

Leaders Who Don't Lead

With the above I think it might be appropriate to open another chapter. This is specifically about the consequences of adopting an arbitrary structure without understanding the need or the benefits, and/or about promoting people to positions that have no actual meaning, without any kind of real selection.

In a short amount of time, I have seen the following:

• Heads of Engineering who are incapable of taking a single decision even gun to their head.
• Lead Engineers without any kind of social or organizational skill
• Staff Engineers who have no idea what they have to do

How can this happen? It turns out, quite easily. If you adopt the structure of an organization who has 5000 engineers, having 200 of them, your pull of people among which you can choose "leaders" (technical or people) is actually so small, that you end up promoting by seniority alone. If you are lucky, you might get an executive/VP level who is actually good at their job and will do the first promotions meaningfully, choosing the right people who - in turn - will do their job properly and so on. However, especially in star/scaleups senior leadership is usually either part of the founding team, part of their network, or anyway not really chosen for a particular combination of rare skills. If this is the case, then you might get the wrong person. If you get the wrong person and -like me- you have the misfortune of working in Fintech, where too many people come from the banking/finance industry, you will get performers. You see, in many big organizations there are a huge number of people whose job is essentially appropriating and at most re-elaborating someone else's work and taking credit, slowly climbing the corporate ladder. A crucial part of this climbing strategy is dodging any and all responsibilities. Yes, because taking a decision is always a risk. So what you do in general is not take any decision, let the people under you eventually figure something out and take credit when that something works out, while passing blame (in the form of a performance review, maybe) when it doesn't. Either way, you will have done a good job as a leader in the eyes of your superiors.

What happens when people like the one I just described take leadership positions early on in a company? They set the culture, and that means that those who get promoted (reaching Head of, VP, etc. positions) are going to be people similar to them.

That's how you end up with senior or mid-level leadership who not only often doesn't have the skill, but generally doesn't have the minimal intention to actually do their job. Because if done properly, their job usually would require arguing and pushing with the people above them, taking decisions for the whole department and therefore carrying their responsibility. Are you crazy?

The moment you have such people in leadership positions you are essentially fucked, because you have no organizational tool to actually enact any change. Have you ever had to chase over and over for your manager to make a decision, just to have them defer the decision after some other chore that you have to accomplish, until you just take the decision yourself? If yes, then you know what I mean.

With such leaders in place, anything else is done in a purely performative way. When the time will come to form teams, they will have no idea of what is actually needed to have an effective set of teams, so they promote based on seniority (or worse), because it's the easy way that upsets the least amount of people. After all, everyone expects seniority to count something. If there is any competition at all, of course. In some cases you might end up with 2 Staff Engineers, 1 Head of, 4 Lead Engineers and 10 Engineers, which obviously means the pool of people is so small, that if you can demonstrate to be alive the moment you apply for the position, you can be sure to get it.

Ok, so now we have promoted a bunch of people, we have a bunch of teams, what do they need to do? Ah! Well, Staff Engineers are individual contributors, they will know for sure what to do, right? No. Because they have not been chosen based on their ability to drive work autonomously or mentor others on specific tech, and also you gave them no direction whatsoever in terms of what their main achievement should be. And leads? Well, leads searched "what should a tech lead do", found out that they need to schedule 1-to-1s with all their team, and are spending 50% or more of their team in meetings, that should be it, right? Unfortunately most of them will have absolutely no idea about why they are doing what they are doing, but they do it because they read other leads who are like them, except with the self-confidence (or lack of shame) to go write their bullshit in LinkedIn or Medium, and now they have imposter syndrome and they are doing way less technical work.

With a few simple moves you have now created a hierarchy that has no goal, made up of people without any objective, which generates a large amount of organizational work (sync meetings, 1-to-1s, leadership meetings, etc.) to accomplish nothing. Congratulations, when you will get your next job as a CISO you will do great things.

No Way Out?

What might sound ironic at this point is that I am a "leader" myself. Not a real leader, just a Lead, which doesn't mean shit in terms of actual agency, but it means I get to have more stressful conversations, I see more shit than others and I get a team to manage. Well, I think I have a team to manage, nobody has ever told me what I should do, but since I know at least what my people need, I take all the responsibility for team organization, mentoring, facilitating discussions and relationship with other teams, in addition to doing my share of technical work.

Is there anything else that I should be doing? Probably, but I have no clue myself. My team seems pretty happy, but eventually I know it's going to backfire on me. Why? Because I take tons of responsibilities. As you might have guessed from the rant above, I hate people who just bounce decisions all the time, because uncertainty is a stressor for people and my only goal as a Lead is to make sure my team is doing the right thing and in the most serene and efficient way. So I take decisions, and when my leadership refuses to do so, I take pragmatic decisions that I simply present above me as done deals, which probably is exactly their plan as my "Head of" can take credit of all successful projects within my team, even without having contributed to them, and if I screw up they can be a good leader by providing criticism.

Anyway, I want to end on a positive note and close this post like a LinkedIn toxic influencer: I want to try to give some suggestions to my fellow Leads, Staff Engineers or whatever you might be that are also lost in a sea of inefficiency and poor leadership.

1. Dodge the bullshit. If that meeting is bullshit, call it for what is it, and skip it. If someone is bouncing a decision to avoid responsibility, make the decision even clearer for them, make it impossible to find a "third way". Call them out, if necessary.
2. Listen to your team. Many people have great ideas and can help you a lot.
3. When you say you are going to do something, do it. If you tell your team that you are going to talk with X to sort Y, do it. When you need to raise topics in some forum, do it. You want your team to trust you? Make your word count something. Really, just staying true to your word can do wonders for building trust and earning the respect of your team.
4. Your team is the only group of people you need to please. They need to work happily and efficiently. If they do good job, you can counter any bullshit during performance reviews. Let the work count.
5. If you are a Staff Engineer, anybody can be your team. Find good people who can benefit from your skills and work with them. Hierarchy and team structure is generally bullshit and without any real reason, don't let it be a barrier.
6. Remember, most people who do bullshit know they are doing bullshit. They know when you do real work too, though. To stay sane and not become another corporate idiot who is part of the problem in 10 years, stay true to yourself and do work you are proud of if you care about your job. If you don't, I get it, just don't be a burden to other fellow workers.

Let me know if you are blessed by great leadership, if I have simply been unlucky or if you have any other kind of opinion or comment: feel free to reach out via email or on Mastodon.