cover of the book: Managing the Unmanageable The Book: Managing the Unmanageable

Other-Language Editions
     Chinese Traditional (Sept. 2013)
     Chinese Simplified (in progress)
     Korean (in progress)

pointer to Ron's & Mickey's new video training Video Training: Managing Software People and Teams

Managing the Unmanageable:

Rules, Tools, and Insights for
Managing Software People and Teams

by Mickey W. Mantle and Ron Lichty

Addison Wesley, publishers
Paperback: 450 pages

order from Amazon

Section Title Page: Rules of Thumb and Nuggets of Wisdom

Rules of Thumb and Nuggets of Wisdom

The "soft, creamy center" of Managing the Unmanageable.

That's how one reviewer described the 80 pages of Rules of Thumb and Nuggets of Wisdom that are central to the book, despite their being printed on half-tone, not cream-colored paper. The hard part to assembling the collection was selecting which to include. We sought out as many relevant rules of thumb and incisive nuggets of wisdom as we could find: We asked our friends and colleagues, read books and articles, and searched websites. Then came time to pare them back to the essentials:

The three hundred most essential Rules of Thumb and Nuggets of Wisdom.

They're in the book. But in no way is our collecting finished... our collection will never be finished. There are many more out there - truly important Rules of Thumb that we haven’t read, seen, or heard (and a few that we regret we have forgotten) - plus Nuggets of Wisdom that have yet to be spoken and others that have not yet been shared.

Send us the Rules of Thumb and Nuggets of Wisdom that you manage by. We will include the best in a 2nd edition when there is one. In the meantime, we'll post them here...

More Rules of Thumb and Nuggets of Wisdom

A simple test that can help you decide if a shift into management is right for you: Consider the books you’ve read in the previous year. If you’re a programmer, and you read a bunch of programming, design and technical books last year, you’re probably not really interested in shifting toward management. If the thought of reading a management book strikes you as boring, you don’t want to be a manager. However, if you already find yourself reading that type of book instead of the more technical books you used to favor, you’ll likely thrive as a manager. Mike Cohn, agile author and thought leader, in his May 2017 newsletter

Mike says this is the test he puts to programmers who ask if they should move from a technical role into a management role, whether that role is a Scrum Master, development manager, QA director, or some other managerial role. Here's what Mike had to say about his own decision to become a manager: "I started my career as a programmer. After about five years as a programmer, though, I noticed that I was thinking more about how to manage the project than I was about writing code. I began to wonder if it might be time for me to pursue a project manager role. (This was back before agile, so yes, I mean project manager.) I talked about this with my boss and began to work with him to develop the skills I would need to make the shift to management. For years, I continued as half programmer / half management. I kept my hands in the code as long as I could. But, ultimately the decision to shift my career in the direction of management worked out well for me. I learned to get joy not from pointing to a part of the software and saying “look what I built,” but to pointing at the overall product and saying, “look what I enabled the team to build.” I noticed I’d fully become a manager one time when I was reading an in-depth book on the .Net framework and thought to myself, “I’m glad my team has to really know this stuff but I don’t.” I knew then that while I could still occasionally contribute as a programmer, it would no longer be my emphasis."

Software is complex and customers don't yet know what they want. Software plans are fiction, a guarantee that customers won't get what they actually want. Andy Wootton, CEng MBCS CITP, UK, 4/17 Agile and Lean Software Development forum post Gerstner & Day, in an article in the Journal of Applied Psychology, found that: "The relationship with one’s boss is a lens through which the entire work experience is viewed." Take a minute to re-read that. Your developers' entire work experience is viewed through you. You are their lens. Researchers found a significant correlation between the quality of relationship that developers have with their manager, and performance and satisfaction in the job. This agrees with Gallup’s finding that “managers account for 70% of variance in employee engagement.” Science of happy developers: How to boost your engineering team's mojo

Author Marcus Blankenship concludes: "managers who want to create high-performing teams and happy developers should cultivate high-quality, individual relationships with their team members." This article reinforces one of the key aspects of being a successful programming manager that resonates throughout our book Managing the Unmanageable. To effectively manage and motivate any programmer a manager must understand them completely: their education and background; their personal life situation; their interests; their expectations; their likes; their dislikes. All of these things embody an effective relationship. This article has some good tips on how to foster this relationship that echo similar insights from our book. In today’s world of increasingly flat organizations, it is surprising that the role of programming manager is being diminished as Tech Leads are given the dual responsibilities of being individual contributors and managers, with overall diluted results. As companies grow, developing and nurturing strong technical managers is critical to their success. Blankenship summarizes, "It's tempting to think that new languages, platforms and tools can solve your mojo problems, but they won't.... I've seen plenty of programmers working on old technology, with old processes, on old platforms, who love their jobs. When I ask them why, they tell me that they love their boss, company, and teammates. They feel their boss 'has their back,' and wants the best for them."

Great group communication... Real-time sometimes, asynchronous most of the time. Jason Fried, Founder & CEO of Basecamp (and the Campfire group chat and messaging tool), co-author of Getting Real, Remote, and REWORK

In his 2016 article, “Is group chat making you sweat?”, Jason points out the dangers of being in group chat all the time and suggests ways to avoid the on-going distraction that can occur when you allow group chat to dominate your communications. In the article he says: "Group chat feels like you’re chasing something all day long. What’s worse, group chat often causes 'return anxiety' —  a feeling of dread when you’re away for a while and you come back to dozens (hundreds?) of unread lines. And just when you’re caught up, you’re behind again.... It’s like you're working two jobs —  the work you’re supposed to do, and the work of catching up on what you missed that probably didn’t matter (but you won’t know until you read back).... I still think group chat is an important tool in the communications toolbox. I just don’t think it’s the go-to tool. I think it’s the exception tool. It’s far more useful for special cases than general cases. When used appropriately, sparingly, and in the right context at the right time, it’s great....

"At Basecamp our perfect-world rule of thumb is 'real-time sometimes, asynchronous most of the time'.... Basically, right now should be the exception, not the rule. That creates space and attention for the things that really do have to be discussed right now, and allows everything else to be thoroughly discussed asynchronously and thoughtfully over time. In Basecamp 3 we use the built-in campfire chat for occasional real-time communication while important asynchronous communication happens on message boards and comment threads that are attached to every object in Basecamp (to-do lists, individual to-dos, documents, announcements, check-ins, etc). Comment threads also keep things in-context since discussions about a to-do (or document or file or announcement or…) are permanently attached to that to-do (or document or file or announcement or…). This way you can easily refer back to any conversation about something you’re working on and be absolutely confident you have the whole story and the complete conversation in one place."

