51–60 of 117 posts
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…
"Software Engineer" is a pretty commonly used title for programmers
Meetings are the only way to grow your career unfortunately. Nobody really cares how shiny your code is.
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…
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.
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 schedule.
PG suggests partitioning the day to AM being maker’s schedule and PM being manager’s schedule. (A form of office hours).
This works if you have power and can swing this. But I’d be curious to hear what ICs do.
I personally just block off my calendar and decline meetings (with reasons given, always politely). I also entertain speculative meetings — I never want to shut myself off to new ideas. Most of my career has been built on serendipitous meetings by people who want to share a crazy idea.
Meetings are the only way to grow your career unfortunately. Nobody really cares how shiny your code is.
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…
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.
No there aren't. If you are consistently getting push backs on meetings within your org it's not that the teams or IC's believe that meetings are useless (what a silly thing to say) it's a sign that they don't have faith in the organization structure to concretely do anything with the information or provide valuable input.
If you try to setup a meeting and get push back you should _immediately_ ask yourself why the other person feels that way about the people involved or even yourself.
I'm curious about what everyone considers to be a high frequency of meetings. Two 1-hour team meetings per week, along with a daily 15-minute stand-up meeting. Do you think this frequency is high?
I have two daily stand-ups (30 minutes) with different teams I’m a part of A weekly status meeting (1 hr) Three weekly status meeting update planning meetings (1 hr each) Sprint planning every other week (2 hr) Demo and retros every other week (2 hr) Eight 1:1 weekly meetings (4 hrs) That’s 12.5 hours per week so far without even counting any real project meeting where we solve anything. I’m generally around 16 hours…
This does not compute to me, do you have 8 managers? What's the content of these meetings?
> Meetings are interruptions that cause context switches This. I find it very difficult to get into a "flow state". Simple meetings such a a standup are highly interruptive for me, especially when time zones push "morning" meetings mid day.
And someone in a "flow state", headed in the wrong direction, is even more wasted time than a meeting to coordinate efforts in the right direction.
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 see it like this: people are going back and forth over email and waffling then it's probably not that important, why should it be any different in person aside from the fact they're performing for management.
Earlier quoted context omitted.
Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output? To be clear, this doesn't mean 100% sync. But a 10 minute daily sync can ensure the team is focused on producing something of business value. Maximal autonomy withi…
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…
That's really the bare minimum that a developer can say and still get away with when you have a lenient manager. HN tends to take the most adversarial take on managers possible, but it's not always necessary.
But, when you've worn both hats (manager and managed), sometimes employees simply don't want to do much work. Again, you can say "that's a management problem", but some people are bad actors and are very good at hiding it in "corporate speak". The internet is full of stories of coasting --- I can even attest to doing it many times and easily getting away with it. Getting someone in a room, or on camera, and actually running through their work can cut through a lot of bullshit and bullshitters. Some developers think "coding" takes precedence over the business -- but some of their "coding" time is completely useless to the business perspective. It seems crazy to insist that managers have no stake in trying to figure out if that's the case.
Sometimes you also need to have a meeting because in an async setting some people have no idea what they're doing. Even with clear goals and deliverables, stuff can easily fall through the cracks.