I'll provide slightly less cynical thought, may or may not help:)
I was purely technical for first 20 years of my career. I never understood meetings like this. I never cared for meetings like this. I assumed there's no value or meaning for meetings like this. They didn't impact me and people can BS each other as much as they want.
I was right? From a personal perspective. I did my technical work, and the org changes and sales strategy and client relationships and wording on contracts did not seem to daily impact my work. You can spend an entire, happy, sane career in that way.
Few years ago I ended up what can best be described as middle management. It is now my JOB to understand what the heck is going on at a certain level, and it is in some way easier. My goal becomes less "Build Server to these specifications" and more about "Help client achieve this outcome". Just like there's a set of language that has developed around "how to build a server" and "how to create a webpage", there's a language around "how to achieve a business outcome". And they'll sound equally gobblety-gook to each other.
A business development manager may believe all techies are interchangeable and building servers is the easy part, hard part is sales and keeping client happy. A pure techie may believe that all managers are bullshitters and hard part is infra/code. I'm sufficiently recent to both sides that I can see both aspects if I squint, kind of like that optical delusion that's like two faces or one vase depending on how you look.
If you genuinely WANT to understand these meetings... you can't go in them cold. You won't understand language and background by starting from the middle. Talk to your management and ask them: what are your goals? What are your priorities? How do we make this team, business unit, company succeed, at strategic level? This will hopefully give you a framework to then start fitting little nuggets you hear into.
If you genuinely WANT to understand these meetings... you can't go in them cold.
This. If you don't understand any of these corporate meetings, ask your direct manager to explain. If you want to keep that question private, ask during your regular 1-on-1. Or, if you know your teammates have the same problem, ask during a regular team meeting. (I'm assuming you have both meetings on some regular cadence, if not, run away!)
Hopefully your boss can explain it in plain language. If not, run away!
Good answer. I'll add that as a middle manager, it's your job to take a large umbrella strategy and break it down into actionable terms for your team. I think this is the root of the OPs problem. These meetings are for disseminating a goal/strategy that is set near the top of the organization. It has to be broad and generic in order for different groups to enact. It's up to the management of each team (whether its sales or engineering) to translate the company goals into specific goals for the team that are understandable.
I've not been a dev for very long, but I don't care for the "build to these specifications" approach. I like to know what outcome I'm helping achieve and why it matters because I think that knowledge helps achieve the outcome. This is part of why I enjoy software consulting.
I agree, but I have seen people of all kinds and preferences.
I've actually been stopped couple of times when I was explaining background - literal line: "Thanks Nikola, but I don't need the context - just tell me what the build and I'm happy:)". This was a team member who was a sysadmin, then tech architect, then decided knowing background and being responsible for outcomes was not contributing to his quality of life, and went back to sysadmin, and lived very happily ever after in carefully managed ignorance. I've seen a number of people who have decided their happiness is in scope management. I don't work like that, for now, but I fully understand that perspective.
As a middle manager with that background, I would think the lesson is that you should make a better effort to brief the engineers on what context they need for meetings rather than let them linger in the state of feeling like it's all pointless.
Agreed; I don't know the requestor's background, org structure, role, and why are they in those specific meetings in the first place. There are any number of activities that their manager can do and improve, but question as I interpreted it was "What can I do / what is wrong with me / how can I improve".
I was purely technical for first 20 years of my career. I never understood meetings like this. I never cared for meetings like this. I assumed there's no value or meaning for meetings like this. They didn't impact me and people can BS each other as much as they want.
I was right? From a personal perspective. I did my technical work, and the org changes and sales strategy and client relationships and wording on contracts did not seem to daily impact my work. You can spend an entire, happy, sane career in that way.
Few years ago I ended up what can best be described as middle management. It is now my JOB to understand what the heck is going on at a certain level, and it is in some way easier. My goal becomes less "Build Server to these specifications" and more about "Help client achieve this outcome". Just like there's a set of language that has developed around "how to build a server" and "how to create a webpage", there's a language around "how to achieve a business outcome". And they'll sound equally gobblety-gook to each other.
A business development manager may believe all techies are interchangeable and building servers is the easy part, hard part is sales and keeping client happy. A pure techie may believe that all managers are bullshitters and hard part is infra/code. I'm sufficiently recent to both sides that I can see both aspects if I squint, kind of like that optical delusion that's like two faces or one vase depending on how you look.
If you genuinely WANT to understand these meetings... you can't go in them cold. You won't understand language and background by starting from the middle. Talk to your management and ask them: what are your goals? What are your priorities? How do we make this team, business unit, company succeed, at strategic level? This will hopefully give you a framework to then start fitting little nuggets you hear into.