During the pandemic, we had a natural experiment at my previous company. Our org had started an org wise auto ‘meeting starts 5 minute past’ while others had the traditional meetings start on the hour.
Also conveniently, we also had the calendar data for internal meetings, internal VC software (not zoom) db that logs the participants when they join and leave meetings and employee function db.
I was serendipitously the lead DS for analyzing the effectiveness of the ‘starting 5 minutes past’. After joining and cleaning a lot of the data, the data showed:
1) at the start of the trial, meetings ended on time. Then after few weeks it slip to ending late, negating the usefulness. Other orgs did not see meetings running late.
2) ICs tend to stick around and over run meetings, while managers tend to leave meetings on time.
3) if I remember right, we had a survey data that showed pretty clearly that managers prefer the ‘starting 5 minutes past’ while ICs do not care or have negative sentiment.
The biggest predictor for people who prefer starting late is how crowded their schedules are. Managers tend to have very crowded schedules which means they want a break between meetings, while ICs prefer not having to waste time waiting.
In the end we reverted back to normal schedule. It was just easier for busy people to bounce early.
I’ve experienced this all before in similar ways. The metric for meetings ending on time isn’t even very useful because when it’s needed people will ask “do you have a hard stop?” or similarly agree to continue the meeting. Often because of all the points you made, it’s the IC that stick around to talk about finer points or specifics of what was decided or discussed. It’s best to do this while it’s fresh and between people that can “talk shop” at a granular level (whatever that means for your org/team). It’s actually a good thing your ICs want to collaborate or align separate from management. If you’re a manager and you could technically continue on the meeting, consider opting out to give them space as peers. I often ask “do you all need me to stay one?” and most often it’s a No. It all means that it’s basically 2 meetings occurring and it’s the scheduling calendar artifact that is faulty.
>ICs tend to stick around and over run meetings, while managers tend to leave meetings on time.
That makes 200% sense. A couple or more ICs tend to want to stick around to go off topic or drill down on some thing if they don't have a conflict. People who aren't expressly relevant to that or have a conflict drop at that time.
You're basically seeing the post-meeting hall conversation of the ICs in your data.
Additionally, most meetings are worthless drivel from an IC perspective. The off-topic/drilldown is usually when ICs actually discuss topics relevant to them and get into a level of detail on issues that actually helps further the project.
> The biggest predictor for people who prefer starting late is how crowded their schedules are. Managers tend to have very crowded schedules which means they want a break between meetings, while ICs prefer not having to waste time waiting.
I have had a few senior managers (at Google) who ask for all the meetings _they_ attend to start 5 minutes late.
This seems 100% reasonable to me. No need for it to be an org policy. Just a affordance for the people who spend 95% of their working hours in meetings.
I've also had several senior managers at Google who _don't_ do this, but are 5 minutes late for every meeting anyway. This alternative is pretty annoying!
The problem is that final decisions tend to be made in the last 30 seconds of a meeting. If you're a manager with a stake in the outcome, you can't leave the meeting until you've ensured that the outcome works for you. Leaving 5 min early is often simply not an option. While arriving 5 minutes late is. It's not an ego thing -- it's the fact that meeting leaders often let meetings run long.
That almost sounds insulting. Like management is the only party with vision, drive and a goal and everybody else is just there to help. When often management just manages and true innovation really comes from people of all positions.
On the contrary, it is a helpful term. Before the term, it was common to ask "are you a manager", and then you were defined oppositionally, as not-a-manager.
Whereas IC having its own identity means it has many positive connotations. "I'd much rather be an IC, so I can get things done" etc. You can still be very senior without having direct reports or having to do line management, often seen as a necessary evil.
In my reading it makes it easy to even spin managers as the bad ones: ICs contribute individually and directly something of worth. Managers contribute only indirectly via ICs.
The term isn’t used to define everyone who isn’t a manager. It’s used to define people like Lead and Principle Engineers who are a subject matter expert, have influence in defining a project, but have chosen to continue in engineering roles rather than switching to management. Often their position in the company is parallel to the managers rather than subordinates, hence the “individual” part of the term.
This requires the intentionality of the organization though. They seem to default to managers make the decisions. Ideally, managers manage people, IC execute and you get the "right" people in the room to make decisions, regardless of title or track.
> This requires the intentionality of the organization though. They seem to default to managers make the decisions.
if a company doesn’t intend to utilise IC then they don’t have ICs, just regular software engineers.
An IC is only an IC if the organisation is structured to utilise them as an IC. It isn’t a job title, it’s more to do with how an individual is utilised in a company. It’s their placement in the org structure.
> IC execute
IC plus engineers execute. IC are a subset of engineers.
As @hnlmorg mentioned, the term is only typically used for people who are at a level where they could be managers, primarily supporting others, but are instead still contributing directly themselves. It's almost the opposite sense from your "insulting", in my experience.
SME and IC are functionally different. SME informs, IC creates. Often, IC aren't SME in the space they're developing in, because they're SME of the technology instead of the business.
That's fine to do that, but kind of pointless. Everyone is then a "SME" in their own job space and thus the term is kind of useless. So, just replace every mention of SME outside of your company to "Business SME" instead of "Technology SME" and you'll understand what we're talking about.
Or, if you truly do not need anyone but a "technologist" to deliver product, you must work in a pretty simple business space! I work in healthcare and our PhD's and MD's have a very, very different knowledge space than I do, I and I deeply respect their contributions.
This whole thing reminds me why I never wanna work for someone again. From what I saw at Google it all just ends up being classist top-down BS of who isn't allowed at the big kids table, or bottom-up BS by insisting they aren't the SME just the IC and we can't do anything until the XYZ PM SME TL and/or manager approve.
It is unparsable Dilbert nonsense to anyone outside of specific scenarios. And it causes interminable discontent. Because what if the SME is the PM because they know business and tech but the SME is actually the IC because they know the tech and its tech but what if the manager is actually the SME because they're running the tech and may need to redelegate if the IC needs vacation, blah blah blah.
(job history: college dropout waiter => my own startup, sold => Google for 8 years => my own startup)
I'm sorry you've had bad experience working with other people, but in my experience as a developer, having multiple SME's available is indispensable to real alignment and fast development. I've primarily worked in startups, not big companies, and have often worked in healthcare. In healthcare, you get beyond your "I'm a big smart engineer" ego BS and you are willing to listen to the PhD's and MD's that help inform clinical workflows. From my perspective, I would never ask a clinical researcher or a doctor to understand our react app, and they aren't going to ask me to have deep understanding on medical details and clinical workflows. We work together to deliver high quality useful software quickly.
My PM SME validated my workflows and I found Jesus in them then my MBA TL PhD…bla bla bla.
A human being who avoided corporate brainrot just writes “I worked with John and he was indispensable because (insert reasons you wrote here)”
I’m 37 and never heard of this acronym. That’s the entry-level version of my point. Not that other people hurt me or people knowing things is actually bad.
True. It is part of the general industrial ritual of reducing workers to a number or a letter combination. That way, managers reduce the emotional attachment to the people, and they can fire them more easily.
If, instead, you would be Tom, Bill and Biff, there is a risk that the manager would build attachment, and make it harder to treat you bad. If you're IC1, IC2 and IC3, you can be exchanged like machine parts when you break, without anyone crying.
No that’s not really how it works in tech at all. There’s a deep recognition that individual engineers (and other functional practitioners) have important knowledge and expertise that is essential. Of course you do need some overlap and redundancy so that people can take sick days and avoid the wheels falling off through attrition, but competent shops aren’t ever treating people as numbers. To the contrary good ICs are widely recognized as being much less full-of-shit then management.
> The biggest predictor for people who prefer starting late is how crowded their schedules are. Managers tend to have very crowded schedules which means they want a break between meetings, while ICs prefer not having to waste time waiting.
People don't know what 'as few as possible' means though. It needs to be clearer than that. As a rule I encourage my reports to consider:
- Does it even need to be a meeting? Keeping meetings to things that need 'a discussion or decision', and keeping updates and announcements to chat or email works fairly well.
- Does the meeting give you any value, or do you bring value to it? If both are no they should decline it.
- Is there an agenda with expected outcomes? No agenda and no goal means it should be declined.
- Are you doing something that's a higher priority? Seeing one of my reports in a meeting when there's an active incident in progress gets me asking questions.
- Does the person running the meeting share notes afterwards? One thing I've noticed over the last couple of decades is that people are much happier to skip a meeting if they'll still hear about what happens afterwards. People don't skip them if being in the meeting is the only way to know about what was discussed or decided. I always encourage people to write some notes and share them if they've set up a meeting now.
>much happier to skip a meeting if they'll still hear about what happens afterwards.
If you're just a 'follower' of what's going on, that's fine. The problem shows up when you have some stakeholder or steering ability.
If you miss meeting about X and don't bring up discussion about Y then other person A may not talk about Z that affects X. But I agree that every meeting should have a point and total number of meetings should be minimized.
Also conveniently, we also had the calendar data for internal meetings, internal VC software (not zoom) db that logs the participants when they join and leave meetings and employee function db.
I was serendipitously the lead DS for analyzing the effectiveness of the ‘starting 5 minutes past’. After joining and cleaning a lot of the data, the data showed:
1) at the start of the trial, meetings ended on time. Then after few weeks it slip to ending late, negating the usefulness. Other orgs did not see meetings running late. 2) ICs tend to stick around and over run meetings, while managers tend to leave meetings on time. 3) if I remember right, we had a survey data that showed pretty clearly that managers prefer the ‘starting 5 minutes past’ while ICs do not care or have negative sentiment.
The biggest predictor for people who prefer starting late is how crowded their schedules are. Managers tend to have very crowded schedules which means they want a break between meetings, while ICs prefer not having to waste time waiting.
In the end we reverted back to normal schedule. It was just easier for busy people to bounce early.