The other half think it's bad because they can't steal everything that's not nailed down.

It's like trying to censor speech. You get rid of "bad" speech but you also get no interesting speech. Is it really worth it?

But it's very nature is anti productive. By this I mean, documenting, discussing, approving, and creating boundaries, all work to slow down an organization, even though it's necessary to ensure the wellbeing of the organization. As a specific example, organizations often have separation of duties for certain things (like activities involving pay to avoid embezzlement from happening), but doing so naturally slows down the handling of these activities. If one person has to do his part, then write documentation to instruct what they're trying to do and what they need someone else to do, send those instructions to someone else, wait for their approval, and then send it to someone else to process it... all of this is slower, than if the person who wrote the instructions, skipped writing the instructions, and approved and processed it themselves. But obviously that can result in some bad situations, and hence why some bureaucracy is inevitably necessary.

This will keep happening to even the most incompetent person cannot do anymore harm. Meanwhile top performers leave. AFAIK the best way out of this has been Netflix's "freedom and responsibility". You expense crazy meals, you get a warning. You do it again, you are fired.

Security for example. Every new things needs security review. How does this fit into the Netflix “freedom and responsibility” concept?

Probably, but not every bad thing happening requires a response. Sometimes mistakes or bad things happen, and you just say, "use better sense next time", and then you move on.

The pernicious part happens when those ancillary functions become conflated with the business itself, at which point it is far too tempting to further expand the beurocracy to service those functions (i.e. auditors). My sense is that the most despised rules in most organizations are such second-order attempts to service the beurocracy.

An common example might be the procurement department, whose purpose was originally to facilitate and track purchases for the business. Maybe at first they managed and distributed credit cards to employees. However, this is still inconvenient when employees make innevitable mistakes. Instead of dealing with this inconvenience, credit cards are eventually taken away from employees and an online procurement portal is set up and/or people are expected to file reimbursement paperwork after trips. Now the beurocracy has effectively shifted its own burdens onto individual employees while making the process slower, more complex, and more expensive. Despite all of this procurement will now be considered a core pillar of the business because executives look at all that sunk cost and fallaciously conclude that the procurement beurocrats are indespensible.

Meanwhile, there isn't really a similar mechanism at play to protect people doing the actual work.

Even after whatever i did showed a ton of value for little cost of any kind, they will eventually find a way to manage it into an inefficient thing or replace it by something much less blame inducing.

As a worker, my focus is on generating value. Either I produce revenue or reduce risk and liability. For managers, this is a distant secondary concern, they are worried of what their boss might think and how they will appear in the management team and what the risk to them (not the company) would be if their reports fail or decide to leave.

So, I could do the best job ever but that might make my manager look like he can't control me. I know what those of you that work in startups might think, the manager should feel like they succeeded in extracting value out of me instead right? That's startup culture, a startup wants to extract all the value out of you to maxize their success. Every other large org has politics and incentives such that even CEOs can't shake things up without gathering support, they can't create a culture that maximizes profits and productivity because that means less people might be needed or would have to do more or the worst case, what irks me the most: "If we do all that now, we will look bad if we don't keep doing this much in the future", i.e.: if you are a rockstar now, that only hurts you when you inevitably become less than a rockstar. So the snowballing inefficiency in my opinion is a result of trying to keep the balance between doing as little as you can vs making some sort of a profit and burning through budget money so you look important and valuable (the enemy of open source!).

It really is frustrating if you get bored easy. I was surprised at the whole "quiet quitting" thing because I have been seeing people do that for a long time, people getting mad at me because now they think they look bad because I did anything more than the minimum.

But really, just observing not complaining. I am now understanding these reasons. But it is difficult to fall in line and comply.

Creative work, inventing things - it’s the most value able thing. Not the “management.” If you are in a non creative environment and you find you have all the ideas, your focus should be either on leaving to build your own thing or to “take over” by effectively being the one who writes all the plans and who everyone comes to for ideas.

Creative people who create value are rarely rewarded in most medium or large sized organizations.

I realized after seeing how larger organizations work: There is no winning.

It is like the red queen problem. The more you run, the faster you are expected to run. You will very rarely if ever be able to convert this into upward motion. Your manager is very non incentivized for you to get ahead.