When you cancel one-on-ones and compensate with an open-door policy, your time investment mimics that of a call center employee who takes requests in the order they are received, instead of an effective manager and executive who aligns his time investment with his priorities. Elizabeth Grace Sounders, author of How to Invest Your Time Like Money, in her article, Cancelling One-on-One Meetings Destroys Your Productivity Most software managers began their careers as software developers. They either had some ambition, some skill recognized as good management material, or were in the right place at the right time. No one I know who manages software was trained to be a manager. Mark I. Himelstein, Interim VP Engineering, "Software Manager Basics", Dr. Dobb's Journal, June 2006 Reward systems in most large corporations are oriented toward existing businesses, with short-term considerations often outweighing longer-term innovation and market development objectives. But innovation can flourish only when risk-taking is encouraged, occasional failure is accepted and managers are held accountable for missing opportunities as well as for exploiting them. Cornelis A. de Kluyver, 1988, as quoted by Jim Spitze in his forthcoming book, The CIO Do not permit important activities to be implemented by a single individual without appropriate peer interaction; peers working together are the first and best line of defense against errors. NASA review board observation, in their investigation to identify the error that caused the 1999 Mars Polar Lander to vanish during the landing phase, as reported in Dr. Dobb's Journal, November 2006, p.75 People hate change and the way things are, in that order. Emily R Speer, Operations Executive, San Francisco Bay Area People do not resist change, they resist being changed. Peter Senge, director, Center of Organizational Learning, MIT Sloan School of Management Change equals Opportunity. Doug Carlston, founder and CEO, Broderbund Software

One of Mickey's favorite Rules of Thumb. Mickey recounts, “We were in the midst of the transition from MS-DOS to Windows 95 at Broderbund, and as we began strategizing what to do with our products Doug mentioned this Rule of Thumb to me in planning that transition. Of course, Doug didn’t really invent this Rule of Thumb, the Chinese character for Danger is the same as for Opportunity… so this idea probably goes back millennia. But he drove it home to me in the technical world, and I’ve embraced it ever since. Whenever there are “sea change” events, I look for the opportunities that can arise from them. I started my current company (Wanderful, Inc.) to take advantage of the sea change happening with the transition of Apps from computers to devices. It reminded me of how much I like Doug's quote. We refer to it in Chapter 6, but it deserves to loom large in the core Rules of Thumb section. Of course, finding the right opportunity to take advantage of when there is change is always the hard part. In my case, I think I have done that in spite of the hundreds of thousands of Apps that are being produced for tablets and smart phones.”

Anyone who has ever seen a programmer at work...knows that programming itself, if the programmer is given the chance to do it his way, is the biggest motivation in programming. Jerry Weinberg, author, The Psychology of Computer Programming In this day and age of informational ubiquity and nanosecond change, teamwork remains the one sustainable competitive advantage that has been largely untapped. Patrick Lencioni, author, Field Guide to Overcoming the Five Dysfunctions of a Team Multitasking is the fastest way to get nothing done. Johanna Rothman, author of Agile and Lean Program Management: Scaling Collaboration Across the Organization, in a July 2015 interview with Matthew Heusser of CIO magazine, Getting serious about portfolio and program management. Also see her blog post, Cost of Delay Due to Multitasking. If you are a senior manager, don't think you can scrimp on training if you want the cultural and project changes. Agile and Lean are culture changes, not a project management framework. If you want the organization to become Agile, you need to become Agile. Johanna Rothman, author of Manage It!, in a July 2015 interview with Matthew Heusser of CIO magazine, Getting serious about portfolio and program management The measure of success is not whether you have a tough problem to deal with, but whether it is the same problem you had last year. John Foster Dulles, U.S. secretary of state under President Dwight Eisenhower …it is much better to lead people, not to drive them. Drive yourself if you must. But not anyone else. Kelly Johnson, fabled founder and leader of Lockheed’s famous Skunk Works (which created such legendary planes as the P-38 in WWII and the SR-71 Blackbird), Kelly: My share of it all, by Clarence “Kelly” Johnson and Maggie Smith, p.30 You know what’s more expensive than hiring good developers? Losing to your competition. Sam Ramji, CEO of Cloud Foundry Foundation, in a CIO magazine 2016 interview The efficiency of a team is approximately the inverse of the square of the number of members in the team. Marc Hedlund, VP Engineering, Stripe, quoted by Ash Maurya, author of Running Lean

Maurya, after quoting Hedlund in his blog post, “Expose Your Constraints Before Chasing Additional Resources,” summarizes Hedlund's point, "Simply adding more people decreases team efficiency. This is why Jeff Bezos instituted a two-pizza team rule at Amazon: Any team should be small enough that it could be fed with two pizzas." Maurya poses his own rule for constraining resources when you don't yet know what you're doing, "When there is high uncertainty, it is prudent to limit resources until you gain more certainty." Kent McDonald, author of Beyond Requirements, who called out Maurya's rule of thumb in his September 2016 webinar, “The 3Ds of Scaling", compared it to an earlier quote from Albert Einstein, "If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

The culture of any organization is shaped by the worst behavior the leader is willing to tolerate. Steve Gruenert and Todd Whitaker, School Culture Rewired, ch. 3 (2015)

What leaders do - and what we don't do - matters.

CFO: What happens if we invest in training our people and they leave us?
VP Engineering: What happens if we don't, and they stay?

Exactly.

Agile is about continually getting better. I don’t care how good a team is today; if they aren’t better a year from now, they’re not agile. Mike Cohn, agile author and thought leader, in his September 2016 newsletter It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.. Steve McConnell, Software Project Survival Guide, p.103 You’ve got to start with the customer experience and work back toward the technology - not the other way around. Steve Jobs, 1997 World Wide Developers Conference The problem with quick and dirty... is that dirty remains long after quick has been forgotten. Steve McConnell, Software Project Survival Guide, p.127 Here’s the litmus test: If you’re spending more time on bugs than you are on functionality, then you need to rethink the implementation and start over. Stefan Estrada, engineering manager at Verizon who oversees a team of five developers working on the OnCue streaming TV service If you are not fired with enthusiasm, you will be fired with enthusiasm. Vince Lombardi, coach What if every coding interview was an uplifting experience that left both parties more knowledgeable and grateful for the opportunity? David Vydra, software craftsman, TestDriven.com, in an April 2016 Tweet The point is not to do Agile. The point is to be effective. Agile provides us insights. Al Shalloway, agile author It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity. Jeff Atwood

From a blog piece Jeff writes called “The Best Code is No Code at All”, wherein he extols the virture of writing less code, not more. Once more emphasizing the difficulty of measuring programmer productivity. Less is more…

