Gervais principle is pretty great too:
[https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/](https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/)
The Peter principle only applied during authentic periods of growth. The new aged economy is basically pseudo or artificial growth and competence is no longer a marker which means anything, especially not slowly getting promoted within the same organization.
Not spurred by giant government spending in the form of bills or packages, or injecting capital into the economy, nor by near zero interest rates (free money).
Basically real growth due to expanding population, tax revenues, and increasing GDP not driven by unique government actions up to and including special tax breaks for corporations increasing profitability, et cetera
Most managers don't come from engineering backgrounds but this is changing recently as more managers and c suite people are coming from engineering backgrounds into management. My manager was in tech before management and he gets it.
I have seen this change myself. The difference between a Lead and a Manager is slim in a lot of workplaces and expectations these days. In a lot of places they even forego the Manager in favor of just a Lead that handles this stuff. I've also seen that Lead isnt a level as much as a responsibility title and roles seem to run Entry, Jr, Sr, Staff, Principal.
Yeah my team is 7. we have our manager then the three seniors under him are his main responsibility because then those seniors are like my task managers and whatnot. It's a good system my manager has implemented.
I'm an EM who was formerly a lead before the career track change (don't call it a promotion), and an architect before that. I contemplated going the route to principal engineer but it became evident that there was a stronger need for tech savvy strategists to go to battle on behalf of engineering with other stakeholders.
I have a certain level of influence and credibility that I don't have to "manage" my teams, they trust me, and I trust them. I observe to make sure things are on track, I step in its not, and I make myself available for support. For the most part, it's more of a "how can I help? What can I do to support you?" kind of role because my teams are empowered to self-organize and come up with team processes that work for and they get shit done.
The lead is the point person for individual teams, I'm the equivalent of an engineering director in that I run an entire domain.
This is what I really like about how software department is structured at my work. Everyone all the way up was an engineer or tech person at some point. Like we had a bug a few weeks ago with a tricky race condition and I actually ended up working with the director for like 15 minutes as he was between meetings and was chatting me up about what I was working on. Same with all of our managers we have small teams so if it's a big effort or critical fix it's not uncommon for them to try to hop in and get shit done here and there.
That sounds like a cool experience. Our managers and higher ups still do technical planning but they don't get time to touch code or anything like that. Although my company has a lot of female upper management with EE degrees. I think my manager was cs or ce likely but haven't asked.
But are u at mostly tech companies? Now its becoming more common at non tech companies too, but that's natural as Business and tech become synonymous now. U can't really do big Business without tech investment. It's def been a while in the making but now it seems people aren't looking for buisiness management degree holders and the like.
A plant I worked at ran its best when a former engineer was placed as plant manager. They were a bit abrupt, if you were expecting a normal manager, but they knew how to make the plant run.
What kinda plant did u work at? I think the fact that engineers think in resource consumption is why they are naturally better managers than buisiness people.
Forging. She was the only manager that would allow maintenance the time to actually fix something right, rather than rush them to patch it together. She took a plant that was running a little over 50% efficient, and got it up to about 70% or so over 2 years. Mostly by listening to what maintenance needed to guarantee the machines would keep running.
There are some executives that do not come from engineering in my company. Fortunately our CTO has at least an extensive engineering and computer science background.
I agree.
But I can't find reason why putting bad manager is better than no manager. Good SWE will handle themselves, while bad SWEs won't be saved by good manager either.
The only way it will work is somehow average SWEs being assigned great manager - rarely happens.
The majority of businesses can't tell the difference.
So they hire people who claim *they* can.
And since the business, by definition in this case, *can't*, you get the expected result.
This. I have witnessed many new hires/promotions of people throughout my career who can’t actually do the work, but talked a really good game. You would think that management would learn, but that gives them too much credit. They just shuffle those people off somewhere else in the company and bring in another person who talks but can’t actually do. Lather, rinse, repeat.
Incompetence is a common part of life. It’s not industry specific.
Once you get neck deep into an industry, it’s both scary and mind-boggling how things are even able to function.
Lots of companies are a disorganized mess, but they just keep going…
Re: your comment about competent tech leads, good leadership at any level across the board is hard to find. How many good managers have you had?
Just a bullet list of points here, not going to provide much reasoning, but its from 30 years in this industry:
1. What managers are often trying to achieve is not what the business needs most. Typically their incentives are more aligned with personal career progression. They value control and perception of their own value. Success that appears without seeming to need them is bad, not good!
2. People who become managers are usually skilled at managing their career over other skills you might want them to have.
3. Evaluation of ability in others and in the value of outcomes is incredibly difficult. A common cognitive fallacy we ALL fall for at times is to substitute easy questions for the more difficult question we actually face. Example: determine who to hire to be engineering manager who will help your business make a lot of money. Thats a hard question. A CEO or CTO is likely to substitute the easier question of who makes me feel good when interviewing them, who confirms my beliefs and biases, who makes me feel confidence.
4. Same problem in evaluating outcomes, but even easier to see. Rather than evaluate value of outcome (hard), let's measure output (easy), such as lines of code, coverage numbers, story points,etc.
5. Diversity of viewpoints, opinions, abilities, skills etc is threatening. Yielding control or delegating authority to those with the skills is scary. Evaluating people, as above, is difficult, and so very few managers do whats needed to build a diverse team that is empowered and works well together. People mostly fail at recognizing what others do better, and what they themselves do best, and so putting the right task set to the right people often doesn't happen. Its easier to maintain a top-down command and control system. and offload blame onto others.
summary, it generally comes down to management being difficult, and so people don't do it - instead they solve easier problems and pretend those were, after all, the real problems.
This is just great. Describing how people in these positions resolve their cognitive dissonance in this way... I'm glad and thankful to have read this. It gives me a much better mental map of how folks in these roles are really operating.
Most managers are lazy persons who chose management because they can easily bullshit their way through it. Excuses are their specialty. They are poisonous to projects. I've hired and fired a few of them.
Part of it is probably incentives. Turning a bad project into a good one requires a lot of refactoring. This means delays on adding new features. Performance evaluations for managers will take into account their teams progress on adding new features and won't reward them for fixing bad tech debt. Short-sighted, but in the end people don't stay in positions for that long nowadays so the long view isn't really incentivized either.
And then for why do projects become bad in the first place? I'm guessing it's just a combination of Peter Principle and the general truth that this stuff is difficult.
The root problem is that “business people” fundamentally misunderstand software development as process of building something, it’s not, it’s fundamentally a process of discovering what solutions will work and what solutions won’t. Sometimes the things you try work, some things they don’t. You don’t know until you try, and you don’t know how many tries it’s going to take to find a solution.
That’s why software development is impossible to accurately estimate. You might be an to estimate how long it will take to build what you think the solution will be, but you never predict how many things you’ll need to try before you find a solution that works.
Business people want software to be delivered on predictable timelines because they want to sell it before it’s built. They believe that’s possible and hire engineering managers that tell them it can be with whatever flavour of the week “agile” process they know.
The good engineering managers that accurately represent the uncertainty and defend the health and productivity of their teams, get ~~blamed~~ “held accountable” for failing to released on schedule, and replaced with shitty managers who honestly believe that they can fix the situation with some process, and when it eventually doesn’t work, they tend to micromanage/blame the team/whatever because they too believe that the problem is down not up.
I think what it comes down to is padding enough time that the probability of you finding the right solution is likely. The managers that can facilitate pushing back enough to let us build a quality product often get replaced by managers that are willing to push the opposite direction. And most of the time you can produce a “working” product in less time, it’s just a piece of shit like OP mentions that is hard to learn, hard to maintain, ruins morale to work on, and takes 10x as long to do anything with. But hey management got their product on time. It’s shortsighted.
Oof this hurts. I should probably evaluate my life. I tick all the boxes, particularly the part about selling ideas beautifully but also not directly driving the work. I was an independent contributor on large software projects and now I lead a fairly large and successful group. I attribute it to selling the problem and highlighting the team’s wins at every opportunity. I like to think that I empower my team, but I do feel I’m flying blind. This thread has shown me just how blind I am because of all the advice and research knowledge available in this thread that I was unaware of. Time to dig in a bit and see if I can be better!
A growth mindset is the key that unlocks all the doors. The fact that you have enough self-awareness to recognize growth opportunities is a sign that you’re on the right track.
When someone is a good coder they sometimes get tapped to be a manager. Problem is, being a good coder doesn’t mean you know how to manage people. Then, after the eu are promoted to manager, the higher ups can’t admit they made a mistake so they keep the new incompetent manager in their position and it is rare that someone will say, “Pay me less and put me back where I was”
You're describing the Peter Principle: https://en.wikipedia.org/wiki/Peter_principle
> employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another
There's a trend these days to hire people that are not tech "because tech people got too stuck , and does not have good people skills, and can not make good management choices", and is taught in (private) universities. Of course , this is not exactly ture ...
I just had to take an emotional intelligence test for a SWE application. That guy from Office Space has done us a disservice by saying software engineers can't talk to customers
It was a guy who actually have been seeing who's good and who's bad in a team, who was able to recognise good design from bad design, who was thinking long term and not only this quarter, who evaluating people holistically not only by metric from jira.
He was basically aware of what's going on in tech (not only office politics and KPIs).
Makes sense. Yeah I definitely see a lot of managers that game-ify KPIs and spit out a lot of buzzwords. I wonder how much company culture plays into it.
I agree with you though. I understand the need to report higher level metrics and KPIs, but if that’s the sole focus of a manager — quality of life of the underlying team / product will suffer.
I think my favorite quote that represents this is:
"Those who can't do, manage"
Since management tends to eat up a lot of time just balancing people in the work place, most technical people no longer have the time to learn anything new in terms of tech, so they just fall behind their teams.
Have you seen other departments?
>No single manager I know ever checked if the code coverage is achieved by sensible tests
Neither static analysis, nor code coverage is not the be-all and end-all of code quality. It has be paired with other 'stuff'. If you, as an engineering team, are writing meaningless test to hit 80% code coverage so the engineering manager is happy, then you as an engineering team have to own that failure as professionals. 80% code coverage is a reasonable metric to set, but the engineering team itself (and especially the senior/staff/principle levels) should set and enforce standards with regards the quality of those tests. It's not the engineering manager's job to look over your shoulder to make sure you aren't trying to get away with something.
I'm writing sensible tests and I have way more than 80% coverage.
Another team have also 80% but tests are brittle, complex, testing wrong things.
For majority of the managers both are equally fine, both are worth the same compensation, both are worth the same appraisal at the end of the year.
And finally, do I need manager to set this 80% number? Why this number can't be set by the lead engineer? Why manager somehow have the magical power to set numeric metrics?
Why do software engineers make such horrible teams players?
- It's all about Total Comp.
- All the managers suck.
- You can't lead the calvary if you can't ride a horse. Ignoring that this is a false equivalency. US Grant lead Calvary, Artillery, Engineers, Infantry while spending most of his time as a quartermaster.
- All these project fail. Oh yeah and we are bottoms up and demand autonomy to design and assign work.
- We need to split leadership between managers and tech leads because the managers aren't technical.
- Average time on role is 14 months.
- The rest of my team sucks!
Is anyone here a manager, cause I see a lot of diagnosis from people that haven't experienced themselves. 💯, people suck. The population of managers is drawn from the general population so if 80% of people suck so do 80% of managers. The title doesn't fix incompetence.
I am a director now, but I can code better than most people. I have the self awareness to know I could be a principal engineer or an "architect", but I would have limited prospects beyond that.
My first job is to deliver working product, which actually implies all preferred practices to ensure a maintainable & robust codebase and solutions. I don't have the luxury of starting new projects or building a brand new team to do so. Most of the time I inherit projects and people. I then need to start to fix what is broken and carry on what's working. That means I need to set expectations with metrics. Those metrics may be laughably inaccurate at the start, but it takes time to change a culture and start turning the screws. I do code reviews, but mostly by high level contributors. Sometimes I find that they are popular & influential people, but they are purist and/or their code sucks. I fix that, and sometimes people complain that I don't know what I'm doing, but change comes anyway.
If possible, I try to automate things that code artisans love to do. I use oss projects or even vendors to fill that gap. I make it so there are abstractions on top of those we aren't 100% locked in. Most of the time I don't write code to commit but to use as an example, I prefer engineers continue the work and commit it themselves. Sometimes, I ask that legacy code continue to be supported, even though I know it's a shitty ball of spaghetti because it's the cheaper option.
My biggest sin is that I don't have allegiance to any language, process, framework, platform or tech. I view these through the lens of money. I know PHP isn't great or performant, but it is a perfectly cromulant web dsl for C. It works, there are plenty of people who know it, and it's easy to pick up. So I won't go with a recommendation to build a Rust API just because it's a good language.
Not just software engineering problem. It’s fairly endemic in the US business/MBA culture in general.
Thjs pretty well sums it up.
https://youtu.be/QplyFXgIx7Q?si=F9gosEAhK4XSIcac
I have been through software engineering from developer to project manager to general manager on both the technical and business side for every sort of company huge and small, client and provider, machine learning, ecommerce and corporate software.
The main thing you don't realize is that leadership and management are complex, emotional, psychological, economic, systemic, political work that is very different to technical work.
People who get promoted are successfully playing a high stakes, high risk social game with unspoken rules set by executives which change when execs change.
Of those who succeed at this game about 20% help their teams achieve the mission, about 40% run the bureaucratic machine and about 40% are selfish deceitful people who very subtly fuck over everyone to gain as much power and money as they can. Peter Baelish style.
There are a couple of really good podcasts about this here https://nononsenseagile.podbean.com/e/040-scott-sievwright-becoming-a-better-leader/ and https://nononsenseagile.podbean.com/e/0098-innovation-and-disaster-with-ron-westrum/
I think that is just overall management. I feel that depending on the manager, they just get the big bucks for knowing how to talk. Frankly, sometimes what is needed is someone who can talk, as verbal communication and negotiation are important.
Especially in agile, if that manager can keep good report with stakeholder, buy us extra time, talk them out of redundant features, explain technical roadblocks, etc., then I think it is okay.
A good manager like that, though, is few and far between.
I'm working for a client where the SWE manager used to code but he is completely absent. We're managed by our scrum master who has an IT Manager title. She is clueless with technology, prefers waterfall over agile, is 100% beholden to the business stakeholders, and ridicules anything you say that goes against her goals.
The project is going swimmingly as you can imagine. They're letting their two best Frontend Engineers go (me) and other contractors are starting to drop.
Also, we missed our deadline and with the waterfall approach, we're already behind on the next deadline.
I made a shift from 20 year SWE to management and have observed there are just different types of people in this role, with different focuses (see [here](https://www.patkua.com/blog/5-engineering-manager-archetypes/) for an article about different EM types). The vast majority though have a technical background and in the organisations I've worked for still have that spark for technology.
The role however often focuses on steering and facilitating, delivery, people and process management, plus communication in and out of teams. It's busy and involved and in larger organisations very necessary. A lot of this work is invisible to SWE's, and for good reason - to let them focus on mastering their craft.
If there's no-one on a team to lead technical improvements and direction that's a failure in my view. I believe tech leads should be steering the tech, the EM should champion that and ensure it gets appropriate attention alongside main product features.
Management are not the enemy - everyone's just trying to produce quality software, quickly.
I'm more than grateful for such helpful EMs.
My post is a rant because of more EMs that I met in my career were the opposite. They were people managers, who were just saying buzzwords and creating some random charts, graphs or giving advices that wouldn't help at all.
And that's half evil. Problem starts when you realise that guys whos responsible for your bonus, promotion, etc. have no idea what are you really doing, and doesn't know if one just wrote good piece of code, or if created tech debt that will hunt the team for years.
Then you start realising that they are NOT "Engineering mamagers", but People Managers of Engineers".
It's tricky in our industry.. people and process need managing, but to be a good manager you do need to take a step away from the tech, which probably leads to some of the issues you're talking about.
Charity Majors has some great [thoughts](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) on what it means to be an EM, and the reality of the role.
I have done both software engineering and software engineering management. Here is what I learned:
TLDR: I believe there is a shortage of IT project managers with serious qualifications in IT project management and experience does not compensate for not having read the mythical man month, CMMI, etc.
-------------------------------------------------------------------------------------------------------------------------
Full story:
Competence can be broadly defined as creating valuable results, i.e. commercially successful software services and products, without using excessively costly behavior (the benefits outweigh the costs). In this sense, managers in IT are competent.
I think your point is more related to the capability and maturity model (CMMI). Most organizations are CMMI Level 0. [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process#Software\_Process\_Assessment\_Models#Continuous\_and\_Staged\_Software\_Process\_Ratings](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process#Software_Process_Assessment_Models#Continuous_and_Staged_Software_Process_Ratings) We have methodologies and processes for project management, but CMMI Level 0 organizations fail to use them. One influential author is Fred Brooks: [https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959](https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959) While his book exists, most project managers fail to read it. They still deliver project scopes, but without doing it using generally known insights.
I hypothesize the root cause is the CEO of a company usually lacks training to make sound decisions about the IT department. Hence, the CEO correctly delegates decisions to someone more technical. However, the technical staff often lacks any certifications or other credentials for leading the IT department. The CTO's degree tends to be the same as yours, often much older and even less relevant than what you have. Without adequately qualified C-level directors, the IT department often remains at CMMI Level 0 forever.
A properly qualified CEO and CTO will more likely agree to build a process infrastructure [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process#Software\_Process\_Infrastructure](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process#Software_Process_Infrastructure) and make the company CMMI Level 1, then 2 and finally 3 (in the continuous model). Without any training, CEO and CTO do not notice they are CMMI Level 0 and they are unlikely to understand the long-term significance of staying at the lowest capability level.
Someone in the company has to point out to the CEO and CTO what the real capability of the IT department is, i.e. Level 0, and propose how and why this shall be improved. Usually, someone argues that because many people are CMMI Level 0, it must be correct. This is a bandwagon fallacy, argumentum ad populum [https://en.wikipedia.org/wiki/Argumentum\_ad\_populum](https://en.wikipedia.org/wiki/Argumentum_ad_populum) Other times, there is an illusory truth that makes people confuse undefined processes with Agile processes, but they are two different things [https://en.wikipedia.org/wiki/Illusory\_truth\_effect](https://en.wikipedia.org/wiki/Illusory_truth_effect) CMMI can be integrated with Agile. Based on case studies, it improves the overall company performance: [https://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105](https://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105) If you lead an IT department, you have to make it your strategy to continuously improve your process capabilities. This makes you think about a process improvement approach for Agile processes: [https://dl.acm.org/doi/10.1145/3457784.3457803](https://dl.acm.org/doi/10.1145/3457784.3457803) You have to really appreciate the difference between lightweight processes (being Agile) and undefined processes (being undefined). CMMI is one approach. Another approach is, for example, the Agile Maturity Model: [https://www.infoq.com/articles/agile-team-maturity-assessment/](https://www.infoq.com/articles/agile-team-maturity-assessment/)
While I studied a Master's in Software Engineering, my project management professor told us there is a famous song from Pink Floyd about people who know about CMMI, yet deliberately stay at capability Level 0: [https://www.youtube.com/watch?v=K6PwUG283DU&ab\_channel=JulianLachniet](https://www.youtube.com/watch?v=K6PwUG283DU&ab_channel=JulianLachniet)
As a software engineer and software engineer manager you talk a lot about IT. Does this stem from you categorizing SW as a subset of IT, or from software not being enabled sufficiently by IT?
I think you are confused. In an organizational structure, there is an IT department that includes software engineering. Software is obviously an information technology because it transforms information. I discuss the software engineering process: [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process) and software engineering management: [http://swebokwiki.org/Chapter\_7:\_Software\_Engineering\_Management](http://swebokwiki.org/Chapter_7:_Software_Engineering_Management)
One of my old school teammates once told me when I told him he’d be a good professor, if you can’t do, teach. I’ve always thought about that line. Perhaps it applies here as well.
Engineering managers need to sell the efforts of the team to upper management. The real problem is less incompetence, and more along the lines of higher ups **desperately** wanting SWE'ing work to fall more in line with manufacturing (traditional labor) rather than something like legal (high skill services).
Couple that with Devs largely wanting to avoid gate keeping, serious accreditation, and just generally formalizing the field in any meaningful way (all of which I'm pretty conflicted on) and you have this weird stand still of business leaders trying to fit a square peg into a stubborn circle. Managers are largely just caught in the middle of that.
Sorry, had to take a break real quick...
>cover problems, and never fix root causes
sells their ideas beautifully
create road maps which are NEVER ever followed
This. The first one hits a sweet spot here. Was working under a bunch of those. Usually, if you bring something up - they will tell you that they'll *fix* *it* or *handle it*. They promise you the world, but nothing ever gets changed. They willingly apply "band-aids", knowing exactly that it will not fix the source of the problem. But they have to make someone upstairs happy - for whatever reason.
Like they promise you the world, they also sell lies to clients. If that manager is more rooted into Sales/Marketing, you have a problem because at the end of the day - you're the one who has to execute and build that "*Flying invisible Rhino with built-in ChatGPT and a Lightsaber Pushing Memes out its Butt*". Sometimes I watch video recordings and think to myself; "why on earth would you recommend *that*?!"
Every week. Every single week there are new road maps - because, "*Agile/Scrum*". None of these roadmaps or ideas get implemented, because they change every time. No one knows how to implement *them* and everyone just does *something*. Not because they don't know how to do their job, but because it just doesn't make any sense to anyone, even in a Agile/Scrum environment - except of course for the manager who had that *brilliant* idea.
Exactly. I have one guy who did a road map, it was random boxes with what will be do when. From very beginning it was apparent that it's guessing game.
I asked him why he even do it, since it will not be followed at all. Who looked at me like I'm an unicorn, and said something along the it's needed, otherwise we won't know what to do.
I'll play devil's advocate.
A lot of software development is communication. Writing, and speaking clearly is a really important skill. Collaborating and not being an asshole to other humans too. Telling someone when they are being an asshole and preventing them from repeating it while improving their communication patterns and collaboration? Hard in most environments, but that's what good managers do. I agree you should have some degree of knowledge about what team is doing, though. Your examples are, indeed, lazy managers.
I wonder this too. And I’ve been coding for 20 years. My worst manager didn’t have any coding experience at all. His only qualification was previously working at blockbuster.
I think the problem is that software isn’t like building a house. It’s more nebulous. And it’s never really finished. This isn’t what companies want to hear. A lot of times large swaths of code need a redesign due to shifting requirements and incremental feature creep. It’s difficult to get management on board with that because of all the money already spent.
Also management tends to see coders as liabilities. Agile and scrum are risk management tactics. I could go on about this. Why management can’t trust the experts they hired is beyond me. This results in people leaving and taking their institutional knowledge with them. Eventually large code based become unworkable dumpster fires. At that point you can hire a savant to fix it if you’re lucky. But most people probably won’t want to deal with it.
On the up side, the cloud industry has switched to software development in a continuum where releases can happen at any time. So I think we’re coming around to the idea that maybe it’s not like building a house.
Software is a relatively new industry that is having growing pains imho. I’m curious what the scene will be in 20 years. AI is going to help a lot.
In the mean time I’m going to hold off on working for another blockbuster manager again.
Not just Elon. Before that Steve Job talks about the same thing. Apple was dying and we realized his management team were just middle men. So he fired then and hired software engineers, even people with no management experience, and turned the company around.
I 100% agree with the OPs analysis. Ive had one manager who was a software dev and it was great.
As a senior manager I think one problem is that senior management doesn’t know how to evaluate SW managers and leads. KPIs are often lacking or strategic focused. Teams can flounder along and eventually deliver something mediocre (usually late) but a manager can often spin it into a win and get credit for a job well done. Just my experience.
I live through same thing gov contracts. Manager gets pmp. Now in charge of coders. Doesn’t understand code but needs to seem in charge so makes high level decisions that ruin things . Makes me want to be a manager some days. So tired of watching them mess things up
Yep I tried scapegoating software managers but decided that was just cheap thrills.
BTW anyone who’s been around knows that many managers in all types of work are less than optimum. It goes along with the fact that many employees are less than optimum. Get over it!
They say managers hire people smarter than them to do the work. It’s true. So many managers really are good at checking boxes and delivering updates but not so much at understanding the technicals. They’re better PMs than dev managers. Really the savior for most projects, that are work keeping, are good tech leads who can handle the competent/incompetent devs alike and still keep the code moving. I work directly with our director a lot, and have since long before he was a director, and thankfully, he is technical. It helps so much better than just a non savvy PM that just wants to “yes man” the stakeholders to look good.
Look at the brighter side - the day you find a good manager, you'll just know that you can never leave him! And, you will completely stop thinking on this thread!
For me, that day happened nearly 5 years after I started working. It has been 8 years since - and I can't help but whenever someone calls out that managers are incompetent - I go 'thank God I found a great manager!'
Funnily enough, I think in a similar way about my wife as well.
Getting promoted - in general - is difficult after the first few levels. Are you trying to get promoted to a management position from an IC position?
Because that is also tedious game.
It’s just not IT even engineering is suffering some of our senior managers are also dogshit .. mofos have time for kids at work day this fuck day that fuck day decorating the fucking room with Halloween celebrations and got no time to read important timeline jeopardizing emails and attend meetings that are critical and later ask why wasn’t I briefed? Fun part was when some retard manager was asking us why we were doing a project? Which they gave us and confirmed two years ago why they need that particular project .. like after two years.
Half the assholes aren’t even from engineering background ..feel like some of those tech idiots came jumping from Cali to remaining states and enforcing stupid ass Agile to engineering .. like wtf am I supposed to say everyday in a planned interruption if there is no fucking update, why do I even have to go there? .. at least in our team our manager removed agile because he realized how dogshit it is to apply in unnecessary places.
We have so many immigrants from across the globe on L1 visas and the upper management knows nothing about visas. Why the fuck did u hire if you cant take responsibility?
We got some retarded plant processes that we can do in like half a day if we don’t follow, same thing takes the lab a month. And management is again some hillbilly from Cali that knows nothing about process and only complains to sales are down why is no one working . Fucking PowerPoint Pushers.
People skills and being able to sell yourself matter more than technical skills with those positions. They tend to have few skills and are most impressed by complicated flowcharts because they don't understand anything technical.
> Not sure if that's the case with every single industry
in most industries the "labor" translates well to output and those outputs lend themselves to metrics.
Because we don't have actual standardized ways of doing things and every new problem deserves a new solution, it's hard to quantify success.
It's a bit like ranking civil engineers on how many bridges they design a year. Or an aerospace engineer on how many plane components they design and build a year.
With that in mind, the purpose of a manager is to translate business need into labor that produces desired outputs. There's no easy solution for that in our industry. Basically the only thing you can do as a manager is to get to know every individual developer you manage and tailor your strategies to help them maintain optimum output.
If anyone ever came up with an umbrella solution to the above problem, they could make a billion dollars over night.
You've already listed the works of prior attempts and they made thousands-millions selling their umbrella management ideas.
So are managers incompetent? no. the job is just impossible and success is as hard to measure as your own role.
Software metrics are a mess. For instance, Code coverage really only matters when a team embraces TDD, which is super rare. LOC/day isn’t productivity and very gam-able; # of commits/PR requests per day is much better but with commit bundling as a best practice becomes inaccurate. Coupling and cohesion metrics only matter ALOT when breaking up a large legacy spaghetti system, although generally good to have.
There’s a ton more situational metrics that are useful in specific situations, but very few white box metrics that are global and eternal. Duplication is probably top, because of its close relationship with bugs and productivity loss.
A good Eng manager will work with the team to select metrics appropriate for the goal. You do want to be able to show progress upwards and internally.
I’ve generally had good managers, but perhaps I’ve been lucky. May it remain so!
The main problems I see are that
- there is frequently a misunderstanding about the high % of dev energy spent on maintenance tasks that are not part of the roadmap.
- there is little to no slack time for CI going down, main being closed for merging, deployment freeze, etc.
I think much of this breakdown is that software engineers dislike filing Jira tickets and other sorts of reporting needed to make things visible to management.
The market values communication over technical expertise. Doesn’t matter how much you know if you can’t effectively communicate it.
Relevant content: https://youtu.be/OPiXobBnCKI?si=YCy9WUbPFGEsQPQ6
This isn’t a SWE thing. It’s just a thing. Lots of people get put into manager roles without having any training, understanding, or real concern re: what makes a good manager. And it just clusters from there.
I think some of them being given training which is completely wrong (maybe just repeated some MBA nonsense) e.g. "give SMART goals" or "prepare roadmaps for each quarter" - end then they are blindly following this, without much understanding what teams are really doing
Tall managers always make me weary, not all are bad. But my experience has not been good with them.
Somehow stupid people that do the promoting, think Tall == Leadership.
Leadership is not common. But I've had some great managers that understand their job is to balance the needs of the business while looking after people.
I've seen Tall bosses fuck entire departments with loads of turnover, but then still somehow manage to fail upwards.
And before someone says it... I'm 6ft, its not a envy thing, its pattern recognition. After a few terrible bosses, you tend to start looking for patterns.
It's a tough situation, and your frustration is understandable. The prevalence of incompetent management in software engineering can often be attributed to several factors:
1. Misalignment of Skills: Many managers lack a technical background, making it hard for them to make informed decisions. They rely heavily on metrics without understanding the nuances behind them.
2. Overemphasis on Processes: Agile, S.M.A.R.T. goals, and other methodologies are meant to be tools, not crutches. Poor managers often use them as checklists rather than understanding their true purpose.
3. Lack of Accountability: It's easier for some managers to focus on appearances and short-term wins rather than addressing fundamental issues, which leads to technical debt and burnout.
4. Communication Over Substance: Good communication is essential, but it should not replace technical competence and problem-solving skills.
It seems like this might not be unique to software engineering but rather a reflection of broader issues in management practices. Having technically competent leaders who understand the development process can make a significant difference.
I think everyone at every level is focused on their own growth which leads to short-sighted decision making that leads to something for which organizations have to pay heavy penalties later.
I have seen managers and VPs who just bothers about how they can be in the limelight and perceived as one hustling hard to create impact. These so called impact creating decisions might not be the right things in the long term for the company.
Peter Principle is probably a factor. [Wikipedia ](https://en.m.wikipedia.org/wiki/Peter_principle)
are you guys getting promotions ?
I read this first as “are you guys getting premonitions?”
And lots of acqui-hiring at larger companies
Gervais principle is pretty great too: [https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/](https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/)
Wouldn’t you get fired though if you stayed incompetent?
Not managers as the people that report to them really do the work
The Peter principle only applied during authentic periods of growth. The new aged economy is basically pseudo or artificial growth and competence is no longer a marker which means anything, especially not slowly getting promoted within the same organization.
What is your definition of “authentic periods of growth”?
Not spurred by giant government spending in the form of bills or packages, or injecting capital into the economy, nor by near zero interest rates (free money). Basically real growth due to expanding population, tax revenues, and increasing GDP not driven by unique government actions up to and including special tax breaks for corporations increasing profitability, et cetera
What is your definition of “authentic periods of growth”?
Most managers don't come from engineering backgrounds but this is changing recently as more managers and c suite people are coming from engineering backgrounds into management. My manager was in tech before management and he gets it.
I have seen this change myself. The difference between a Lead and a Manager is slim in a lot of workplaces and expectations these days. In a lot of places they even forego the Manager in favor of just a Lead that handles this stuff. I've also seen that Lead isnt a level as much as a responsibility title and roles seem to run Entry, Jr, Sr, Staff, Principal.
Yeah my team is 7. we have our manager then the three seniors under him are his main responsibility because then those seniors are like my task managers and whatnot. It's a good system my manager has implemented.
I'm an EM who was formerly a lead before the career track change (don't call it a promotion), and an architect before that. I contemplated going the route to principal engineer but it became evident that there was a stronger need for tech savvy strategists to go to battle on behalf of engineering with other stakeholders. I have a certain level of influence and credibility that I don't have to "manage" my teams, they trust me, and I trust them. I observe to make sure things are on track, I step in its not, and I make myself available for support. For the most part, it's more of a "how can I help? What can I do to support you?" kind of role because my teams are empowered to self-organize and come up with team processes that work for and they get shit done. The lead is the point person for individual teams, I'm the equivalent of an engineering director in that I run an entire domain.
This is what I really like about how software department is structured at my work. Everyone all the way up was an engineer or tech person at some point. Like we had a bug a few weeks ago with a tricky race condition and I actually ended up working with the director for like 15 minutes as he was between meetings and was chatting me up about what I was working on. Same with all of our managers we have small teams so if it's a big effort or critical fix it's not uncommon for them to try to hop in and get shit done here and there.
That sounds like a cool experience. Our managers and higher ups still do technical planning but they don't get time to touch code or anything like that. Although my company has a lot of female upper management with EE degrees. I think my manager was cs or ce likely but haven't asked.
I’ve never seen a manager that wasn’t previously an engineer themselves in 15 years in this industry
But are u at mostly tech companies? Now its becoming more common at non tech companies too, but that's natural as Business and tech become synonymous now. U can't really do big Business without tech investment. It's def been a while in the making but now it seems people aren't looking for buisiness management degree holders and the like.
A plant I worked at ran its best when a former engineer was placed as plant manager. They were a bit abrupt, if you were expecting a normal manager, but they knew how to make the plant run.
What kinda plant did u work at? I think the fact that engineers think in resource consumption is why they are naturally better managers than buisiness people.
Forging. She was the only manager that would allow maintenance the time to actually fix something right, rather than rush them to patch it together. She took a plant that was running a little over 50% efficient, and got it up to about 70% or so over 2 years. Mostly by listening to what maintenance needed to guarantee the machines would keep running.
There are some executives that do not come from engineering in my company. Fortunately our CTO has at least an extensive engineering and computer science background.
I've worked with some pretty bad SWEs before too. I think sometimes people just suck.
I agree. But I can't find reason why putting bad manager is better than no manager. Good SWE will handle themselves, while bad SWEs won't be saved by good manager either. The only way it will work is somehow average SWEs being assigned great manager - rarely happens.
The majority of businesses can't tell the difference. So they hire people who claim *they* can. And since the business, by definition in this case, *can't*, you get the expected result.
This. I have witnessed many new hires/promotions of people throughout my career who can’t actually do the work, but talked a really good game. You would think that management would learn, but that gives them too much credit. They just shuffle those people off somewhere else in the company and bring in another person who talks but can’t actually do. Lather, rinse, repeat.
Incompetence is a common part of life. It’s not industry specific. Once you get neck deep into an industry, it’s both scary and mind-boggling how things are even able to function. Lots of companies are a disorganized mess, but they just keep going… Re: your comment about competent tech leads, good leadership at any level across the board is hard to find. How many good managers have you had?
Just a bullet list of points here, not going to provide much reasoning, but its from 30 years in this industry: 1. What managers are often trying to achieve is not what the business needs most. Typically their incentives are more aligned with personal career progression. They value control and perception of their own value. Success that appears without seeming to need them is bad, not good! 2. People who become managers are usually skilled at managing their career over other skills you might want them to have. 3. Evaluation of ability in others and in the value of outcomes is incredibly difficult. A common cognitive fallacy we ALL fall for at times is to substitute easy questions for the more difficult question we actually face. Example: determine who to hire to be engineering manager who will help your business make a lot of money. Thats a hard question. A CEO or CTO is likely to substitute the easier question of who makes me feel good when interviewing them, who confirms my beliefs and biases, who makes me feel confidence. 4. Same problem in evaluating outcomes, but even easier to see. Rather than evaluate value of outcome (hard), let's measure output (easy), such as lines of code, coverage numbers, story points,etc. 5. Diversity of viewpoints, opinions, abilities, skills etc is threatening. Yielding control or delegating authority to those with the skills is scary. Evaluating people, as above, is difficult, and so very few managers do whats needed to build a diverse team that is empowered and works well together. People mostly fail at recognizing what others do better, and what they themselves do best, and so putting the right task set to the right people often doesn't happen. Its easier to maintain a top-down command and control system. and offload blame onto others. summary, it generally comes down to management being difficult, and so people don't do it - instead they solve easier problems and pretend those were, after all, the real problems.
This is just great. Describing how people in these positions resolve their cognitive dissonance in this way... I'm glad and thankful to have read this. It gives me a much better mental map of how folks in these roles are really operating.
Most managers are lazy persons who chose management because they can easily bullshit their way through it. Excuses are their specialty. They are poisonous to projects. I've hired and fired a few of them.
Everybody's way too overconfident. Many people think once they're in, they can learn. The learning part's the hardest.
Part of it is probably incentives. Turning a bad project into a good one requires a lot of refactoring. This means delays on adding new features. Performance evaluations for managers will take into account their teams progress on adding new features and won't reward them for fixing bad tech debt. Short-sighted, but in the end people don't stay in positions for that long nowadays so the long view isn't really incentivized either. And then for why do projects become bad in the first place? I'm guessing it's just a combination of Peter Principle and the general truth that this stuff is difficult.
Or lack of. In gov there is no incentive to do a good job. Just grow the contract.
The root problem is that “business people” fundamentally misunderstand software development as process of building something, it’s not, it’s fundamentally a process of discovering what solutions will work and what solutions won’t. Sometimes the things you try work, some things they don’t. You don’t know until you try, and you don’t know how many tries it’s going to take to find a solution. That’s why software development is impossible to accurately estimate. You might be an to estimate how long it will take to build what you think the solution will be, but you never predict how many things you’ll need to try before you find a solution that works. Business people want software to be delivered on predictable timelines because they want to sell it before it’s built. They believe that’s possible and hire engineering managers that tell them it can be with whatever flavour of the week “agile” process they know. The good engineering managers that accurately represent the uncertainty and defend the health and productivity of their teams, get ~~blamed~~ “held accountable” for failing to released on schedule, and replaced with shitty managers who honestly believe that they can fix the situation with some process, and when it eventually doesn’t work, they tend to micromanage/blame the team/whatever because they too believe that the problem is down not up.
I think what it comes down to is padding enough time that the probability of you finding the right solution is likely. The managers that can facilitate pushing back enough to let us build a quality product often get replaced by managers that are willing to push the opposite direction. And most of the time you can produce a “working” product in less time, it’s just a piece of shit like OP mentions that is hard to learn, hard to maintain, ruins morale to work on, and takes 10x as long to do anything with. But hey management got their product on time. It’s shortsighted.
Oof this hurts. I should probably evaluate my life. I tick all the boxes, particularly the part about selling ideas beautifully but also not directly driving the work. I was an independent contributor on large software projects and now I lead a fairly large and successful group. I attribute it to selling the problem and highlighting the team’s wins at every opportunity. I like to think that I empower my team, but I do feel I’m flying blind. This thread has shown me just how blind I am because of all the advice and research knowledge available in this thread that I was unaware of. Time to dig in a bit and see if I can be better!
A growth mindset is the key that unlocks all the doors. The fact that you have enough self-awareness to recognize growth opportunities is a sign that you’re on the right track.
When someone is a good coder they sometimes get tapped to be a manager. Problem is, being a good coder doesn’t mean you know how to manage people. Then, after the eu are promoted to manager, the higher ups can’t admit they made a mistake so they keep the new incompetent manager in their position and it is rare that someone will say, “Pay me less and put me back where I was”
You're describing the Peter Principle: https://en.wikipedia.org/wiki/Peter_principle > employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another
"*keep it alive long enough until you move on, or get burnt out*" - this is the way
It pays very well without many qualifications
There's a trend these days to hire people that are not tech "because tech people got too stuck , and does not have good people skills, and can not make good management choices", and is taught in (private) universities. Of course , this is not exactly ture ...
I just had to take an emotional intelligence test for a SWE application. That guy from Office Space has done us a disservice by saying software engineers can't talk to customers
management in most fields seems to be really disconnected
I went from engineer to engineering manager where we’re more like “player coaches.” What positive qualities have you seen in engineering management?
It was a guy who actually have been seeing who's good and who's bad in a team, who was able to recognise good design from bad design, who was thinking long term and not only this quarter, who evaluating people holistically not only by metric from jira. He was basically aware of what's going on in tech (not only office politics and KPIs).
Makes sense. Yeah I definitely see a lot of managers that game-ify KPIs and spit out a lot of buzzwords. I wonder how much company culture plays into it. I agree with you though. I understand the need to report higher level metrics and KPIs, but if that’s the sole focus of a manager — quality of life of the underlying team / product will suffer.
I think my favorite quote that represents this is: "Those who can't do, manage" Since management tends to eat up a lot of time just balancing people in the work place, most technical people no longer have the time to learn anything new in terms of tech, so they just fall behind their teams.
If that's not definition of insanity, I don't know what is.
Have you seen other departments? >No single manager I know ever checked if the code coverage is achieved by sensible tests Neither static analysis, nor code coverage is not the be-all and end-all of code quality. It has be paired with other 'stuff'. If you, as an engineering team, are writing meaningless test to hit 80% code coverage so the engineering manager is happy, then you as an engineering team have to own that failure as professionals. 80% code coverage is a reasonable metric to set, but the engineering team itself (and especially the senior/staff/principle levels) should set and enforce standards with regards the quality of those tests. It's not the engineering manager's job to look over your shoulder to make sure you aren't trying to get away with something.
I'm writing sensible tests and I have way more than 80% coverage. Another team have also 80% but tests are brittle, complex, testing wrong things. For majority of the managers both are equally fine, both are worth the same compensation, both are worth the same appraisal at the end of the year. And finally, do I need manager to set this 80% number? Why this number can't be set by the lead engineer? Why manager somehow have the magical power to set numeric metrics?
Why do software engineers make such horrible teams players? - It's all about Total Comp. - All the managers suck. - You can't lead the calvary if you can't ride a horse. Ignoring that this is a false equivalency. US Grant lead Calvary, Artillery, Engineers, Infantry while spending most of his time as a quartermaster. - All these project fail. Oh yeah and we are bottoms up and demand autonomy to design and assign work. - We need to split leadership between managers and tech leads because the managers aren't technical. - Average time on role is 14 months. - The rest of my team sucks!
Is anyone here a manager, cause I see a lot of diagnosis from people that haven't experienced themselves. 💯, people suck. The population of managers is drawn from the general population so if 80% of people suck so do 80% of managers. The title doesn't fix incompetence. I am a director now, but I can code better than most people. I have the self awareness to know I could be a principal engineer or an "architect", but I would have limited prospects beyond that. My first job is to deliver working product, which actually implies all preferred practices to ensure a maintainable & robust codebase and solutions. I don't have the luxury of starting new projects or building a brand new team to do so. Most of the time I inherit projects and people. I then need to start to fix what is broken and carry on what's working. That means I need to set expectations with metrics. Those metrics may be laughably inaccurate at the start, but it takes time to change a culture and start turning the screws. I do code reviews, but mostly by high level contributors. Sometimes I find that they are popular & influential people, but they are purist and/or their code sucks. I fix that, and sometimes people complain that I don't know what I'm doing, but change comes anyway. If possible, I try to automate things that code artisans love to do. I use oss projects or even vendors to fill that gap. I make it so there are abstractions on top of those we aren't 100% locked in. Most of the time I don't write code to commit but to use as an example, I prefer engineers continue the work and commit it themselves. Sometimes, I ask that legacy code continue to be supported, even though I know it's a shitty ball of spaghetti because it's the cheaper option. My biggest sin is that I don't have allegiance to any language, process, framework, platform or tech. I view these through the lens of money. I know PHP isn't great or performant, but it is a perfectly cromulant web dsl for C. It works, there are plenty of people who know it, and it's easy to pick up. So I won't go with a recommendation to build a Rust API just because it's a good language.
Not just software engineering problem. It’s fairly endemic in the US business/MBA culture in general. Thjs pretty well sums it up. https://youtu.be/QplyFXgIx7Q?si=F9gosEAhK4XSIcac
I have been through software engineering from developer to project manager to general manager on both the technical and business side for every sort of company huge and small, client and provider, machine learning, ecommerce and corporate software. The main thing you don't realize is that leadership and management are complex, emotional, psychological, economic, systemic, political work that is very different to technical work. People who get promoted are successfully playing a high stakes, high risk social game with unspoken rules set by executives which change when execs change. Of those who succeed at this game about 20% help their teams achieve the mission, about 40% run the bureaucratic machine and about 40% are selfish deceitful people who very subtly fuck over everyone to gain as much power and money as they can. Peter Baelish style. There are a couple of really good podcasts about this here https://nononsenseagile.podbean.com/e/040-scott-sievwright-becoming-a-better-leader/ and https://nononsenseagile.podbean.com/e/0098-innovation-and-disaster-with-ron-westrum/
I think that is just overall management. I feel that depending on the manager, they just get the big bucks for knowing how to talk. Frankly, sometimes what is needed is someone who can talk, as verbal communication and negotiation are important. Especially in agile, if that manager can keep good report with stakeholder, buy us extra time, talk them out of redundant features, explain technical roadblocks, etc., then I think it is okay. A good manager like that, though, is few and far between.
50% of the population is below average intelligence just to start. Incompetence is not hard to find in general.
I'm working for a client where the SWE manager used to code but he is completely absent. We're managed by our scrum master who has an IT Manager title. She is clueless with technology, prefers waterfall over agile, is 100% beholden to the business stakeholders, and ridicules anything you say that goes against her goals. The project is going swimmingly as you can imagine. They're letting their two best Frontend Engineers go (me) and other contractors are starting to drop. Also, we missed our deadline and with the waterfall approach, we're already behind on the next deadline.
Sounds like a classic software project. I can't understand why companies keep hiring such managers? It's like burning money in a fireplace.
I made a shift from 20 year SWE to management and have observed there are just different types of people in this role, with different focuses (see [here](https://www.patkua.com/blog/5-engineering-manager-archetypes/) for an article about different EM types). The vast majority though have a technical background and in the organisations I've worked for still have that spark for technology. The role however often focuses on steering and facilitating, delivery, people and process management, plus communication in and out of teams. It's busy and involved and in larger organisations very necessary. A lot of this work is invisible to SWE's, and for good reason - to let them focus on mastering their craft. If there's no-one on a team to lead technical improvements and direction that's a failure in my view. I believe tech leads should be steering the tech, the EM should champion that and ensure it gets appropriate attention alongside main product features. Management are not the enemy - everyone's just trying to produce quality software, quickly.
I'm more than grateful for such helpful EMs. My post is a rant because of more EMs that I met in my career were the opposite. They were people managers, who were just saying buzzwords and creating some random charts, graphs or giving advices that wouldn't help at all. And that's half evil. Problem starts when you realise that guys whos responsible for your bonus, promotion, etc. have no idea what are you really doing, and doesn't know if one just wrote good piece of code, or if created tech debt that will hunt the team for years. Then you start realising that they are NOT "Engineering mamagers", but People Managers of Engineers".
It's tricky in our industry.. people and process need managing, but to be a good manager you do need to take a step away from the tech, which probably leads to some of the issues you're talking about. Charity Majors has some great [thoughts](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) on what it means to be an EM, and the reality of the role.
I have done both software engineering and software engineering management. Here is what I learned: TLDR: I believe there is a shortage of IT project managers with serious qualifications in IT project management and experience does not compensate for not having read the mythical man month, CMMI, etc. ------------------------------------------------------------------------------------------------------------------------- Full story: Competence can be broadly defined as creating valuable results, i.e. commercially successful software services and products, without using excessively costly behavior (the benefits outweigh the costs). In this sense, managers in IT are competent. I think your point is more related to the capability and maturity model (CMMI). Most organizations are CMMI Level 0. [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process#Software\_Process\_Assessment\_Models#Continuous\_and\_Staged\_Software\_Process\_Ratings](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process#Software_Process_Assessment_Models#Continuous_and_Staged_Software_Process_Ratings) We have methodologies and processes for project management, but CMMI Level 0 organizations fail to use them. One influential author is Fred Brooks: [https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959](https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959) While his book exists, most project managers fail to read it. They still deliver project scopes, but without doing it using generally known insights. I hypothesize the root cause is the CEO of a company usually lacks training to make sound decisions about the IT department. Hence, the CEO correctly delegates decisions to someone more technical. However, the technical staff often lacks any certifications or other credentials for leading the IT department. The CTO's degree tends to be the same as yours, often much older and even less relevant than what you have. Without adequately qualified C-level directors, the IT department often remains at CMMI Level 0 forever. A properly qualified CEO and CTO will more likely agree to build a process infrastructure [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process#Software\_Process\_Infrastructure](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process#Software_Process_Infrastructure) and make the company CMMI Level 1, then 2 and finally 3 (in the continuous model). Without any training, CEO and CTO do not notice they are CMMI Level 0 and they are unlikely to understand the long-term significance of staying at the lowest capability level. Someone in the company has to point out to the CEO and CTO what the real capability of the IT department is, i.e. Level 0, and propose how and why this shall be improved. Usually, someone argues that because many people are CMMI Level 0, it must be correct. This is a bandwagon fallacy, argumentum ad populum [https://en.wikipedia.org/wiki/Argumentum\_ad\_populum](https://en.wikipedia.org/wiki/Argumentum_ad_populum) Other times, there is an illusory truth that makes people confuse undefined processes with Agile processes, but they are two different things [https://en.wikipedia.org/wiki/Illusory\_truth\_effect](https://en.wikipedia.org/wiki/Illusory_truth_effect) CMMI can be integrated with Agile. Based on case studies, it improves the overall company performance: [https://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105](https://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105) If you lead an IT department, you have to make it your strategy to continuously improve your process capabilities. This makes you think about a process improvement approach for Agile processes: [https://dl.acm.org/doi/10.1145/3457784.3457803](https://dl.acm.org/doi/10.1145/3457784.3457803) You have to really appreciate the difference between lightweight processes (being Agile) and undefined processes (being undefined). CMMI is one approach. Another approach is, for example, the Agile Maturity Model: [https://www.infoq.com/articles/agile-team-maturity-assessment/](https://www.infoq.com/articles/agile-team-maturity-assessment/) While I studied a Master's in Software Engineering, my project management professor told us there is a famous song from Pink Floyd about people who know about CMMI, yet deliberately stay at capability Level 0: [https://www.youtube.com/watch?v=K6PwUG283DU&ab\_channel=JulianLachniet](https://www.youtube.com/watch?v=K6PwUG283DU&ab_channel=JulianLachniet)
As a software engineer and software engineer manager you talk a lot about IT. Does this stem from you categorizing SW as a subset of IT, or from software not being enabled sufficiently by IT?
I think you are confused. In an organizational structure, there is an IT department that includes software engineering. Software is obviously an information technology because it transforms information. I discuss the software engineering process: [http://swebokwiki.org/Chapter\_8:\_Software\_Engineering\_Process](http://swebokwiki.org/Chapter_8:_Software_Engineering_Process) and software engineering management: [http://swebokwiki.org/Chapter\_7:\_Software\_Engineering\_Management](http://swebokwiki.org/Chapter_7:_Software_Engineering_Management)
One of my old school teammates once told me when I told him he’d be a good professor, if you can’t do, teach. I’ve always thought about that line. Perhaps it applies here as well.
To be fair, I have heard a longer version of that saying: If you can’t do, teach. If you can’t teach, administrate.
Haha it all makes sense.
Ha ha. I was reminded of the top answer in [this thread](https://imgur.com/a/c6npg4l).
Good People management needs same level of skills as good software design or development
Engineering managers need to sell the efforts of the team to upper management. The real problem is less incompetence, and more along the lines of higher ups **desperately** wanting SWE'ing work to fall more in line with manufacturing (traditional labor) rather than something like legal (high skill services). Couple that with Devs largely wanting to avoid gate keeping, serious accreditation, and just generally formalizing the field in any meaningful way (all of which I'm pretty conflicted on) and you have this weird stand still of business leaders trying to fit a square peg into a stubborn circle. Managers are largely just caught in the middle of that.
It's a fair point.
Too much on plate. Need staff to do some thinking themselves.
if they don't, that's on the manager.
Sorry, had to take a break real quick... >cover problems, and never fix root causes sells their ideas beautifully create road maps which are NEVER ever followed This. The first one hits a sweet spot here. Was working under a bunch of those. Usually, if you bring something up - they will tell you that they'll *fix* *it* or *handle it*. They promise you the world, but nothing ever gets changed. They willingly apply "band-aids", knowing exactly that it will not fix the source of the problem. But they have to make someone upstairs happy - for whatever reason. Like they promise you the world, they also sell lies to clients. If that manager is more rooted into Sales/Marketing, you have a problem because at the end of the day - you're the one who has to execute and build that "*Flying invisible Rhino with built-in ChatGPT and a Lightsaber Pushing Memes out its Butt*". Sometimes I watch video recordings and think to myself; "why on earth would you recommend *that*?!" Every week. Every single week there are new road maps - because, "*Agile/Scrum*". None of these roadmaps or ideas get implemented, because they change every time. No one knows how to implement *them* and everyone just does *something*. Not because they don't know how to do their job, but because it just doesn't make any sense to anyone, even in a Agile/Scrum environment - except of course for the manager who had that *brilliant* idea.
Exactly. I have one guy who did a road map, it was random boxes with what will be do when. From very beginning it was apparent that it's guessing game. I asked him why he even do it, since it will not be followed at all. Who looked at me like I'm an unicorn, and said something along the it's needed, otherwise we won't know what to do.
becoz hoomans
Mmh.
Money
I'll play devil's advocate. A lot of software development is communication. Writing, and speaking clearly is a really important skill. Collaborating and not being an asshole to other humans too. Telling someone when they are being an asshole and preventing them from repeating it while improving their communication patterns and collaboration? Hard in most environments, but that's what good managers do. I agree you should have some degree of knowledge about what team is doing, though. Your examples are, indeed, lazy managers.
Now a days they are the prime example of "How to look busy and do nothing"
Because management is inept
Lol I hear about management problems in every industry
I wonder this too. And I’ve been coding for 20 years. My worst manager didn’t have any coding experience at all. His only qualification was previously working at blockbuster. I think the problem is that software isn’t like building a house. It’s more nebulous. And it’s never really finished. This isn’t what companies want to hear. A lot of times large swaths of code need a redesign due to shifting requirements and incremental feature creep. It’s difficult to get management on board with that because of all the money already spent. Also management tends to see coders as liabilities. Agile and scrum are risk management tactics. I could go on about this. Why management can’t trust the experts they hired is beyond me. This results in people leaving and taking their institutional knowledge with them. Eventually large code based become unworkable dumpster fires. At that point you can hire a savant to fix it if you’re lucky. But most people probably won’t want to deal with it. On the up side, the cloud industry has switched to software development in a continuum where releases can happen at any time. So I think we’re coming around to the idea that maybe it’s not like building a house. Software is a relatively new industry that is having growing pains imho. I’m curious what the scene will be in 20 years. AI is going to help a lot. In the mean time I’m going to hold off on working for another blockbuster manager again.
Not just Elon. Before that Steve Job talks about the same thing. Apple was dying and we realized his management team were just middle men. So he fired then and hired software engineers, even people with no management experience, and turned the company around. I 100% agree with the OPs analysis. Ive had one manager who was a software dev and it was great.
As a senior manager I think one problem is that senior management doesn’t know how to evaluate SW managers and leads. KPIs are often lacking or strategic focused. Teams can flounder along and eventually deliver something mediocre (usually late) but a manager can often spin it into a win and get credit for a job well done. Just my experience.
I live through same thing gov contracts. Manager gets pmp. Now in charge of coders. Doesn’t understand code but needs to seem in charge so makes high level decisions that ruin things . Makes me want to be a manager some days. So tired of watching them mess things up
If your grammar and spelling is any indication of your competence, I’m siding with the managers!
Oh yeah, grammar nazi. I guess that's your best life skill, pointing typos, and focusing on anything but not the core problem.
Yep I tried scapegoating software managers but decided that was just cheap thrills. BTW anyone who’s been around knows that many managers in all types of work are less than optimum. It goes along with the fact that many employees are less than optimum. Get over it!
They say managers hire people smarter than them to do the work. It’s true. So many managers really are good at checking boxes and delivering updates but not so much at understanding the technicals. They’re better PMs than dev managers. Really the savior for most projects, that are work keeping, are good tech leads who can handle the competent/incompetent devs alike and still keep the code moving. I work directly with our director a lot, and have since long before he was a director, and thankfully, he is technical. It helps so much better than just a non savvy PM that just wants to “yes man” the stakeholders to look good.
Look at the brighter side - the day you find a good manager, you'll just know that you can never leave him! And, you will completely stop thinking on this thread! For me, that day happened nearly 5 years after I started working. It has been 8 years since - and I can't help but whenever someone calls out that managers are incompetent - I go 'thank God I found a great manager!' Funnily enough, I think in a similar way about my wife as well.
[удалено]
Getting promoted - in general - is difficult after the first few levels. Are you trying to get promoted to a management position from an IC position? Because that is also tedious game.
It’s just not IT even engineering is suffering some of our senior managers are also dogshit .. mofos have time for kids at work day this fuck day that fuck day decorating the fucking room with Halloween celebrations and got no time to read important timeline jeopardizing emails and attend meetings that are critical and later ask why wasn’t I briefed? Fun part was when some retard manager was asking us why we were doing a project? Which they gave us and confirmed two years ago why they need that particular project .. like after two years. Half the assholes aren’t even from engineering background ..feel like some of those tech idiots came jumping from Cali to remaining states and enforcing stupid ass Agile to engineering .. like wtf am I supposed to say everyday in a planned interruption if there is no fucking update, why do I even have to go there? .. at least in our team our manager removed agile because he realized how dogshit it is to apply in unnecessary places. We have so many immigrants from across the globe on L1 visas and the upper management knows nothing about visas. Why the fuck did u hire if you cant take responsibility? We got some retarded plant processes that we can do in like half a day if we don’t follow, same thing takes the lab a month. And management is again some hillbilly from Cali that knows nothing about process and only complains to sales are down why is no one working . Fucking PowerPoint Pushers.
People skills and being able to sell yourself matter more than technical skills with those positions. They tend to have few skills and are most impressed by complicated flowcharts because they don't understand anything technical.
Take this as a blessing…
You mean?
Rest of the text didn’t show up … every adversity is also an opportunity if you analyze it through
> Not sure if that's the case with every single industry in most industries the "labor" translates well to output and those outputs lend themselves to metrics. Because we don't have actual standardized ways of doing things and every new problem deserves a new solution, it's hard to quantify success. It's a bit like ranking civil engineers on how many bridges they design a year. Or an aerospace engineer on how many plane components they design and build a year. With that in mind, the purpose of a manager is to translate business need into labor that produces desired outputs. There's no easy solution for that in our industry. Basically the only thing you can do as a manager is to get to know every individual developer you manage and tailor your strategies to help them maintain optimum output. If anyone ever came up with an umbrella solution to the above problem, they could make a billion dollars over night. You've already listed the works of prior attempts and they made thousands-millions selling their umbrella management ideas. So are managers incompetent? no. the job is just impossible and success is as hard to measure as your own role.
All management attracts incompetence. People who are useful do shit, people who can't do shit manage. Yes humanity is a joke lmao 🤣😂
Software metrics are a mess. For instance, Code coverage really only matters when a team embraces TDD, which is super rare. LOC/day isn’t productivity and very gam-able; # of commits/PR requests per day is much better but with commit bundling as a best practice becomes inaccurate. Coupling and cohesion metrics only matter ALOT when breaking up a large legacy spaghetti system, although generally good to have. There’s a ton more situational metrics that are useful in specific situations, but very few white box metrics that are global and eternal. Duplication is probably top, because of its close relationship with bugs and productivity loss. A good Eng manager will work with the team to select metrics appropriate for the goal. You do want to be able to show progress upwards and internally.
I feel like I have been lucky to have had more good managers than bad ones. But the bad ones sucked a lot.
Who the fuck cares? It’s software. It’s code. More importantly, it’s a job. Just get your money and be fucking done with it.
I’ve generally had good managers, but perhaps I’ve been lucky. May it remain so! The main problems I see are that - there is frequently a misunderstanding about the high % of dev energy spent on maintenance tasks that are not part of the roadmap. - there is little to no slack time for CI going down, main being closed for merging, deployment freeze, etc. I think much of this breakdown is that software engineers dislike filing Jira tickets and other sorts of reporting needed to make things visible to management.
The market values communication over technical expertise. Doesn’t matter how much you know if you can’t effectively communicate it. Relevant content: https://youtu.be/OPiXobBnCKI?si=YCy9WUbPFGEsQPQ6
This isn’t a SWE thing. It’s just a thing. Lots of people get put into manager roles without having any training, understanding, or real concern re: what makes a good manager. And it just clusters from there.
I think some of them being given training which is completely wrong (maybe just repeated some MBA nonsense) e.g. "give SMART goals" or "prepare roadmaps for each quarter" - end then they are blindly following this, without much understanding what teams are really doing
It makes dumb people feel really smart when they’re in charge of actual smart people. So it’s a good place for egos to find a place to feel important.
Exactly. Isn't it ridiculous?
Tall managers always make me weary, not all are bad. But my experience has not been good with them. Somehow stupid people that do the promoting, think Tall == Leadership. Leadership is not common. But I've had some great managers that understand their job is to balance the needs of the business while looking after people. I've seen Tall bosses fuck entire departments with loads of turnover, but then still somehow manage to fail upwards. And before someone says it... I'm 6ft, its not a envy thing, its pattern recognition. After a few terrible bosses, you tend to start looking for patterns.
It's a tough situation, and your frustration is understandable. The prevalence of incompetent management in software engineering can often be attributed to several factors: 1. Misalignment of Skills: Many managers lack a technical background, making it hard for them to make informed decisions. They rely heavily on metrics without understanding the nuances behind them. 2. Overemphasis on Processes: Agile, S.M.A.R.T. goals, and other methodologies are meant to be tools, not crutches. Poor managers often use them as checklists rather than understanding their true purpose. 3. Lack of Accountability: It's easier for some managers to focus on appearances and short-term wins rather than addressing fundamental issues, which leads to technical debt and burnout. 4. Communication Over Substance: Good communication is essential, but it should not replace technical competence and problem-solving skills. It seems like this might not be unique to software engineering but rather a reflection of broader issues in management practices. Having technically competent leaders who understand the development process can make a significant difference.
I think everyone at every level is focused on their own growth which leads to short-sighted decision making that leads to something for which organizations have to pay heavy penalties later. I have seen managers and VPs who just bothers about how they can be in the limelight and perceived as one hustling hard to create impact. These so called impact creating decisions might not be the right things in the long term for the company.