I personally feel like startups are simply the way to go. There is a much much larger market, many more options, granted it pays less, but you will get seen and credit for your work.

And startup skillsets are generalist skills that are often much more transferable. And you are valued more in general as more depends on you.

Reading what you said here: You are maladapting to a corrupt environment.x

I know exactly what you are saying: I spent my career having my ideas snatched, ignored, implemented with great results and no recognition or reward or worse.

I think you should just go to smaller firms in general.

There are probably very few people on HN qualified to help you with your situation. Even for those who are, a public forum is not an effective place to do it. No, a therapist won't magically fix anything. But therapists and psychiatrist are the "debugging experts". They have training and experience to help with problems like yours.

In effect, there is a magnifying glass which is making past events loom larger and larger. A therapist can help you get grounded, reversing the glass so to speak. A psychiatrist can help if there is some physical issue, such as OCD, that is feeding in to it.

I'm not qualified to help, but please be assured that many, many of us have experienced similiar situations. That doesn't mean "I know what you're feeling." We don't. You are you, your situations is unique to you (as with all people), and even if we knew exactly what you were experiencing that doesn't get rid of the feelings. But we can empathize and sympathize. You are not alone.

I would like to commend you on trying to handle things "the right way". That speaks well to you character. Please don't give up on it. Get the expert help.

Honestly that description of a manager’s motivation (how they are seen by others who control their fate) is one that many engineers also adopt. In my experience, managers are actually focused on what you described for a worker (ensure the team generates value via revenue or reduced risk), while most engineers are typically focused on the quality of their craft.

I am not one but I believe staff and principal SWEs start thinking more like this for comparison. (I am not a developer).

Silently implied: "Spend more hours working. Alter existing estimates enough to fit it in."

You can ask them if they're asking for overtime/crunch and they'll say, "No, work/life balance is important to us at BigCorp. It's just that this is as important as our existing planned work and it would make our team/department look amazing if we can get this done too.". Yada, yada, yada. You can keep pushing back but how many times can you do that before you're no longer considered a team player?

-Oscar Wilde

Management exists to guide the priorities of those below them, so when management is gone, people feel liberated.

But the point of managers was to keep them on the tasks deemed most important to the long-term wellbeing of the company, even if those tasks seem boring and unimportant.

In the past 6 years of my working career, a manager has meaningfully intervened in my work exactly once, and the outcome was weeks of time wasted. Manager-originated assignments have tended to be of inferior quality and impact to the ones I generate myself. I have not done a manager-assigned task for the company for 3 years, and I have not done a worthwhile management-assigned task for 6 years.

My personal example is probably extreme, but what I bet is not extreme is the lack of accountability. There was never a time where my choices were recognized as superior to the managerial choices, no matter how many times this was proven true. Instead, managers seemingly just lost interest in assigning me work and let me figure it out myself, which frees me to be one of the objectively most productive people in the organization.

6 weeks of wasted work is much better than 12 weeks of wasted work.

And how exactly did you know what work to do in the first place?

If he had wasted 6 weeks less than would have otherwise been wasted, I would have given him credit for saving 6 weeks rather than blame for wasting 6 weeks, which is what actually happened. According to everyone involved, including reportedly the manager himself, though he wouldn't say it to my face.

> And how exactly did you know what work to do in the first place?

I'm a data scientist who helps people across the company with analytics. They make measurably better business decisions than they would have without me. Relationships, continuous service on existing products, and word of mouth generate more work.

Basically I run my own analytics consultancy inside the company.

A lot of managers are paper pushers instead of leaders. Their usefulness varies depending on circumstances.

It is actually my experience that the organizations which are able to organically evolve like this are the most effective ones.

My manager tends to have a lot more context on my wider team and things in the pipeline than I do. You can only self-manage in the context you know.

Based on my experience; many knowledge workers think they are self-managing because they are able to set objectives for themselves and reach those. But the lack on context means that those objectives are only loosely aligned with the direction of the underlying organisation as a whole.

Often times, this is because the general direction of the organisation itself is hard to define and/or poorly understood. When that's the case, it can be tempting to look at very "dry" numbers to measure ones contribution (My piece of code generates XYZ dollar-amount, it's the highest of the company, so I must be one of the objectively most productive people in the organization).