The 80/15/5 rule for programmers: Spend 80% of your time on low-risk/reasonable-payoff work. Spend 15% of your time on related high-risk/high-payoff work. Spend 5% of your time on things that tickle you, regardless of payoff. Teach the next generation to do your 80% job. By the time someone is ready to take over, one of your 15% experiments (or, less frequently, one of your 5% experiments) will have paid off and will become your new 80%. Repeat. Kent Beck, Smalltalk programmer and creator of Extreme Programming The effort required to create a new system that is functionally equivalent to its predecessor is typically vastly underestimated. Mitch Abaza, in his blog post, "When Does a System Rewrite Make Sense?"

My own rule of thumb: triple your worst-nightmare estimate, and you'll be about right. If you're still thinking about it, read Mitch's entire blog post. And also read Dan Milstein's post, "How To Survive a Ground-Up Rewrite Without Losing Your Sanity, aka: Screw you Joel Spolsky, We're Rewriting It From Scratch!"

In the case of rewrites, ... the estimates are often wildly optimistic - largely because few teams have any real experience with true rewrites. Marty Cagan, author, Inspired: How To Create Products Customers Love, California: SVPG Press, 2008, p.28

Marty notes, "at some point, if you neglect [it], all software will reach the point where it can no longer support the functionality it needs to.... If you haven't yet reached this situation, here's what you need to do to make sure you never do - you need to allocate a percentage of your engineering capacity to what we at eBay called 'headroom'.... The deal with engineering goes like this: Product management takes 20% of the team's capacity right off the top and gives this to engineering to spend on... whatever they believe is necessary to avoid ever having to come to the team and say, 'we need to stop and rewrite'.... I get nervous when I find teams that think they can get away with much less than 20%." The alternative is a massive rewrite during which feature progress comes to a halt. "This situation... happened to eBay in 1999, and the company came far closer to collapsing than most people ever realized. It happened to Friendster, opening the door for MySpace to take over social networking. It happened to Netscape during the browser wars with Microsoft, and everyone knows who won. The truth is that most companies never recover."

The deal with engineering goes like this: Product management takes 20% of the team's capacity right off the top and gives this to engineering to spend on... whatever they believe is necessary to avoid ever having to come to the team and say, 'we need to stop and rewrite'.... I get nervous when I find teams that think they can get away with much less than 20%. Marty Cagan, author of the product management bible, Inspired: How To Create Products Customers Love, California: SVPG Press, 2008, p.28

Marty notes, "at some point, if you neglect [it], all software will reach the point where it can no longer support the functionality it needs to.... If you haven't yet reached this situation, here's what you need to do to make sure you never do - you need to allocate a percentage of your engineering capacity to what we at eBay called 'headroom'.... The deal with engineering goes like this: Product management takes 20% of the team's capacity right off the top and gives this to engineering to spend on... whatever they believe is necessary to avoid ever having to come to the team and say, 'we need to stop and rewrite'.... I get nervous when I find teams that think they can get away with much less than 20%." The alternative is a massive rewrite during which feature progress comes to a halt. "This situation... happened to eBay in 1999, and the company came far closer to collapsing than most people ever realized. It happened to Friendster, opening the door for MySpace to take over social networking. It happened to Netscape during the browser wars with Microsoft, and everyone knows who won. The truth is that most companies never recover."

The single worst strategic mistake that any software company can make: rewrite the code from scratch. Joel Spolsky, in his Joel-on-Software post, "Things You Should Never Do"

Take heed!

Optimistic programmers might think I’ve missed something important here. If you’re rewriting a system, you’ve already got the code. The code can serve as the spec, right? Probably not. Based on my own experiences and conversations with thousands of software developers around the planet, I unscientifically conclude that almost all production software is in such bad shape that it would be nearly useless as a guide to re-implementing itself. Chad Fowler, in his blog post series, "The Big Rewrite" It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point - you're not here to write code; you're here to ship products. Jamie Zawinski, in Peter Seibel's Coders at Work: Reflections on the Craft of Programming, (c) 2009, p.22 Latency reduction is... a form of compound interest. Edmund Jorgensen, "Speeding Up Your Engineering Org, Part I: Beyond the Cost Center Mentality"

Jorgensen, in making the case for latency reduction (often also known as paying down technical debt), notes that "big rewrites tend to be a terrible investment.... The 'rewrite reflex'... is, unfortunately, a real and dangerous tendency that almost all engineers have to some extent.... Almost certainly you... don’t want to commission a full-on rewrite." Rather, he notes, you want to commission "a steady, incremental investment in testing, monitoring, and refactoring.... You should insist on smaller, incremental latency improvements, not just because of all the normal, eminently true reasons that big increments are bad (everything that makes waterfall a bad idea applies here too), but because... finished latency reduction efforts tend to speed up future latency reduction efforts. Latency reduction is... a form of compound interest, which Einstein himself called 'the most powerful force in the universe.'"

The most dangerous phrase in the language is, 'We've always done it this way.' Admiral Grace Hopper A leader is best when people barely know he exists. When his work is done, his aims fulfilled, they will all say: we did this ourselves. Lao Tzu

