I remember an experience many moons ago where there was some "emergency" situation and our manager was just insufferable. Every 40-60 mins wanting to check with the ~3 engineers working on the issue for an update or to offer futile advice. I could palpably feel their anxiety and helplessness. I remember it reminding me of the trope of a parent in an ER on a hospital TV show. Obviously there was a lot of pressure put on them from above. I am sympathetic.
Years later, a very similar experience happened with a different manager. But they handled it very differently. They called a meeting, led us through understanding the situation and us working out what the solution should be. They got our feedback on how long we thought it would take and then said they'd come by for an update in half that time. And that was it. I was so impressed.
Something to note is that there are two important variables in the second story. The first, as you say, is that you had a different manager. The second is that you had more experience. In every situation a manager is only ever as effective as the information they have, and that comes from how good their team is at communicating with them. I'd hazard a guess that you were better at telling your manager what they needed by the time the second event happened.
If the team has good comms, and experience of both working and communicating updates to their manager regularly, and the skills to explain things in ways people understand, generally speaking you find the manager needs to check in less often. They can trust you to raise things promptly, to ask for them to do things for you, and that when you're quiet it's because you're busy rather than stuck. I find that teams who complain about their manager very often don't trust their manager and vice versa. Building up that trust by getting both sides to work on improving comms fixes a ton of problems.
While I do think the manager bears the vast majority of the responsibility in situations like these, the reality is that you're right, and oftentimes managers do a bad job because they're getting pressured from above to communicate and don't know what to do.
You can often get them on your side by giving them a plan that makes them feel like they're in control (again, totally not your responsibility! But better than dealing with them being obnoxious constantly). If they ask for an update and you say, "I don't know what's wrong, but we're looking into it" then they don't know what to do. If you tell them "I don't know what's wrong, but right now we're investigating x because we suspect that's the source of the issue. I'm checking the logs and other engineer is trying to recreate the issue in a clean environment. Unfortunately I don't have a good answer as to how long it'll take, but we'll update you either when we've learned something useful or in two hours, whichever is sooner," then they have something to say to the people above them and they understand when they'll get an update, so they don't need to bother you.
A helpless manager is like a child - if left alone, they'll just shout and cause problems. What they really need is direction and structure.
> A helpless manager is like a child - if left alone, they'll just shout and cause problems. What they really need is direction and structure.
What they really need is to find a different job. Needing to "manage up" is the ultimate waste of resources IMO and puts a lot of stress on the employees, why even have a manager at that point.
I think more often than not what they need is training - I tend to see this kind of thing in people who were promoted from IC to manager but never actually trained for the job.
A manager can definitely be helpful in this situation - a good one will be a barrier between you and whoever is above them, credibly telling those people that the best thing to do is leave you alone.
While I tend to agree with you, this doesn't look like anything actionable.
I've even tried it by saying something like: "I get the impression you don't really enjoy your job" and getting a response something like "no, I hate it, I hate trying to manage people", and then suggesting the look at job ads.
I agree, and to make matters worse, IME managers of managers tend to be very apathetic of their reports and don't have the same kind of scrutiny of the folks under them that they expect those same people to have of their reports. So the people that shouldn't be managing others don't really have a "check" above them to confirm it, especially if they're good at deflecting blame/sacrificing their reports.
I'm a big advocate for no confidence votes from reports to signal to someone that this person needs to go.
That doesn't seem fair to me. An example from my job—we had a SEV 0 incident, and an _extremely_ important partners was calling our CTO directly to find out details, estimated time to resolution, etc. Being able to clearly articulate the problem at the CTO → 3rd party level in a way is a pretty important example of managing up in my opinion.
> I don't know what's wrong, but right now we're investigating x because we suspect that's the source of the issue. I'm checking the logs and other engineer is trying to recreate the issue in a clean environment. Unfortunately I don't have a good answer as to how long it'll take, but we'll update you either when we've learned something useful or in two hours, whichever is sooner,
Just don't get too specific, especially with even a bit technically inclined ones, because they will have ideas to help and bother tech people to check their random guesses when trying to be helpful
People in management have a wide spectrum of technical proficiency and to imply that someone in a management position could not legitimately help reeks of inexperience.
We must have different experiences. I’d expect someone with more experience to lean towards management not being able to legitimately help (with a technical issue).
Experience varies. No doubt some can help and there are better companies but there are often those that can't as well. There's a side where all the managers / decision makers are so far removed they don't even know what the tech we use on a day to day basis is.
It doesn't matter, it's not their job. They weren't hired to perform that job, they don't perform that job daily, and so they can and should leave the people who's job it is too do it.
Part of the job is to unblock their teams. Sometimes that's achieved by their own technical knowledge, sometimes by coaching, sometimes by coordination with other teams/resources. It's very situational.
Obviously yes? You know what needs to be done to fix the issue, you simply need to communicate upwards that it’s in check. A certain amount of herding is to be expected.
that comes from how good their team is at communicating with them
Communication is a two-way street. Proactively calling a meeting with all those involved to understand the situation and then letting the team get on with their work is 100% a managerial skill, not a function of the seniority of the engineers.
My knee-jerk reaction is to offer a riposte of additional data demonstrating it really was about the managers. But I think you've got a valuable and generalizable point here. I'm going to reflect a bit on that.
You know what's difficult? Looking back at a younger self and being truly critical. Gosh, it's so easy to just say, "yeah well his employment future at that company proves my point." But then I learn nothing else that I can grow from.
> > Every 40-60 mins wanting to check with the ~3 engineers working on the issue for an update
> I find that teams who complain about their manager very often don't trust their manager and vice versa.
I get that sometimes it's not (only) the manager's fault if there is no trust, but if as a manager you need a status update every 40 minutes while the people are fire fighting and working on an incident, I feel like you failed as a manager.
I feel like there's a good and bad way to do this at the same interval. Of course it depends on the situation as well and what you say, but when I'm dealing with an actual emergency, I can't imagine not posting an update every hour or so. Usually much more as a way of documenting what's happening for a later PIR.
If a manager doesn't get the required details to know what's happening (I'm situations where they do and still ignore it), then the whole process could use an improvement.
From my SRE perspective, if an incident takes longer than 30min, I want my manager/coordinator to be constantly updated and handle communication with the rest of the company/customers.
Usually there’s a primary and a secondary. One person handles the actual debugging and the other handles the communication and coordinating. While I agree it’s poor management to ask for an update every few minutes, it’s not because asking for an update is bad, rather because they themselves failed to communicate and train their employees to properly handle communication. Looking back, this was something we did in our team when I was just <2 years out of college. I was the secondary and posted updated to the tickets and emailed the team every 30 minutes. I was also the one calling in people to help when primary needed help. My manager didn’t bother us because he had already clearly laid out how we handle issues of each severity and who does what. It was also clear what the chain of escalation was and who and how to reach out. Incidentally, it was also my job to close the issue by identifying the cause and fixing the issue from recurring - because the secondary was only observing and communicating they get to see the bigger picture and also a welcome break for the person working hard to fix the issue.
Learnt a lot by working with a team that knew how to handle themselves. And we weren’t SRE - just regular devs. This manager - my very first one - has also been the best one I’ve ever had. I wasn’t surprised at all when he quickly scaled the ladder and is doing really well for himself now.
I’ve been that SRE senior manager in some longer-than-ideal outages.
One of my biggest roles was chasing off the lookie-loos and fending off the VPs and CIO (usually by telling them to GTFO of the war room but then going to give them an update away from the team with what we knew and what I thought).
> In every situation a manager is only ever as effective as the information they have, and that comes from how good their team is at communicating with them.
> I find that teams who complain about their manager very often don't trust their manager and vice versa. Building up that trust by getting both sides to work on improving comms fixes a ton of problems.
Sometimes it's beyond that. The problem can be layers up where neither the manager nor the rest of the team can solve. The team wants changes / improvements but the manager is powerless or forced to act in a certain way.
When I interview for a job I always ask my prospective manager about the is. “What’s your process for getting status updates during a crisis”. This question is graded pass/fail.
I am sure you know this, but be careful with this strategy. The worst managers of all will tend to give you the answers you most want to hear in these situations.
The best will tell you the truth. This might be the same in the best case but is often less than perfect in reality (though, per being a good manager, can at least improve).
>The worst managers of all will tend to give you the answers you most want to hear in these situations.
How is that different than employees giving the answer employers want to hear in the interview just to get the job? Do you think everyone is 100% honest? Everyone puts on a face.
I've worked in >1 companies where the SLA requires hourly updates for incidents, and they have to have substance beyond "still fixing."
This is in large scale finance and/or investment sectors where it is immeasurably important to keep clients (both "those paying us" but also the "those integrating with us" types) well informed of progress so as not to cause market panic.
Sometimes communicating is worth it for interrupting the team.
Sometimes communicating is worth it for interrupting the team
Perhaps, but the first thing any emergency responder will tell you is that there should be one incident commander, and that all communication and allocation of resources should go through that one person. And that the person with the incident commander role should not carry out any operational duties besides coordinate and control, because those other tasks require the same mental faculties, but use them in a different way, making them less effective in either.
If there is a requirement to update customers affected by an incident, the company should have processes in place to streamline the flow of information without interrupting the team. And the team responsible for updating customers should only communicate with the incident commander, and absolutely steer clear of the operational responders. If specific details are required, it falls to the incident commander to gather those details from the team, not to outside people running interference.
There's communication by interruption and there's observation. If you have a situation where there need to be hourly updates, there should be a person explicitly tasked with observing and noting what's going on to be able to provide those updates with minimal impact to the group that's actually working the problem.
Unfortunately, that means the observer has to be able to understand and follow what the engineers are doing while staying out of the way as much as possible. Tricky, but something you really need if for no other reason than to communicate and look for any holes that the team/person working the problem may not have thought of in the interim.
Yes, this role is defined as the "journalist" at my company and is an engineer tasked with writing status updates and the post-mortem report. It is important to have this role assigned from the start so that expectations are clear!
Assigning a "communications officer" at the start of an incident seems to work well. They are a person with the same technical skills as the people actively working on the problem, but their job is primarily to observe and filter/transform communications to and from the team. A nice side benefit is that having someone who isn't actually responsible for fixing things seems to free up their mind to notice things that their hands-on-keyboards colleagues missed.
If that is the case you should pair program, where one of the pair's only job is to sit behind the engineer doing the job and listen in, then take the meetings. This needs to be a full engineer who is fully capable of doing the work, but instead is just understanding the work, but not doing any.
If the main engineer has a 'family emergency' your communication engineer has enough context to take over, while another engineer is assigned to communication.
Agreed. That was how I've seen it run well. eg we'd create 2 channels for the incident - the first was for the technical team trying to fix it and would have quite a bit of noise as debugging went on. The second was for more senior managers and the client/account people to coordinate comms with customers. The only manager in the first group was the teams direct technical manager or their eg Tech Lead type of role. Their job was to not work on the fix but to communicate what they were observing to the 2nd group who would deal with the customers.
Smaller companies though are a bit less structured, and have to wing it a bit more depending on circumstances.
> Sometimes communicating is worth it for interrupting the team.
If you need constant updates from someone who knows the subject material, you need to nominate a single person who knows the material to take point on communication. They can help in between communication updates, but they can’t be tasked with leading or owning the work.
The worst way to do it is to have a manager who can’t understand the subject material themselves, then let them interrupt the entire team over and over again. Then the team has to stop and educate the manager about what needs to be communicated so they can relay it to someone else.
Having non-technical managers relaying information back and forth from the entire team is always a mistake.
The key component in this system that understands human psychology is to set reasonable expectations. Most places don't have that kind of SLA, but when an event occurs you can set an expectation of when the next communication will be and as long as it's not crazy, people will go along with it. But if you just leave people hanging, not knowing when/if an update is coming, they have nothing to do but panic about the lack of new information.
Scheduled communication is far easier to handle than random interruptions.
If your target is to get update every hour you just dedicate a person during incident to communicate with the "outside" and make rest of the team post the updates on shared chat, which you want anyway if you don't want people to get on eachother's toes
I've seen this distinction and it always boils down to two factors: is the manager technical and what's the caliber of the engineers.
Technical managers typically have a pretty good idea of what the rough requirements for a given situation will be. They might not be familiar with the exact details but should have some clue, so they just want to make sure everyone has a plan and it's sound. Non-technical managers don't understand what's going on so need to micro-manage because they perceive everything as high risk and complicated.
Caliber of engineers is pretty self-explanatory, but maybe that's selection bias; a 10x engineer won't stay long where he's micro-managed.
non-technical managers have literally no tools at their disposal other than to bug other people to do things. in a crisis, therefore, all they can do is dial up how often and how much they bug everyone else to do the actual work. At best they act as communication hub, gathering crucial information and coordinating to ensure it gets to the right people as fast as possible and they act on it in the right way. But even in that role they are limited because they don't have enough insight to really know who needs to know what and what they can do with the information.
I had a manager at my last job who tried to do the "what's the update" during a crisis and I just decided to make fun of her saying "I solved it but decided it would be funnier if didn't tell anyone" and she stopped
Crisis communication is an specific sub problem of team communication. Good takes on this often come from experienced disaster responders, like a fire chief or FEMA.
Their version of this is very real: 1) the annoying manager bugging for updates is the mayor's office or other powerful executive branch, 2) the emergency from which people are being distracted is life or death, 3) a jumpy executive can give wrong messages to the public which increase the workload or danger level.
Saw a lecture about this once, takeaways were 'clear lines of communication' and 'clear chain of command'. Wherever possible, put a person or a process between non-operational managers and front-line responders.
All the good managers I've ever encountered have the same skill:
They ask smart questions.
====
At the beginning, they try to understand the situation by asking the very dumb questions - but they're not shy about it.
They'll say, "Let me pick your brain", "Sorry I'm an idiot, so let me ask this dumb question" - and so on.
No ego.
But in no time, their questions will become smarter.
Coupled with their big picture view / perspective, their understanding of the system and the business - they quickly became a very helpful assistant for us to understand the problem, and in many cases, even able to suggest the, best, solution.
=====
Bad managers gives no added value, and instead distract you from your job.
Any senior management should understand these, and should be able to pick the good ones.
Otherwise the company/institution will be mired with persistent problems in no time.
God I've been feeling this lately. Manager turned into full micromanage mode. I started regretting waking up and checking slack, because there'd be an "Any updates on X?" message sitting there, often coupled with some passive aggressive remark. When I feel like I have more autonomy, I intuitively feel the urgency and act appropriately, updating people as updates happen.
I had some emergency a while ago where they insisted on being on a call with 10+ people while it was resolved. After an hour of badgering and applying fixes that all those helpful people thought up I told them I couldn’t focus, went off the call, and fixed the damn thing in 15 minutes.
Being on a call with people trying to be helpful is extremely aggravating.
You gained seniority. I have employees who don’t take a support case with a customer waiting with the straightest path, instead they take the opportunity to refactor code, so I check on them all the time; Others who refactor the code after delivering the bugfix, and those I leave them alone.
This is a result of always having the refactoring put on hold for feature development. Eventually engineers realize the only way to address tech debt is to refactor as part of a feature or bug fix.
This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.
> This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.
To my surprise, this is not always true. Some engineers do things because they have fun, even senior ones, and they will keep on refactoring things until there is a hard stop.
Best is to never generalize. It may depend from team to team, etc.
If you don't let them do this from time to time they will quit eventually, IME as a manager. Whether that's beneficial to the org or not is debatable. You can kind of "release the pressure" in a planned manner via hackathons, but those almost always never have the appropriate frequency.
When my coworker did it, it was the result of zero self discipline or focus, so he straight up got distracted by thinking of a way he could rewrite the whole app instead of making the two line *already understood* fix. He was a very good programmer and a terrible engineer and terrible coworker.
The prioritization of refactoring is strongly context dependent. A small startup with a fast moving product trying to acquire and retain customers cares much more about serving said customer right now than an established business who has more freedom and engineers available to dedicate time to forward thinking projects like refactoring.
I've worked at both large companies and small startups, and I've never seen taking on tech debt pay off. Features never get delivered as quickly as anyone wants, but sometimes tech debt completely prevents even thinking about features, and not being able to even imagine implementing something is a much worse problem than being 2 extra weeks late to the newest pivot. If I were starting a software company today, I'd want to keep my POC code about as clean as I'd keep production code at a large company. Well, cleaner. It's going to be alive as long as you are, and there will never ever be a good time to rewrite it.
Having said that, I am very skeptical about what some people identify as tech debt. Things like "we're using X logger instead of Y logger, this codebase is unmaintable" I tend to not prioritize, but things like "this system looks weird and we don't understand if the code is wrong or the documentation is wrong" is something that should be addressed with high urgency. It's very easy to spend a lot of time maintaining misbehavior that should just be fixed, and the first step is understanding whether or not something is wrong.
I do that on non-time-critical cases, if it doesn't matter whether I deliver it within an hour or day better to just do it now when I have it fresh in my mind.
This is an interesting point and may be part of the factor. I.e. There are two variables, and chances are that playing with either affects the outcome - experience and self sufficiency of the hands on person, and experience and self sufficiency of the manager (plus, I'll argue, other variables like maturity of processes, and client relationship / management state, etc). There is an inclination to focus on one variable only.
Fwiw. I've been a hands on techie for 20 years, then ops manager for 5. I've certainly been an Inexperienced/been a bad manager at times (especially as for a while, highly functional specialized vols reported to me as well), and I'd like think I'm becoming a decent or even good manager. But even still, there are definitely teams and individuals that I will feel the need to manage and focus ; vs others that I feel I can let prioritize and self manage.
(In the ops, of course, establishing formal urgency levels and resulting comms expectations and paths, can reduce stress on EVERYbody)
I think this is an interesting comment because it seems to try to re-locate agency back onto the manager. Ie. It’s not that the other manager was better, it’s that I somehow earned the better management. Correct me if I’m misinterpreting you.
It seems like a pretty standard (and simplified for HN) classification of employees who are and aren’t able to prioritize well.
Employees who can prioritize well will naturally be given more independence to make choices than those who don’t.
This of course assumes the management is able to make good decisions about prioritizing but I think the commenter should be given benefit of the doubt here.
I like to practice incident response on a regular basis, so people, including managers, know what to expect out of the process. If you do a practice incident every week, a real emergency will feel routine and people will be less anxious. If people are really distracting on the incident response call, you can always kick them off and elect someone to keep them updated, of course. I've never had to kick anyone off a call, though.
As a VP I had some conflicts with subordinate managers who were super anxious and transferred their anxiety on their own teams. Basically they had no clue how to solve problems due to not being technical and as a consequence made their whole teams neurotic like they were. I typically had to take over for a while to cool down the team and shield them from their managers whereas managers were supposed to shield the team from me.
In that scenario, it's often because the manager has someone breathing down his neck too, so you have bad communication and high stress all up and down the org chart. But sometimes the manager is the source of his own stress and all you can do is manage that.
Hah, when an emergency is happening only one person asking for hourly status updates would be a goddamned reprieve.
When stuff hits the fan I expect to be getting constant questions from the business analyst, the helpdesk, and manager, as well as having to explain to every other person who hasn't heard that I'm busy that no I can't help them with that today.
After being in a large company for ten years, I’m convinced that managers and companies don’t want productivity from their employees, what they want is alignment and legibility.
Alignment being: we both agree on what you should be working on, and legibility being: are we on track, or do we need management intervention to ensure completion? Emails, status meetings, stand ups, pop ins, IMs, while detrimental to achieving objectives, satisfies management desires.
But what's the point of productivity if you aren't working on things which align with larger goals of the organization?
You can be the busiest person in the company, but, if your doing work which doesn't align with the goals of the company your contribution is either useless or in many cases is actively harmful.
I think what OP means (and I would be inclined to agree) is that companies will take significant cuts to productivity in order to feel more secure and informed of the progress, even if that feeling is not grounded in data.
> But what's the point of productivity if you aren't working on things which align with larger goals of the organization?
Assuming larger goals on the level of "profit", sure. There's no point.
But alignment that people harp on about tends to be on specific business initiatives, or possibly KPI targets (generally tied to executive bonuses). This sort of alignment is how you get an alignment trap (where teams that are more aligned actually cost the business more and deliver less value than teams that are less aligned).
Goals at what level? I mean the goals for the CEO are so broad almost anything that is not going to land the board in court is a likely candidate. But for most middle management goals are highly restrictive.
I suspect that the guy who invented gmail (or rather linked ads to the text), had he asked his manager would have been told "hell no, fix the javascript bug that's assigned this week - that is putting us behind target for the month"
I generally think one should measure new or increased capability as opposed to most other metrics.
> I suspect that the guy who invented gmail (or rather linked ads to the text), had he asked his manager would have been told "hell no, fix the javascript bug that's assigned this week - that is putting us behind target for the month"
The history of gmail is that it started as what Google called a 20% project. A side project the developer, Paul Buchheit, worked on with the knowledge of his managers and peers.
Yes but there are diminishing returns to alignment. The difference between 90% and 99% alignment is minimal, and cutting productivity in half to achieve it is not worth it.
I also hypothesize that when you have systematically low productivity, the business/product no longer becomes aligned with the market. In that situation you actually don't want your employees to be 100% aligned with the business.
Why are you so sure that legibility and alignment are the wrong things to look for in a large organization?
Most of the work in a large software project is coordination between all the minds involved. The more minds, the harder this task is. Large companies don't need people who can work super productively but might work on the wrong thing for weeks before surfacing again.
Absolutely ... for large organisations the key is scale. When it comes to staff in strategic roles (engineering, software, etc etc) that build capability, there's a point where the challenge of growing past a certain scale completely depends on substituting individual action (aka productivity) with organisational ability to deliver results using any number of employees, where that number doesn't really matter any more. And that depends far more on the things you mention - clarity, alignment, procedural coherence, etc than getting even 2x more from the individuals involved.
It's funny because software engineers will be the first to tell you that "premature optimisation is the root of all evil" and other similar mantras but then be perplexed that their own individual productivity isn't the first item on their manager's agenda. The manager is probably busy optimising something else.
As usual, tech bros assume they know how to do everyone elses job better than they do. And if they aren't doing it the way the tech bro thinks it should work, it's because they are incompetent, not that there is some other factor not considered.
I would argue that your innovation center should be staffed primarily focusing on productivity rather than scale. You can always add scale as needed but you can’t add productivity once you’re at scale
My team is the heart of my company's innovation center and we've very intentionally sacrificed a lot of productivity for alignment and it's been really good for the business. It's an internal platform with probably another ~20 eng years of work left, turns out the bits of work our team thought would be most impactful weren't. By focusing on alignment we've been able to sequence the work so that more of company gets onboard early and the company as a whole delivers more value, faster, with less long term debt.
How would you define productivity and scale here? Because I would say the exact opposite: you can always add productivity by employing more people to do the same job, but to really grow you need to innovate so that the processes/tools you use become productivity multipliers. So in my mind, the innovation center is where the scaling happens, and operations departments is where linear increases in productivity happen.
There are productivity decisions at the micro-level that actively hurt scaling. The easy business example here is the choice to manage data in Excel as opposed to a formal database. (Very common in financial orgs). Excel gives the team today much more flexibility, at the trade-off of risk (anyone can edit numbers) and scaling (other teams probably can't find your excel file).
> There are productivity decisions at the micro-level that actively hurt scaling
Probably the most obvious one that HN readers will be familiar with is the 10x developer who trail blazes out amazing software but even if they do document it well, it generates an unsustainable technical foundation because it can't be supported after they move on (whether internally or externally). In a startup, this person is invaluable. In a large organisation you may even screen them out at interview stage in certain contexts.
I feel like everyone acts so surprised at this like it’s some contradiction when it’s exactly purposefully right.
At the end of the day delivering results isn’t the end all be all. It’s delivering the right results on a known and predictable time scale without any surprises. Above a baseline of speed it doesn’t really matter because you’re only as fast as the slowest business unit involved in your release and it’s not usually engineering.
Realistically my team could push out features that could fill a newsletter every single week but the parts of the business that figure out what features customers actually want, how we can market and sell them, how we tell users about them, getting them through qa, gathering incremental user feedback for the next iterations all work on human time and so we directly (or indirectly through management) get pulled into those concerns.
I think lots of devs feel weird about coding for 20 or less hours a week because it’s the part we associate with work when in reality we’re delivering real business value in those stupid meetings, it just manifests outside our view.
Dumb Hack: Treat meetings even ad hoc ones like card work, groom them, assign them point values, define ACs and retro them. You’ll discover really quickly the meetings that aren’t serving you and the value you’re providing to the rest of the business.
> I think lots of devs feel weird about coding for 20 or less hours a week because it’s the part we associate with work when in reality we’re delivering real business value in those stupid meetings, it just manifests outside our view.
Blink twice if you’re saying this under duress, because otherwise, this just sounds like post hoc justification from someone who gave up and dedicated themselves to promulgating the soul-sucking management games that made producing real value untenable.
Spending less than 20 hours a week actually writing software is a horrendous use of a developer’s time. It’s a marvel when anything intelligent gets written at all in such an environment.
When I was younger I always assumed all the tracking had value. After a decade of working, it’s all a facade. And all these people are constantly trying to be managers which explodes the amount of documentation
Some tracking has value. Last year I did some testing. Its results were recorded for posterity. A year later, for god only knows what reason, production environment differed slightly from testing environment a tiny little bit. Records allowed for a relatively quick follow up with vendor and resolution.
But it goes back.. how do you know something will be important?
Everything always ends up on a confluence dumping ground, and I have trouble finding pages I wrote after any sort of significant period of time, much less finding things other people wrote.
To be honest, I think it is my history with the vendor. I know them to be flaky so I keep anal documentation of minute changes one version to the next. It is genuinely just an excel spreadsheet, but there is a focus on changes they introduce along with dates since I was burned before.
The issue was fairly unique and actually tested for and the list of implemented defect fixes in testing env. was listed on our end ( and maybe for once the fact we don't use confluence helped ), which helped to narrow it down on the vendor's side ( I am not sure what they use internally ) and it certainly helped that there were only two related projects for that specific move for the date the issue occurred.
FWIW, it is possible that I am just still relatively new to this ( 3 years for the testing part ) so all the issues we experience don't all blend together yet.
edit: Apologies, as I re-read it, my response feels fairly generic, but I am not sure I can discuss more details.
Ahh, I see. I think I can see the value in tracking kept by a person for themselves to troubleshoot things in the future.
But I can't imagine that's the kind of tracking greatpostman had in mind, and it's definitely not the kind of tracking that most managers I've worked with try to produce.
10 employees working fully aligned will achieve much more of what is valuable to the company than 10 employees working just as hard but on things that don't sync up right.
And legibility is needed in order to achieve alignment. A manager needs to make sure all the parts of a project come together by the deadline, and so tracking progress allows them to quickly say OK let's drop that feature or I need to unblock you on this so I'll reach out to the other team's manager.
Productivity isn't a scalar quantity produced by employees that simply adds together. Think of it as something more multiplicative, where a "zero" from a key employee tanks a project altogether. (E.g. your team of nine back-end engineers and one front-end engineer achieves zero productive output if the front-end engineer doesn't deliver anything workable. Or the back-end database engineer fails at their tasks.)
So alignment and legibility aren't detrimental to achieving objectives -- they're critical.
Having worked in all sizes of companies, I've learned this: bad managers want obedience. I've seen this from team leads, from C-suite, and in between. For me it's a huge red flag, a sign of incompetence and of an offensively domineering mindset.
Good managers want communication (or as you said: alignment and legibility).
> I’m convinced that managers and companies don’t want productivity from their employees, what they want is alignment and legibility.
That's like saying managers and companies don't want productivity from their employees, they want developers to write lots of tests under the guise of making code more robust, lots of documentation under the guise of making it more maintainable, and do lots of code review to ensure it meets the team's standards of quality.
If we didn't have to do all that testing, documentation, and code review, we'd be able to move a lot faster!
I actually think both are important and pretty much define what real productivity is. Since the company pays me dough surely it has a say in what I should work on.
And a bonus if manager can pull his weight to make things happen, i.e. management intervention.
My current manager works like that and I'm perfectly fine with it. The only issue that I can see is that said manager might drastically misunderstand the scope of things at hand. But so far I haven't met anyone like that.
The 2 most important traits that managers desire are agreeability and subservience. Never argue with them. Even the slightest of power corrupts humans.
I thought execs had to do all the cunty things they do because "it's their legal duty to maximize profits for the shareholders"? But suddenly it's OK to sacrifice productivity for the sake of power-tripping? Shouldn't he have been fired on the spot?
That's literally a manager's job. If you don't have managers, by definition, you have individual contractors. The point of being a manager is to line up the work of all the ICs so they are more or less pointing in the same direction and can tackle problems that no one person could handle on their own.
There is always a productivity cost to this, and it takes many forms. One is simply the manager's salary: they aren't doing useful IC work, they're spending all their time aligning their reports' work with the goals of the organization.
Another is that the ICs will typically be working on projects that align with their organization's goals rather than their own goals, and most people are less excited by a faceless megacorp's goals than their own personal projects. A third is that all the communication overhead and status reports come out of time that could be spend actually working. A fourth is that you're often forced to adapt less productive methods, programming languages, frameworks, etc. simply so that what you're doing can be communicated with other employees.
But this is all intentional, and savvy businesses know it's going on. It's the cost of being a big business, and you usually can't become a big business unless you can solve problems that smaller businesses cannot.
A corollary is that a good manager usually doesn't care much about how productive you are, only that you have positive productivity and demand little of their time & energy. If they manage a team of 10, your productivity could be 1/10th theirs at the same task, and yet be a net win for them (and the organization), because the team's output is more than they could achieve on their own. However, if your productivity is half theirs and you take up half of their time with your questions, it's easier for them to just do your job, and now you're a performance problem. And conversely, if your productivity is double theirs but you're a jerk that demotivates the other 9 employees, they're better off letting you go even though you're a superstar, because their team productivity is 1/5 what it would with the other 10 people on it.
This is why there's often a lot of counterintuitive behavior in large organizations. Your manager knows that you're reading HN on company time, or taking personal calls, or arranging doctors appointments. They don't care; you'll make it up later, and it's usually a net productivity gain to make sure employees are rested, happy, and healthy rather than squeak out every working hour from them. Same if you want to take off an hour early for childcare. But conversely, if you're putting in long hours and cranking out tons of code but you're a jerk that makes the rest of the team stressed and anxious whenever they come into work, you are a net productivity sink and will probably get let go. It's even worse if you're putting the company at risk through HR violations, negative PR, stealing trade secrets, etc - which is why even prominent high-performers can get fired for that.
The bigger the company the higher the downside, and hence the greater the tendency toward mediocrity. In a startup your bad attitude, loose mouth, or penchant for lechery might be tolerated because the potential upside outweighs the risk to a company that's probably going to fail anyway. In a megacorp there are 200,000 other employees that can do your job, so a.) your productivity has to be pretty bad before you're a net negative to the organization and b.) your potential negative productivity caps out at 200,000x your salary, which means it doesn't take much of an infraction against the company before you're terminated.
I once worked for a startup co-founded by people who created DirectX at Microsoft. There is a book written on how DirectX was created and what went on inside the team during those initial days of DirectX. Hence this book was available in the library of the startup where I worked. These is a very interesting statement in that book on the topic of what a manager's responsibility should be in a team. And this is what it said:
"A manager's responsibility is to remove any roadblocks from the path of an engineer. If an engineer is coming down a hallway and there is a chair in the path blocking that engineer, then it is the manager's responsibility to remove the chair from the path so that the engineer is not troubled." :)
Years ago, very early in my career, I rotated among a few teams at the company, and even then, one manager stood out as different from the others. I straight-up asked him if he had a philosophy or something, and this is what he said:
"Yeah, my job as a manager has three parts. First, get the right people for the job. Second, get them the resources they need. Third, get everything else out of their way."
Decades later, this still rings true. That team was the most productive I've ever seen.
That I very cool to hear. Only once have I had a manager with that philosophy and mindset.
He left my place of work recently and as a result I’m leaving too. Good managers are rare as leprechaun gold.
It’s a world of difference from the manager I had at my first job out of university who was more interested in their own job security and didn’t give a shit about his reports.
This always gets stated - "Removing roadblocks". But if the engineer isn't removing roadblocks on their own and collaborating with other teams, then they get labeled as "lacking initiative". People managers really don't deserve a place in the software industry. More often than not, they are the real roadblocks.
Every time I read an article from HBR, I find myself wondering (a) how the content isn’t obvious to anyone with a working nervous system, and (b) what value its core readership can possibly bring to a company.
But this one really takes the cake. My respect for the “academic” field of business has somehow managed to fall below rock-bottom.
The content isn't obvious to them because they operate in a different context than you.
Managerialist culture is founded on the notion that workers must be supervised and controlled. That the important thinking should be done by people in the managerial class. In that context, the experiences of non-managers is always secondary, because workers must be coerced via carrots and sticks to do things they are not smart/wise/good enough to see on their own.
A great example here is the ubiquitous status meeting. Everybody troops into a conference room for an hour and takes turns saying things to the boss while everybody else's eyes glaze over. This lets the boss feel powerful and important, but it's a giant waste of time. The POSIWID conclusion is that organizational effectiveness is very much secondary to reinforcing the dominance hierarchy.
For somebody adapted to that world, treating the time of minions as truly important -- by which I mean more important than the passing feelings of the powerful -- is radical. Even though that's something blatantly obvious to makers and others who do direct work.
> Managerialist culture is founded on the notion that workers must be supervised and controlled.
That's a shallow view of the situation. What you're describing is "Taylorist" management, or "Theory X" management.
Modern management theory also discusses "Theory Y" management, in which providing context and trust is more important than supervision and control.
Many managers are unaware of this concept, even though it's Management 101. If that's the case in your company, it's not a problem with "managerialist culture"... it's a problem with your company's culture.
> Modern management theory also discusses "Theory Y" management,
Good god, "management" is so deeply devoid of any actual substance that they can't even name their prominent theories? No wonder it's a constant struggle for them to justify their own existence.
These theories are taught in an MBA program. Most managers never go through such a program. Ironically, MBAs are often mocked on HN, but now I find it ironic that you find it shocking that managers (who don't complete an MBA) don't know what the prominent theories are.
It's possible to have strongly negative opinions of both MBAs and middle managers, even if they don't perfectly overlap.
> now I find it ironic that you find it shocking that managers (who don't complete an MBA) don't know what the prominent theories are
Hard to be "shocked" anymore, since it's so normalized, but if we break it down:
- Management theory is mostly bereft of useful information
- Most managers don't learn the theory anyway
- Most managers don't bother to try to get better at their jobs, and if they do, it's by reading vapid articles like this one or going to the expensive training version of the same
- Higher-level managers earn multiple times what ACs ("actual contributors") earn
- Bad managers can, and do, sink entire teams, and may represent some of the biggest risk to most companies, and yet virtually no effort is ever made to hold any managers accountable for anything, because the only people who could do that are other, higher-level managers, whose jobs are even more worthless, and they know it, so bad managers are kept around because otherwise the entire House of Feudalism could collapse
- Good managers are frequently praised for their ability to protect their reports from the torrent of stupid bullshit coming from above them in the chain, and yet nobody ever asks why the fuck there's a torrent of stupid bullshit coming from higher-level managers, who, again, make much more than the people being protected from their wanton disregard for effective management.
As you said, most managers haven't even heard of "Theory Y" management. Mangerialism (and here I'm using it as defined by Spender and Locke) is the dominant paradigm in most parts of the business world. This is not a problem with one individual's company. It's way larger than that.
You're correct, of course. I didn't realize you were using the "managerialism" in a formal sense. And you're right that it's common... not because people are explicitly subscribing to "managerialism" as a theory, but because command-and-control Theory X management seems to be people's default mode of thinking.
I don’t disagree with any of what you’ve said, but you haven’t addressed the issue.
The issue is that anyone unable to intuit what has been said in this HBR rag has no business directing the work of another human being.
No amount of difference in “mindset” or “context” can account for the sheer obviousness or what is being said, nor can it justify passing this off for expert analysis.
It is obvious to you and me. It is not obvious to them. I would agree that it's terrible that this is the dominant management paradigm is one that seems terrible to a lot of workers. Whether or not these people "have no business" managing doesn't really matter in that they are broadly in charge. Denying the reality isn't going to change the situation.
>A great example here is the ubiquitous status meeting. Everybody troops into a conference room for an hour and takes turns saying things to the boss while everybody else's eyes glaze over. This lets the boss feel powerful and important, but it's a giant waste of time. The POSIWID conclusion is that organizational effectiveness is very much secondary to reinforcing the dominance hierarchy.
This is a good point and resonated with me. It would be a better use of the employees time (and thus presumably better for the company) if the boss walks around, and sit down with people to have a chat about the status of the project/status in general. However this would take a lot more time for the boss and probably doesn't feel as empowering as well, so all hands on deck, lets use 1/8 of today to sit and do nothing. I think having a 1 on 1 would help people be more honest about their status, and maybe even the group dynamic in their team as well. I have been a consultant where we were 10+ consultants plus 2-3 internals in a weekly meeting. It baffles me that the customer wanted to do something that costly and ineffective.
Almost every meeting I ever attended had an agenda and the others were on single, specific topics. So is that normal and hbr is inventing a problem, or am I very fortunate?
Why do you think a regular status meeting is definitionally a giant waste of time in all business contexts? Is informing others of status and next steps not a business goal?
Many tech-forward schools of thought would probably suggest that status of work is something that should be discoverable - ie, we shouldn't need a status update meeting because the status is obvious from looking at tasks on a Kanban board or some other tool that is used for tracking work. I'd guess the person you're replying to believes more that meetings are a poor way to accomplish this than that a pulse on work isn't important to business.
If you're a brand like HBR, you need people to mindlessly link to uncontroversial articles. Particularly from LinkedIn where this kind of thing lives. Nobody will pick a fight about this, but thousands of people will like it and re-post it.
This is a good articulation of the problem. It’s effectively business-class shovelware.
But my concern is less about the people writing or publishing this drivel than about the people who consume every drop of it, hoping for some “insight” into “strategic thinking”. Before anyone accuses me of attacking a straw man, I have personally met dozens of such people.
What pains me the most is that there is something out there that can give them what they want; a classic liberal-arts education would actually teach them to think with some rigor. But they’re stuck. They can’t think well enough to dig themselves out of this hole of mediocrity, and it’s an unsettling mix of tragic and repulsive.
So in true HBR form, if you find yourself reading “thought leaders” or looking to improve your “strategic thinking”, please — for all our sakes - read a book. (NYT bestseller doesn’t count.)
>than about the people who consume every drop of it
but but but, how can you become a thought leader if you don't slurp up this kind of content to regurgitate on your own blog as if it was your original thought and then relentlessly post about it on $theSocials?
While I mostly agree with you, I can offer a more optimistic view that you may choose to consider. Think about all the hobbies that people pursue in which there is some new gear they can read about and aspire to having that will take their pursuit of said hobby to the next level. There are entire magazines devoted to reviews of new gear.
If HBR is such a magazine for managerial oriented people then at least it shows that some people are aspiring to improve their ability as managers, or at least the functioning of their organization.
I see your point, but this is akin to witnessing someone go to a psychic for help. There is little cause for optimism when people seek help from vacuous people or publications.
> Every time I read an article from HBR, I find myself wondering (a) how the content isn’t obvious to anyone with a working nervous system (b) what value its core readership can possibly bring to a company.
Pretend for a moment you are responsible for the quality of management at a large tech company. You think this article's guidance is obvious but what percentage of managers do you think already practice it? How do you make that number go up?
As to your actual point, it’s horrifying that people need to be told “don’t be distracting”, and that this passes for best-in-class analysis on the subject of business organizations.
P.S. as a sibling comment points out, this drivel isn’t even meant to be helpful. It’s meant to be uncontroversial.
It's for the bullet point class. The type of person who, if you can get their attention for 10 seconds and stuff 3 bullet points in their head, they will make a crude, flawed, but genuine movement in the direction you pointed.
If this person were rare, the world wouldn't be nearly as saturated with slogans as it is.
And to be honest, I think we are all this person from time to time, when we are stretched thin.
> As to your actual point, it’s horrifying that people need to be told “don’t be distracting”, and that this passes for best-in-class analysis on the subject of business organizations.
It's really not best-in-class analysis--that honor probably goes to the Academy of Management Journal[1]. It's a free blog post on a non-peer-reviewed _magazine_'s site. Yes, there is a dynamic that makes paywall journal articles anti-viral, which is why you won't find any at the top of HN.
But I do think the article is meant to be helpful, not just inoffensive. As a manager, your peer and everyone above you is interrupt driven. There is some missed deadline or other crisis you are expected to attend do. Even your employees have an oncall function, and we have all these amazing instant messaging tools like Slack. And agile is all about changing the plan a lot, right? Heck, peopleware has a section on overhead intercoms in the office, to give you an idea of how bad it used to be. And extroverts (ie sales and marketing) don't mind interruptions, maybe even thrive on it if they made a promotion to management. It's just not obvious at all for some section of humanity, unfortunate as it is for us engineers.
Finally, think about it like this: some employers are putting spyware on employee computers to monitor work from home behavior. That is the audience for this article. Not sure why it's on HN.
Not only should managers not distract their reports, I view a primary responsibility of any engineering manager as proactively shielding their reports from as many unnecessary meetings — particularly with external teams — as possible so that engineers can focus on what they're paid to do: building stuff. The best managers I've ever had spent a significant amount of their time just interfacing with product managers and designers to cut down on bullshit that distracts engineers from doing their jobs.
This only works if the EM is both somewhat technical and actually communicates well with their reports. "Shielding" and leaving out key, important details will eventually result in pissing off your reports even more than useless meetings.
One of my managers had the goal of "shielding" the engineers, which in practice meant that everything went through him (at each step losing nuance), we never knew why something was important (we didn't know what we wanted to solve and why it was valuable for the company), why something was the most important task at a time (why not work on something else), we didn't know who to ask about it (felt like learned helplessness), we didn't know how deadlines came to be (where they just made up or was there a really good reason).
Pretty much each piece of advice here can easily be replaced with software. I think "manager as supervisor" is frankly dead. It just hasnt stopped moving yet.
For me a great thing to learn from software development is daily integration builds - whatever work is being done, build it as the complete sellable product every day. This way you will get good at making the saleable product
> I think "manager as supervisor" is frankly dead.
sorta. as someone who is an EM, so i guess take the bias with a grain of salt, the difference between a really good EM, and someone who warms a seat is astounding. the really good ones have strong opinions, can coach well on a variety of topics (e.g effective communication, organizational thinking), and understand the technicals at least from a level of where you can see how your direct reports are doing. they also understand the economics/business of a company and can foresee which teams are dead-ends so they can offer good advice to direct reports to grow careers.
the ones who warm seats are glorified project managers. no real advice beyond "should we do standups, when are retros" and basics like running a board, or taking notes during meetings. usually pretty disconnected from the day to day, no strong opinions on the actual hard stuff, just topical high level advice. plenty of those in the field, and its unfortunate because its not a hard science, so they tend to BS their ways into these positions and make a lot of money.
either way, managers aren't going anywhere and no amount of code will automate them away.
I agree and further - After ~20 or so years in tech (including being a manger myself for awhile) I would guess about 70% of EMs industry wide are your “seat warmers”. They’re not necessarily harmful or bad people, just kind of useless. These days I have learned to pretty much ignore what they say and chart my own path to making things happen.
Unfortunately in corporate America there are many people who are simply coasting towards retirement. It’s quite difficult to motivate someone when they only have three years left.
im not sure if its that in tech - mostly people are pretty motivated. I think there's just more need for manager roles (HR stuff, 1/1s, communication, coordination, etc) than there exists willing talented candidates. So the bar gets naturally lowered and we end up with a lot of mediocre seat warmers.
question for ya -- i've been thinking about going back into IC actually. i'm sort of in a weird position where i am bored to death being an EM, but also appreciate some of the problems i get to think about and try to solve that i would never get to as an IC. was your decision to go back to being an IC the right one? do you miss anything about the EM role?
great question. It was absolutely worth it for me, but let me give some extra context and explain what kind of role i work in now.
background:
- what i liked about management was leverage, and being able to influence strategy, etc more than i could as a regular IC. Also coaching and growing people.
- what i was "meh" on was the very time consuming mechanics of mgmt, 1/1s, perf reviews, sprint mechanics, status reports, interfacing with HR machinery etc.
So i wanted to create an IC role where ideally I could have large scale influence, and still participate in the strategy and high level decision making at a company. I did NOT want to go back to IC to be left alone to code hard things in a corner. Thats a totally valid path too that ive heard from some, but not for me, so just calling that out.
So creating the role:
- you need to be at a company that believes in (or has already established) an IC leadership track that parallels the management track. That means there should be IC levels that match (in pay and responsibility) to manager, director, VP levels. Facebook, google, big tech all do this now. Creating and paying for a non-management ladder is kind of the "put your money where you mouth is" - if the company wont do this, they wont take IC leaders seriously when push comes to shove.
- one way to do it is to pair an IC role with a senior mgmt. eg, there is an eng Director in charge of payments, so there should be a single technical IC in charge of payments tech. They work together on shaping the overall strategy for their unit - the EM & IC lead are responsible for the same domain. Notably, these folk dont have to be on a specific delivery team, rather they work with each delivery team in their unit as needed.
- the senior roles come with real responsibility and accountability... if you are the payments lead IC, you're making technical decisions with consequences in the millions or 10s of millions of $$, in terms of risk but also in terms of engineering opportunity cost. A rough proxy for "how senior is this person" is "what would it cost us if they were wrong". Make that clear to the business side, take responsibility, justify decisions in business/commercial terms. It will be received well and you will be taken much more seriously as a strategic stakeholder.
- you can still coach and grow people, just on your own terms without the formal reporting structure. Better to me.
anyway enough rambling - and YMMV this is all advice that applies to what I wanted to do with my role. Others may have different goals. Happy to talk more if you have questions, email in profile.
Supervisory management actively impedes work. Managers should be planners, resource allocators and stakeholder communicators. They should work to bring their team into alignment with their org's goals and their company's goals. By attempting to be a supervisor, it sets the wrong incentives within the team.
This is also the reason why penalizing performance reviews don't work. It causes lower morale within the time and nobody really feels aligned with the company. Everyone is out there looking out for themselves.
>>> Managers should be planners, resource allocators and stakeholder communicators. They should work to bring their team into alignment with their org's goals and their company's goals.
But there are either better ways to do these things, or they still require coercive (supervisory) activity.
So planning. yeah it's important. Have a clear goal and work out what you need to achieve it. Frankly the new intern can achieve most of that in one day, and all the senior team can easily do it. And prioritise it. The hard part is where you have multiple parts in parallel. Sometimes people think they are some Moriarty style genius who can direct each part to develop and land with precision six months in the future. Total bill ox. If you aren't doing daily integrations you aren't co-ordinating and so you aren't "planning".
Yeah there is a function of logistics - but that's spreadsheets and gaming out scenarios - not a "management task" but certainly a "management input" - and if instead of giving it solely to managers you just published it to the whole org such logistics would be available to increase discussion and awareness (ie the workers would understand the plan better and not need managers)
Resource allocators - pretty much as above - plans, resource budget all different sides of same coin.
Aligning goals ... that's incentives. That's easy - pay me. Otherwise ... looks a lot like coercion.
> But there are either better ways to do these things, or they still require coercive (supervisory) activity.
I wish there were a consistent answer to this, but part of the reason management is hard (and I won't deny there's plenty of useless managers) is that people is very variable and you need to adjust your approach depending on the organization composition.
> So planning. yeah it's important. Have a clear goal and work out what you need to achieve it. Frankly the new intern can achieve most of that in one day, and all the senior team can easily do it. And prioritise it.
There are plenty of teams and situation where this is hardly "easy", particularly at very large companies. Relative priorities are not always clear, many teams demanding your team's attention and understanding what is "best" for the company and company goals, the team and individuals is non-trivial. You need to align all of those. It requires constant communication (hence why managers spend time on meetings, reading presentations, reading roadmaps from other teams, 1:1s with their team to understand their personal goals, etc);
> and if instead of giving it solely to managers you just published it to the whole org such logistics would be available to increase discussion and awareness (ie the workers would understand the plan better and not need managers)
Even in organizations where the information is open and all documentation, meeting notes, spreadsheets, etc; are open people struggle to understand and some just want the summary (I'd say most); they don't want to know how the sausage is made outside maybe have an understanding of the process (and some not even that).
> Aligning goals ... that's incentives. That's easy - pay me. Otherwise ... looks a lot like coercion.
Maybe is that easy for you. A lot of people want something else from their careers and as a manager you have to align what the organization wants with what the individual(s) and teams want as much as is reasonable to maximize their satisfaction (retention, performance, etc; is better if you achieve this).
I am maybe being overly cynical but I do not get the distinctions you are making.
We are talking about software, and software is eating the world - but the great thing about software is that you can deploy it in different environments and monitor the results. Now of course "prod is different" but, the "difficult" bits you are talking about are all "how can we alignnincentices so that the ten big projects all
land successfully and deliver in two years". You cannot. No matter how big brained you are no matter how many meetings. It's impossible.
So just integrate the whole fucking lot early, run a series of prod like data through it, build a couple of teams that run this integrations and they tell everyone the current state of the ten big projects. Everyone will align around those test rigs pretty damn quickly, and the ceo only needs to beast one team regularly to make sure they are not favouring anyone too much.
Or even better run two test rigs or theee and triangulate the results.
Expensive yes but damn it will get results.
And it removes a huge layer of "management status reports". What is the status of the ten projects? go look at each test rig.
As for "people don't want to read the open docs" - that's not what Inmean. people don't want to read the minutes of the board meeting because the decision has already been taken and their views don't matter. Democracy works differently - people will take an interest when their votes directly influence which stupid project gets ten million this year. And importantly politicians will arise internally - who will explain and advocate for certain projects amoung the voting base - they will be like FDR and gain power and be called traitors to their class.
And finally - no. aligning incentives is easy. Pay me.
> "how can we alignnincentices so that the ten big projects all land successfully and deliver in two years". You cannot. No matter how big brained you are no matter how many meetings. It's impossible.
If you are basically saying we should throw our hands up and give up at any kind of project management, then yeah, a significant part of engineering management is not needed. You seem to be basically saying all can be solved by http://programming-motherfucker.com/ and I get it, sometimes as a sw engineer that's all I wanted to do, but the reality is that often you need coordination and project management to get results you (or the organization) wants in a timely fashion.
> Democracy works differently - people will take an interest when their votes directly influence which stupid project gets ten million this year.
Democracy is super slow for decision-making and not everyone is equally qualified or invested to have a vote. I'm not talking about even "board meetings" here. I'm talking about having a freaking doc with 10 potential projects a given team could tackle this year. Who is going to curate those 10 projects? justify why they are needed or relevant that we should spend time on them? who is going to decide who works on what? as I said, democracy and consensus-building is slow and often will just mean "the most opinionated or stronger personality wins". You need a skilled eng manager to navigate complex conversations and keep everyone aligned on why a given project was picked.
> And finally - no. aligning incentives is easy. Pay me.
I guess this sums it up. You personally may only care about being paid, but that's not everyone. Your whole view is a simplistic take on what it takes to make you specifically happy and that's why you think is easy.
Project management (IMO) has two major aspects - co-ordination and risk management.
For co-ordination it is waaaay better to have some overarching vision clearly articulated (maybe a blog to keep it simple) and then an awful lot of integration early and often.
Any group of management that thinks it can do-ordinate better than actually integrating against working software needs a reality check. If the organisation finds what is integrating is not what it wants (pretty much all projects) then early delivery finds the answer quickly
I mean this is totally what Agile Methods means. It's just the higher up / programme management process does not recognise this chnage - they think things can be planned - they can't they can only be predicted and predictions chnaged based on up to date information.
And it cannot be that they understand it because their salaries depend on it.
And maybe I am being mercenary- but paying people almost always gains their compliance for a while. and either you take that short while as a given or you only hire people whose personal vision aligns to the desired company vision - sadly i think we will see far more "political companies" - not for example democrat / republican but climate change / social justice aware - and your personal views will be meaningful at higher levels. but that is probably true anyhow, it's just implicit
I'm a relatively new team lead (this is my second year with the title officially, though I did TL responsibilities prior) and my entire goal is to be the antithesis of the type of manager mentioned in the article. My best managers were ones that let me focus and removed roadblocks, so I try to do the same. Ideally, my team has zero to one meetings per day (stand-up inclusive); I'd rather them focus on development than get caught up in unnecessary meetings. As a result, I'm often in meetings instead (which is fine) and then can give my appropriate teammates the outcomes of those chats. Everything else should be offline / async where possible, and I try to prefix those slack messages with a priority level so they can tell at a glance whether a given message can be safely ignored until a break between work items.
So far my team seems to love this arrangement, but I'm curious if anyone has advice on the long term effects of this approach.
Seems very similar to how things are run where I'm at. I've been here 10 years now and I think it's been a very good way to do things for us.
Now that I'm more senior I do get called into more meetings. But still it's usually not more than 2-3 per week and almost all of those are 30 minutes, or an hour tops, and very efficient. Most of the other meetings my boss does and relays info to us through issue tracker or mail/chat. Like you, he spends a lot of his time in meetings.
In some cases he'll forward the invite and let us know he might ask us to join to answer one or two specific questions. In those cases we do just that. While not interruption-free, since we're aware the disruption of the 2-5 minute diversion is minimal.
We do have a longer weekly team meeting where we go through all issues being worked on and upcoming work. This might be an hour or two depending.
We're office-based though, and noticed during the pandemic that some extra follow-up was needed. So my boss would usually do a quick call at the end of the day every other day or so to follow up each of us, and also for the social bit.
I used to run Teams reports on our employees to figure out how much $$$ was going into meetings.
I found that some of the least productive employees spent 60-80% of their time in meetings (high Teams usage), and I suspect it wasn't because of the meetings that they were not productive, but that they had a lot of meetings because they were not able to be productive: it made them feel good.
I worked in one place where the CEO monitored us on Slack, and also via a/v cameras which were everywhere. He had the entire working space covered and he'd sit in his office (which had a TV and PS4 in the corner) sat behind a desk with half a dozen monitors feeding back audio and mic from the office, like a spy operation. If he saw us chatting even a little bit he'd tell us on slack to get back to work. His idea of running his business was to run a CIA sting operation on his staff.
Every now and then he'd bring one of us in and promote us but the promotion meant nothing. I got 'head of frontend' in 3 weeks.
This article seems so obvious to me that I'm surprised it got traction on HN. Are there managers here that felt there was some new/interesting content in this article? Maybe the scarier notion is that this was upvoted by the reports of managers that are not heeding this advice?
I consider this like drinking water. It's a no brainer that you should drink water, but some people need reminders because mentally they are getting caught up in other stuff.
I think this advice is subsumed by the more general heuristic that managers should basically understand and be able to do their direct reports’ jobs. If they understand the importance of focus and flow state, they will also understand the cost of interruptions.
One thing I love about the company I'm currently at is that pretty much every eng manager does some level of IC work. Meaning they all have some pulse on the codebase beyond higher level planning.
My first job out of college was working at the backup site of a state lottery as a computer operator. Nothing ever happened all three years i was there to need it.
But we were told by our manager at the time that while shit is hitting the fan and you may have all sorts of people breathing down your neck, focus on the people you need to coordinate with and politely tell other people that you are following the checklist and you will give them updates at the appropriate time.
This was in the mid 90s. I have followed the same m.o. through out my career. I have been on all sides as a psuedo-manager, software architect, hybrid developer/sysadmin, consultant, etc.
Who is more important? An efficient manager that has 5 reports, or an inefficient manager with 10 reports?
How about a very inefficient manager with 30 reports who now needs 2 levels of management to manage that team?
Distracted employees are inefficient, create the perception of busyness and the opportunity to require more headcount, making bad managers more important.
Many large organizations are just bad managers trying to look bigger.
Those managers do not want efficiency, because they need inefficiency to justify their organization size and their role.
It’s the classic support response of “try clearing your browser cache, delete all cookies, update to the latest versions of all software and drivers, then reboot your PC” when the questions was “why doesn’t outlook.com let me forward my emails any more?”.
I’m pretty cynical of most peoples motivation these days. Your local coffee shop’s point-of-sale asks if you’d like to round up to the nearest dollar with the change going to charity? Sounds like someone’s Q2 goal was to improve community relations. As soon as they get that promotion, will they maintain the charity thing? Probably not.
Another classic is the endless A/B testing to pursue growth metrics. Reddit can’t show you this video of a man calling his dog “f**king hilarious!” but if you sign in with the app and lie about your age it will. Or maybe it just “looks better” in the app, or some other carrot? One day they’ll just get the stick out and www.reddit.com will have a popup saying “we are now blocking 50% of IP addresses from web access to make you just use the damn app”.
And don’t get me started on “we are experiencing high volumes of calls right now, please hold for the next available etc.” As if there’s anything unpredictable about call centre statistics! Whenever I hear this message, all I’m hearing is “in order to maximise productivity from our agents, this call centre deliberately understaffs to maintain 100% capacity throughout the working day… sorry!”. The idea of an agent taking a break due to a lull in calls is anathema.
Tracking and being led by metrics is nothing if you don’t have a principled, moral, qualitative reason to be doing so in the first place.
Biggest distraction I see in companies that want to act like they have a mature software engineering culture but don't actually have one is to focus on the process. This can range from sticking with traditional waterfall to voodoo agile with "scrum" and daily standups that are really just status meetings for PMs. Often I see companies using Jira or whatever and PRs for being really particular about how work is logged and tracked. Moving stuff through the stages and merging PRs quickly becomes the goal, because to management it looks like stuff is getting done. Actually releasing working features to production is, at best, an afterthought.
All that process and ceremony distracts programmers from doing the job of, you know, programming.
I completely agree with you. I have said it multiple times but I believe mismanagement through busy bodies and incompetence is actively and systematically impacting software engineering as an entire industry.
Maybe this is counter-zeitgeist, but managers are just people like you and me.
As you get “higher” up the org, you get further and further away from action/result. But you can see more.
The narrative around “why don’t managers just let people get their work done without annoying them” is comes down to a lack of leadership. Both from the manager, and from the direct report. This is the missing ingredient that few managers and almost nobody on the ground “gets”. The manager needs you to step up and lead, so that they can manage. They just generally can’t articulate this because the manager and you both think you’re not in a leadership role. But you are, everyone is. That’s your path to not being distracted by your manager.
30+ years of experience here working for companies in 5 different countries. Both as a manager, a director, a CEO, and as a developer.
The truth is that most managers are incompetent. It’s that simple. Most of them think that it is their job to make all the decisions. Nope wrong. Or that they need to interrupt people all the time to get status reports or whatever. Nope. Wrong again. No cookie.
I actually blame the companies they work for. Being a manager is something you need to be trained to do well. And yet companies promote and hire managers who have never received even the most basic training on how to be a manager. A few still succeed despite their lack of training. But those ones are rare.
Look at the military. They train their leaders before putting them in charge of soldiers. They know how crucial it is to have well trained managers (officers) in charge. For some reason companies don’t get this.
Reminds me of my first startup in the US. When things got difficult, we had daily 30 minute status meetings. Then things still didn't go fast enough so everybody had to attend 2 30 minute status meetings every day. It was just nuts. I tried to tell upper management that probably nothing important will change every day and even less likely in half a day but no luck.
Yeah, I've been there, too. Daily standups start out as standups but then turn into 1-2 hour long meetings first thing in the morning. Consequentially, those meetings had negative effects on productivity, because the entire team would be stuck there on the call while the manager talks to one person at length. Usually the same one person, at that. I don't miss that place at all.
Many managers fail to bring out the energy in the people they “lead”. Some people are energized by autonomy in their job, some relatedness to others or the work itself, and some competency in their skills or career progression.
Work is getting more personalized every year and modern management cannot be a one sized fits all approach anymore.
When a remote, international company gets very large, it can be just about impossible to find a time where everyone can meet.
Even in time-sensitive situations, I prefer asynchronous communication methods like email and voice memos. That way everyone can catch up as soon as they get a chance, no matter what time-zone they're in.
So, suppose a manager profiles an employee using metrics software, and subjectively concludes from the outcome that the employee is not performing well. What are they going to do subsequently? Admit the deed of profiling and ask the employee to level up? How will the employee feel, motivated?
Ok so just to be clear is there a reason these guys aren't writing articles where s/manager/leader? Yet another manager bashing article while leadership is sublime! How about "leaders, give your managers space to do their effing jobs without having to constantlu sell your Kool aid?"
Years later, a very similar experience happened with a different manager. But they handled it very differently. They called a meeting, led us through understanding the situation and us working out what the solution should be. They got our feedback on how long we thought it would take and then said they'd come by for an update in half that time. And that was it. I was so impressed.