This is one way to contribute, but in those situation the most critical (and thus most productive/valuable) undertaking is to clarify the direction. This can be extremely hard to do, requires immense amount of work and often times the "right choice" is virtually impossible to define. Thus, the output of the people working on that absolutely essential task is blurry, at best.

When it's done correctly tho, it yields impressive results. A clear direction is set, people somehow know and understand it and you can quite literally let them figure out their work for themselves and get that often surpass what you could have hoped to get if you were involved. And like many things, doing it harder than it looks. And when it's done very well, it seems easy and effortless.

I feel like this is a failure of the organization, rather than of those managed.

I’m perfectly capable of prioritizing things correctly if given proper context, but chances are very real that I’ll still pay more attention to what is important 5 years down the line, rather than what will make manager X look good this month.

Very much agreed. Indeed, this is the most important job of the management. Many comments speak of engineering as something that would go off track if left to their own ways. But, the reason for that is lack of context and wrong incentives, in the first place. If engineers don't know why they are not being allowed to work on technical debt, it's a management failure.

Probably, but how much effort does that take? Why are you duplicating that effort along with all the other ICs?

You’re at Amazon, in 2001 and you know that in 5 years there will be a thing called AWS and that’s going to become the most important thing?

Much of this is attributed to the email Jeff Bezos sent telling people to productionize internal APIs.

My guess is: yes. People would be building what would have become AWS early on by solving the root problem for any given issue, establishing a decent API for it, and then consuming that API in some business logic.

Bezos' big contribution was telling people to do what they would have usually done.

A large part of a managers job is to have that context. Making everyone aware of wider context in a large org is untenable. ICs need to be able to focus on their immediate context so they can get shit done.

There's a reason staff+ eng aren't writing code all the time. They need to focus their time and energy on higher level tasks that enable other ICs to write code.

Personally I would love to have more context on everything, but I've got a glimpse of how much stuff my manager and PM are involved with and I definitely can't keep up with everything and also investigate issues, write code, etc.

I know it feels like you can be self-managing, but you can't (outside of a tiny startup). For a long time I felt that way. After all, I know the product code inside out better than anyone. I can see what needs to be done both short and long term. I can lay out the road to get there and execute on it very well. What else is needed?

What's needed is alignment with all the other parts of the company. Marketing, sales, infosec, project management, executive wishes, etc. Who is doing that? Oh, I can do it. And I can. But by the time I'm done, I'm left with like 30 minutes a week to write code. So I can't actually do both full-time.

A challenge I've seen in management-heavy organizations is that the many layers of management largely function to make good management impossible. The many layers of command between ICs and the source of many decisions means that the people responsible for relaying information up the chain of command are incentivized to put their own spin on information as they relay it, in part in order to help secure their own positions within the hierarchy. The other side of that coin is that the many layers of communication between senior decisionmakers and what's actually happening on the ground mean that the information they get is often of insufficient fidelity to support accurate decisionmaking.

The manager isn't a genius and the employees aren't morons. The business objectives could be explained to those employees and they could coordinate with each other to fulfill them without necessitating a conductor. Deep hierarchies are archaic holdovers from military organizational thinking.

If you can’t quantify the boring necessary tasks with dollars and deliverables then don’t be surprised when you get “oh yeah whatever.”

I’ve had to fight so damn hard with my own teammates who rail on and on about tech debt but won’t do an ounce of lift to turn the kvetching into an actual business proposal. For some reason devs have such a hard time conceptualizing that they are also one of the stakeholders to the business.

Here’s one that I made happen.

“Setting up new 3rd party integrations takes $x hours of work (here’s the cards) costing roughly this much in engineer time. Based on our sales trajectory we expect to do this many next year costing this much. The team believes that if we develop a framework for these integrations we can cut the time spent for each one to this. Our metric for success will be measured by having a dev who didn’t work on the framework convert an existing integration in the test environment.”

I’ve never gotten a green light so fast from our product management.

I still think you need to sometimes look at software as requiring some base level of regular maintenance funding, like a fleet of vehicles gets regular cyclic maintenance in any transport company.