One of my programmers at one of my large corporate gigs came to me one day and said he didn't think his team needed a manager. He was just 22, the youngest member of his team, but I'd already hired him three times as an intern (in one of those he became our team's internal expert on the microprocessor change we were then making), into a second company to tackle the worst of our code issues, and now into this third company. His teammates were like him. They were self-directed. They worked well with the business. They did amazing work. He was right: they did not need to be managed. In fact, I was doing little managing of them. What was my role? As I showered the next morning, girding myself, as I did every day, for defending and advocating on behalf of my teams, I realized how lucky my team was that they had no idea of what I did on their behalf every single day.

Poor staffing is worse than no staffing at all. Bruce Borden, founder and technical leader of 3Com, the first of 3 startups with 3 successful exits; manager of the first workstation development at Silicon Graphics in 1983; and chief scientist at General Dynamics

Bruce, in his talk to the Silicon Valley Engineering Leadership Community meetup in 2016, shared seeing a high-functioning team of five lose 30 percent of its productivity when the wrong three people were hired to grow the team from five to eight. He adds, "A corollary to the staffing rule is that team productivity is much more important than team size."

Repair or replace Robert Sher of CEO to CEO

This is Sher's "mantra" regarding toxic team members. He explains, "Flawed team members cannot be left alone. If they are repairable in a short time frame, it is worth the effort. But this must be a forced march, with a firm timeline for repair. Otherwise plan to make the replacement quickly, as teams with toxicity are more likely to fail to hit their objectives. That hurts the team, the company and damages the reputation of the team leader."

Jobs at startups are pass-fail: you’re either doing your job and you stay; or you're not and you have to go. Bruce Borden, founder and technical leader of 3Com, the first of 3 startups with 3 successful exits; manager of the first workstation development at Silicon Graphics in 1983; and chief scientist at General Dynamics

Bruce, in his talk to the Silicon Valley Engineering Leadership Community meetup in 2016, shared this simple performance review formula for engineers on his teams. He adds, "in a large company, the cost of recruiting and training justifies working with under performing employees, and there are some great examples of employees simply in the wrong position or team (personalities) who flourish with job reassignment & coaching."

If you’re just using your engineers to code, you’re losing half their value. Marty Cagan, author, Inspired: How To Create Products Customers Love, and founding partner of the Silicon Valley Product Group

In delivering his comments to a web-product corporate audience in 2016, Cagan continued, “The single biggest innovator in many companies is the tech lead.” Cagan drove this point and another about collocation home by pointing to three chairs next to each other at the front of the audience... "I want to see the product manager, the UX designer and the tech lead sitting this close. You should consider these three people your co-product owners."

If you don’t put them [bugs] in, you don’t have to take them out. Dave Cutler, System Programmer, Microsoft and, earlier, Digital Equipment Corporation, on the occasion of his being named a Computer History Museum Fellow in April 2016, commenting in MSpoweruser.com

Dave continued, “I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none.” Dave Cutler is one of the greatest (and possibly the greatest) Systems Programmer. His legacy includes designing and implementing three of the greatest operating systems ever: Digital’s RSX-11M, VMS, and Microsoft’s Windows NT (the basis for all Windows operating systems ever since). Additionally he did hardware design for Digital's MicroVAX chip, designed and implemented Microsoft Azure cloud services, and designed and wrote the hypervisor for Xbox One.

When I first wrote The Mythical Man-Month in 1975, I counseled programmers to "throw the first version away," then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised. Fred Brooks, in an interview with Kevin Kelley, Wired, August 2010, "The Master Planner"

It's no surprise to find Fred Brooks espousing the principles of agile and lean.

Start with a vision, rather than a set of features.... Great design does not come from great processes; it comes from great designers. Fred Brooks, in an interview with Kevin Kelley, Wired, August 2010, "The Master Planner"

Fred went on to say, “Edwin Land, inventor of the Polaroid camera, once said that his method of design was to start with a vision of what you want and then, one by one, remove the technical obstacles until you have it. I think that’s what Steve Jobs does. He starts with a vision rather than a set of features.”

The critical thing about the design process is to identify your scarcest resource; then you have to make sure your whole team understands what scarce resource you’re optimizing. Fred Brooks, in an interview with Kevin Kelley, Wired, August 2010, "The Master Planner"

Elaborating, Fred continued: “Despite what you may think, that (scarce resource) very often is not money. For example, in a NASA moon shot, every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage.”

For 10 people, don’t devote anyone to engineering effectiveness.” [People will figure out what they need on their own.]
    “For 100 engineers, devote two people” [to making tools and other support better] “and they’ll be as productive as 101 engineers.”
    “In a group of 1000, 255 engineers need to support the rest, and they’ll be as effective as more than 1400 engineers.
    “And in a group of 10,000 (the size of Facebook’s engineering team), one-third of the engineers need to be working on engineering effectiveness.
Peter Seibel, Tech Lead of Twitter’s engineering effectiveness group, Twitter's Tips for Making Software Engineers More Efficient, IEEE Spectrum A good guiding principle is “Don’t motivate people – remove the demotivators”. If people see you removing real impediments and creating a high-trust environment that helps them work effectively – that will probably motivate them a lot more than things like hawaiian t-shirt fridays, free drinks, and ping-pong tables. Henrik Kniberg, What is an Agile Leader? Done is better than perfect. Mark Zuckerburg

A variant of “Perfect is the enemy of good” and “Always aim for the best result possible, not the best possible result.”

In the tech industry we overestimate what we can achieve in one year, but underestimate what we can achieve in 10 years. Bill Gates ...it comes back to worse is better. If you spend the time to build the perfect framework... well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you're out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor's six-month 1.0 has crap code and they're going to have to rewrite it in two years but, guess what: they can rewrite it because you don't have a job anymore. Jamie Zawinski, in Peter Seibel's Coders at Work: Reflections on the Craft of Programming, (c) 2009, pp.22-23 Why I really need pair programming: it forces me to sit down for three solid hours, or even two or one solid hour, and work on one thing with somebody else, and they force me to not be bored. Brad Fitzpatrick, in Peter Seibel's Coders at Work: Reflections on the Craft of Programming, (c) 2009, p.73 ...taking testing... to the ultimate: going to visit customers... having to go live with a customer for a week... a huge amount of insight into what it's like to actually use our stuff.... Going back afterwards, developers who had not had that experience all seemed arrogant to me in a way which was completely inexcusable. The lack of respect they had for the people who used our stuff was appalling. Douglas Crockford, in Peter Seibel's Coders at Work: Reflections on the Craft of Programming, (c) 2009, p.123 You have to decide what your highest priorities are and have the courage - pleasantly, smilingly, nonapologetically - to say 'no' to other things. And the way to do that is by having a bigger 'yes' burning inside. Stephen Covey Good ideas are not adopted automatically. They must be driven into practice with courageous patience. Hyman Rickover, American admiral (1900–1986), cited in the opening of Jurgen Appelo's 2014 Management 3.0 book I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler Apple's focus, from the very beginning, has been on the end-user's experience and not on the technology. Steve Jobs famously answered a kind of nasty question at a WWDC more than a decade ago about why he'd killed a particular software product by explaining that the hardest thing about what Apple did was to not try to make a product out of "technology", but to figure out what kind of product they did want to make and then use the technology to do it. David Schlesinger, former Apple networking engineering manager Everyone sits in the prison of his own ideas; he must burst it open. Albert Einstein, theoretical physicist

Mickey relates, “Too many times I have seen, in retrospect, that challenging the status quo and pushing the edges of the envelope would have been the best thing to do. It is hard to innovate without breaking out of that prison of our own ideas. I wish I had learned earlier in my career to push harder and more often to break out of that box I put myself in."

You can't connect the dots looking forward; you can only connect them looking backward. So you have to trust that the dots will somehow connect in your future. ... This approach has never let me down, and it has made all the difference in my life. Steve Jobs, entrepreneur We need workplaces that harness people’s intrinsic motivation. Leaders have to get out of the way. Stop directing and supervising... Nurture and steward people on a quest. John Verdon, Former Futurist for Canadian National Defense, Complexity and Foresight Consultant The real hero is the guy who did the first draft. David C. Evans, Founder and CEO, Evans & Sutherland

It's always easier to edit than to create the first draft. Hence the importance of this Rule of Thumb. This was related to Mickey by Rod Rougelot, after Mickey asked him if he had a list of Innovations that E&S had created. Rod was the GM of the Simulation Division of E&S and succeeded Dave as CEO after he retired. As Rod recalled "Dave used to say that the real hero was the guy who did the first draft. Be the hero, and perhaps if you plant a few seeds and engage some of the old timers in a collaborative effort, the list will materialize."

Agile planning is deceptive. I’m always amused, and sometimes saddened, by the lack of understanding about agile planning... First, agile teams do a lot of planning, but it is spread out much more evenly over the entire project. Second, agile teams squarely face the critical factor that many non-agile teams ignore—uncertainty. Jim Highsmith, Agile Practice Director, Cutter Consortium, in his Foreword to Agile Estimating and Planning

Highsmith adds, "Is planning important?—absolutely. Is adjusting the plan as knowledge is gained and uncertainty reduced important?—absolutely. I’ve gone into too many organizations where making outlandish early commitments, and then failing to meet those commitments, was acceptable, while those who tried to be realistic (and understanding uncertainty) were branded as “not getting with the program,” or “not being team players.” In these companies failure to deliver seems to be acceptable, whereas failure to commit (even to outlandish objectives) is unacceptable. The agile approach... is focused on actually delivering value and not on making outrageous and unachievable plans and commitments. Agile developers essentially say: We will give you a plan based on what we know today; we will adapt the plan to meet your most critical objective; we will adapt the project and our plans as we both move forward and learn new information.... Many traditional planners don’t understand a key concept—you can’t “plan” away uncertainty.... Many project management approaches appear to be “plan, plan, plan-do.” Agile approaches are “plan-do-adapt,” “plan-do-adapt.” The higher a project’s uncertainties, the more critical an agile approach is to success."

It should be clear that no manager, no architect, no designer, no matter how lofty, can precisely estimate just how many features can be done by how many programmers in how much time. Ron Jeffries, in his 2005 blog post, "Making the Date" For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We’ve been rather successful at transformation, often while operating outside our control envelope. Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been. Tom DeMarco, Why does software cost so much? And other puzzles of the Information Age, New York, NY: Dorset House Publ., 1995, p. 95 Software people are not alone in facing complexity. Physics deals with terribly complex objects even at the “fundamental” particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unified field theories. Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary.
    "No such faith comforts the software engineer. Much of the complexity that he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God.
Fred Brooks, in his 1986 paper on software engineering, "No Silver Bullet — Essence and Accidents of Software Engineering", which is included in the anniversary edition of his book, The Mythical Man-Month It’s not that we don't have enough time. We have too much to do. Chet Hendrickson, member of the very first XP project team

Ron Jeffries in his 2005 blog post, "Making the Date", remembered, "A long time ago, on the very first XP project, we were faced with a huge pile of things to do, and it was clear that we didn’t have enough time. We were pretty much in a panic. Then Chet Hendrickson [made the above observation]. That change of outlook changed everything. It focused us on what we could do.... A project needs to start with more goals than can be accomplished. It’s only by looking at a wide range of possible ideas that we can be sure we’ve got the important ones. Then, we need to decide which ones we really need. And then, informed by reality, we need to decide which ones we can actually have."

Courage is the first virtue that makes all other virtues possible. Aristotle If you just work on stuff that you like and are passionate about, you don’t have to have a master plan with how things will play out. Mark Zuckerberg Dead silence is a fairly reliable indicator of a project with productivity problems. Randall W. Jensen, Improving Software Development Productivity: Effective Leadership and Quantitative Methods in Software Management (Prentice Hall, 2015), p.26

Jensen, in forging an approach to measuring productivity impact, identified coherent, iterative, effective communication as one of just three factors that can significantly impact productivity. Jensen cites Alistair Cockburn for his analogy of "convection currents" for communication flow in a development environment. "'Convection currents' of information move about a work area just like the movement or dispersion of heat and gas. Air moves freely through an area unless the air is blocked or diverted by an obstruction. Information moves in precisely the same fashion." Jensen goes on to indict facilities planners for the uniform cubicle-grid layout so prevalent in space planning today. "The cube farm, as it exists today, virtually eliminates information convection." But he holds his highest disdain for distributed software development. "People have at least some physical contact when in adjacent cubicles."

Ideally, you want to co-locate your developers and stakeholders to improve their ability to collaborate and communicate, thereby reducing cost (they don't need to document as much) and risk (you increase the chance that they understand each other) on your project. Scott W. Ambler, "Imperfectly Agile: You Too Can Be Agile!", Dr. Dobb's Journal, October 2006, p. 82 Optimism is still widely used as a management tool. Randall W. Jensen, Improving Software Development Productivity: Effective Leadership and Quantitative Methods in Software Management (Prentice Hall, 2015), p.13 Poor management can increase software costs more rapidly than any other factor. Barry Boehm, Software Engineering Economics (Prentice Hall, 1981), p.486 Work doesn't have to suck... it can be an expression of joy, an alignment toward a higher purpose. Jeff Sutherland, co-creator of Scrum, in his book, Scrum: The Art of Doing Twice the Work in Half the Time, p.39 What can companies do to create an atmosphere in which people thrive? Managers can encourage autonomy by letting people make their own decisions about their job. And they can make sure that employees know everything that's going on, because, as they put it, 'Doing your job in an information vacuum is tedious and uninspiring.' Managers should also have zero tolerance for incivility and never allow an employee to poison corporate culture through abuse or disrespect. And, finally, they should give quick and direct feedback. Jeff Sutherland, co-creator of Scrum, in his book, Scrum: The Art of Doing Twice the Work in Half the Time, p.162

Sutherland goes on regarding his core topic, "Scrum gives people all those things. It's set up to make them happen, especially the direct feedback, which happens every day in the Daily Stand-up meeting, and which is what the Sprint Retrospective and the Happiness Metric are designed to illuminate." What is important about Sutherland's book is not the recounting of the practices - there are no end of books that provide those - but the spirit of agile and of scrum that pervades his thinking now - and obviously did back then.

Producing the instructions with the keyboard is not where the work happens. The work is in interpreting the requirements, producing and testing the design, correcting faulty reasoning, coordinating the work with others working on the task, and producing the documentation. Randall W. Jensen, Improving Software Development Productivity: Effective Leadership and Quantitative Methods in Software Management (Prentice Hall, 2015), p.8. ...no matter how excellent your technicians, you who are leaders must strive for advances in the improvement of product quality and uniformity if your technicians are to be able to make improvements. The first step, therefore, belongs with management. First, your company technicians and your factories must know that you have a fervor for advancing product quality and uniformity and a sense of responsibility for product quality. Nothing will come of this if you only speak about it. Action is important. W. Edwards Deming, 1950, in a talk to Japanese business leaders

Deming is often cited as the single most important thought leader responsible for rebuilding the Japanese economy after WWII, introducing the concepts of "lean" manufacturing and launching the Japanese automotive (and other) industries on a trajectory to outperform every competitor in the world. His famous PDCA cycle - Plan, Do, Check, Act - at the time a radical idea - is the basis not only for Lean manufacturing but for all of Agile product development, including Scrum, Extreme Programming and Kanban.

The important thing is not your process. The important thing is your process for improving your process. Henrik Kniberg, agile trainer and author At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you're doing is heading in the right direction, and if it's actually what people want? And question whether there are any ways to improve how you're doing what you're doing, any ways of doing it better and faster, and what might be keeping you from doing that. Jeff Sutherland, co-creator of Scrum, in his book, Scrum: The Art of Doing Twice the Work in Half the Time, p.9 Scaling a process-based organization is a thoughtful pursuit; scaling a hero-based environment is insanity. Richard Sheridan, founder of Menlo Innovations in Ann Arbor, in his book, Joy, Inc.: How We Built a Workplace People Love, p.201

Rich makes clear in his book that by "scaling", he means both scaling up and scaling down. Hero-based environments are even harder to scale down than up!

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse. Michael Feathers, author, Working Effectively with Legacy Code In the absence of a strategy, every tactic is of equal value. Mark Miller, author, The Heart of Leadership A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. . . . W. Edwards Deming, The New Economics, 1994, MIT Press The agile methods are deceptively simple and common sense oriented. In many ways, that’s one of their great strengths, but it’s also one of their fundamental weaknesses. I see so many teams convinced that they can “go Agile” just by reading a book or an article and then diving in and “sprinting” towards successful software delivery. The logic goes that agile is simple common sense practices, self-directed, and intuitive—so of course it will be simple to pick up and execute.... These teams adopt a small, superficial, and somewhat trivial set of the core agile practices and then think they’re agile. In almost every case they don’t understand the agile mindset nor how the core principles and practices complement one another to foster improvement. They’re “doing Agile”, but they’re not “being Agile”. Robert 'Bob' Galen, "The Agile Project Manager: Agile Basic Training – What Is an Acceptable Level?", Executive Brief, September 2012 Agile’s wins don’t come from learning drills and nomenclature but in meaningfully applying them – which requires understanding the meaning behind the drills – application of agile’s principles to the unique culture and challenges each team and each company faces. Ron Lichty, "Colleges: Teach the “How”!", Silicon Valley Project Management blog, UC Santa Cruz, June 4th, 2013 Any agile transformation is one management change away from failure. Brent Barton, now with Rally, then w Solutions IQ, as quoted by agile and management coach Earl Everett When a programmer says, 'it works on my machine', grab their machine and ship it to the customer! Richard Sheridan, founder of Ann Arbor-based Menlo Innovations, speaking to the Bay Area Agile Leadership Network (BayALN), May 20, 2014

Sheridan, making the case, as nearly all agilists do, that teams must agree on a common definition of 'done' and live up to the standard they set, noted that teams are otherwise subject to the fact that 'programmers have as many words for "done" as Eskimos have words for "snow".'

Is it Done done? Jeff Freund, Founder and CTO, Clickability

Jeff notes,
   done == it works
   Done done == it is ready for production (tested, validated, signed-off on, ready to roll!)
This is a fun one as it applies broadly across the entire business. Sales guys get really excited about stuff like verbal commitments. But you can't stop pushing until things are truly Done done.

As you gain more agility you have to have more discipline - they have to go together. Ryan Martens, founder and CTO, Rally, speaking at Silicon Valley AgileCamp 2014

Martens says agile needs to become a biorhythm throughout the organization, and urges companies to extend agile beyond execution teams.

When teams self-organize there's still plenty for managers to do... a manager's job is to engineer the organization so that teams can do their best work. Esther Derby, co-founder, Scrum Alliance, and co-author, Behind Closed Doors Managers are still needed. Not so much for their planning and controlling ability, but for the important job of interfacing on the team’s behalf with the rest of the organization. Diana Larsen, co-author, Agile Retrospectives A common misconception is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. Mike Cohn, Succeeding with Agile

Managers have a critical role to play: in the success of transitions to agile - and in the success of agile. But have you ever had a scrum trainer who drew the picture of a scrum team and drew in a manager? Instead we do 2 days of training the team and leave managers scratching their heads wondering what their role is.

Lean-Agile management is the art of leading people, not managing them... Leading people involves creating the correct environment, focusing them on the right things, and trusting them to do their work... In Lean-Agile, the manager has two primary responsibilities: setting the outcomes or goals expected of the team; assisting the doers in creating a better process and workspace to get their jobs done... The Lean-Agile manager should be relentless in raising awareness of the two biggest wastes in software development: delays and building what is not needed. Alan Shalloway, Net Objectives, and author, Lean-Agile Software Development

Sounds like three primary responsibilities to me! (or is that four?) Regardless of number, they're important, needed stuff.

If you have to change your unit tests when you refactor code, you are probably doing more than refactoring. Paul Watt, Software Architect, in his blog post, An Eye on Refactoring

Paul writes, "Refactoring is not intended to mean rework, re-implement, or create version 2.0. You are merely supposed to simplify the structure of your program while keeping the same functionality set. This is where unit tests are very valuable to help insure you do not break things that were previously working. A good rule of thumb, if you have to change your unit tests when you refactor code, you are probably doing more than refactoring."

As soon as you move one step up from the bottom, your effectiveness depends on your ability to reach others through the spoken and written word. Peter Drucker Users will often ask you for a solution when it would really be more helpful to tell you that they have a problem. Laura Klein, "6 Reasons Users Hate Your New Feature"

"The upshot is that users aren’t great predictors of which brand new features will be big hits. Sometimes users will tell you that they want a toaster in their car, when what they really mean is that they don’t have time to make breakfast in the morning. Before building a new feature that your customers are demanding, ask yourself, 'What known user problems is this solving, and is this the best way to solve it for everybody?'"

As we look ahead into the next century, leaders will be those who empower others. Bill Gates Sometimes the only way to find out what customers want is to give them what they ask for. Dennis Pozzi, Operations Engineer, Adobe Systems 5 management tips from Microsoft CEO Steve Ballmer:
       1. Make sure you see the whole playing field
       2. Don't pin hopes on a single individual or "dream team"
       3. Realize there's no perfect business model perfect for every era
       4. Don't place only long-term or only short-term bets
       5. Know your limits
Fortune, December 12, 2013

As an admittedly business/sales-focused guy, Ballmer delivers advice applicable not just for tech CEOs. His lessons learned should carry weight, argues Microsoft watcher, Wes Miller, an analyst at research outfit Directions on Microsoft, Kirkland, Washington.

What makes a good developer a great developer is willingness to take risks. You can measure a developer's willingness to take risks by the frequency they check into source control. Source control is their safety net. Ike Ellis, in his talk on "Continuous Integration", Silicon Valley Code Camp 2013 The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten. Anonymous

Shared with us by Kimberly Wiefling and Irina Elent

Recent research from Harvard professor Leslie Perlow found that forcing Boston Consulting Group consultants to unplug one night a week increased their productivity and job satisfaction. Michael Healey, "IT Doesn't Hate End Users: Tech is accepting the benefits of consumerization", InformationWeek, May 28, 2012, p.29 I never hire candidates - for any position - from whom I've been unable to learn something during our interview. Ron Lichty

I now approach interviewing candidates as an opportunity to learn. It took me some time, as a manager, to learn this: There is no position I've ever interviewed candidates for - whether technical or business or an admin assistant - that I shouldn't expect to get value and insight from a good candidate. It has become a litmus test in my hiring.

I had a golden opportunity to test some of the prevalent folk wisdom about hiring. The results were pretty surprising... Of many attributes I tested, the three that achieved any kind of statistical significance were 1) grammatical errors/typos/syntactic inconsistencies, 2) whether the candidate worked at a top company and 3) whether you could tell from their resume what they did at each of their previous positions. Two out of the three attributes, in other words, had to do with a candidate's written communication skills.... Aline Lerner (former programmer, turned recruiter) in her blog post Lessons from a year’s worth of hiring data

