I've led cross-functional teams in multiple organisations (albeit not in tech) and I'd argue it's a bit more complex than that. Regular team meetings can cover multiple needs, e.g.:
* Keeping everyone working on a complex project updated on progress
* Keeping everyone 'aligned' - (horrible corporate word but) essentially all working together effectively towards the same goals (be they short or long term)
* Providing a forum for catching and discussing issues as they arise
* A degree of project management - essentially, making sure that people are doing as they said they would
* Information sharing (note I prefer to cancel meetings if this is the only regular purpose)
* Some form of shared decision-making (depending on the model you have for this) and thus shared ownership
If a meeting 'owner' is sensitive to not wasting people's time and regularly shortens or cancels meetings, it can be done well, I believe.
Excellent list! I want to add a point about keeping people aligned. One thing that becomes very apparent when you lead a group of more than one small team is how you need to communicate everything multiple times, phrase it in multiple ways and blast it through multiple channels. As a former boss of mine once said "if nobody is rolling their eyes you need to say it more often". Even though I intellectually know this I've still had cases that blew my mind where is repeat something I've been saying for weeks and one person is genuinely surprised and calls out how helpful it was to hear this (one might think this was a prank but the person was definitely the opposite personality type for that and sometimes struggled a little with English). This makes that portion of the meeting or email boring and a waste of time for many attendees but there is no getting past it.
Similarly I've had so much feedback that people wanted to have a better idea of what everyone else in the department was working on. So various things were tried. Summary emails, brief section in monthly all-hands, yet many of the same people who asked for it didn't pay attention in the meeting and didn't read the email.
Yeah I hate those team calls too though. I don't give a shit what others in the team are doing. I'm not a team player at all. As such I always manoeuver myself into owning a particular topic which works well because I'm not slowed down by others. But these calls are something I just tune out on. I wouldn't even read the summary because I just don't care.
Well I'm on a team now managing a cloud SaaS package. Meaning most problems just involve finding workarounds for their incompetence.
I tend to grab the more interesting issues, which is easy because nobody else wants them. But in general I hate my job and I can't learn much from it.
I have to admit that if I was in a more fulfilling position I'd be happier to collaborate. But I'll never be a "team player". I just don't have this in me.
I stick to IC roles but personally I prefer meetings over your alternatives.
Project management tools are there for the long view and tracking, I don't want to juggle priorities of a JIRA backlog, it basically pushes the burden of PM to me. With a meeting if someone has a blocker thats on me I prefer if they raise it in front of the team and we agree if it should get done now or later. Other than that I share what I am currently focusing on and ignore the rest until I have to deal with it. Multitasking and context switching is a PITA and I will gladly delegate that to PM and hop on a meeting to sync with everyone.
I don't want to be spammed with JIRA updates on dozens of tickets I might be needed on, only to forget about them in 15 mins when something more important comes up.
And written communication takes more effort, it's a tradeoff for sure.
Yeah, it could be. But why would I want 5+ small 5 minute interruptions when I could have a single 20 minute interruption? Assuming all interruptions have a minimum of a 5+ minute context-switching time, the 20 minute meeting is 25 minutes whereas the 55 ends up being 510=50 minutes.
Are you an actual engineer with a degree and subsequent accreditation through a professional body? or an "engineer" by role? Those mean very different things depending on country, quality of education and skills or...how many Microsoft Points you have.
This drives me up the wall so much. I had a boss that used to introduce me to customers as an engineer, and I'd correct him on the spot. And now that I'm looking for another job (not because I pissed off the boss), I keep having to search through "engineer" roles because people can't get their terms right.
I work with engineers - actual electrical and chemical engineers that design processes and controls - and I make the software side of their ideas happen. They can't do their job without me, and vice-versa. But I'm a SCADA integrator, not an engineer, dammit.
* Keeping everyone working on a complex project updated on progress
* Keeping everyone 'aligned' - (horrible corporate word but) essentially all working together effectively towards the same goals (be they short or long term)
* Providing a forum for catching and discussing issues as they arise
* A degree of project management - essentially, making sure that people are doing as they said they would
* Information sharing (note I prefer to cancel meetings if this is the only regular purpose)
* Some form of shared decision-making (depending on the model you have for this) and thus shared ownership
If a meeting 'owner' is sensitive to not wasting people's time and regularly shortens or cancels meetings, it can be done well, I believe.