And while I do agree that's important to learn how to frame things in terms of the business benefit there are going to be things that aren't as simple to translate into a straightforward benefit and KPIs. If you're working on something that just increases developer happiness to help with things like general productivity and retention measuring the benefit for any one thing isn't always going to be feasible.

I had a SVP keep pushing for an innovative approach to X. I told my boss it must be in her development plan.

My bosses laughed, but it’s true, even VPs have development plans and when the CEO tells them to do something “innovative”, well, they make sure they do it, feasibility or need be damned.

Then when I got more senior and closer to the decision making, I realize just how hard it is to keep large organizations on track. I've worked at companies that do it poorly and it's a mess - everyone is busy, but the company is just spinning it's wheels. Every with an oar is paddling in a different direction.

I've worked under leaders who are really good at providing direction. It's a very valuable skill when done right.

My first taste of this was leading a small project of myself and 2 other devs, and wondering how the hell you're supposed to get other people to do what you want.

Doing a good job of leading a large number of people seems extremely difficult, and I'm glad I don't have to deal with that yet.

Your explanation of companies doing this poorly sounds exactly like the example I gave in a comment I just wrote: https://news.ycombinator.com/item?id=34295803.

Launch goals? There were 3 short ones and not fluff like “drive sales”. Everyone on the team knew what the goals are and why. What should you be working on? Just look at the 3 launch goals. And leadership constantly reinforced them and empowered people to stop doing things that didn’t work towards them.

And I’ve worked in smaller teams where everyone had their own idea of what needed to be done. Leadership would keep changing goals (or they were so vague that anything fit them) or making exceptions. None of the pieces fit together and it was a total disaster. People got frustrated when they did great work but other critical parts weren’t done because something shiny or “cool” distracted other teams.

Effective leadership makes a huge difference.

Startups were a breath of fresh air, but as we continue falling towards the monopolization regime, the nepotism will permeate anything of value. Beyond these networks only soul-crushing work will remain, basically production of datasets for our replacements.

https://en.wikipedia.org/wiki/Kingman%27s_formula

Since c_a, c_s and tau are out of your control, focus on the left part (rho / (1-rho)):

25% vs 90% utilization: .25/.75 vs .9/.1 = 27x increase in lead time.

That's kind of the point of bureaucracy, isn't it? To slow the rate of change in a system?

The trick is adding bureaucracy (management layers) once something is not only working now but working in a way you'd like it to X-many years in the future. Then you freeze-ray your process with bureaucracy.

Side note: that's also why a large, bureaucratic government is supposed to be good - it means it will be stable and only accept small, slow change.

While funny, it's extra funny because it's true. Slow gradual change is much safer than massive revolutions -- regardless of whether your talking product development or politics.

Big change in complex systems are best done gradually.

Ugh, artificial deadlines are the worst. They hurt morale, productivity, and quality.

But sometimes/often required to actually get things done and shipped.

On the flipside, waiting around for an engineer to overoptimize something that matters only in their head, or doing something they believe is necessary when it totally isn't...not stellar for overall team performance either.

(I am speaking in general, not referring to the parent comments...)

Or then they will rob you blind. Your mileage may vary and is very much dependent on other things like the general work culture.

Anyway, failing to treat people like they would deserve to be treated is the most basic managerial failure. Any manager worth their salt should have an idea how their underlings need to be treated.

Seems like quite a wide variation -- so your proposed approach results in either the desired outcome or the worst case possible outcome? There's no middle ground?

> Anyway, failing to treat people like they would deserve to be treated is the most basic managerial failure. Any manager worth their salt should have an idea how their underlings need to be treated.

Have you managed a team before? I ask because the most basic managerial failure isn't "failing to treat people like they would deserve to be treated" but rather operating a team who delivers more value to the company than they cost, and ideally at or exceeding the level that leadership expects. That's it. That often requires the following:

1) Hiring high potential, high performance employees 2) Managing out low performance employees 3) Unlocking extra performance from employees where possible

Of these three activities, it's only the third one that approaches what you've mentioned. Why haven't you mentioned the other two?