Given her finding, Aline recommends, to hire the right software developer, get a writing sample! ("it should be a concise description of something [the developer] worked on recently that [he or she is] excited to talk about as explained to a non-technical audience.") Read her blog post: she also debunked other folk wisdom (revealing, for example, that while top-company pedigree is linked to success, undergraduate pedigree is not!).

Task-switching penalty = Mechanics of moving to a new task
      + Rework due to inopportune abort
      + Immersion time for think-intensive tasks
      + Frustration (emotional immersion)
      + Loss of team binding effect.
Tom DeMarco, author, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency Create the right balance between rewarding teams and rewarding heroes, and you'll have many team members willing to save the day, but few times when you need them to do so. Mickey and Ron

OK, we said this on p.341. It's in the book already. But we keep finding ourselves talking about rewards and about being careful what you reward - about rewarding teamwork and about using care before rewarding heroes. We realized with this simple statement, we had captured that complexity.

If everything's a priority, then nothing is a priority. Sheila Brady, then system software program manager at Apple

When Sheila shared this with me at Apple, I realized I was in the presence of an especially wise sage - and recognized the power of a rule of thumb, possibly for the first time. Lack of prioritization is one of the banes of our existence, as developers. Prioritization is essential.

The manager's function is not to make people work, but to make it possible for people to work. Tom DeMarco and Timothy Lister, Peopleware, p.34 (third edition)

