So if your work is 90% meetings I am sorry but you have a bullshit job, nothing more, nothing less.
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.
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...
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:
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
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.
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.
This way there are no ambiguities and no one can evade responsibility. This avoids a he-said vs she-said situation as well.
A meeting has value beyond just the words themselves, which is where writing meets its limit.
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.
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 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.
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.
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.
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.
meetings are so much fun that of course people go to them all day long in an effort to slack off.
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.
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 hate those meetings.
I used to sip coffee and daydream during most meetings when I was a junior dev.
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.
Do CEOs have a bullshit job?
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.
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.
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.
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).
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.
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.
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.
The experience at Morning Star (the company referred to in that link) is oft-quoted, but rarely replicated.
Thanks for posting this.
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.
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).
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.
"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.
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.
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.
The things that truly matter – 1:1s, own team stand-ups... - only take about 8 hours per week.
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.
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.
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?
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.
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.
> 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.
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>".
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.
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.
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).
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 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.
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.
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!"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.”
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.
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?
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".)
The comic you linked also makes an excellent point about the nature of racism: https://satwcomic.com/white-on-white-hate-crime
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 =)
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.
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.
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.
Like, I get what you're saying, but I think it might be a little unproductive to consider all communication work as "not doing."
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.
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.
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).
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.
If I'm in meeting that my report could have led/attended instead, that's a failure on my part.
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.
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.
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).
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.
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.
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.
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
1-1s aren't about how _you_ feel. They're about your directs's feelings, and the relationship between the two of you.
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.
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.
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.
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.
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!)
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.
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.
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.
Most of these rules of thumb came about before tools like slack, which for better or worse, let you communicate more directly more frequently.
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.
The obvious exceptions are new hires and very junior engineers who need more handholding while they ramp up.
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.
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 did actually complain about him to my own manager. It didn't go well.
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.
If you need an agile lead, there's something seriously messed up in the management of your org.
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.
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.
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.
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.
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.
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".
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?
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
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.
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.
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.
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.
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.
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.
"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.
> 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.
"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
> > 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.
That's a significant part of the role for effective managers.
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.
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?"
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.
When are the action items from all the 1:1s, standups, etc worked on ?
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.
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?
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 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.