Although, an engineer pre-accustomed to in the weeds work who has no management guiding what to work on can be the worse because they can create work for the other engineers that can have zero motivating context, other than they think it’s what needs to be done. And they will report to management all these technical details that somehow appear to bolster the need but don’t actually. I am no fan of management, but working with these types of engineers can be infuriating because you end up getting sucked into their random deep dive that is messy and full of edge cases that ultimately matters zilch. I will pretty actively communicate to management that, look, if you don’t step in we’ll be following this engineer to the ends of the earth.

An example I can think of is one engineer being obsessed with making a once a year report being as optimized and performant as possible, while also being obsessed with “cleaning up” the data and fixing so-called discrepancies at the report level, making little hot fix patches everywhere, rather than working with the teams that were generating the supposedly bad data in the first place. I did everything I could to avoid working on that because it was nothing but being mired in details and things that literally no one but them cared about. These types of engineers can be black holes of productivity.

That’s after a very-long (nearly three decade) career as an IC in “big tech”.

I think my take on this is not surprisingly different than yours.

As a first-level manager my job is all about execution and getting things done. Being in 20+ hours of meetings a week gives me a lot more perspective on the big picture than the ICs on my team.

They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term.

There is a lot of management above first-level that doesn’t seem to add a lot of value, but I’m not sure how much of that is inherent versus the specifics of who is in those roles. I expect my manager to be focused on strategy, long-term direction, team composition, building relationships with other orgs, etc. Up a level from that, again an even broader perspective. Depending on who is filling those roles I may or may not see those behaviors.

It’s very common and convenient to focus on personal productivity as an IC, but if 25% or 50% or 90% of that effort is going towards things that ultimately don’t have impact for customers, it’s not very productive after all.

How do you balance the additional work needed to provide the necessary transparency to this decision-maker?

Providing this additional reporting often becomes an unreasonably (I think) large part of the job, creates friction, and unexpected changes of direction interrupt flow.

As a manager with experience and sensibility for both the importance of doing the right thing and productivity, satisfaction and flow - what are some ways you lower the cost of managing?

Because information is freely accessible, there is less need for dedicated "reporting" processes every time a manager is added into the system.

> They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term.

I would love to hear your perspective (or pointers to other resources that might explain this better) on how one can effectively communicate this kinda of context with ICs.

I've worked with managers who have been from "fully transparent about org dynamics" to "Ill shield you from shit (i.e. politics)". Personally, I prefer the former approach as an IC since I respect honesty and the truth, so e.g. if its a political decision I can simply stop trying to push for another direction. However, I understand that this kind of radical transparency might come at a cost and might only work with certain kinds of ICs.

No I will not.

Day to day shielding from nonsense wasn't his best feature but it was a contributing factor in having such a productive relationship.

I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." I have heard them say all sorts of politics like "If we get this out now, then that'll prove massive impact that will free us up politically down the line"

Or for example I worked at a known location-sharing startup, and managers gave 0% thought to concerns like "hey is battery life impact worth measuring?" and kept pushing random integrations (like with Italian telecom company) hoping to get some huge amount of customers (which never payed off in my experience).

When I picture managers and directors I think of the idiots at Yahoo managing to fail to understand I need more than 15megs of storage or a spam filter (can't imagine what those managers were wasting their time ona), while a company of mostly engineers with scarcely any management builds gmail and eats their whole market.

Then perhaps you had less-than-great managers, and I could think of a variety of reasons for that.

Maybe it was as simple as you claim: no consideration was made to introducing an undercooked user experience. But if a software development manager is green lighting that, likely causing more work for customer service and perhaps sales, I would hope there’s more to the story than that.

Maybe this manager didn’t communicate why releasing a bad experience by a specific date was, perhaps, mandatory to fulfill a contractual obligation. Or maybe you were not able to sort that out from the limited amount of information they gave you.

Maybe they didn’t see the bad UX as truly as bad as you, and perhaps your team, thought it was. Maybe where you thought the feature’s UX passed the 80/20 rule was different than many customers.

I’ve had (product and project, not as often people) managers who have pushed to hold on delivering a half-baked implementation. And I’ve been a manager who has done that. Those better managers exist

Did you ever get feedback or do something to reevaluate why the bad experience was shipped?

The experiences you describe do sound like clueless folks making calls, but know that there are folks in management positions not just wildly flailing about.

There's a couple of things going on here:

  - Personal ambition. Usually this is about money, especially the higher up the org you are, but it might also be about becoming a better at tech, or keeping a stable job to pay your mortgage.
  - Incentives.  How the company rewards things it wants.  This might be shares, commission, salary, or bonuses.  But it's also about how the company measures and manages those things.
  - Ethics.  What you're willing to do to achieve your goals.  Both individually, and at an org level.

Of course, some people do, but when faced with a company that allows people to focus on short sighted personal ambition, they'll either fall in-line or move along.

And/or that the personal work experience they themselves have had, would be representative for people in general.

(Not saying that the posters above necessarily did now)

> couple of things going on here ... few people are actually interested in helping orgs make mone ...

Yes, nicely written :-)

