HN Books @HNBooksMonth

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

Selling alone can get me a couple years worth of runway but I've been in two where overselling before ops/process where at a stable velocity everything choked so bad it forced the biz to pivot (not in a fun or good way).

What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them.

At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically.

If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails.

[0] https://www.amazon.com/dp/0735679665