101–110 of 116 posts
Earlier quoted context omitted.
i see, I didnt read it as a command but as a "We volitionally chose to solve the issue this way"
"Had to" usually implies coercion of a sort. Like you might say "in PE class we had to stand on one leg for 10 minutes".
"If I wanted the outcome I was aiming for I had to.... (workout?)" This is how I took the sentence. A totally volitionally accepted responsibility
1. "An Elegant Puzzle - Systems of Engineering Management" by Will Larson. His blog & "Staff Eng" posts are helpful as well. https://lethain.com/tags/staff-eng/ 2. "The Phoenix Project", "The Unicorn Project" (novels), and "DevOps Handbook" by Eugene Kim, on how different parts of a tech + non-tech organization come and work together. 3. "High Output Management" by Andrew Grove on overall technical management. 4. "Me…
8. "The Mythical Man-Month" by Fred Brooks (still, IMO, one of the best management books ever, esp. for software and product development.)
9. Boyd: The Fighter Pilot Who Changed the Art of War by Robert Coram (OODA is the true core of agile thinking, and it works pretty much everywhere.)
For software and computers specifically, add:
10. Computer Lib/Dream Machines by Ted Nelson (Impossible to categorize - it's a hypertext book for crying out loud - but browsing it can change your thinking.)
11. The Soul of a New Machine by Tracy Kidder. (Good for new products in general.)
And for general management and leadership inspiration, two great autobiographies:
12. Mover of Men and Mountains, by R.G. Le Tourneau.
13. Rickenbacker, by Eddie Rickenbacker.
Earlier quoted context omitted.
EDIT- Seems the below came from a misreading of the OP text, But i cannot delete it now that I'm downvoted... Please ignore. > Skills learned in the military are for war, learned for conflict situations and applying them to civilian environments and bringing a war mentality or attitude to a workplace is toxic. > only adds to the toxicity of a workplace What exactly was the toxicity besides your choice to overreact (s…
>besides your choice to overreact (stay overnight) It was not a choice. It was an order.
The best book on leadership I read was Jocko Willink's Extreme Ownership[1]. He was a career US Navy SEAL and bring a lot of great leadership approaches from the SEALS and correlates them to the business world. His principles lead back to the idea of taking extreme ownership of everything related to your team and the "mission". I really liked his no nonsense approach. The best lesson I learnt on leadership is to list…
When I was still a new dev, I had a "superboss" in another city (HQ) managing teams across the country including our little dev team. I was new and did not interact with "superboss"-es from HQ directly. One day after a major release stuff broke in production. The company was losing customers daily. The "superboss"-es from HQ descended on our little dev team in a small midwestern city and ordered "Code Red". What it m…
Earlier quoted context omitted.
>besides your choice to overreact (stay overnight) It was not a choice. It was an order.
A company can’t “order” you to stay overnight. Unlike the military you can walk away.
The best book on leadership I read was Jocko Willink's Extreme Ownership[1]. He was a career US Navy SEAL and bring a lot of great leadership approaches from the SEALS and correlates them to the business world. His principles lead back to the idea of taking extreme ownership of everything related to your team and the "mission". I really liked his no nonsense approach. The best lesson I learnt on leadership is to list…
This is an excellent concept and an important one to really get. I go out of my way to never use the phrase “my team.” It’s not my team, it’s all of ours. I’m a member of it, too.
It’s my job to make sure they succeed. So instead of “my team” I always say, “the team I support” to reinforce that.
A few things that have helped me. 1. Have a one-on-one meeting with every member of your team, for 30 minutes each week. They know when that meeting is coming up, and you know, so things that they want to tell you in private can come up then. 2. A good leader anticipates what his team is going to need before the team knows they need it. Try to do that. If there's a big release coming up next month, do what you can to…
Once a week is a lot in the age of Slack. I talk to my people asynchronously all the time, so the one-on-one is less important. Still do it though. I'll tell my single Golden Rule for managing people is to make sure they always know what's expected of them. Not knowing what's expected of you is probably the single greatest source of stress.
> Do you have any recommendation on what should I do, read to become better and better every day? It helps to write a hello world for every hot new tech out there. Not to follow trends, but to actually be knowledgeable enough to have a valid opinion. Think of yourself as a radio station who has to buy or at least sample every popular track. Crystal is hot? Set up a web server and connect to sql. Set up a Vert.X serve…
> These all take an hour max each day. um, what? If this is based on personal experience I would love to understand how. In my experience, Setting up a totally new development environment in an unfamiliar toolset generally takes waaaay more than an hour.
Do you have an example of a setup you got stuck on for hours?
1. "An Elegant Puzzle - Systems of Engineering Management" by Will Larson. His blog & "Staff Eng" posts are helpful as well. https://lethain.com/tags/staff-eng/ 2. "The Phoenix Project", "The Unicorn Project" (novels), and "DevOps Handbook" by Eugene Kim, on how different parts of a tech + non-tech organization come and work together. 3. "High Output Management" by Andrew Grove on overall technical management. 4. "Me…
Some good suggestions (and a couple I'll have to read...) I'd add the following: 8. "The Mythical Man-Month" by Fred Brooks (still, IMO, one of the best management books ever, esp. for software and product development.) 9. Boyd: The Fighter Pilot Who Changed the Art of War by Robert Coram (OODA is the true core of agile thinking, and it works pretty much everywhere.) For software and computers specifically, add: 10.…
On that note, I would also add another book about organizational psychology - how people game incentives, how cya evolved, how people focus on short term thinking over long term investments, problems common across big businesses, written by a sociologist embedded for a few years in a corporation, but I can’t for the life of me remember it.
But also:
The Secrets of Consulting” by Gerald Weinberg on generally thinking through ‘solutionizing’.
“Systemantics” by John Galt as a short and fun intro to applied systems thinking and cascading effects.
“We Need to Talk” by Celeste Headlee on how to have difficult conversations.
“Never Split the difference” on handling and understanding negotiations both up and down the chain.
Earlier quoted context omitted.
A company can’t “order” you to stay overnight. Unlike the military you can walk away.
People did walk away eventually. But not immediately because when you have a family, for instance, you can't leave a job without making sure you have health insurance etc., People eventually left once they found other jobs.