Maybe in many cases they are "right" not to care, if the company doesn't contribute meaningfully to society anyway

Meanwhile, I have no idea if battery life impact is worth measuring in your use-case. My assumption would be "no" because I would imagine the battery life impact would vary too widely to yield useful data and I don't see what I could do with that information anyway other than recommend some people not use the app. But I'm not really thinking deeply about it now, so I'd love to be enlightened. Meanwhile, trying to get more customers is a good thing, even if it fails.

It's not exactly common for an organization to actively attempt to mitigate the negative aspects of middle management so it's almost an apples to oranges comparison. But since we're on the topic of Google, maybe making management reduction one of an organization's goals is the correct strategy to reduce the bloat and increase the productivity of ICs.

IMHO this is really the point. Somebody has to hire devs, run the evaluation/promotion stuff, facilitate communication to/from upper management, and so on.

I've just never been to a place that couldn't do that with 1/2 to 1/3 of the EMs they have. For whatever reason the standard is one EM per team. A better ratio is on EM per 2-4 teams.

And that illustrates what releasing half-baked stuff and not caring much about tech debt is all about - visibility. This seems to be true across industries. Not releasing something, even if it's not ready gives impression of not doing enough, not delivering, always being late, etc. Releasing stuff shows you (the manager) are the person who delivers. If it's crap, you'll get even more resources to throw at fixing stuff that's already delivered. And you're the hero again (even if it's "techies" who did 80-hour weeks to make it happen).

This doesn't even break down too much in physical product world. "Deliver" could mean sales, first to the market, we'll add copy&paste in 3.0, and so on...

Presumably, in your case, you're talking about an engineering manager. But you haven't mentioned if there's an engineering manager and no accompanying trained product manager. Engineering managers aren't formally trained in doing the hard work of talking to the customers to figure out what the market actually wants, so if leadership at your organization did not build it out to include this role, you would end up being in a tough spot.

Based on you saying that your manager made the decision to build a random integration which had questionable value to the org it sounds like this was the case. Depending on the size of the team, an engineering manager may even be dead weight and engineers should report to a technical founder or GM. But regardless, you actually are making the case that more rather than less product ownership and management is necessary to ensure that a product isn't dead on arrival -- after all, the symptoms you mention are of poor prioritization and product discovery/strategy (symptoms of poor/nonexistant active product management) rather than of poor engineering management (endless tech debt, production outages, awful on-call support, inability for the team to deliver features, unrealistic delivery roadmaps causing endless late nights with poor quality and buggy software delivery, attrition and difficulty recruiting).

[1] https://en.wikipedia.org/wiki/History_of_Gmail#Internal_deve...

Now that can sometimes align with adding actual value or figuring out the best product or organizational strategy, but not always.

Maybe, time to trim the fat from the top: get rid of these empires by downsizing. Also, companies at very high level should look at the bad effects of empire building, which happens in every large organization. Now one can ask "who gonna bell the cat"? If executive vice presidents start empire building, who gonna stop that? After all, CEO should give free reigns to his underling EVPs. Maybe, the majority stock holders should bell that cat; however, they have delegated that to the board of directors, who are different set of cats.

The mice have a solution for the murderous cat: simply put a bell on the cat’s collar and then they will know when it’s coming.

But… who’s going to “bell the cat”? i.e. who is going to perform this unpleasant and possibly fatal job?

