Skill and Genius

I never really know what to say when I meet famous people.  It’s awkward.  I mean, we’re complete strangers, but I often know weird and interesting facts about them – that seems uncomfortably invasive.  For actors and writers, I’ve now settled on a simple autograph moment, “I enjoyed your work; thanks for sharing.”  It’s one thing, however, to appreciate skill, but another to appreciate genius.  I’m going to define genius as someone who blends multiple, unrelated skills into a single package that seems marvelously and magically unique.

Paul Reed Smith visited The Seattle Guitar Store in July 2015.  I heard in person some of the stories I’d watched online.  When it was my turn to get my guitar signed, I was so beside myself that I put my guitar case on the counter upside down.  Why?  I’d been reading about PRS Guitars since I was young, long before I could afford one, and here I was meeting The Man Himself – and he is a genius.  His guitars are, literally, like nothing else I’ve ever played or heard.  It’s just not the wonder that are his instruments, it’s the unusual blend of skills that got him to where he is.

What makes Paul Reed Smith a genius?  It is abilities and skills he both possessed and developed.  He started repairing guitars and determined his passion was to build them.  It’s not enough to just build guitars, you have to sell them.  He developed sales skills, pitching them to artists, with his big break coming up when Santana bought one.  To be able to scale meant learning about manufacturing and the business of manufacturing (“If you make 8% in manufacturing, you’ve had a pretty good year”).  He became an expert in marketing, creating a set of differentiated product price points for every budget. He sought mentors in the great builders of guitars to perfect his craft.  He became a better musician along the way, providing even more insight into making guitars. Most of all, the thing that sets him apart from other luthiers, is that he is an engineer and a scientist.  His quest is to understand what makes an instrument great, to know what physical qualities make an instrument special.  He creates a hypothesis, tests against it, and incorporates what he learns.  Year over year, you can see the evolution in the resulting instruments.  I’m passionate about clever engineering and, as far as I know, that engineering skill is unique among guitar builders.  Musician, manufacturer, engineer – an unusual combination.  His passion was building guitars; his genius was in building them better at scale, creating a $40M company renowned for quality and sound.  He did it by constantly learning, constantly improving, constantly developing new skills.

The photographer at is a *genius*. Check those folks out.

What does integration of all those things looks like?  Look at the guitar on the right.  Beyond the masterful photography that highlights its beauty, it is an amazingly figured piece of maple that is unlike any other I’ve seen – look at how the grain on the horn points to the center.  Why are PRS guitars almost “too pretty to play”?  I can nearly hear Paul Reed Smith’s thoughts:  If you see it, and it’s pretty, you’ll want to pick it up.  If you pick it up, you’ll want to play it.  If you play it, you’ll hear the sound.  If you hear the sound, you will buy it.  It starts with how it looks.  If you have any doubt, watch Rob Chapman try to talk himself out of a guitar that sounds wickedly good in his hands… because of the looks!  Paul Reed Smith got it exactly right.

I write about project management, but to be successful, you are going to need to do and be more.  Although it’s said that project managers don’t need to be subject matter experts, to have a career, it’s essential to think of the full range of talent and skills you bring to the table.  What insights do you have that make you unique?  What can you dive into deeply to provide value?  What new things will you learn to maintain marketability beyond your employer?  What synthesis of things make you a genius?

Answer those questions and maybe your next introduction to genius won’t be awkward, because you’ll look in the mirror and that genius will be you.

(If you’re curious, here are some additional links about Paul Reed Smith, with the last highlighting my awkward connection to Andertons…)

Hello, Dolly! Using the Right Tools

Ever change a tire? How much work is it to carefully wrestle a wheel onto its car mount, avoiding banging the calipers or rotors? If those wheels are nearly a foot wide, 27 inches in diameter, and weigh nearly half of what you do – quite a lot! Faced with the problem, I bought a wheel jack – Dolly. With the car on jack stands, Dolly works perfectly to remove one wheel, move it, place another wheel on the Dolly’s rollers, align it to the mounting bolts, and gently place the wheel on the car. This simple tool makes the whole job of swapping tires much less of a chore.

Normally, four wheel jacks are used to lift and move a car. This can be handy if you’ve removed the engine, or if you have a large garage and want to tuck the car a corner for storage. Seeing wheel jacks in use, however, gave me (and apparently many other people) the idea to use one to change tires. Using a single wheel jack to change a tire isn’t the primary use case, however, once you’ve done it, it seems obvious – but my dad, who first taught me about cars, never showed me the trick!

Having learned a trick that works for this job, is a wheel jack the right tool for all jobs? Of course not. Just as there is no one tool for every job, there is no Excalibur to make you Ruler of All Great Projects. Rather, if you know process groups and knowledge areas well, and therefore how to effectively run a project, you can decide what to optimize for in your projects. In software, the quest is not for “the single, best software development practice for ALL projects”, but rather “the single, best software development practice for THIS project.”

Think of it this way – knowledge is your tools. Knowing how and when to creatively use tools to best effect is what makes a craftsman or artist. The process of sizing up the problem provides the insight on how to resolve it. When organizing a development project, it is essential to understand the requirements and constraints, both from your organization and your customers, and then create the best development practices for that specific product and project. Sounds a lot like business analysis, doesn’t it?

