Not the person you're asking, but I was actually somewhat underwhelmed by that book. Maybe I had unrealistic expectations, but I felt like it combined very general, obvious ideas ("keep teams together") with oddly specific numeric recommendations ("a manager doing technical work in addition to management can support at most five people") that didn't come with any good evidence beyond author opinion.
There were some things that I did find reason to take notes on, such as:
- Each area of responsibility should have a team dedicated to it, even if some teams end up having zero people in them, and sometimes members from other teams have to rotate into that function. I liked this because I know how easy it is to forget that some functions are understaffed if you squeeze them in with other functions.
- If you want to improve how the larger organisation works, run the improvement as an experiment in your team and then publish a very brief report on the results along with instructions for how other teams can try it. I liked this because I've often done the first part, but I've often forgotten the publishing part.
- A leader is asked to decide a million things a day. Your job is not the make those decisions, your job is to figure out a system in which the decision is not needed, or the right decision is clear for anyone to see, and then help others participate in that system. I knew this from before, but it bears repeating because it's so easy to forget in the heat of decision-making.
(The last point has a more general corollary: your job is never to do what you were hired for, it's to teach others how to do what you were hired for.)
I found "An Elegant Puzzle" brilliant because the advice was so specific and concrete on a wide range of topics. But I'd guess the target audience is a leader in a mid-size startup (100-500 employees), so its advice isn't going to be so much help outside that group.
There were some things that I did find reason to take notes on, such as:
- Each area of responsibility should have a team dedicated to it, even if some teams end up having zero people in them, and sometimes members from other teams have to rotate into that function. I liked this because I know how easy it is to forget that some functions are understaffed if you squeeze them in with other functions.
- If you want to improve how the larger organisation works, run the improvement as an experiment in your team and then publish a very brief report on the results along with instructions for how other teams can try it. I liked this because I've often done the first part, but I've often forgotten the publishing part.
- A leader is asked to decide a million things a day. Your job is not the make those decisions, your job is to figure out a system in which the decision is not needed, or the right decision is clear for anyone to see, and then help others participate in that system. I knew this from before, but it bears repeating because it's so easy to forget in the heat of decision-making.
(The last point has a more general corollary: your job is never to do what you were hired for, it's to teach others how to do what you were hired for.)