Speakers Spotlight
1 HN recommender · recommended in 3 months, 2016–2022
9:48 · 536K views · Oct 15, 2013
Retired submarine captain David Marquet explains, with drawings, how he turned the USS Santa Fe around by treating his crew as leaders rather than followers. It summarizes the ideas of his book Turn the Ship Around.
Recommended as a short, illustrated take on empowering teams instead of giving orders.
3 comments from Hacker News
Here's the "Non-Bullshit Book on Culture" book this post discusses: Turn the Ship Around!: A True Story of Turning Followers into Leaders, by L. David Marquet Also here's a great speech given by the David Marquet (with drawings!) on the same topic: this video
I believe the take you see is mostly coming from enterprise developers that have witnessed the immense inefficiency and waste of larger organisations. The solution to a non-engineering savvy manager in such organization is to add more people and more frameworks. Mind you - to "them", these "dreaded MBAs", the development organization is a problem, often regarded as cost, and development is done by... developers. Sometimes the developers is the actual problem and they have gradually sunk the software in to a unmaintainable swamp of crappy code and debt - but this is a competency and hiring problem. It will not be solved by any framework or project manager. But you need the competency in your leadership to understand what's what and this is missing from pretty much any large org I've set foot in. The high functioning teams is these settings are more a stoke of luck, and they often have to utilize guerrilla tactics to keep delivering value. I've seen my fair share of global CIO's talking us through cloud and blockchain, never have to actually deliver and move on to the next company or fancy role. I've seen CIO/CTO not trusting developers and believing no-code and citizen development to be the end all. Guess what - more unmaintainable crazy stuff I've seen large organizations falling in to the "one system" trap on all levels, even trickling down to the software teams - a dedicated 8 person jira team for the whole org! What could possibly go wrong. I've also witnessed amazing auto
Saying "Yes" to one thing equals saying "No" to other things. Make the cost of the Yes-Es explicit and have the requesting parties prioritize whenever possible (or request prioritization from the decision makers). For the PM and boss: "to attend to this new task, I'll have to postpone these other tasks which you asked me to do. Which one is more important?" + paper trail + "this week we focused on Y and are pushing X one week" in status reports. For the peers and subordinates: if the request is legitimate, discuss, brainstorm, "Here's how I'd approach finding a solution, try it and check in when you find a few possibilities. Google and SO are your friends." And, for subordinates: teach them to think for themselves and to lead this video Of course sometimes you'll have to put out a fire. But if it's a small fire then you should be training your firemen on it.