It's abstraction, but for things you don't care about. I was an engineer early in my career and I felt exactly as you. All that stuff was in one ear and out the other and I couldn't for the life of me make sense of it.
I moved to product and finally got it. A PM can't explain the same concepts/ideas/initiatives/etc every meeting because the whole meeting will be spent doing that. They give it a name.
Take the strategy example. In the early stages of forming this strategy, part of the PMs job is to communicate it lots of groups of people. They have the same meeting 1-10 times depending on the size of the company. Then everyone who needs to know about this strategy has an understanding of what it is. Then the PM gives it a name. The next meeting, rather than having to explain it from scratch, they call it by its name.
You're either not paying attention when it is first explained (I don't blame you, a lot doesn't matter to an engineer), or you weren't invited to the meeting it was explained.
You are absolutely right. Also on the part that it makes sense that you don't know since a lot of the information you receive isn't necessarily relevant to you as an engineer.
If something is unclear, the normal path forward is to ask a clarifying question. I wonder why OP hasn't mentioned or tried this at all. In my experience people are happy to answer these kind of questions because they don't want to lose their audience.
I also wonder why engineers are OK with the concept of technical abstractions, but are somehow in despair when business people use business abstractions. Most people here understand how abstractions are useful.
Why would anyone hold business people to higher standards than yourself? Do you really think that if you would explain a technical abstraction everything is immediately clear to anyone outside your domain? Surely not. Then why expect better from coworkers from other domains who are just people too?
I do ask questions. If it's a smaller meeting within my team I'll always ask questions if I'm not following. It's when it's department-sized meetings that I struggle. In these I find it harder to follow what's being discussed and I also need to balance my need to ask questions with the need of the meeting to proceed smoothly.
I think you're right though. There have been a few occasions in my career when I have seen corporate narratives form around projects I've led technically. In those instances I know with certainty that what's being said is mostly corporate BS that dances around the specific what, whys and how's of the problems we're solving. But to your point, that's probably for practical reasons. A lot of the time the details I'm concerned with from day to day just aren't that important as you move up the org structure.
I guess what I'm confused about is how other people seem to follow along in these meetings. I don't understand how some people seem to know everyone and about every project. Even if I have some awareness of someone or some project, I rarely know enough to follow much of what's being said, and certainly not enough to contribute anything useful.
I know I'm doing something wrong, I just don't know what it is. I do try to pay attention, but that doesn't seem to help me much. I'm worried it's more to do with the fact that I struggle with vagueness and corporate discussions are full of vagueness.
Sometimes I wonder if I'm following along more than I realise and it doesn't really matter that I don't know all the details about some project. Perhaps it's not that I can't contribute to a discussion if I don't know any details, but that the only contributions I care enough to make would involve details. For example, you don't need to know what [project xyz] is to ask who's leading it or if there's documentation on confluence.
> For example, you don't need to know what [project xyz] is to ask who's leading it or if there's documentation on confluence.
Bingo, there is a pattern to most business problems (not that the generic corporate template for problem solving is right solution) and if the know the pattern, you can engage with it. You only need a few high level details to have enough context, so some people can go really wide and have a superficial view of wide breadths of corporate initiatives.
> In these I find it harder to follow what's being discussed and I also need to balance my need to ask questions with the need of the meeting to proceed smoothly.
I think this is a key issue/insight. The larger full-department meetings will inevitably have parts to them that various people won't understand. It might be a 10-minute section about sales strategy that the engineers don't understand, or a 15-minute section about a technical issue that marketing doesn't understand. When you get that many people together across different disciplines with different areas of expertise, it's inevitable that this will happen.
The important thing is knowing what you (as an individual) need to understand, and if there's something in that bucket that you don't understand in the moment, hopefully the atmosphere is inclusive enough that you don't feel embarrassed or penalized asking a question, and the question can be answered quickly enough that it doesn't bog down the meeting. And on the flip side, if there are things you don't need to understand, you just accept that and wait until meeting conversation moves to something that's relevant to you.
You could argue that this type of meeting is horribly inefficient, and you'd be right. But sometimes inefficient meetings are just necessary, because doing it in a way that seems more efficient turns out to not actually be that efficient (or it is, but it's not thorough enough, and you end up with people missing critical information that they need to know). But this is also why this type of meeting (hopefully!) doesn't happen often, like maybe only once per quarter.
If you're in this type of meeting once a week, then something is wrong. Either your company is terrible at internal communication, or the person inviting you has misunderstood your role. A quick side conversation with the meeting organizer after the meeting is over should hopefully clear things up, and maybe excuse you from further attendance.
> I guess what I'm confused about is how other people seem to follow along in these meetings.
Why are you so sure they do? I mean, yes, certainly there will be some people in these meetings whose job function aligns pretty well with everything discussed. But there will also be others, like yourself, who sit there and listen (or pretend to listen), but don't really understand a lot of what's being said. They just don't admit to anyone else that this is the case, so you might think that they follow along but just don't have much to say.
> I know I'm doing something wrong, I just don't know what it is.
I don't think you're doing anything wrong. Consider your day-to-day job. Do you think you have the necessary information to do your job effectively most of the time? If so, then it's fine that you don't get much out of these meetings. If not, it's still not certain that your inability to understand these meetings is the reason. It's possible your direct manager doesn't give you enough context (either one-on-one, or in smaller team meetings), or maybe there are other meetings that you should be invited to but aren't.
Please don't immediately assume you're at fault here. Meetings -- especially those with a lot of attendees -- are just these big amorphous things that are often not very useful to many people attending. That's just how corporations work, for better or worse.
< I also wonder why engineers are OK with the concept of technical abstractions, but are somehow in despair when business people use business abstractions. Most people here understand how abstractions are useful.
Because business 'abstractions' are often buzzwords or intentional jargon, that hide the simplicity of what actually lies underneath. Whereas software abstractions are genuine abstractions of the complex mechanism that underlie software.
I think a lot of confusion comes from meetings with no agenda/context. The organizer should be required to include a reasonable context for what is going to be discussed and decided in the meeting. I’ve only worked in one company where this was widely adhered to and it was amazing (meetings often declined without agenda on invitation). Before and since, I often just have no idea what I’m walking into and tend to think of my best questions after it’s ended. If I had some time to view the agenda, pre-read the materials (slide deck, etc), and collect some base level thoughts before having 2 slides per minute of content shoved in front of me; then I’d be better prepared to participate IN the meeting.
As my career has matured, I’ve just become better at making sure I’m up to speed and understand (at least conceptually) the topics at hand. I also build relationships with everyone such that I can have sidebar conversations and seek clarity on things when needed outside the meeting. Also, have become pretty good at just filtering/ignoring the stuff that’s not important (to me).
It's funny how many comments like yours are insisting that, of course everyone knows what's going on, they just have more context and relevant expertise -- obviously it makes sense to them and they're being totally productive, you're just not keeping up...
... and yet 8 months ago there was a discussion[1] that revealed that many such meetings were actually built on foundations of sand, and infected with false domain beliefs and double-illusions of transparency[2]. Where someone had to come in and say, "wait, stop, explain all this like I'm an idiot" before anyone could actually get on the same page.
One example[3]:
>>I get pulled into a meeting about something that I have no context on because it touches my area of expertise, and the discussions have apparently been stalling out.
>>I brace myself to be the idiot. I'm going to waste everyone's time asking questions that everyone knows the answer to, and I just got looped in, so everyone's going to feel like they need to walk through all the super-obvious stuff to satisfy the one guy who didn't do his homework.
>>So I start asking questions, and slowly begin to realize that nobody in the room has any idea what they are talking about.
Another[4]:
>>This is me all the time haha sometimes I really am just "stupid" and the only one in the room without a clue, but many many times my stupidity has revealed no one really has any idea what they or the others are talking about.
So yes, I don't doubt that sometimes what you're describing is what's going on. But also, the OP may be deeply aware of something others don't realize.
Several times on email lists or in Slack channels, I’ve stuck my neck out and said stuff along the lines of “Whenever anyone asks a question about this stuff, people throw out these code words and obscure references to internal projects, and for people new to the process like me, it might as well all be Japanese. You can tell me to find it on the “foo server”, but if I don’t know what the “foo server” even is, that doesn’t help! Where can I find the beginner’s guide to doing this stuff for someone who has zero experience with it?” I’ve had numerous people ping me privately afterwards to thank me for asking the “dumb” questions because they all had the same questions and were afraid to ask and look stupid.
Similar to one other commentor, I wonder whether a text-based format (perhaps email/wiki) could be a more effective use of everyone's time?
(that plus the ability to question and correct aspects of the project asynchronously could compare favourably to spoken meetings, where details could be forgotten or misinterpreted over time, and where bandwidth for audience feedback is usually limited)
Agree that it's an abstraction that OP doesn't know the definition of, but there's also a tendency for people to
* over-abstract (where you could replace the abstraction name with a slightly more verbose but clearer definition)
* over-generalize (it's a meeting about handling returns in multiple physical locations but they keep talking about "channels" instead of physical locations)
* propagate abstractions without actually understanding the underlying concrete implementation (they know omni-channel means having multiple ways to return, but not exactly which ones)
But yeah as the consumer of abstractions you have to dig into the definition and understand the context in which it's applied in order to understand what's going on
I wish meetings were held in textual form (like a Slack channel). Reading the history and being able to search through it would make it a lot easier to understand context.
I moved to product and finally got it. A PM can't explain the same concepts/ideas/initiatives/etc every meeting because the whole meeting will be spent doing that. They give it a name.
Take the strategy example. In the early stages of forming this strategy, part of the PMs job is to communicate it lots of groups of people. They have the same meeting 1-10 times depending on the size of the company. Then everyone who needs to know about this strategy has an understanding of what it is. Then the PM gives it a name. The next meeting, rather than having to explain it from scratch, they call it by its name.
You're either not paying attention when it is first explained (I don't blame you, a lot doesn't matter to an engineer), or you weren't invited to the meeting it was explained.