What does my engineering manager do all day? | Hacker News Reader

What does my engineering manager do all day?

parkjoon.medium.com

187 pointsmooreds246 comments

I’ve been in those meetings, we’ve all been with different responsibility levels, we know that people are slacking at least 80% of the time and that most of those meetings could be efficiently replaced by emails.

So if your work is 90% meetings I am sorry but you have a bullshit job, nothing more, nothing less.

I hate how meeting people need to meet over everything. You start typing on slack something simply and they have to throw a zoom meeting at you. Seems overly hostile.

Ah yes, damn those people who would rather have a 5 minute Zoom call instead of getting carpal tunnel bike shedding over Slack. I bet they’re the same people that talk in the cafeteria instead of texting across the table.

I get that it’s fun to bash excessive meetings, but trying to hash out a complex topic by lobbing Slack message grenades back and forth over the wall is often the worst idea.

I prefer typing over slack because it’s easier to be rigorous and concise in exposition in writing than it is when speaking (you can’t erase what you already said without breaking a train of thought). Writing can be consumed at the consumer’s pace rather than the producer’s. Additionally, writing can be searched later, so there’s no fog of memory.

But, typing can be a bottleneck for people I suppose, both in speed and pain as you say. I wonder if there’s a WPM inflection point for chat vs call preference.

I value zoom for 1 to 1 or small group interactions. It's very suited for work on something specific where you need live interaction and where a shared screen tells more than a 1000 words.

For general coordination, a written medium is better, especially since one can take the time to be precise, and the content is searchable later as you say.

I mean you can always have the best of both worlds. Do the zoom meeting by all means but never forget to send a meeting summary to all parties with an agreed statement about the objectives and assignments.

This way there are no ambiguities and no one can evade responsibility. This avoids a he-said vs she-said situation as well.

Until you have disagreement on the summary because it turns out not everyone came to the same understanding verbally - they erroneously thought they did. I’ve come to prefer having as much as possible of the common, written reference come before, not after the meeting - with time to consume and digest prior.

A meeting has value beyond just the words themselves, which is where writing meets its limit.

> Until you have disagreement on the summary because it turns out not everyone came to the same understanding verbally

This itself is a victory. This means the subject needs more discussion or is too complex for a 5 minute meeting.

I prefer to spend 2 hours to make a subject clear to all parties rather than developing under a false interpretation and having to fix the issue through a grueling 5 day back and forth.

I think writing before and after the meeting is both desirable. Before to specify the object of the meeting and to limit its scope, afterwards to conclude and archive the decisions made.

Or that if you wrote it in the first place you wouldn't have agreed?

Sure, it really depends on the subject. I have a slight preference for the quick meeting (5 minutes) -with a followup email- rather than a long come and go in slack.

Incapable of synthesising ideas. Decision by exhaustion.

As you see at this person's calendar, they all take 30 minutes at least.

You inserted detail here not present originally. I know anything said in a zoom worth remembering will be written down. Why not save some steps?