Let’s consider organizational requirements and constraints. Two areas to consider is what the PMBOK® calls “enterprise environmental factors” and “organizational process assets.” Enterprise environmental factors are the company culture and existing systems that the project can make use of – or will have to deal with. You could substitute the word “baggage” and get most of the idea. “How we’ve always done it” might help or hurt your project, making it essential to ask questions and review basic assumptions. Organizational process assets are existing process, procedures, and historical information – do you have a bug tracking database you can review? A build system already in place? Other projects to compare? Can you take advantage of process assets to benefit your project? What assets could your project contribute to others?

Think about your development team. Is it one developer or hundreds? Are they in one place or geo-distributed? How many languages and cultures are involved? Is it one unified team or many disparate teams with different managers and goals? Is the team fixed for the duration or the team members rotate and change over time? Is a single company or many companies involved? The team and resources available shape the development project, and shape when and where you’d use traditional or agile methodologies. Planning to use Scrum in a large monolithic, complex, tightly coupled and not well-documented Version 1.0 design with a global team of hundreds across multiple companies? Well, have fun storming the castle!

Customer requirements and constraints are the other influence. Customer requirements will not only define the product, but how you produce it. Whether your product is an embedded system or a cloud application dramatically changes how it can be serviced. Is the product consumer or enterprise? One user or hundreds of millions?  Single installation or high volume on many platforms? Are there legal or industry (healthcare, finance, government) considerations? Is the software free or cost millions of dollars? Is the product a simple game or mission critical avionics? Answers about customer requirements for your product will inform how to optimize your development process. Reliability/quality vs. velocity is an important balance, and needs to be determined by customer expectations and use cases. Software quality issues can be trivial. The “exit seat position” feature in my car has an “arrays start a zero!” bug – it means the seat doesn’t quite return to preset driving position, so I don’t use the feature. For another application, however, software quality issues can be extremely expensive – or even deadly.

There are gotchas in the process.  Micro-optimization can cause poor decisions. If the company produces a million cars, and instead of using a $2 switch per car, you substitute a $1 switch, you’ll get a pat on the back for saving the company a million dollars. If, however, those $1 switches have a MTBF of one year, instead of ten years for the $2 switches, you will cost the company three million in warranty costs (assuming the cars have three year warranties), plus reimbursing dealership labor (which will easily bury the cost of the switches). Also, data-driven decision making can cause difficult-to-metric costs to be ignored or trivialized. Loss of customer trust and goodwill can be devastating, but hard to quantify.

To summarize, project management knowledge is common regardless of the project – but the techniques and details of execution in software development can be very different. Traditional or agile, know the fundamentals, then make intelligent optimizations to meet business and customer goals.

For another take on this topic, read “The Right Way to Ship Software”.  For a story of development gone wrong, read a story about a video game.  You, like me, probably have some genuine empathy for those folks, along the lines of “Oooooh, ouch, yeah, I remember something like that.”

Doing The Right Thing

“Once you start down the dark path, forever it will dominate your destiny.”

That quote from Yoda in The Empire Strikes Back has two meanings. The first, and clear, meaning is that once you start justifying bad acts “for the greater good,” when will you stop? As time goes on, you will justify more and more questionable acts. The ongoing risk-reward calculus blinds you and normalizes bad behavior. The second, and subtler, meaning is once you have a reputation for heinous deeds, it will follow you. No matter how many “good” deeds you do, a single “bad” deed will be remembered. It damages the trust others have in you. People will expect you to behave unethically, and will act accordingly.

What can you derive from this? Ethics. Matter.

The popular news is filled with examples. How do you feel about Volkswagon right now? The $2.8B in penalties and resignation of executives is the least of their trouble. How about Uber? Issues with the company’s culture and ethics have leaked out, forcing change. Turing Pharmaceuticals and the behavior of its former CEO?  My guess is that no one in business is claiming to be that guy’s friend. These are just recent examples. There are many, many more.

The root of many intentional and unintentional lapses is the pressure to perform.  Do it faster, cheaper, or with fewer resources – make more money.  These values can become such a part of a company’s culture that individuals are strongly incentivized to short term gain.  It’s false economy.

Unimpeachable conduct has its benefits. An article in Bloomberg suggests that ethical companies are stronger and last longer. The Wall Street Journal suggests that companies perceived as ethical don’t reap premium prices, but that companies that are perceived as unethical are forced to sell at a steep discount. Forbes points out it is easier to be ethical than unethical.

The message should be clear. It is best to not only avoid impropriety, but the appearance of impropriety. Reputations are hard earned and easily lost. Ethical lapses can have both civil and criminal consequences. Winning at all costs is not winning, it is just the slow and inexorable deterioration of your professional integrity.

Today’s message is to encourage you to really think about ethical behavior and implement in your daily dealings.  Company culture starts with every individual.  Lead by example.   Don’t wake up one day in a black mask with a breathing problem, and wonder “How did I get here?” Instead, be honest and ethical until it is just second-nature.

Yoda: “Once you start down the dark path, forever will it dominate your destiny, consume you it will, as it did Obi-Wan’s apprentice.”
Luke: “Vader… is the dark side stronger?”
Yoda: “No, no, no. Quicker, easier, more seductive.”

Wise words!

(Disclosure: I work for Microsoft Corporation. Microsoft has a clear, and unambiguous, statement about business conduct. It has yearly training for all employees to reinforce that company culture. As a manager and mentor, I’m a passionate supporter of these policies.)