No, my comment doesn't boil down to that. It boils down to many (not all) ICs, especially ones without a lot of experience, are more interested in focusing on problems that interest them than actual issues that customers want solved. So they go off and start working on interesting problems rather than important ones.

LOL, my current team does 2 hours of meetings per week (at most!) and we are incredibly productive. I hope we never work together!

I have 20+ hours because I work cross-functionally across a huge company that is both designing hardware and writing software for it. The complexity of what we build and ship is many times that of anything I've worked on during most of my career. As a result, there are a large number of moving parts and a lot of coordination that needs to happen across teams.

I'm sure that 90% of the current team would quit if we suddenly had to attend 10X more meetings per week :P.

One company had a homegrown debug protocol and tool to interface with it. I needed to add some custom info screens for development, but it was very hard to add because the code was $h!t. So I started fixing it just to be able to add my new data. Not only was I told that Work should be "managed" and prioritized, it was later discarded even though I had done it.

When programmers do things to "make the code better", it may not have an impact on today's customer demands, but it is meant to make the programmers more efficient in the future. This is stuff that will - by definition - Never be a priority in management's eyes.

I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value.

The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later?

If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work.

The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.

Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer.

The time to fix a disaster is when someone has that intrinsic motivation to do it.

And that the right people are there (and stay there), that the right tools are there (which does increase efficiency), that no work gets left behind, etcetera, etcetera.

I think the root cause of this tendency is the law of the least resistance. Creating new things is hard, especially if they go against the conventional wisdom. Supervising and managing things is easy, especially if the people being supervised are professional enough not to need much supervision. Then the managers job is basically just to stay out of the way, which is quite easy.

Of course even managers get eventually bored if they feel they have no impact. That's when the reorganizations start. That's also when the best time to actually create something new ends.

We (I'm a middle manager myself) Aren't stupid, so we will.

More headcount and influence means more (at least potential) business impact, and often promotions. If the organization encourages us to fight with other managers to get more of that, that's what we'll do instead of running our organizations better.

Right... So how many business goals got accomplished?

The techie in me hundred percent empathizes with you. I want a Clean system based on best practices and modern technology stack.

It took me a long time to understand that my technical OCD is irrelevant from business goals perspective. I don't know your full story but as presented, there's a possibility that while you enjoyed six months without management, business suffered for it. Or not - don't know the details. But it's important to understand that my techie perspective of what's important to accomplish, and business perspective, may differ. Management's job (amongst others) is to enact company strategy and prioritize business goals.

To wit, a business may be more successful with certain percentage of outstanding maintenance issues (his ibportant was that decade old issue really?? :) while having important new features built.

* good and self-respecting developers will not work on bad quality code. Business will be left with bad/mediocre devs who will implement bussiness needs slowly and with bad quality

* good code base and good dev practises make development much faster and with fewer errors, with easier new developer onboarding etc.

How many of IT projects have had a rewrite a costly rewrite because it became unmanageable?

80% managers think only about business needs- even those who previously were developers themselves because it is convenient and they do not have sell that maintenance is also needed

In my experience, both of others, and certainly of my own proclivities, if an IC is left to their own devices, the work they do will deviate further and further from business goals. Yes, that includes long term business goals like “not needing to do a big bang rewrite because everything goes to shit”.

These threads tend to give the impression that maintenance is a completely unique need that you need to be a Big Brain Developer to understand. Truth be told this is the case in loads of other fields. “Long term thinking”, “short term thinking”, and prioritising appropriately, are well and truly within the remit for people and these positions, and improper execution of the above is one id the things that separates good and bad managers/executives.

Barring a good pairing of a development team that always has the wider business context in mind, and a good management / executive team that understands the nuances of development, this back and forth over maintenance and housekeeping is always going to happen to an extent. And to be honest you don’t want a development team that has the wider business context in mind to the extent of whoever is “above” them. Past a point, it’s a distraction.

So, the revenue that year increased dramatically? How many new clients your company acquired?

Not all work in an enterprise yields revenue. Security or compliance or HR are great examples of that. Also, very often work that you do doesn't bring immediate benefits. They are usually deferred by months or sometimes even years.

> Meanwhile you can fire all of the management and the company will still work just fine, if not better.

I wish you could try it and survive to tell the world that story.