Every outstanding programming manager we know either has Peopleware on their shelf next to The Mythical Man-Month - and pulls both down to consult regularly - or is searching their office trying to figure out where they went. (Hint: there are replacement copies to be had at Amazon.)

To only a fraction of the human race does God give the privilege of earning one's bread doing what one would have gladly pursued free, for passion. I am very thankful. Frederick P. Brooks, Jr., The Mythical Man-Month, p.291 (anniversary edition)

Us, too.

No four-legged fish! Jeff Freund, Founder and CTO, Clickability

Jeff notes, "Four-legged fish (Ichthyostega) are all those evolutionary dead-ends. The fish got legs for a reason, but in the end, it really didn't work out. In software development, four-legged fish are those temptations to do one-offs, customer specific code, short-cuts to fix later, hard-coded things that shouldn't be, etc. In biology, evolutionary missteps die off; in software, they pollute code and product, making it harder to maintain, enhance, understand, etc."

You must maintain the core principles of Continuous Improvement and No Surprises! always Jeff Freund, Founder and CTO, Clickability

Jeff notes, "This is especially true during periods of rapid change: business/product turn-arounds, high growth, re-orgs, new process definition. The first principle will ensure you will make mistakes only once and feel like you are moving forward and generally making things better. The second is equally as important: surprises will kill you due to lost time and attention."

