While I'm working my way through Management 3.0, here's two recommendations that will get to the point in rapid order, convey ideas in simple language without all the self referencing analogies, and be applicable to specific problems you may encounter on projects.
and
The Rocket Scientist book and related to the Martian Principles book are many ways more subtle than Management 3.0 and in other ways just plain blunt - do this is you'll be successful.
The Martian Principles book is about developing software at JPL for Mars landers, orbiters, and the Deep Space Network that supports them. This software is done in an agile manner, with emerging requirements. At the same time the software is subject to very high levels of formality. The software must integrate with a complex network of other software, all of which is emerging in parallel.
There are 19 principles are:
- Don't reinvent the wheel
- You won't do better than what's already been done
- Your customers don't know what they want
- Get something working as soon as possible
- Use sound software engineering practices
- Don't trust the client applications
- Plan to make changes
- You can't predict the future
- Don't tie your services in knots
- Build early, and build often
- "What middleware" should be your greatest compliment
- Expose the invisible
- Log everything
- Know the data
- Know when it will break
- Don't fail due to unexpected success
- Strong leadership drives project success
- Don't ignore the people issues
- Software engineering is about the D's - discovery, diplomacy, definition, design, development, debugging, documentation, deployment, dmaintenance.
Sound familiar? It should. The development of Deep Space Network (DSN) based missions is all about agile development inside the rigor of spaceflight. But most importantly this book is about how to "engineer" the solution. None of the fluffy "it'll emerge" crap. Make it emerge. The customer doesn't know, so have a process that moves the customer down the path of knowing. We're build Billion dollar mission in an emergent environment.
The Rocket Scientist book is a step-by-step process of how to approach complex problems. This complexity is real complexity - engineering complexity. This process has some simple steps:
- Dream - imagining, working on the big picture, aiming high, BS'ing, Brainstorming, creating the desire, telling a story, sleeping on it, and thinking like JFK.
- Judge - getting real, playing games, simulating, running thought experiments, knowing your limits, weighing ideas.
- Ask - asking dumb questions, asking big questions, asking what if questions, asking animal, vegetable, or mineral questions.
- Check - proving yourself wrong, inspecting for defects, having a backup plan, doing the sanity test, checking your arithmetic, knowing the risks, questions assumptions.
- Simplify - keep it simple stupid, draw a picture, make a mock-up, name the beasts, look at the little picture, do the math, apply occam's razor.
- Optimize - minimize the cost, minimize the time, be Mr. Spock, make it faster, better, cheaper (but not all three), know when bigger is better, let form follow function, pick the best people, make small improvements.
- Do - learn by doing, sharpen your axe, correct it on the way, do something, don't ignore trends, work on your average performance, look behind you, and learn from your mistakes.
These sub elements of each chapter have working examples you can apply to your own projects. No philosophy here, no high minded principles, just plain old engineering and program management practices.
Both these books make an assumption that is critical to understanding how complex systems are delivered. They are delivered through getting the right people on your program, getting the wrong people off your program, having the best skills and experiences, and never ever confusing effort with results.
This means "we're here to build something of value, if you want to grow your career, learn how to be a better person, come to understand all the philosophical aspects of developing software for money, do that on someones else's program." I want fully formed engieers who can work together as a team - after some forming, storming, and norming processes for sure. But then behave like a team. Jon Katezbach's team
A group of individuals who hold each other accountable for a shared outcome.
