I built my career on being in these meetings and have split my time between strategy and coding. You have to do the work to understand the concerns of the company and weigh those with your technical opinion.
- Try to find a way to not go to the meeting. Anything you say, especially the most insignificant part, will be used against _someone_ in an argument that doesn't make any sense. You're going to feel the need to correct their misunderstanding and misuse of what you said. You might even try to re-focus the discussion back to the important thing you were _trying_ to say. It only goes down hill from there. You're better off interfacing with a group of C-level people through documents.
- 1:1 meetings can work. Make sure you can back up everything you say with data.
- You're a developer, you can't estimate time and effort for shit. If asked, say you'll get with your manager or the PjM or w/e to get a date.
- Find out from the person that asked you to join what you should be prepared to speak to.
- If there's an agenda or documents that will be discussed, read them before the meeting. Doesn't matter if they plan to read it during the meeting.
- No hemming and hawing. If you don't understand what you're being asked, ask for clarification. If you don't have an answer you're confident in, say so. If they insist, prefix your crisp and concise answer with your level of confidence. "In my experience.." "From what I've read.." etc.
I'd like to add that, what you are describing, sounds like a pretty hostile environment.
Luckily, I made the opposite experience. However, it also requires that you, the developer, are open and curious about the motifs that the C-Level has. Sure, you can sing the tantrum that you cannot estimate times - and I agree! But it helps to ask what they actually need, and why they need it. Maybe you can come up with better ways to help them get clarity. Remember - from their standpoint, it's all a big black box they cannot understand.
From my experience, execs want to know the current state, and also want to be able to intervene before a project derails. That's usually accomplished by open and coherent communication - a skill that is yet to be found by some developers. But you can work on it! ...if you want.
I built my career on being in these meetings and have split my time between strategy and coding. You have to do the work to understand the concerns of the company and weigh those with your technical opinion.
In my experience
- Try to find a way to not go to the meeting. Anything you say, especially the most insignificant part, will be used against _someone_ in an argument that doesn't make any sense. You're going to feel the need to correct their misunderstanding and misuse of what you said. You might even try to re-focus the discussion back to the important thing you were _trying_ to say. It only goes down hill from there. You're better off interfacing with a group of C-level people through documents.
- 1:1 meetings can work. Make sure you can back up everything you say with data.
- You're a developer, you can't estimate time and effort for shit. If asked, say you'll get with your manager or the PjM or w/e to get a date.
- Find out from the person that asked you to join what you should be prepared to speak to.
- If there's an agenda or documents that will be discussed, read them before the meeting. Doesn't matter if they plan to read it during the meeting.
- No hemming and hawing. If you don't understand what you're being asked, ask for clarification. If you don't have an answer you're confident in, say so. If they insist, prefix your crisp and concise answer with your level of confidence. "In my experience.." "From what I've read.." etc.
I'd like to add that, what you are describing, sounds like a pretty hostile environment. Luckily, I made the opposite experience. However, it also requires that you, the developer, are open and curious about the motifs that the C-Level has. Sure, you can sing the tantrum that you cannot estimate times - and I agree! But it helps to ask what they actually need, and why they need it. Maybe you can come up with better ways to help them get clarity. Remember - from their standpoint, it's all a big black box they cannot understand.
From my experience, execs want to know the current state, and also want to be able to intervene before a project derails. That's usually accomplished by open and coherent communication - a skill that is yet to be found by some developers. But you can work on it! ...if you want.