Software projects don't go bad, they start bad. Here's what's needed:
       1. Clear and quantified business value
       2. Budget that's roughly in the ballpark
       3. Team that has the right skillset
    Unless ALL these three things are checked off, I don't recommend starting a software project.
Pradeep Ananthapadmanabhan, CTO, Digital Marketing Technologies Hub, Vivaki

Pradeep continues, "A LOT of waste in the software industry is caused by starting a project without having these in place with the 'assumption' that these three things can be figured out as you go along. That simply NEVER ever happens in my experience. On the contrary it always ends up in a lose-lose situation for everyone involved."

Obscurity and obsessive abstraction are two of the worst problems that affect software development; they combine into a form of willful ignorance that makes us write crappy code. Marco Tabini, http://blog.tabini.ca/the-7-bit-internet/

Amen.

There's just a tremendous amount of craftsmanship in between a great idea and a great product. Steve Jobs, in Steve Jobs: The Lost Interview, 1995 television interview with Robert X. Cringely

Steve's whole quote is much longer but (no surprise) equally revealing: "One of the things that really hurt Apple is that, after I left, John Sculley got a very serious disease. I've seen other people get it too. That disease is the disease of thinking that a really great idea is 90% of the work. And that if you just tell all these other people, here's this great idea, of course they can go off and make it happen. The problem with that is that there's just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows - it never comes out like it starts - because you learn a lot more as you get into the subtleties of it, and you also find there's tremendous tradeoffs that you have to make - there are just certain things that you can't make electrons do - there are certain things you can't make plastic do or glass do - or factories do - or robots do. And as you get into all these things, designing a product is keeping 5,000 things in your brain - these concepts - and fitting them all together and continuing to push to fit them together in new and different ways to get what you want. And every day you discover something new - a new problem or new opportunity to fit things together a little differently. And it's that process that is the magic."

Part of what made the Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to be the best computer scientists in the world. Steve Jobs, in Steve Jobs: The Lost Interview, 1995 television interview with Robert X. Cringely Part of Steve's role was to drum into us how important what we were doing actually would be to the world. Andy Hertzfeld, interview by Robert Cringely dated 11/05, curated as part of the Steve Jobs: The Lost Interview DVD.

