These excerpts are from the book, ‘Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams’ authored by Mickey Mantle & Ron Lichty, published by Pearson/Addison-Wesley Professional, Sept. 2012, ISBN 032182203X, Copyright 2013 Pearson Education, Inc.
For more info please visit http://www.informit.com/title/032182203X%20or%20managingtheunmanageable.net
Want the whole thing? We’re giving away a free copy to one lucky member — find details on the Community Blog.
The Challenges of Managing
Managers must manage.
—Andy Grove, Former Intel chairman and CEO
I’ve used Andy Grove’s phrase innumerable times to coach my managers and directors of programming teams. When confronted with a problem, they can’t just “raise a red flag.” I’m always available when needed, but good software managers find ways to solve problems without my involvement or executive management direction.
Management is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant.
Drucker, born in 1909, is the man who has been called the “father of modern management.” He coined the term knowledge worker and predicted the rise of today’s information society and its need for lifelong learning.
A manager of years ago gave sage career advice: When you land at a new company, pick a gnarly problem—one that people have been avoiding—and solve it. It gets you up the learning curve,and it gains you credibility and respect, both of which you’ll need to be an effective developer and influencer.
—Dave Smith, agile software development coach
People hate change but love progress.
—Terry Pearce, author, Leading Out Loud
It is not enough to respond to change; we must lead change or be left behind.
—Pollyanna Pixton, Founder, Agile Leadership Network (ALN)
You miss 100 percent of the shots you never take.
—Wayne Gretzky, hockey Phenom
I have missed more than 9,000 shots in my career. I have lost almost 300 games. On 26 occasions I have been entrusted to take the game-winning shot and I missed. I have failed over and over again in my life. And that’s precisely why I succeed.
—Michael Jordan, Basketball Phenom
Trust your feelings, young Luke. The Force will be with you.
—Obi-Wan Kenobi, Jedi Master in Star Wars
We counsel many managers and programmers to listen to their intuition carefully; it’s usually right. The older I get, the more I regret those times when I don’t listen to my intuition. Programmers usually know the right things to do—if they allow themselves to trust their feelings.
Accountability is not micromanagement.
The author of 100 Questions to ask Your software Organization, speaking to the Best Practices SIG of the East Bay Innovation Group in 2006. We’ve always hated being micromanaged and thus have avoided being managers who micromanage. The challenge is to realize the line between micromanaging and holding your people accountable. Giving up micromanagement is not giving up expecting accountability.
Trust but verify.
President Reagan was referring to the Soviets during the Cold War with his frequent use of this translation of a Russian proverb that had been equally frequently quoted by Soviet founding father Vladimir Lenin. Perhaps it was because of that context that I didn’t pay attention until I heard another VP of Engineering use the expression in describing how he managed his team—and realized that it described my goal-state management style: my goal is absolutely no micromanagement, but enough checking to know that the delegation I’d done was appropriate.
One of the surest sources of delay and confusion is to allow any superior to be directly responsible for the control of too many subordinates.
—V. A. Graicunas
Graicunas was an early-twentieth-century management consultant and the first to mathematically analyze the complexity of increasing management responsibility. Graicunas showed that as span of control increases, the number of interactions among managers and their reports—and thus the amount of time managers must spend supervising—increases geometrically. His formula takes into account manager-to-report, report-to-report, and manager-to-all-combinations-of-reports interactions, and he posits that supervision time increases proportionately with interactions. He showed that by adding a fifth report, while the potential for accomplishing more work may increase by 20 percent, the number of potential interactions increases from 44 to 100— by 127 percent! Eight reports increases to 1,080 potential interactions and 12 reports to 24,564 to track and manage! Graicunas recommended that managers have a maximum of five reports, ideally four.
Managing Teams to Deliver Successfully
Software is hard.
Knuth is the acclaimed author of the art of Computer Programming. Here, he was quoted speaking to an audience of 350 people at the Technische Universitat Munchen.
Software isn’t released, it’s allowed to escape.
—Project management lay wisdom
. . . you’re not here to write code; you’re here to ship products.
Hofstadter’s Law: It always takes longer than you expect, even when you take Hofstadter’s Law into account.
Always take redundancy over reliability.
Too much data could be worse than no data at all.
The secret of software development has always been good people and lots of Chinese food.
— Jeff Kenton, Consulting developer and development manager
Lots of Chinese food or pizza. Critical projects or milestones often require extraordinary effort to be exerted by the programming team. It’s a simple thing that should be obvious: Programmers under schedule pressure will work long hours unless they are interrupted. Bringing in meals—Chinese food, pizza, or even meals from a great restaurant—keeps the programming team going. If you allow them to go out for food, their will to continue will erode and the extra effort will diminish.
Projects should be run like marathons. You have to set a healthy pace that can win the race and expect to sprint for the finish line.
—DD Catmull, CTO, Pixar animation studios
At Pixar, Ed Catmull, its co-founder, president, and CTO, encouraged me to manage my projects this way, and I’ve used this as a rule of thumb ever since. When interviewing new candidates, I make sure I find a way to bring this up so that I set the expectation that there will be times when the programmer will need to work very hard and sprint for the finish line and project completion, but also to set the expectation that I don’t expect them to “sprint” all the time.