61–70 of 117 posts
Why is this industry filled with children? If you are sure you don't need to be in a meeting, decline. Why do these children need blog posts to be a bare minimum adult?
Title says “engineer” but article is solely about computer programmers? Isn’t that computer science? I don’t remember there being a coding engineer at my college…
There are some who believe that meetings are work. If those people are in charge of an organization, there will be tension with people who have real tasks and deliverables. My preferred approach is not to modify the meetings to make them more efficient, but to go on an extremist crusade against all meetings. Insist on asynchronous communication. Create dashboards with whatever metrics are discussed at status update m…
> Insist on asynchronous communication. Not disagreeing, but you've also got to be mindful of scenarios where there is something which needs to be hashed out and neither party fully owns the thing. If you don't nip it in the bud by getting those people together on a call or in the room together, you can end up with a lot of unnecessary back and forth. Getting people in the room together is particularly effective for…
There are some who believe that meetings are work. If those people are in charge of an organization, there will be tension with people who have real tasks and deliverables. My preferred approach is not to modify the meetings to make them more efficient, but to go on an extremist crusade against all meetings. Insist on asynchronous communication. Create dashboards with whatever metrics are discussed at status update m…
> Insist on asynchronous communication. Not disagreeing, but you've also got to be mindful of scenarios where there is something which needs to be hashed out and neither party fully owns the thing. If you don't nip it in the bud by getting those people together on a call or in the room together, you can end up with a lot of unnecessary back and forth. Getting people in the room together is particularly effective for…
I suspect the population for whom this holds isn’t much smaller than the famously-a-majority “bad at math” set, and the difference in visibility of the issue is because the “bad at literacy” folks don’t volunteer their status as readily as the bad-at-math folks.
You know what's a bad meeting? Any Scrum meeting or status 'sync'. Meetings are invaluable. Get together frequently to talk about what you're actually trying to build with the stakeholders and you don't need process, you barely even need tickets.
But you have to be present, involved and responsive to jump on a quick call.
Instead engineers whine about context switching and how the business context of their work is irrelevant "just put it in a ticket". So now we have micromanagement up the wazoo with execrable Scrum type meetings.
I love meetings and feel a lot of anger to the type of engineer who thinks it's beneath them. Equally I detest all 'ceremonies', absolute time wasting dregs.
The concept of "decision meetings" is a really tricky one to master. I think: Good: Put a meeting on a calendar in the future in order to force all discussion and investigation to happen before that meeting and keep things moving. Bad: Adding a "decision meeting" doesn't make a decision any easier or harder than before, and doesn't make the research and investigation take any less time than before, and often we don't…
Paul Graham wrote an article about the difference between a Maker’s schedule vs a Manager’s schedule. [1] Powerful people are on a manager’s schedule. Meetings are a unit of work for a manager, and they freely schedule meetings because there’s very little cost to them. The advantage of this schedule is you can have speculative meetings that potentially open up new opportunities. This is very costly on a Maker’s sched…
Earlier quoted context omitted.
There are some who believe that meetings never accomplish anything. If those people are in positions of power in an organization, there will be tension with people who use meetings effectively to coordinate, communicate and drive decision making with all stakeholders present.
I've seen this argument often but I'd guess 50-75% of the meetings in my organization could've been handled in an email. Often times the only reason we have a meeting in the first place instead of an email is because of the politics around things, which to me is a sign of inefficiency in the 1st place.
Also, the more your meeting goes beyong half an hour, the less fruitful it becomes. Half-hour meetings are the most productive, one-hour meetings are understandable, multi-hour meetings are dreadful.
Earlier quoted context omitted.
> Insist on asynchronous communication. Not disagreeing, but you've also got to be mindful of scenarios where there is something which needs to be hashed out and neither party fully owns the thing. If you don't nip it in the bud by getting those people together on a call or in the room together, you can end up with a lot of unnecessary back and forth. Getting people in the room together is particularly effective for…
If it takes corralling people into a meeting and interrupting their day to 'hash out' some aspect of a project, then it's a management failure where the importance of this particular thing wasn't communicated or emphasized before and how the individuals' inputs matter. If everyone understands how this project, regardless of the parties' full ownership or not, or whatever contributes to success because there was clear…
Yes. And you can't fix those as an IC, so you just have to work around them. This is like complaining about the direction of the company and advising to fix the root cause of whatever corporate drama - not wrong, just not helpful or practical advice.
> why should it be any different in person aside from the fact they're performing for management.
There's many reasons why in-person is more effective:
- Fewer distractions
- More emotional investment in the discussion (the same dynamic where people are more polite in person, but less so on internet forums)
- More "skin in the game" by making more of an effort to show up
Earlier quoted context omitted.
If there's no deliverable and no visibility, that's a failure of management, either to define the deliverable to a more granular extent where an update could cover the progress, even if async, which would also fix not having visibility. A developer piping up async and saying 'no updates, still working' is still an update and gives visibility. If they (managers) want to lord over the process and do work for work's sak…
> If there's no deliverable and no visibility, that's a failure of management, either to define the deliverable to a more granular extent where an update could cover the progress, even if async, which would also fix not having visibility. A developer piping up async and saying 'no updates, still working' is still an update and gives visibility. That's really the bare minimum that a developer can say and still get awa…
A coasting employee may be a problem of the employee's making, but it is still a failure of management. If an employee isn't doing anything then you fire them. But it's still a failure of management because that wasn't fixed right away. And again, if someone doesn't know what they are doing (if that's truly the case why did you hire them, but that's another conversation), even async, a keen manager should be able to pick up on that and provide coaching, connections, or other resources--you know, actually 'manage' this person. Failing all that, then cut them loose. But it's still the manager's problem.