Andy continued, "We understood that if we pulled it off - obviously there was no guarantee that we would - but if we pulled it off, Apple was in a position to change the world with our work. And I think we did, to a large extent."

I found that when you get enough 'A' players - when you go through the incredible work to find five of these 'A' players - they really like working with each other - they've never had a chance to do that before. And they don't want to work with 'B' and 'C' players. So it becomes self-policing and they only want to hire more 'A' players. Steve Jobs, in Steve Jobs: The Lost Interview, 1995 television interview with Robert X. Cringely

Steve's whole quote is much longer but (no surprise) equally revealing: "In most things in life, the dynamic range between average and the best is at most two-to-one. If you go to New York City and you get an average taxicab driver vs the best taxicab driver, you're probably going to get to your destination with the best taxicab maybe 30% faster. In an automobile, what's the difference between average and the best, maybe 20%? The best CD player and an average CD player, 20%? Two-to-one is a big dynamic range in most of life. In software - and it used to be the case in hardware, too - the difference between average and the best is fifty-to-one. Maybe a hundred-to-one. Very few things in life are like this. But what I was lucky enough to spend my life in is like this. And so I've built a lot of my success on finding these truly gifted people and not settling for "B" and "C" players. Really going for the "A" players. And I found something - I found that when you get enough "A" players - when you go through the incredible work to find five of these "A" players - they really like working with each other - they've never had a chance to do that before. And they don't want to work with "B" and "C" players. So it becomes self-policing and they only want to hire more "A" players. And so you build up these pockets of "A" players and it propagates. And that's what the Mac team was like. They were all "A" players. These were extraordinarily talented people."

Code review is as much about improving the code as it is improving the developer. Adarsh Pandit, developer at thoughtbot, shared 4/17/13 in a webinar on agile development Using money as a motivator is like playing with dynamite because money is a VERY effective motivator. Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward. Therefore monetary motivators have a long track record of generating unintended consequences. If there is any apparent competition for the money, money motivates people to get as much as they can for themselves. Thus monetary motivators have a track record of suppressing collaboration. Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators. These are things you probably cannot change about using money as a motivator. Mary Poppendieck, posting to the Lean Software Development group in 2008 Five minutes into my initial interview with Steve, I wanted to throw caution and logic to the wind and join Apple. My intuition told me that joining Apple would be a once-in-a-lifetime opportunity to work for a creative genius. Engineers are taught to make a decision analytically, but there are times when relying on gut or intuition is most indispensable. Tim Cook, who joined Apple in 1998 and would take over managing the company on Steve's death, as quoted in Steve Jobs (Simon & Schuster, 2011), by Walter Isaacson, p.360

Isaacson notes of Cook, "He had always been a very logical engineer, and Compaq then seemed a more sensible career option, but he was snared by Jobs's aura." His gut told him to join Apple, and he made a right choice. We've found hiring to be another of the places where gut or intuition is indispensable. Sooner or later, you'll find one or more members of your interview team (maybe even you) adding layer on layer of analysis to sway you to hire - or not. Never, ever, in hiring, allow analysis to dismiss the truth your gut is telling you.

There's a temptation in our networked age to think that ideas can be developed by email and iChat. That's crazy. Creativity comes from spontaneous meetings, from random discussions. You run into someone, you ask what they're doing, you say, 'Wow,' and soon you're cooking up all sorts of ideas. Steve Jobs on his strong belief in face-to-face meetings, as quoted in Steve Jobs (Simon & Schuster, 2011), by Walter Isaacson, p.431 Peer pressure and the distaste for letting down a colleague will motivate a team player more than any fear of authoritative punishment or rebuke. Patrick Lencioni, author, Field Guide to Overcoming the Five Dysfunctions of a Team We are not the user. button, SIGCHI Conference of ACM, mid-90s

Ron notes, “I joined the Computer-Human Interface (CHI) Special Interest Group of ACM while at Apple. I found myself responsible for the user experience of a segment of Apple's applications that were lacking dedicated designers, later offered to teach third party developers what I'd learned about UI design, and ultimately got to manage development of the Mac's UI, Apple's crown jewels. I was still in the first of those three, I think, when I attended a CHI conference during which we were all handed this rule of thumb as a button to wear. It stuck with me (no pun intended): If the folks closest to design were reminding themselves they aren't the user, I and my team certainly weren't!”

Always be recruiting Mickey and Ron

This is a rule of thumb that's important enough that we spend a whole section of the book on the topic. We summarized our chapter on hiring by noting that hiring is likely the most important job you'll do as a programming manager, concluding, "And remember that while hiring is an event, recruiting is a part of your job you should always have turned 'on.'" Since the book's publication, as we've talked about managing by rules of thumb, we've both ordered "Always be recruiting" at the top of the list.

I inspect what I expect. Alan Lefkof, president and CEO of Netopia for many years

A Rule of Thumb that Ron returns to over and over is "Trust but Verify." He notes, “For me, I think it expresses both the imperative not to micromanage and the essence of delegation. Alan Lefkof expressed the same thought another way in this Rule of Thumb. He told me he'd learned it from Lou Gerstner when he was at McKinsey. I find myself doing more and more mentoring of managers at all levels (Ron Lichty Consulting) and these are a couple Rules of Thumb I often share as a pair.”

There are no best technologies, only technologies that are among better ones for particular problems and problem sets Ron Lichty

All of us who deal with technology have to be careful of "shiny" technologies. (We also have to be careful not to jump to skepticism based on how many times shiny things haven't worked out.) Choosing technologies is a question of balance between what will speed development and the cost of ensuring new code is consistent with existing code base technologies, can be delivered and maintained within the skillset of the team, and will be reliable, scalable and extensible.

Start from the product, not the technology Ron Lichty

Survey technology choices frequently. No one of us will know them all. We need to have a sense for what's appropriate for our problem set - and continually re-survey to expand the list. That way, when product leaders define product priorities, we're ready with options. But beware of "shiny" technologies. Products are about delivering value to users, not about making use of "cool."

Beware of 'shiny' technologies Mickey and Ron

Or as we put it in the section on "Technology Offense and Defense," ensure that your staff is not seduced by the allure of new "shiny things." In this section we also share Obi-Wan Kenobi’s rule of thumb, “Beware the dark side of the force.” New technologies are the “dark side of the force” for programmers, who will spend countless hours exploring unproved technologies rife with potential to introduce risk if embraced before broad acceptance, extensive field testing, and guaranteed support by those promoting the technologies.

 

Remember, the core three hundred rules of thumb and nuggets of wisdom are the soft, creamy center of Managing the Unmanageable, which you can...

order from Amazon