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.
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.