Agreed, I switched to call this morning and quickly realised I was banging my head against a brick wall, I gave up the fight we were having (the guy didn't understand something very basic) and switched to doing some actual work. This would have gone on for hours in a text chat. face to face can be much quicker at times.

> Seems overly hostile.

I find that invasive too. For me, this often turns a 5 minute interaction that fits in the middle of a task into a 30 minute interaction with the same outcome, but with a huge interruption of my workflow, which may mean that I lost an hour or more.

set some boundaries. say "no".

Why would someone use Zoom all of a sudden when they're already using a calling app (slack). I don't get this.

Slack video meetings aren't as mature yet as Meet (for instance), in my experience.

Habit. It's quite easy for me to type, "/zoom" and click a button. I'm used to Zoom. I rarely use Slack's audio/video features.

I don't mind if it's something that does actually require more discussion.

However, pre-slack there used to be a certain type that would never read e-mail, but instead would call 5 seconds after the e-mail and want to be walked through the e-mail rather than read it themselves. Also had one time about 15 years ago where someone literally tried to break through a secure door to ask about an e-mail I had sent 3 minutes ago. I was on VPN @ home, and they got pissed off thinking I was just ignoring the call to my desk.

Thank you! The overwhelming feeling I got when reading this was "wow, this person really does virtually nothing!". I went in expecting a challenge to my view that mid-level managers are mostly worthless, but instead that view was reinforced.

this was exactly what i was thinkink..

>I’ve been in those meetings, we’ve all been with different responsibility levels, we know that people are slacking at least 80% of the time

meetings are so much fun that of course people go to them all day long in an effort to slack off.

I get the sarcasm but this is not about fun, this is about faking work in a convincing way by doing the minimum amount.

I used to sip coffee and daydream during most meetings when I was a junior dev.

Developers doesn't hate meetings, like lets say they had a meeting where they discuss the latest frameworks or technologies, they'd love it! The thing people don't like about meetings is the power dynamics, you can't speak freely with your manager in the room. Also if you have deadlines and people will get angry if you don't do the work and the meeting is wasting your time then you will feel frustrated since you know you will get shit for this that wasn't your fault.

But what happens once developers gets the power? Just look at architects, scheduling meetings where he talks about the latest tech blogs he read. Or managers, scheduling meetings where they talk about the latest linkedin blog he read. Or even CEO who schedules a company all-hands where he talks about the latest team-building blog he read on HBR. In those cases meetings aren't work, it is you forcing people you have power over to listen to your hobbies and thoughts. Of course the participants wont like it.

>like lets say they had a meeting where they discuss the latest frameworks or technologies, they'd love it!

I hate those meetings.

> The thing people don't like about meetings is the power dynamics, you can't speak freely with your manager in the room

Why not? There may be a toxic management culture in some places, but in a well functioning organisation the manager wants people to challenge things.

I kind of agree.

In my last role I ended up in a fantastic place where the teams under me could operate fairly autonomously and were happy. My only recurring meetings were:

- 1-1s fortnightly and only with senior members

- My 1-1 with my boss, again fortnightly

- Senior leadership team, once a week

I kept 1-1s to 30mins unless someone had an important issue, in which case I was completely flexible.

Most of my time went on planning/strategy, customer research, and acting as an ad-hoc coach for the teams beneath me.

The key things I found were:

- many meetings can be replaced by an update email

- decisions often work better through docs + feedback than big meetings

- you don't need frequent contact with the team if the goals and constraints are communicated very clearly

I realise none of this is groundbreaking. But it seems quite rare, and also hard to achieve in practice.

Are you still there or did you move? If you did move, what were the reasons? I'm honestly curious from career choices point of view.

Moved to start my own company. So not to do with the culture.

> - many meetings can be replaced by an update email

Highlights from the feed(s); GitLab has the better activity view IMHO but I haven't tried the new GitHub Issues beta yet.

3 questions from 5 minute Stand-Up Meetings (because everyone's actually standing there trying to leave) for Digital Stand Up Meetings: Since, Before, Obstacles:

  ## 2021-09-28
  ### @teammembername
  #### Since
  #### Before
  #### Obstacles

Since: What have you done since last reporting back? Before: What do you plan to do before our next meeting? Obstacles: What needs which other team resources in order to solve the obstacles?

You can do cool video backgrounds for any video conferencing app with pipewire.

You can ask team members to prep a .txt with their 3 questions and drop it in the chat such that the team can reply to individual #fragments of your brief status report / continued employment justification argument

> - decisions often work better through docs + feedback than big meetings

SO, ah, asynchronous communication doesn't require transcripting for the "Leader Assistant" that does the Mando quarterly minutes from the team chat logs, at least

6 Patterns of Collaboration: GRCOEB: Generate, Reduce, Clarify, Organize, Evaluate, Build Consensus [Six Patterns]; voting on specific Issues, and ideally Chat - [x] lineitems, and https://schema.org/SocialMediaPosting with emoji reactions

[Six Patterns]: http://wrdrd.github.io/docs/consulting/team-building#six-pat... , Text Templates, Collaboration Checklist: Weighted Criteria, Ranked-choice Voting.

Docs and posts with URLs and in-text pull-quotes do better than another list of citations at the end.

> - you don't need frequent contact with the team if the goals and constraints are communicated very clearly

Metrics: OKRs, KPIs, #GlobalGoals Goals Targets and Indicators

Tools / Methods; Data / Information / Knowledge / Experience / Wisdom:

- Issues: Title, - [ ] Description, Labels, Assignee, - [ ] Comments, Emoji Reactions;

- Pull Requests, - [ ] [Optional] [Formal] Reviews, Labels & "Codelabels", label:SkipPreflight, CI Build Logs, and Signed Deployed Documented Applications; code talks, the tests win again, docs sell

- Find and Choose - with Consensus - a sufficiently mature Component that already testably does: unified Email notifications (with inbound replies,) and notifications on each and every Chat API and the web standard thing finally, thanks: W3C Web Notifications.

- Contribute Tests for [open source] Components.

- [ ] Create a workflow document with URLs and Text Templates

- [ ] Create a daily running document with my 3 questions and headings and indented markdown checkbox lists; possibly also with todotxt/todo.txt / TaskWarrior & BugWarrior -style lineitem markup.

What does an engineering manager do all day?

A polite answer would be, continuously reevaluate the tests of the product and probably also the business model if anyone knew what they were up to in there

> - many meetings can be replaced by an update email

Project Manager checking in here. I'm one of the originators of all these meetings. Whenever someone complains that this meeting could be replaced by an E-mail, my response is: "But, do you actually read your E-mail?" If they are honest, the answer is often "NO". I'd love to reduce our meeting load at work, but Person A needs a decision from Person B and Person C would like updates from Team X, and none of these people use their goddamn E-mail! So, sadly, it's off to another meeting room...

To be fair, a Slack or Teams thread is also a good way to obtain consensus on decisions.

>So if your work is 90% meetings I am sorry but you have a bullshit job, nothing more, nothing less.

Do CEOs have a bullshit job?

I you have meetings outside of the company to raise money or win contracts, this is real work.

If you have meetings with seniors to make strategic decisions this is real work.

If you are recruiting people, again this is real work.

I do think that CEOs have very few incentives to waste time, contrary to middle-management.

> So if your work is 90% meetings I am sorry but you have a bullshit job, nothing more, nothing less.

It's not a personal failing, though. The modern world necessitates bullshit and inevitably people will fall into those roles out of either advancement or utility.

In noticing that percentage of meetings is a measure of bullshit, we have to be honest and question how roles that require fewer meetings, such as engineering roles, can be bullshit. I don't think such people think about this enough because the bullshit is masked by more measurable levels of "productivity".

To be honest, at least 80% of the work that I've done as a software engineer did nothing to improve the product or improve the world. Most of it is caused by a lack of inertia-control which creates "technical debt" (aka shitty code) that makes even the simplest of changes into huge undertakings. But there's not enough time to make anything right because we need to get this other thing done by this deadline. In other cases where that isn't a problem, what I'm being asked to do may not be particularly valuable to the user/customer.

As a web developer, the problem is further exacerbated by the perceived need for tools that weren't needed for nearly the same job not so long ago. We've turned JavaScript into Java because the field believes that every webpage should be capable of everything Google accomplishes with their products. We can't see the forest for the trees; the vast majority of internet users don't care about page reloads. In fact, I would be much happier if my bank website, for example, ditched all of the JavaScript and assets that slow down the page and went with simple HTML forms. All of these doo-dads, if you will, are just extra bullshit that costs the world millions, perhaps billions, and for what?

Management, in my eyes, isn't in so much of a different position than anyone else. Meetings are their form of spending time fiddling with build toolchains and debuggers.

I think some managers would think twice if they saw the cost of meetings.

I mean (meeting duration + interruption duration) * hourly wage of everyone involved.

Even a so-called five minutes stand-up easily cost more than a coffee machine.

I've always been perplexed by tech's love of managers despite widespread complaints about them.

The people that are tech leads already do much of what is in these meetings. Whether it's team/product alignment or the one on one's, I don't see much happening here that isn't already covered by a leader on the team. The curious thing is that, often, the tech lead isn't working side by side with a manager -- they work for that manager.

I'll admit, I'm biased. I've never had very good managers in tech and most of them sound fairly clueless to me. When I have met good managers they were usually either people that by their very nature stayed out of my business and let me run the team as I see fit (within some acceptable bounds) or people who were very senior engineers and transitioned into management and let me run the team as I see fit (within some acceptable bounds) while being able to personally identify with why this Root Cause Analysis is totally useless.

Could you really just not have managers in an org that reached a certain size? Past a certain point hierarchies and power structures are going to form, and an explicit management structure is way to make them clear and explicit.

I think in a lot of ways managers are just the glue that holds orgs together. Nobody at all might really want the glue a whole lot, but I'm not sure what not having glue would look like.

I think managers can be useful, but I am starting to think that maybe the issue is that managers don't have to share power with someone who has technical chops.

Line managers should definitely have technical chops.

I've rarely had managers that did not have technical chops.

Did they know the ins and outs of fashion in the latest JavaScript frameworks? Not always. Were they sometimes rusty remembering the method signature of standard library functions? Yeah.

But they typically had deep knowledge and experience with architecting systems, maintaining those systems, making important strategic tradeoffs, planning and estimation, reviewing code, and interfacing with the business.

Having a manager with these skills is invaluable for a productive team.

Most technical managers (like myself) come from a development background. I personally have a very strong fear of not having the technical chops to demand specific behaviours & actions; of being illegitimate. My group's staff developer was very close to taking the job that I now have, but decided he wanted to be a technical leader. I do all the stuff that gives him the time to do that.

Sounds like your team is lucky to have you. I know not all teams are in a good spot in this regard. As you mentioned, not all engineers want to end up in your role. Good managers create the conditions necessary for architect/staff engineer roles, and engineer career growth in general, in addition to achieving business goals.

Yes, see here: https://hbr.org/2011/12/first-lets-fire-all-the-managers

The experience at Morning Star (the company referred to in that link) is oft-quoted, but rarely replicated.

Neat! Never knew of this company.

Thanks for posting this.

I’ve read numerous of times that a flat organization will work in the early years of a company. But in the end it has to evolve into something more hierarchical.

Reading your first sentence, I was prepared to answer with "well you must have never had a truly great manager who cared about you as a person and helped you grow", but you revealed that later.

It's one of those Pareto principle things. I had 4 terrible managers, but my 5th one helped me grow in ways I wouldn't have alone, and taught me lessons I still carry today. There's no measuring an effective manager.

The ones that do it because it's a job or because they were Peter principled into the role eventually work themselves out of the role, thankfully (or at least out of the company).

Could you describe some of these lessons and events in detail made them so great?

> I had 4 terrible managers

I've fallen back in to "I've had bad managers" but do wonder how often I was the "bad managee". I know it was true in a couple of cases that were obvious to me. And... I can usually point the finger to "bad manager" when multiple folks in a group all had similar (bad) experiences. In other cases, it's not always so clear.

So as an Engineering Manager I'm msot definitely bias, though sometimes even I question my own existence, but I have 7 leads who do a lot of this BUT (a) I do similar things for them, (b) I really help them transition from the direct doers to facilitators that even I once was, (c) I take on the higher-level concerns; ex: your leads might help you by doing a pairing interview but they certainly shouldn't be filtering the 5-10 people you interview before they get involved, or they may run a stand-up or planning session but they shouldn't be making the final call around what your flavour of dev processes look like.

> help them transition from the direct doers to facilitators

But why is this a desirable outcome? It sounds like failure to me. Or at least like retirement.

For an analogy with sports: Good athletes do not retire as early as possible to become coachs. They keep winning medals for as long as they can. When they cannot win anymore, they retire and become "facilitators" (after a significant pay downgrade).

> But why is this a desirable outcome? It sounds like failure to me.

"Why is this desirable?" is the wrong question to ask, IMO. It is not always desirable, as your analogy shows.But the higher value tasks in many business are often not achievable by a single person, like in individual sports. In those cases, it is very valuable to have a good facilitator, and no, they don't take pay cuts doing so.

The analogy does not work.

Athletes are seen perform, but not ICs at a company: nobody pays tickets to see John Smith, the TensorFlow master, at work at Google (and when they pay, like for "webinars", is to become like them, not to enjoy seeing them at work).

ICs and managers can move from domain A to domain Z, but you don't see someone playing (or coaching) football for 4 years and then when the stock is vested or whatever equivalent event indicating it is more profitable to move on, start coaching volleyball.

Also, managers, apart from some companies that have the double ladder--IC and leadership--, managers are paid more than ICs. That does not happen in sports, where the top players are certainly paid more than coaches.

The problem with this analogy is that athletes have particular physical attributes that cannot be taught or learnt, and their possession of those attributes and their ability to use them (while they're still young) is what gives them their value. The bell curve of athletic ability is a different one to that of coaching ability and there isn't a meta-bell curve that joins the two together.

Software engineering and software engineering management are both brain work that require a similar level of intelligence. It's the same bell curve if you zoom out a bit.

Also in some sports the coaches make more than the athletes, and in others the athletes make more than the coaches. You can't generalise.

Other people have answered this, but I think they've missed something. I'm not a manager because I'm a great engineer. I'm a good manager because I'm a decent engineer who has the skills necessary to be a good manager. There are plenty of engineers who should never be managers. In my opinion there are plenty of good managers who will never get to be managers because they aren't good enough engineers.

It's not that the most successful quarterback gets to become the coach. It's the running back who has insight into the strategy, the long term goals adn inter-personal dyanmics that ends up as a good manager.

I don't care what my manager does all day, but I fully expect them to own the situation when things go downhill, to take responsibility and to make sure that the team is shielded from pressures from outside.

I feel like this is often the most obvious sign of a good manager. There’s a lot of variance in other areas, but if you’re on the hunt for a good manager to report to, look for the one that passes credit to their people and holds blame for themselves.

If your manager shields you too well, you may not know when potentially cataclysmic organizational changes are coming. Especially if this is paired with your manager falling out of favor with their manager.

It is your manager’s job to know when to shield you and when to bring you up to speed. A good manager never lets you get caught off-guard, because that is how you quickly lose great engineers.

I agree that having a good manager makes all the difference, but have never yet figured out a way to get assigned only to good managers.

Yeah, the only sure way is to "move jobs by manager." This is why employees will often follow good managers from one company to another.

A good manager manages up and manages down. What you're describing is someone who manages down but not up.

> A good manager manages up and manages down. What you're describing is someone who manages down but not up.

A good employee manages up to the extent the organization they are involved in permits, a manager is just an employee whose duties inide managing down.

But the truth of heirarchical organizations is that while managing down is universally expected (and is usually just called “managing”), managing “up” is...not (and, often, barely even tolerated), even among organizations where citing it as a way of victim-blaming is common.

>The people that are tech leads already do much of what is in these meetings. Whether it's team/product alignment or the one on one's, I don't see much happening here that isn't already covered by a leader on the team. The curious thing is that, often, the tech lead isn't working side by side with a manager -- they work for that manager.

This is exactly right! A "Tech Lead" (i don't care about the label as much as the person's responsibilities) IS a "Manager" in any "Tech Company".

In a "Tech Company" there should be as few levels as possible between an Engineer doing the work and the CTO/CEO. The CTO/CEO should always have a "Open Door Policy" in actual spirit and deeds. This in turn implies that they are knowledgeable in Business/Technological/Communications domain (in other words; "earning their pay"). This is the only way to ensure that crucial information is not lost as it is compressed and sent up the hierarchy and the company/business objectives are very clear as it is sent down the hierarchy.

In my entire career i have had only two Managers (that i can recall) who i had judged competent and respected. All the others were mere "paper pushers" who i had just tolerated/managed to get my work done.

It just doesn't have to be this way if people realized that the need for "Standardized" Models of Management (ala Peter Drucker) does not exist for most "Tech Companies" below a certain size and where it is needed, has to be tailored to the Domain i.e. no "Cookie-Cutter" Management Techniques.

A lot of this seems like things that could be cut. 1.5h every day on post-mortem meetings stands out as the obvious time sink – does the organisation really have that many production issues to debrief every day? Also a fair amount of ceremony, planning and pro-bono. Webinar for distributed ledgers in enterprise??

The things that truly matter – 1:1s, own team stand-ups... - only take about 8 hours per week.

Maybe a naive question but do you really need 1:1s every week? At my first startup we did them like every 2 months and it was a treat. If you needed something in between you just asked for it. At my second company even once every two weeks seemed sort of ridiculous, at first it was a welcome excuse to not work for an hour and eventually they just got boring and took me away from things I liked working on.

I think somebody's going to say "you or your manager were failing to extract what you could from those meetings, that's why they seemed useless," or something like that. But I really just think they weren't necessary to do that often.

I don't think 1:1s have to be weekly as a hard rule, but it's a good starting point.

If bi-weekly works for you and your reports, do that. However I would argue that 1:1 is the one area you shouldn't try to minimise - as a manager, spending time coaching and developing your reports is a large part of your job. The time you spend on them should be highly valuable. If you or your reports think 1:1s are a waste of time, something is going wrong and you need to change how you do that.

If we're talking coaching then having a weekly learning session would be good. It would be even better to share it with more people and have a mini lesson. I wouldn't call it 1:1, even if I did similar things because the company we worked for mandated 1:1s religiously and we were out of things to talk about.

If a 1:1 is just a way to surface problems with the employee and plan skills progression, weekly is way too much. Even monthly, there is hardly something new going on, in my experience.

I think this happens because of deep issues with how companies operate, which is a frustrating and painful issue to deal with upper management.

The problem with skill progressions in most companies I've seen is that they're something meant to retain engineers, while what engineers are hired for is to build a product. Once you're not a junior engineer anymore, you have probably seen all the technical tasks you can do. What are you going to learn next? Functional programming? Cool, it will come in handy to fix pixels on buttons.

Some companies are better than others. From what I've seen, it's worse where skills progressions are basically irrelevant for promotions and raises and the only factors that matter are product related.

It's hard for an engineer to get the time out of their busy schedules. I've seen two types of engineers. Those who don't care about their career and spend as much company time learning something to show off at their next interview and those who care so much about the product that they don't have time. I'm sure just the notion of these factors being in play influence the way mentees portray themselves to mentors. If you don't trust your mentor and you know there is no punishment or reward for not learning whatever skill is important to learn, you'll just say you didn't have time to learn it and focus on the product.

Engineers are always busy but IME their schedules are typically clearer than managers; be careful!

I promote explicitly scheduled focus time (ex: 4 hours twice a week of "GSD"). Also a good manager will know when they really don't need to probe on current health & status and happily call a meeting early. I wish more meetings ended with "we're done 30 minutes early!"

> However I would argue that 1:1 is the one area you shouldn't try to minimise

It should also be a scheduling priority. A 1:1 may not seem super important, but it's often the only time an employee will have to talk with their boss. Repeatedly cancelling it (especially last-minute) is an indicator that your employees are not a priority and that can destroy trust and kill morale.

100% agree. If you are a manager, dont cancel 1:1s unless it is a legit emergency. if someone schedules over it, tell them you cant do it because you have a 1:1 and you dont reschedule those. These are the most important meetings on a managers calendar. any org that treats them differently will not be as successful and employees will not feel as supported, as they could be.

I rarely get anything from my 1:1 which is one hour every two weeks.

Most reasons for the call could be replaced just by emailing agenda items to me, and allowing me to respond with any issues, then based on that and what is on the agenda we could decide to have a call but most of the time we wouldn't. And if we did to get past something in particular, it would be like 10 minutes not 60.

My manager is not technical though and can't really coach me about much. It seems strange that 1:1 time would be used to coach and develop technical staff -- what do you mean by this exactly? Some kind of training?

I think in general you'll get out what you put in. 1:1 should be your time, your agenda. If it's a status meeting it's being done wrong. If you aren't setting the agenda and bringing things to talk about, goals to discuss, questions, etc. I think you are missing out. If your manager isn't pushing you to bring those things (many don't, but should) take it into your own hands. Shows that you own your development plan, and that is always a plus.

Manager is very open and always asks me to bring any issue I have, asks me about it on the calls etc. I do bring things to talk about when I have them. Which is not very often because most things I have can be done far quicker and more precisely with a written record I can refer back to on slack.

I am not the one who schedules these 1:1 meetings though. Manager is. Cardinal rule of meetings should be only schedule them if you have an achievable goal for them which is not better achieved with email or IM. And the goal can't be "talk about X".

I don't have a strong desire to push back against it. My schedule is not one that is full of meetings, and most of the ones I do have are interesting and enjoyable technical ones. And the manager is a nice person who means well and probably gets pressure from above to schedule them. And blabbering on for 30 minutes per week isn't terrible. It's just not at all productive or useful for me to be spending that long on a 1:1 as far as I can see.

Just a thought, but maybe your manager does have a goal for these meetings? Maybe checking on your wellbeing, keeping an eye on your engagement etc? I can get a lot from a casual chat with someone. Just because you don't personally benefit from a meeting doesn't mean someone else doesn't.

For my team members, one of my reports started an agenda doc with the things they wanted to talk about allowing us to stay focused, I add things to the doc too and it works really well. When we have nothing on the agenda, we don't have the one on one. It worked so well, I now do it with all of my reports (and the peers and management types that I report to).

He generally puts together an agenda and does ask about how I'm doing, always asks whether I have any problems or want to talk about anything.

Don't get me wrong at all, he's a lovely person and means well. The 1:1 does not irritate me as such, my week is not loaded up with meetings. If that was different, I would gently try to change things. I also think he is getting pressure from above to meet various metrics like 1:1 time.

I just don't get much out of it that couldn't be replaced by a couple of minute slack or email once in a while when things come up. And I accept it might work well for others.

It’s hard to give concrete recommendations because everybody’s company/role/background is different, but two things that really stand out to me:

1. As parallel posters have pointed out, yea, if your 1:1 is spent reporting task status / receiving task direction, woof, that sucks. 1:1s are (as you’ve found) a horrible medium for that, in that they burn your time, your manager’s time, and also are a high-delay channel for that information. In my experience, a good 1:1 is meta-level feedback. I spend a lot of my 1:1s discussing what’s likely/unlikely to come over the horizon in the next 3/6/9 months, both in terms of projects and my personal growth.

2. There are plenty of coachable skills that are not technical, and the average engineer, in my experience, tends to climb the IC ladder via tech skills and then plateau because their non-tech skills are an undeveloped muscle. This is how tech ends up with so many very skilled programmers that have to be hidden in a dark corner because when they talk to another team they accidentally piss everybody off or they get pissed off. As a mundane example of this: I have worked with several developers over the years that write awesome code, but if somebody from another team pinged them and said “hey, can you work on $project”, would just say “sure” or “go pound sand” based on their personal mood w/o any concept of how to prioritize that ask. Time management and prioritization are amazingly important non-technical skills that an effective manager can help coach.

No it's not reporting task status. Some times a high priority issue that he was asked about in some other meeting by a project manager for example that I haven't made good progress on, he'll just mention it. Or just a friendly "how is <this> project going?" how is "<that> interesting feature you are working on going?" chat. Which is fine it but not necessary to be in a 1:1.

I'm not one to believe I can't be taught anything new or training has no place (technical or non-technical), but I don't really see how a 1:1 is an appropriate place for it. Shouldn't it be offered as some training, perhaps even in a group setting to maximize use of time (which is how we organize informal training sessions between the team on topics one might know a lot about), perhaps even offered as a formal training course run or paid for by the organization?

So I don't see what the 1:1 itself is achieving in any of this.

Does your organization not offer internal or external group training opportunities? They’re great, but I’m not sure why you’re presenting them as mutually exclusive with individual coaching.

> Does your organization not offer internal or external group training opportunities?

It does.

> They’re great, but I’m not sure why you’re presenting them as mutually exclusive with individual coaching.

I'm not, it just sounded to me like time management and prioritization were skills better taught in training courses or group sessions.

I'm still not clear on what this coaching really looks like, or why it is appropriate for a regular 1:1 call.

Coaching generally differs from training in that it’s drawn from actual ongoing circumstance. So you can go to a group training on how to manage your time, where somebody teaches you techniques for prioritizing requests. But a good manager can notice if you’re getting burned by bad prioritization and spend time coaching you based on the specific circumstances you’re hitting.

Well I'm a bit skeptical whether they would or whether it would be better to suggest actual structured courses for me. But either way I don't see how that justifies regular 1:1 when I don't get said coaching. Send a message mentioning their thoughts and ask if I'd like some help with it, and if they think they are the one to give it and other team members would not benefit, great organize a regular call for a few months or do it over slack or whatever.

As I said, I have no problem with a call for a said purpose with an achievable goal. "1:1" is not a goal though, nor is "talk about <x>".

Yes, kind of like training, except it doesn't have a set agenda like a training session would, but is instead rooted in the circumstances of what's going on at that time. Any questions your report has? Anything they are struggling with? Any feedback you have for them? What are they working on longer term and how that's going?

I've never managed senior people, but for junior to mid engineers there is plenty to talk about most weeks. Occasionally there isn't, in which case it's just a 10 min checkin, but the weekly opportunity to raise anything is quite important.

1:1s that are status updates or things that could be resolved over email are definitely an anti-pattern.

An hour seems like too much, but scheduling 30 mins, and leaving the subsequent 30 mins free in case something significant comes up during it, feels right.

Trust erodes surprisingly fast, so even if there’s not a whole lot of substance to discuss, a consistent time to shoot the shit or whatever, is worth the time out of your week. I’d be very worried if I joined a place and there weren’t weekly 1-1s with my manager.

It does depend on company stage though, if it’s very early and the team is small enough to not need these supporting tools, you can probably get away with less frequent 1-1s.

>> but scheduling 30 mins, and leaving the subsequent 30 mins free in case something significant comes up during it, feels right.

Yes! this is an obvious (in hindsight) but pro move. You never want to cut off a direct report in the middle of an important, emotional discussion because "Hey, sorry got another meeting, peace out!"

To the GP: 2 months is too long between real 1:1s, this sounds like more of a career direction discussion or a skip-level with your boss's boss. Or if you're in a really small team/org you might be discussing 1:1 material far more frequently/casually without realizing it. I STILL like explicit, strict 1:1 schedules though because it's time owned by the IC who guides the conversation while the manager listens and figures out how they are going to solve the questions presented. I do very green juniors, people on performance improvement plans and those I'm mentoring for leadership positions every week; everyone else on 2-week schedules. Longer than that makes me nervous, out-of-touch and it's really hard to build personal relationships.

I agree. I had a manager who was really hard to pin down for one on ones. Whenever I asked for performance feedback he said I was fine but surprised me with a poor performance score at the end of the quarter and a bunch of improvement points. This is a great way to demotivate an employee, especially when performance scores are tied to bonuses etc. One on ones are a GREAT time to let employees know if they slipped up or you noticed something they could do better in future.

I personally don't understand 1on1s. I never had them in the teams that I managed and I never wanted to implemented them. They seem like such a huge wast of time. We do have some global talks about raises and global performance every 6 months, but whenever there is an issue or there is something to discuss, we do it as soon as possible. For me they seem like some sort of ritual to show that you are connected to the team or that you care, but I think you show that by actually being there for the team all the time when they need it. Even when we have our 6 months meetings, most of my colleagues just say that we always talk, there nothing much to say extra. The other excuse is also that the team is too big and you need 1on1s to you can have a chat with everyone. If your team is too big, then you might have bigger issues than that, or you just need to delegate so that other people that work closely together take over some of those responsibilities.

worked in a place that did these... I think monthly. for "problems" it was a time to review/discuss some issues that came up recently but that may not have been important enough at the time to interrupt the other party (interrupting a big concerted 'push to live' effort was usually not a good idea). And, it gave you time to reflect on some of those issues, perhaps see patterns, and discuss those.

It was also an actual time that someone carved out specifically for the purposes of talking/listening, instead of things being interruptions. "My door is always open" is fine, except... they're still doing other stuff, and whenever you raise an issue to someone, it will almost certainly be interrupting something else.

Lastly, it was a time/place where you could explore some other ideas that weren't necessarily in any pipeline or backlog.

"you show that by actually being there for the team all the time when they need it". Someone can't simply always be there all the time whenever someone needs it. The urgency/importance level isn't always the same on both sides, and someone is being interrupted. I'm not meaning "save every single issue for a planned meeting 2 weeks from now" but ... scheduled time that is intended specifically for discussion purposes has utility on its own.

My first couple of jobs, the only time you'd ever talk to "a manager" of any sort was when you were in some sort of trouble. If/when you'd get asked to go speak to a manager... it was anxiety inducing, whether it was intended to be or not.

I do bi-weekly 1:1s with my people. Rule 1 of people management: everyone is different.

Some folks need 20 minutes, some want the whole hour. Some have bullet points to discuss, some just need a chat. When the pandemic hit the 1:1 became a place for some people to have vital social interaction. There's others who want to show off their work and receive guidance on next steps.

Reading through all these comments it seems like a lot of people have robotic managers who don't care about people at all. A good manager uses a 1:1 for understanding their needs as an employee and building trust.

I want to ensure my employees are productive, and the 1:1 is the best place to find out how.

In the late 90s/early 2000s, I worked for a fairly large ISP. Every customer-outage since the previous meeting was reviewed by senior management in the morning -- in the parlance, sev-0 and sev-1. This was scheduled for 60 minutes and usually ended early; occasionally ran late. A lot of them were 20 minutes.

Most of that calendar is pointless time wasting guff that benefits nobody.

Stand ups should last no more than 10 minutes and a middle manager has no place at them any more than occasionally.

Status updates should be slack messages or emails. Sync ups are just filler.

121s aren't necessary any more than monthly unless directly mentoring someone.

Daily post mortems tell you something is broken with your organisation that needs fixing at least one level of abstraction higher.

You could put every recurring meeting in that calendar in the bin and there'd be no loss to the business, probably a significant gain for having time to do things. This is a broken organisation.

Have you tried onboarding a new direct report fully remotely during a pandemic? A monthly 1:1 is not going to cut it.

Also, a manager has to be aware of what's happening in his team, so he can both advocate it upwards and remove blockers as they arise. "Doing things" by itself doesn't get you very far if the higher-ups never hear about it.

I think you and the GP are both right (and wrong). On-boarding via a monthly 1:1 is most definitely not going to work, but this should probably be a team responsibility anyways. As a manager I do pay closer attention during this period but the new hire's buddy is the contact point, our process & documentation is the guide and team leads and senior devs do all the pairing and presenting.

You're definitely right about the advocating and facilitating IMO; equivalent to a code smell is managers who do regular coding in their daily work. It's a great way to build empathy but it's not your job.

We switched daily standup to a slack channel and it works great. Everyone posts before 12 and discussion is handled in the threads. That's a lot of time reclaimed.

Careful. One of the valuable things a standup huddle enforces is that the team decides together what to do for the day, then heads off and spends the rest Of the day doing.

If you remove the time box and let decisionmaking drift into slack threads, you risk not making decisions and not doing.

Stand ups should be action oriented planning conversations, not passive status sharing. They need to end with decisions made.

In theory I agree, and what works for one team may not work for another (Scrum and Agile are just a starting point).

We do a decent amount of up-front planning before committing to work, so day-to-day there aren't a ton of directional decisions left to make. So what works for us are two questions:

- What are you working on? - What are your blockers?

> Stand ups should be action oriented planning conversations, not passive status sharing. They need to end with decisions made.

Yet most stand ups I’ve been a part of at big and small companies are nothing more than status updates. Unfortunately, I’d guess the “stand ups” that the manager is doing here are the same and thus why they take 30 minutes.

This is a classic trap that new managers fall into. It's not the number of meetings that you are judged by. It's how effective you are in execution and how well can you drive your team(s). The meetings are just a means to the end.

I've been in management for a long time now and have managed managers. Frankly, I would cut as much as I can and skip as much as possible _while_ being able to do my job - which is to drive results, quality and other team performance metrics.

I also manage, have plenty of 1:1s. Some things stand out to me. Some of these daily meetings happen far too often. Many of these meetings should not be weekly. I find a good rule of thumb is to only have weekly meetings if they serve the individual or team, but insist on meeting at least every other week for core contributors and stakeholders. This person could easily get ten hours a week to "do" things, but they wouldn't necessarily be consecutive, or easily applied to deep problems that a very senior IC could solve. This is the dilemma of the manager's schedule.

I try to optimize what time I have for solving problems that are valuable but not quite worth my teams' time to solve. Depending on demand, I may have more meetings to "pad" my week (i.e. discover and anticipate things my teams can effectively solve for), or even cancel less important meetings in favor for accelerating more timely business value.

The hallmark of a mature manager is knowing what meetings you can turn down, and what a justifiable alternative is to that meeting. It takes time to learn, and there's a lot of playing by ear. The author will get there.

One more thing to note: being a manager doesn't mean you shouldn't find time for yourself during your work day. It's a bummer to see the excited tone with which the author takes the rare lunch, and the firm but somewhat embarrassed tone of taking time during the work week for a doctor's appointment. Everyone's health and sanity is important. Managers must act as role models here to help their teams maintain a healthy work/life balance.

I can’t help but feel this whole thing is a read-between-the-lines satire. Maybe it’s the Michael Scott reference at the top.

It’s like the whole thing is an incognito script for “I was what all of you aspire to be (senior, respected, remunerated, creative) engineer. But then I went on a journey—-and without being the kind of obvious I could get in trouble for—-it really is the giant waste of time y’all think it is, and I really do get paid more than y’all to do it. Neener, neener, neener.”

You can read it in the exact tone of the Tech Lead. This way, you won't know if parts of it are really satire or not.

One thing I learned: do not do meetings for status updates. Those are emails. Meetings are for decisions.

that used to be the case for me, but since we all started working from home my manager started doing team meetings to try to get some of the discussion and help that happens incidentally in the office to have a time scheduled for it. So everyone talks about what they're doing and what difficulties they're having and I want to die as I waste time I could be working.

Your manager should encourage you to do this among your peers all the time. These are not meetings - with agenda, attendees, notes - these are just discussions among 2 or 3 people.

Do you ever help the people who are struggling with tips and suggestions?

all the time. but its usually more productive in smaller get togethers than in team meetings where everyone 'presents' their stuff. If I'm helping someone else my stuff doesn't matter at that moment.

I think you need to have open ended meetings or you will miss a lot of things. It doesn't need to be every day.

Fair. I would not call them meetings. They are 2, maybe 3 person “white boarding” sessions. They are problem solving and ideation things.

That, and also after a speculative discussion about what's going on and you find out haphazardly that the team is always waiting for something that should really just be automated, but you mightn't have learned that otherwise. Or after 3 different meetings you keep hearing the same name popup about something. Or something feels off and you find out your lead devs mom just died. Or you find out that they're re-writing some bit of architecture again and you can't fathom why you weren't told about it. Or that someone told you something in private that they might not tell you otherwise. Or you have someone demo the thing to you and it's just crap, way worse than the verbal assessment you were given etc..

there goes the scrum daily/weekly...

> Are you an engineer and think I’m wasting time?

Well, yea. You're a manager :)

> Which meetings would you cut?

Well, 30 min standups seem long for what I assume are two groups of 4 people. I'd probably shave off 5 minutes from those every so often until you get it to 15 minutes each. That will net you 2.5 hours a week.

pro-bono project during business hours: sounds silly if you're feeling stressed about time management.

"50 days of learning": continual learning is good idea, but I save this for after work hours, and probably you need to do the same. Especially since you're already doing multiple training sessions a week during the work day.

Going-away get together for team #2 member / virtual happy hour: shouldn't these be happening during "after work" hours?

Finally, 9-5 is banker's hours. A typical 40 hour work week would involve working from 8-12pm, an hour break for lunch, and then from 1pm-5p. If the daily operational review meeting is running from 7:30am-9am you're doing it wrong. It reads like you want credit for attending an early meeting but aren't accounting for the 8am-9am hour?

The reason we stand up in standup meetings is specifically to keep them short. Unless you're Russian Orthodox, you're likely to get impatient after standing up for more than five or ten minutes. The standup format exploits this impatience to create social pressure to keep the meeting to no more than about ten minutes by the simple ritual of remaining standing during the meeting.

From the 30-minute "standups" on the calendar I'm guessing this person is not actually standing up in them. Why is a manager involved in standup meetings at all, though? It seems like that could interfere with communication (as people censor themselves in order not to look bad or make others look bad) and create the potential for the manager to become involved in decisions that properly belong to the individual contributors.

"Standup" meetings where people don't stand up seem like the perfect emblem of Fake Agile: they've adopted our rhetoric, but not only don't they understand our practices, they don't even carry out the motions without understanding them; they just use the words.

(Let's see if some fake woke person who's never been to a Russian Orthodox church will castigate me for being "racist" this time because "Russian Orthodox" contains the word "Russian".)

To the flagged dead person who said, "Seems unlikely; you can't be racist against Russians," I actually did get smeared as "racist against Russians" only a week ago here on Character Assassination News by this other flagged dead person: https://news.ycombinator.com/item?id=28591684

The comic you linked also makes an excellent point about the nature of racism: https://satwcomic.com/white-on-white-hate-crime

Strong disagree on pushing personal development out of working hours. I always tell engineers I work with that they are 100% allowed to take working time and spend it learning skills they need to do their job. I don’t see why that doesn’t apply to managers too (though if it’s cross training prep for a career move that might take you away from the company I might question you doing it on company time).

FWIW, I do support some working hours personal development. My strategy: schedule an hour a week for on the clock training. This works out to about 50h (versus Target's 50d program). This hour is used for:

1. Mandatory "trainings" from HR 2. Reviewing recordings from internal training sessions 3. Attending live training sessions

Critically, these are the things I can only get from the company, and probably wouldn't do if not employed by them. OP is already doing more than 1h per week from what I can see of the schedule. They're also usually directly related to my job in some fashion.

Beyond that, I have also done some conferences, weeklong training sessions and 'work through a book on a tech I'm about to use for a work project' on about an annual basis.

The stuff I do outside work hours:

1. 3-5h/week of reading journal articles and books, on a Kindle at night. 2. About 1h/week of Anki, split between adding new cards based on #1, and daily reviews. 3. As they become available, conference presentation recordings. 4. Like, a lot of podcasts, usually at 1.5x-2x speed. This is basically how I avoid 'screen time' an hour before sleep and would be counterproductive to move to the workday =)

The author goes to far too many meetings.

A manager with multiple teams should and will likely have team leads for each team. This should be a person who mostly codes, does some leadership for team as well.

Manager shouldn't be micro managing being in daily scrums. Every other day is fine, alternating between teams. Why have a team lead at all?

Working lunches are terrible idea as well. Eat lunch, don't pretend like you're paying attention to the totally coincidental "anti-racism webinar" that just so happened to be on your calendar that day and totally isn't a way to tout HR policies and virtuousness.

Other meetings are quarterly meetings, so that's 1 day out of 90. Let's not pretend that's normal. Meetings with directors shouldn't be every day, EVER.

Not commeinting on this anymore, other than to say that I'm blown away by how wasteful big companies are. After having been at a startup that blew up and went public, and then recently starting a company and being one of 5 engineers, its just obvious that big companies eventually accumulate a whole class of people who do nothing but talk all the time. Those people LOVE hiring other talkers who then hire more talkers who hire scrum masters to make up for the engineering teams getting bombarded by the talkers and so the hell continues.

>Working lunches are terrible idea as well. Eat lunch, don't pretend like you're paying attention to the totally coincidental "anti-racism webinar" that just so happened to be on your calendar that day and totally isn't a way to tout HR policies and virtuousness.

In order to become senior leadership you need to signal you are a leader in corporate values, which means loudly talking about how engaged you are in whatever you think might be what the company wants to thinkits corporate values are. This is very easy when your company is kind enough to literally run a seminar about what its corproate values are.

So, a lot of talking and meeting. No doing. Color me unsurprised.

A good manager leads the team, finagles resources from upper tiers, un-sticks stuck processes, settles disputes, and then gets the hell out of the way. This manager sucks.

I mean... how would you do those things without talking and meeting?

Like, I get what you're saying, but I think it might be a little unproductive to consider all communication work as "not doing."

Let me be a little more specific, with one pretty obvious red flag. I see a lot of 1-on-1s, which is fine, but:

1. 30 minutes for a weekly 1 on 1 is pretty long, almost certainly a waste of time.

2. There's nothing after these 1 on 1s along the lines of "Planning time block for resources requested by Team Member B and E" or "Escalation call with Director B to handle sticking point M" or "Handling requirements conflict with product manager C over feature Q"

There are plenty of other issues here, but this is one clear issue. It sounds like this guy is is a highly paid sounding board. There's nothing in this schedule to suggest he's actually acting on information communicated during any of these meetings.

This! ^ If you’re getting tons of info from these meetings, but have no time to do anything to solve or correct those problems/issues, then you’ve created a false expectation and will let down your employees. I prefer the open door policy, ping me when you want to chat.

> ping me when you want to chat

Many people feel uncomfortable "bugging" higher-ups and "wasting your time" when you have "some many other things to worry about". I've discovered that most people will not initiate, and I need to be the one to reach out and make things happen.

Some of my biggest career snafu's could have been avoided if I just hadn't been so insistent on figuring it out on my own (or letting others do the same).

>30 minutes for a weekly 1 on 1 is pretty long, almost certainly a waste of time.

30 minutes for a weekly 1 on 1 is borderline too short, IMO. It depends on the person, but 1on1s are by far the most valuable and productive meetings that I have, and they often stretch longer than 30 minutes if possible.

>There's nothing after these 1 on 1s along the lines of "Planning time block for resources requested by Team Member B and E" or "Escalation call with Director B to handle sticking point M" or "Handling requirements conflict with product manager C over feature Q"

I count several meetings on their calendar that seem like exactly these things. Some of these things might even be covered during the 1 on 1s which you think are a waste of time.

>It sounds like this guy is is a highly paid sounding board.

Sounding boards are incredibly valuable and useful. We have people at my company that are literally just 40-hour-a-week sounding boards that probably haven't actually "done anything" in years, and they are some of the most critical people in the entire company.

Better processes and empowering your team.

If I'm in meeting that my report could have led/attended instead, that's a failure on my part.

What is a manager for if not to "front line" for their team and take the role of representing the team in meetings, then filtering and distilling that information down into action items? (I'm conflating a little with PM/PO roles, but not much.)

Obviously, discussions around technical decisions are something that engineer input should be required for. But I would argue that many, if not most, meetings that require "your team's" attendance are the ones that the manager should be fielding.

For one, a manager should have the broader context and relationships to better understand the information being presented/decisions being made in the meeting.

For two, time spent in that meeting is engineer time not spent doing the hands-on-keyboard work of software engineering.

If the meeting is for updating teams/disseminating information/resource planning/strategic planning, that is the purview of an engineering manager, and a bit of a waste of time for engineers to be doing/leading.

All of this is written very declaratively, but this is all, of course, my personal opinion; haven't been in software very long, so these are just my current thoughts.

At risk of sounding brash, you have a very traditional (old school) mentality on what management is.

The teams currently seeing the best results are the ones embedding their engineers in the discovery process so they can deeply understand the customer's problems and drive appropriate solutions. It's a bit "less efficient" upfront, but pays dividends during delivery when they can more appropriately model their code and make meaningful decisions without always relying on an outside party.

My role as a manager isn't telling my team how to solve problems. It's helping them identify the most meaningful problems and guiding them towards solutions against those problems. Over time this means that I actually spend less and less time "managing" them and more time listening.

Look at the complete schedule for the week. Almost their entire working hours are totally packed with meetings. Discussions and stand ups and status updates and briefings.

Let's assume all those meetings are productive and necessary and the results could not be achieved in much less time with emails or slack or fewer/shorter meetings. Then he is not putting enough time into each meeting. He has almost no time to prepare, to think about things, to go away and investigate issues with technology more deeply, to make plans, etc. It's just meeting after meeting and thinking by the seat of his pants.

If he is not in a position to seriously participate to the point of making productive input, and asking serious questions or making important decisions in meetings (which he clearly is not given the amount of time he can possibly put into them), then he does not need to be in them. He can skim through minutes to stay generally up to date about those things if he needs/wants.

I typically don't like to nitpick articles like this, but the author is specifically requesting it, so here goes.

1. From tech lead to "Senior Manager" is quite the jump. And to have multiple teams reporting to him as well?

2. I'm willing to be the senior director staff meeting is worthless 90% of the time.

3. 30 minutes for a standup is a long time unless there are... 35-40 people on each team.

4. The 15 minute ads meeting definitely could have been an email.

5. NPS surveys are a waste of time by themselves. Do you really need 2 hours to review them?

6. The App/platform boundary meeting could/should have probably been a document. Nobody will remember any specifics from the discussion within 48 hours.

7. Tuesday morning's standup presumably has more (~2x) the people but has the same time window, proof positive you're just wasting time the other standups.

8. Team 2 has two standups on Tuesday?

9. You have a scrum master.

10. Monthly status updates can/should be documents.

11. I would love to know what the "sync up" with an SEO consultant entails. That sounds terrible.

12. Virtual happy hour at 3pm?

13. 6.5 hours worth of "production post mortems" in a week. If you're spending 15% of your week discussing production problems, you have structural issues that need to be emergency-level for your team. Imagine having to take ten minutes out of every hour, every day, all week, for production problems.

Lots of stuff here that should be persistent documents/Wikis, emails, etc. rather than 30-90 minute meetings. But I don't think that's going to surprise anyone reading this. It seems like one or two meetings each day are actually needed, best case, not including the 1-on-1s (which I think are super important).

13: its curious how long production problems can be tolerated/ignored. My son just quit a job where he got moved to a group of 12 that fought a certain fire whenever it occurred (multiple times daily). Had been going on for years.

Action was initiated by an email on a certain account from the field. He immediately set up a notification for this email - something nobody else in the group had done. On the first notification he waited to see how long it took for the group to respond - almost an hour before anyone noticed. Then they went into action and hand-edited database entries to 'fix' the issue. And went back to reading comic books or whatever.

So he looked into the problem, found the root cause, submit a change order to be tested and deployed. And put 12 people out of a job his first week there.

He quit shortly after. It was not a culture he had any interest in learning any more about. It's astonishing how many of these 'Dilbert' groups exist inside large organizations.

This kinda feels like a answering "what does an engineer do all day" with "writes code". Like, ok sure, but that's not the the detail that's interesting.

What are you doing in these meetings, how do you help things go more smoothly, how would you describe your role in terms of the benefit you provide to the org, not just where your time goes.

I would either throw out almost all of these or quit my job immediately. My first CTO position was like this for a while and that never again.

So from the article;

> Are you an engineer and think I’m wasting time? Are you a manager and think I’m terrible at time management?

Yes, both. I am an engineering manager and you are doing both in my opinion.

7:30 meetings are horrifying to me

also, do 1-1s need to be weekly? what about biweekly? i only have a few direct reports and even then i feel weekly is too often

There is no one-size-fits-all answer here. It’s certainly fine to do them less often if you aren’t finding enough value in doing it weekly.

Most of these rules of thumb came about before tools like slack, which for better or worse, let you communicate more directly more frequently.

Many companies had instant messaging systems before regular 1 on 1 meetings. Email too.

A lot of the ideas and heuristics for one-on-ones came from “high output management” which was published in 1983.

I’ve been doing this tech stuff a long time. Companies I worked at started doing regular 1 on 1s before regular use of instant messaging. More importantly, the heuristics most use for 1 on 1s clearly came before use of instant messaging and digital collaboration tools.

I do biweekly. It's my job to keep myself appraised of what reports are working on and make sure they are unblocked. A 1:1 should be focused on long-term career goals and relationship building which can be done biweekly.

The obvious exceptions are new hires and very junior engineers who need more handholding while they ramp up.

Yeah this is what struck me, the fact that the 1:1s were so out of sync with the standups. Realistically this manager is probably making the same mistake most managers initially make, which is failing to manage up, and failing to take a role strategically shaping the company. Mostly, the 30 minutes "So what are all the things you've stored up to talk to me about" conversations aren't that valuable, the more free-form broader conversations are. Especially in covid.

> i only have a few direct reports and even then i feel weekly is too often

1-1s aren't about how _you_ feel. They're about your directs's feelings, and the relationship between the two of you.

1-1's are a cargo cult thing that someone decided was a Good Management Idea.

1-1s have been the basis of most human relationships for millions of years.

Real ones, though, which makes the checkbox corporate ones feel that much more fake, because we all know what the real thing is like.

Well, let's put it like this: the wrong reason for a manager to cut a 1:1 to biweekly is because they don't have enough time in their calendar to support their directs. A better reason would be because there isn't enough time between 1:1s to fill out the weekly meetings.

But the manager isn't the person who can easily make that judgement call. IMO, the correct person to judge that is the direct -- they can't just show up at their managers desk and demand a 30 minute meeting when something important shows up, whereas a manager can (and often does!)

1 on 1's did not use to be 'a thing', and we still got plenty done in those days, which were not that long ago.

Generally ideas like this seem to spread because it was part of some successful company and so it got written up and now a lot of people copy it because it's easy to copy and they think it will help make their own company successful.

As a result, the thing that actually occurs in a lot of places is a manager reading from a script that they've been trained on a little bit from someone else.

It does not feel useful to me.

Take it into your own hands. It's your time. Bring stuff to it. You won't always have an amazing manager, but you can get a lot out of it if you are proactive IMO.

Also, I think all managers should be asking what cadence and length of time their directs want for 1:1.

The least would be 30 minutes bi-weekly IMO.

The most would be 1 hour weekly.

Depends on the person, the projects, where they are in their career, etc.

If it were up to me, I would not bother with it.

I have 20 years of experience in this field, and a vital part of the job is communicating well with other people. I do not need someone's "Management Best Practices Checklist" in order to do that. And I do not think I'm exceptional: most of us got by just fine without all this.

People have differing opinions on this, so maybe learn to respect that. Seems like 20 years of experience has not done that.

These things are mostly not based on opinions where teams get to pick and choose, but some kind of received wisdom that checks a box on someone's list of Best Management Practices and everyone is forced to go through the script, like it or not.

That's why I'm suggesting you take control and turn the meeting into what you want it to be. It doesn't have to be a checklist but it sounds like you -have- to have this meeting at the company you are at. So instead of suffering through it, you can turn it into something beneficial for you. Ya know?

1:1's are a good way to make room for reports to voice concerns, uncertainties, mistakes, backlogs, blockers and unknowns with their manager. If you're the kind of person who feels completely comfortable promptly voicing that sort of thing in front of your team, then good for you, but you're in the minority. If your manager is excellent at consistenrtly handling that in a way that feels good to the whole team, then good for your manager, but they're in the minority.

For one example, a manager who has regular 1:1s with their reports probably won't be blindsided when they quit or miss a deadline.

That's the theory. In practice it's a checkbox with an accompanying script in a lot of places. Most places that I've been that worked well, you could send an email or walk over and ask a manager if you could schedule a bit of time to talk, if you needed something.

And if you're proactive, and don't feel like you're wasting your manager's time, again, good for you.

For reports who need a bit of a support in raising issues, this is an effective way to make that space. People new to lecturing are often taught to count out 30 seconds after asking questions, for a good reason: silence is awkward, and questions are the salve that even shy students will reluctantly reach for.

Not only I find the fakeness of 1:1s appalling, I also think that putting your weekly fix of human-relationship in a timebox is great to make me want to go through the meeting like a robot and avoid any other contact with the person outside of it.

I have a personal relationship with my manager, and we often chat outside of our 1:1s. We spend our 1:1s talking about work stuff, and end the meeting early if there isn't enough work stuff to talk about. When we're in the mood to chat person-to-person, that happens organically. When we need to talk business outside of the 1:1, that's more structured. I consider this distinction to be a healthy boundary; you may benefit from the same.

I second. To add, I work on a pretty busy team. It’s hard to catch time to just talk to my manager and having that time carved out every week to talk is valuable.

Also, there is stuff that needs to be discussed that shouldn’t be in an email or be discussed out in the open. You know, things meetings are actually good for.

> there is stuff that needs to be discussed that shouldn’t be in an email or be discussed out in the open

Maybe I'm reading this wrong, but it sounds unhealthy to have that much of that kind of stuff that you'd need to discuss it with no record of it on a regular basis.

I work on a team that’s tasked with a lot of future corporate development stuff. Lots of off-the-record planning involved.

My 1on1s are useful. It's like any other meeting. Have an agenda or cancel it. The people I work with are good about canceling meetings. The standing spot is nice to have.

It's a fair point that their input on the matter is more important than mine. I like to reiterate that 1-1s are for them, not me. But my feelings are not formed in a vacuum independent of theirs. Plus if it's about the relationship, both sides should have some input and opinion.

I think weekly is great! They don't have to go for the full time, but when I was an EM, it was the one time of the week where my attention was fully on the other person. That's great for the employee because they can bring things up and it's great for the EM because if there are any subtle issues (dissatisfaction) it's a chance to catch them early.

I have minions who want it to be every two weeks. I have minions who are happier if it is weekly. I have minions who do not want them regularly, but want the option on occasion.

These are all simultaneously fine. When I miss one with a weekly regular, nobody frets. When I miss one with a biweekly, I make sure to reschedule if it makes sense. And I always make time ASAP for someone who doesn't usually want that meeting, when they ask for it.

Probably avoid calling people minions if you can. Do you want to come across as someone who manages unimportant simpletons, or do you want to be perceived as someone who manages smart and interesting people? Build up those below you, don't knock them down - everyone wins.

I found it refreshingly honest. Most of us aren't landing people on Mars or working on a cure for cancer here. Most of us are, infact, relatively unimportant (including the guy managing minions.)

The people who speak like this in my experience typically use that kind of terminology to highlight their own superiority, not realising that it has the opposite effect.

I condensed "people who see me as their boss and/or mentor and/or intermediator with the company" into the humorous and highly inaccurate "minions".

Feel free to continue to evaluate my performance on the basis of my word-choice here rather than the actual management process I was describing.

I have no idea about your performance, I'm sure you're a great manager. I only noted your word choice because I've seen people talking this way about their reports and it doesn't reflect well on them.

Have you seen people talking about themselves like that? Because that's how "minion" is frequently used humorously, and I was assuming that OP was channeling that.

More or less what I expected, actually. Now riddle me this: what does a _scrum master_ do all day?

I've never seen a dedicated scrum master, they've always coded features on the same team. Is this really a thing?

It is definitely a thing. And for big projects it can be helpful. But in most cases I think a scrum master should probably handle multiple projects if that is going to be their dedicated role.

Yes. We had a team of 20 with 2 scrum masters, because they wanted to grow the team, and they had 2 scrum masters available. It was ridiculous. But don't worry, they will manage to fill their time with meetings. Just try to avoid them.

Oh lord, yes. The scrum masters at my last gig had no technical knowledge at all. All kinds of certifications for scrum, had no idea about actual software development.

I have the feeling that this is almost exactly the opposite of what these methodologies and principles were originally about.

Considering that the main purpose was to sell consulting services and certifications, it's "mission accomplished".

I find it amusing that Agile and Scrum have been around for literally decades now, and we still have substantial disagreement in the industry over what exactly they are. IMO, it hints strongly at the lack of substance.

Absolutely a thing. Our dedicated agile lead establishes and "runs" a 15-person standup, story refinements three days a week, a short S2 standup three days a week, sprint planning, product increment (three-sprint groupings) planning and pre-planning meetings, a demo and a retrospective and a standing "team lead AMA" every sprint, and handles setting up inter- and intra-team discussions when that need is expressed in standup or via slack. Also, they maintain "Program" section on our team wiki, set up story boards and pull team velocity metrics, and generally work full time doing all the things that I would be doing for these teams as a team lead, if they weren't there.

Having been without an agile lead for a couple months this summer, I'm acutely aware of how much they do, because they're often doing things that I was just letting drop on the floor as non-emergency.

15 person standup...speaks volumes

Well, it's three teams (hence three of some things), but things have gone more smoothly so far when we operate as a megateam. :)

Most of those things are busy work, and provide no actual benefit to a team being productive. I've worked on a lot of teams, and the teams with this amount of planning structure tend to be the ones that perform the worst, while also having the most unhappy members. It sounds like you're spending a pretty considerable amount of time in meetings!

If you need an agile lead, there's something seriously messed up in the management of your org.

I know. When your thing is a process and not tangible work output then you need to be fired.

There were three dedicated scrum masters at a previous job - two seemed to watch Youtube all day and eventually left and the other one read about tech all day and got made redundant. The scrum masters that survived did dev work as well.

It's absolutely a thing. We have a guy with no technical or product management responsibilities who is the "scrum master." He doesn't know how to use Jira, and seemingly delegates everything to one of his direct reports. Last meeting he literally phoned it in from a soccer game.

I did actually complain about him to my own manager. It didn't go well.

"Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?"

The "scrum masters" at my last place didn't interact with customers at all. That was the PO's job.

I highly recommend this movie: https://www.imdb.com/title/tt0151804/

Eh, I didn't actually care for it. It hit a little too close to home.

Good ones spend most of their time in meetings or preparing for them. Bad ones tend to have a lot of free time or waste the teams time with pointless crap.

To be a full time position generally involves a lot of administrative work or covering multiple teams. Talking to management is kind of a catch all but generally it’s interfacing with the rest of the world outside of clients. Legwork on security clearances, making sure all the boxes on contracts are checked, and or enduring the team has all the hardware software they need etc.

It tends to be more important in less software oriented companies.

Filling your time with meetings, pretending you are being productive.

If "scrum master" is a dedicated job, and they aren't in scrum meetings all day, they are probably really a project manager by a different name.

My main tip to this engineering manager:

Try to overcome the default assumption that every meeting should be an hour long.

There’s only one meeting on this calendar that needs to be an hour - the team happy hour - and for some reason, that’s the one you have at 30 minutes duration.

Also: 30 minute stand ups are a bad sign; one possible reason they take 30 minutes: there’s a manager attending them.

A 30 minute standup is really a status meeting. Don't call it a standup.

Why is an engineering manager even attending team standup. If following scrum it is for scrum team members only. Even if they are invited then should go once a month or something to observe.

The problem is that calendar software and industry-wide habit pushes meetings to last a multiple of 30 minutes. And you can't trust that everyone will be connected or in the room before 10-15 minutes after the planned start. So 30 minutes transform into 15-20 minutes, and is too small for anything but a short chat that could have been an email.

Those are cultural habits that can be broken. Start meetings on time, don't let people straggle in. Setting half hour meetings is easy.

For my part I'd love it if more people would accept 20 minutes as a reasonable meeting duration, but it definitely requires companywide norms to get people to fragment their calendars that way.

I would go crazy with that number of meetings, hearing people complaining all the time. Management is definitely not for me.

The author is completely inexperienced and without any sort of mentoring. The natural tendency of an organization is, well, meetings. So without experience and a guiding hand, it tends to rot into the hellscape that is presented in the article.

This is similar to what my calendar looked like when I was a manager.

You know you've hit full manager when you start blocking out an hour of time in your calendar so you can use it to prepare for other meetings. Spending 30-60 minutes preparing reasons why we should spend $XXX,XXX budget on 3-4 different vendors in a way that a non-technical CEO will not only understand, but buy into, is the difference between my team getting the tools they need to deliver a project on time quickly and not delivering at all.

Add to that 2-3 interviews a week, doing your own reach out for candidates, some 1/1's, explaining to the CX team in the most political way possible why filling out the bug form instead of just sending a slack message to a random engineer is important, putting a PIP together for an IC who hasn't been delivering... Nothing particularly _technically_ challenging, but sometimes a bit emotionally challenging and still important.

I realized the part I liked the most was the coaching/communicating/presenting part so I shifted to developer advocate and training roles instead. I enjoy creating and giving engaging presentations a lot more.

I would rather take up work on the farm shovelling pig shit, and administering anal suppositories to sick horses than do all that.

Reminds me of the second half of 'MongoDB is web scale' https://www.youtube.com/watch?v=b2F-DItXtZs

Yep, you got the quote! And I've even (narrowly) had more vote ups than down.

"Are you a manager and think I’m terrible at time management? Which meetings would you cut?"

The immediate thing that raises questions is your meetings with "Team #1" and "Team #2", which is a bit unusual. General practice is that it takes a manager per team; so if you're managing two teams yourself then it's expected that you'll be overloaded (and if there's not many people then perhaps you can't afford the overhead of managing them as two separate teams and need to "merge" them in practice, having one common meeting instead of two separate ones) and on the other hand if there are separate team leads for these teams, then I'd argue that you don't need to participate in as many direct meetings as you do and instead delegate more to them and the teams themselves. If you "need to know" then perhaps review the meeting minutes without direct participation.

You don't know how he's defining 'team' in this context. I often organize management of my big-T Team by referring to groups of teammates focused on a particular task or project as a small-t team, especially if they're on-going tasks. So this week I had a couple of people working on a 'team' covering API issues, another group covering IAM, and another set on key management.

But then this reply is just full of "I don't actually know what your on-the-ground reality is, but that definitely won't stop me from telling you what you're doing wrong".

Well, I'm answering an explicit question by the OP based on the information provided; but my observation from the schedule is that he seems to be running two teams as if they are big-T Teams - if those are actually two small-t teams of four people each, then IMHO he should devote less meeting time to each of them or merge some of the meetings.

In your big-T Team, would you schedule a separate daily standup for each of the task/project small-t team you're supervising, and organize separate social events for each of your "groups of teammates" as OP is doing?

Sorry to be overly negative/confrontational/whatever, but an annoyingly frequent (for me...once a quarter or so) part of my own "what does this engineering boss do all day" is push back on people who have no idea what my team does every day or how they do it, or what makes them as productive as they are or even what the output eventually is, drop by to tell me what they think I should be doing (usually accompanied by a rep from the PMO and shilling a new tool to enable said 'way I should be doing it').

If all you have is a hammer...

On the other hand, I get a lot of managers who ask my opinion about how they are running things, which for me starts with "why did you make the decisions you made up to now and tell me what is or is not working", not "let me give you my dissertation on the One True Way...".

IMHO he should devote less meeting time to each of them or merge some of the meetings.

Fair enough, "less time in meetings" is always something to pursue. Perhaps aggressively, even ruthlessly. Lawyers schedule meetings in 6m increments and I've considered it. Unless the OP can't, for any number of reasons. Which we don't know.

N.B. - I get lots of time back teaching people that if you think you only need 15m, then it's pretty easy to only schedule 15m and not 30m just because it's the default (in Outlook).

would you schedule a separate daily standup for each of the task/project small-t team you're supervising

Since 'standup' implies things that do not apply to how my team organizes work, I'm pretty sure 'no'. You'd need to know that to advise. Kinda my point.

and organize separate social events for each of your "groups of teammates" as OP is doing

I see:

4:30 PM — Going-away get together for team #2 member

Which in no way implies separate social events.

If you mean:

9:00 AM — Holidays peak preparation meeting for team #1 1:00 PM — Holidays peak preparation meeting for team #2

I guess it could be social. But since it explicitly says "peak", I'm slightly skeptical that in the real world it means anything other than organizing operational coverage when lots of people are taking time off for whatever they're working on.

Of course, that's just my opinion. I could be wrong.

fwiw, nearly every software engineering manager (at least at the senior level) at my work runs two teams. That said, you hit the nail on the head: delegate. My tech leads are my default catch-all, but we have an owner on the team for different things. One engineer goes to security related meetings. Another is running point on proj_a and another running proj_b. The other thing to do is block out time on your calendar to have time dedicated focus time. You can't get anything done in 30min. You need a 60-120min block on your calendar.

I don't like the implication that being busy is indication that something is being accomplished. I would ask the question, what are the outputs of this schedule? If there are meetings that happen but don't have meaningful outputs, then it doesn't matter than you attended them. Perhaps those can be dropped entirely.

People who attend that many meetings do so because they lack confidence (perhaps rightly) that they can be productive/creative themselves, and so they hide in group activities. The claim that work-weeks like that are necessary / desirable is one of the biggest lies of our industry.

Lol. 30 minute standups.

Outside of a very time critical release, standups are absolutely worthless. There is no need to coordinate when multiple people are independently working on separate projects.

All too often standups degenerate to sequential 1:1 micro status reports. Even if that micro coordination is beneficial, there’s no point for the manager to even be there since they’re not actually doing any of the work. All they need need to know is if the project is hitting its milestones, and daily updates are simply too noisy for that.

Even if you disagree my opinion of the efficacy of standups, 30 minutes is 2-3x too long, as every description of a healthy standup I’ve ever read says they should be quick. 10 to 15 minutes at most. Subdivide the teams, or take the discussions offline. This isn’t the way they should be run.

How much of all that provided any actual value?

I feel like either there are organizational issues, or this guy micromanages. I report to a VP (Fortune 100) and even he has fewer meetings than this guy.

I wonder how many of these meetings just exist to fill time and feel important. Yes, communication and dicussions in a team are important but I throw the hypothesis into the room that most of these could also be solved in a 5 minutes walking meeting.

This is a great read on the role of managers

https://www.spakhm.com/p/parallel-tracks

I know you don't go to them every day but you aren't required to go to all of your teams' agile ceremonies (standups, etc.). They can be handled by the teams and their scrum master, which would be covered by your sync with the SM and your team members. That frees up some time, if you need it. Personally, I'm a big fan of managers being so busy managing that they don't have time for work. Keeps them from writing code. ;-)

> agile ceremonies

Not to pick on your comment, because I know this is, sadly, common parlance, but:

Weddings are ceremonies. Meetings at work are just meetings. Sometimes stuff in this field gets so ridiculous and pompous sounding.

> Weddings are ceremonies. Meetings at work are just meetings. Sometimes stuff in this field gets so ridiculous and pompous sounding.

I like that they're called ceremonies because it highlights just how ridiculous and pompous this cargo culting has become. To me a ceremony means mostly pointless tradition that is way overdressed.

Our team can put all that stuff in a box and say "we avoid ceremony", and the kind of people that we want to work with will appreciate that and want to work with us.

Here's my take on it. You are the best judge when it comes to identifying what makes sense to continue and what you need to give up. A lot depends on where you are in your management journey, the context and the environment in which you operate and your goals.

Ask yourself a few of these questions to make this decision for yourself: 1.What are your goals? What do you wish to achieve as a manager and as a team? 2.Do you know what success looks like to you and your team? 3. Using #1 and #2, ask how each of these meetings/discussions align with your goals and the success you wish to achieve. Knock off anything that doesn't align. 4. For things that make sense to keep, next identify if there's a better process to get the same level of information, one that doesn't require meeting time e.g. emails, chats, more 1-1 conversations. 5. Finally, take feedback from your team to understand which meetings they find useful and which ones they don't.

Apply some of these strategies. Learn from them and keep improving. It will take some time, but you will now have a process at hand that helps you with making such decisions for yourself and your team in the future.

At my company you can see other people's calendars by default so I can easily know what anybody on a manager-schedule is doing unless they opt out of sharing.

I am not sure why people think it is bullshit. 1:1s, cross-team meetings, project planning, sitting in on various engineering-driven meetings (e.g. "What should we do about this problem that popped up?" "How should staffing work for this new project?"), hiring, and other managerial odds and ends (your report has a question/needs XYZ) amount to a large amount of work for a larger team.

I am not a manger, but I go to many of these meetings. A lot of these recurring cross-team meetings are phenomenal wastes of time - most people don't say anything, other people only talk maybe 5% of the time or less, really only 2-4 people talk a lot. Many "process" meetings, like whatever agile/scrum/story/retro bullshit are also filler.

However everything else is IMO kind of necessary, and I'd say it is real work. People won't manage themselves, projects won't plan themselves and align them with people's needs or career plans, and fundamentally a tree structure is usually a much more efficient way for info to be communicated than an ad-hoc peer to peer structure (no, maybe not for the more senior people, but if you have worked with junior people, you know what I'm talking about) - we're talking O(n) compared to a pessimal O(n^2). People can and should still communicate peer-to-peer anyway, but it makes sense for mangers to take on as much of the overhead as necessary.

The problem with the OP is they have found a way to somehow stuff their calendar with the worst kinds of meetings - random webinars, "status updates", and jira jockeying.

Why do people think it's bullshit? I'll give it a shot:

"1:1s" - time-filling waste at best, a chance to micromanage at worst. If individual contributors need this much help all the time, they should have a technical mentor. Mentorship doesn't come in weekly 1 hour increments, either.

"Cross-team meetings" - Most likely, people from within the teams should be talking to each other when they have questions for each other. Why the telephone game with managers?

"Project planning" - In software development, project planning is mostly fiction anyway. Way too much project planning all over the place. You're exploring a vast uncharted territory; stop planning and start exploring.

"Sitting in on various engineering-driven meetings" - the "sitting in" has given it away. That's all they're doing. Sitting.

"What should we do about this problem that popped up?" - get an engineer working on it now if it's super important; put it in the backlog otherwise. Why is some manager who barely touches the code trying to tell me how to solve the problem? Your advice is useless, just let me fix the damn thing.

"How should staffing work for this new project?" - The same way staffing works generally? I'm confused. Get some engineers on it. Preferably smart ones. Preferably ones that aren't already overloaded.

> A lot of these recurring cross-team meetings are phenomenal wastes of time.

Yup.

> People won't manage themselves

They will if you let them.

> Projects won't plan themselves

Your plan is wrong anyway.

> we're talking O(n) compared to a pessimal O(n^2)

Peer-to-peer is only O(n^2) if everyone is spamming their conversations in a group channel. It's just about maximally efficient if everyone knows exactly who to ask for their specific problem.

I agree with some of what you say, a lot of big meanings could be compressed to emails. But I think you are really simplifying a lot.

"1-1s": If they are used to micromanage they aren't 1-1s anymore. There are a lot of politics in a medium to large sized software org that can be difficult to manage. How do you get ahold of a person in another team you rely on but isn't responding? How to juggle contradictory requests. How to get better in some area? How to prioritize/manage time? The answers to these can be hard to intuit, especially for a new team member and might need to be discussed as issues pop up and can be very context specific.

Staffing: When resources are clearly defined and a person is working on one project for a clearly defined amount of time it is simple. But often times there are new hires, people leave, someone might be switched projects, projects might get delayed, etc. There are actual trade-offs to consider here. They probably don't require a weekly meeting, but you are doing a lot of hand-waving.

People managing - People can manage themselves for things that they are incentivized to do (normal project work for example), but if it is unclear what the priority is or if something is necessary, they won't do it. Many times there were "team initiatives" to improve code quality or testing and they never went anywhere because there wasn't appropriate time allocated to do it and there were project priorities. Same with asking people on other teams to do something for integration or to fix a blocking bug, often times they wouldn't respond or delay many times and it would be necessary to talk to management.

I feel like a lot of your points are assuming everything is constant and things are running perfectly. But in any software organization things are constantly changing

Your post comes off as a bit arrogant to be honest, but I think you are essentially right. The most convincing argument is this:

> > People won't manage themselves

> They will if you let them.

I feel like this is kind of the root of it all.

You also mentioned mentorship. Maybe more experienced workers should consult, teach, mentor others to help everyone to become more autonomous, rather than "managing" them.

And yes, that means it's people who know how to do the work, have done it in the past and hopefully will do it still.

There is value in having people who make high level, strategic decisions, and those typically don't need this kind of level of expertise, but should rather trust their experts. But that's usually not what we mean with "management".

You see I strongly believe in autonomy, which is why I have decided for myself to not have managers/bosses anymore. Just clients and colleagues for the time being.

There are environments which are deliberately focusing on and enabling autonomy, which is very attractive.

> Maybe more experienced workers should consult, teach, mentor others to help everyone to become more autonomous

That's a significant part of the role for effective managers.

There are managers and other types of leaders who optimize for metrics, attribution and individual short term gains that can be put on a spread sheet or a list of contributors etc.

People that empower others, or quite simply make them happy are extremely valuable. "My team feels safe and we trust each other" is hard to measure.

Management is one of those jobs that when things are going well, you may only need to be involved for an hour a day or less. When things are going pear-shaped, then it's full on for ages.

It certainly begs the question of "do we need managers", but the nature of the job is that it is lumpy in its time schedule to begin with.

A similar question is: "What does my on-call engineer do the entire time they are on-call?"

If my employer caught wind my workweeks were replete with busywork like this, I'd have a day or two to fix it, or I'd be looking for a new job. This schedule is a bad look and reinforces do-nothing (or little of value) management stereotypes. Maybe there's an upcoming second part to this post that saves face..

I think there is a strange transition to filling days with recurring meetings in many tech/start-up companies - 1-on-1, stand-up meetings, weekly meeting with different subset of the same group of people etc. My direct report had about 15 people under him, so this was 15 hours a week on 1-on-1 meetings (he sat beside me by the way).

Most of these I found to be incredibly ineffective. Rather than making decisions and getting things done, many tasks were delegated to different meetings and non-trivial amount of effort was spent on keeping track of just what was discussed. This sort of 'meta-work' quickly grows to become unmanageable and any task that requires even the smallest of approval becomes an enormous exercise in bureaucracy.

What I notice is no time to work on the meetings

When are the action items from all the 1:1s, standups, etc worked on ?

Most likely they're worked on by someone else, and then the manager uses half of the next meeting to follow up on them.

If you start at 7:30, why is there anything after 4:30?

There's plenty that can be cut.

Managers at my company do not attend most postmortems, standup/scrum, and backlog grooming.

On top of that, my company expects managers to work 9-10 hours.

It’s fascinating to me that the comments are intensely polarized between the crowd that thinks weekly 1:1s are a giant waste of time, and the crowd that thinks 30 minutes a week isn’t nearly enough.

Out of curiosity: to the folks on either side of the fence, is this something you’ve posed (either upstream or downstream, as the case may be), and if so, what was the response?

I'd love to have a weekly 1:1 with a good manager. Bi-weekly with my current one is plenty.

I can feel this. At this point in my career, “who will my manager be” is essentially the #1 question I ask when considering any new project/team/etc. As is seemingly obvious from the comments on this post, the divide in experience between “horrible manager”, “meh manager”, and “good manager” is huge.

My direct report is awesome. The guy I do 1:1s with is decent. Department head should not have any direct reports. Too abrasive.

That... is my nightmare.

> lead frontend engineer to a senior engineering manager

How does one make a jump like this in one year. I'd question their career ladder and development more than his supposed daily scheduling. Maybe he wasn't well equipped to handle senior management

The way to evaluate whether these meetings are necessary and effective is to ask if there is an agenda, decisions to be made, and a list of next steps following the meetings. If not, they're unnecessary.

I miss working in a company where the engineering managers mostly coded, and also did a bit of management.

Would a senior EM attend the teams' stand up? Isn't that the work of engineering manager to do?

Nothing about budget and costs? This was a significant part of my time as a manager.

I would have a lot of trouble starting my day at 0730, personally.

how much time is typical for 1:1s? At my previous job I had around 30m/week, but at my current job I have 20m every 2 weeks. Not sure what's more common.

Almost as little as me, an American programmer.

TLDR; Attend all the meetings you don’t want to be in.

This.

I don't get it (I really don't).

fwiw, I worked at a company with a reasonably sized engineering department. The engineering VP quit. His secretary took over some HRish work and the Directors dealt with the other senior management.

the guy being missing made no difference at all.

oh, and our line managers spent at least a month of the year preparing for, performing, and writing up an insanely complex yearly review process.

it's a damn wonder anything gets done at all once a company survives into middle age.

Reply on news.ycombinator.com