[nserrino]

The stories we often see about burnout in tech are interesting. There’s a lot about burning out of programming etc, the hours. Of course, long hours will eventually burn you out in most any profession. Less commonly discussed, it seems like most people I know actually burn out from bureaucracy. It’s far more exhausting and demotivating to not make forward progress and waste time in meetings all day. Of course, it should go without saying that some meetings are necessary.

[mbrodersen]

Formal meetings are rarely necessary (IMHO). I have been in less than 10 meetings the last 10 years. However quick informal discussions with subject matter experts are really useful.

[stuntkite]

Amen to that. I'm gonna rant a bit about my experience, strategy, and opinions on the cult of bad managers.

The cult of talentless MBAs, man. Took something as well meaning as XP/Agile and turned it into a way to formalize having no plan and offloading it to developers then bitching when the result isn't what they had in mind. Actually though they never really had anything in mind, they just thought they did and someone told them this method is a great way to get results after you poorly explain a hunch you have based on some crap that you saw some other company is doing.

Meetings should never be more than an hour, anyone who doesn't want to be there should be allowed to leave whenever they want. If they are required to present something then they should be allowed to show up just for that if they think that's a better use of their time. The person booking it should send an itinerary with the meeting and outline what will be discussed in 5, 10, 15 minute blocks. If anything goes more than a couple minutes over, that means the person who put the meeting together didn't understand the scope and it needs to be addressed again later and move on. Meetings are not the time to ideate at hostages. The end of the meeting should have 15 minutes for general discussion that anyone can skip. But this is critical to always block for because we all work remotely and if you don't make this a habit, problems brew because all interaction becomes transactional. The more people that are required to be in a meeting, the shorter it should be and likely the less useful it was ever going to be. If the meeting is just broadcast and not a dialog, then go make a wiki page, screencast, or just send everyone a voice memo and pretend like you did a good meeting.

This is my recipe for meetings that I've developed over 20 years of software development in the trenches as well as product management and working as CTO in a couple startups. I believe in these principles so much that I'd be happy if it was carved in my tombstone. The thing that tanks projects is trust between collaborators and people cargo culting what it means to be a manager. Meetings without care destroy trust. Also, the job of a manager isn't to be a puppet master, it is to talk to the people you are working with about what interests them the most and find the tasks that best fit their interests. Create pipelines for communication that work with all stakeholders so people can easily communicate the need to spend extra time on something hard or just walk away from something that doesn't work for them. As a manager I see my job as being the janitor. I sweep the floors. I clean up hard coded environment variables. I run and rerun and rerun the stack and look for kruft and inefficiencies, I do a repetitive meditation on removing frustrations and packaging work tools so anyone who wants to do anything with the code base can easily touch and manipulate any part of it with very little effort completely on their own computer.

I have only worked with a couple managers that sort of do parts of the things I'm saying up here. As I started codifying and applying the above rules I started to be able to not only turn projects around but overdeliver in less time with happier people.

EDIT: Also, shout out to Karl Wiegers Software Development 3rd Edition[0] and it's companion book Visual Models for Software Requirements[1]. Those books coupled with really learning to ask about peoples interests and needs and listen to not just what they are saying but watching to see if they are engaged changed my life and I think I've made more than a few working experiences better for everyone involved and I hope that's something I'm remembered for.

Also Marshall Rosenberg's Nonviolent Communication[2]. As a sarcastic pedant person on the autistic spectrum, finding his audio book on NVC helped me be a better listener and problem solver and not create unnecessary problems just by using my words in dumb and glib ways in the wrong setting. I mean, I still do that, but now I'm aware when it's unhelpful and do it much less.

[0] https://www.amazon.com/Software-Requirements-Developer-Best-...

[1] https://www.amazon.com/Visual-Software-Requirements-Develope...

[2] https://en.wikipedia.org/wiki/Nonviolent_Communication