PJ McCormick UX Manager at Amazon, Speaker, Cancer Survivor

“Death by Powerpoint” is a piece by Erik Heiss on an incredibly challenging and complicated subject: information design and communication in the military (and similarly complex and resource-strapped operations). It’s thought-provoking and full of empathy.

The central lesson is this: The illusion of clarity offered by bulleted-lists can be misleading at best, and deadly at worst.

It’s easy to sit back on our design high-horse and laugh at the weaknesses in these presentations. The painful reality is that these are just normal people, without any design training, trying to do their jobs the best they can. They don’t have experts advising them, and even if they did, they probably wouldn’t have the time to listen.

These officers are doing about as good a job at design as most designers would do at the controls of a modern warplane. I say that not to excuse anything, but to place these very different skill sets in perspective.

One of the most critical aspects of building and leading a strong team is cultivating strong leadership within the team itself.

This is a never-ending, constant task for a leader or manager. A team that organically generates inspiration and trust amongst its members will be happier, output higher volumes of better work, and suffer much lower turnover rates. So it’s important to have a clear idea of what leadership potential signifiers you look for in your team’s members.

The number one thing I look for to identify leadership potential in my directs is humility.

There are other things that are important to being an effective leader, of course: the ability to communicate well, present, manage executives, set and manage expectations, prioritize, compromise, make good decisions autonomously, and so on.

However, I’ve found that people who are talented, driven, and humble tend to effortlessly earn a reputation of leadership…peers want to follow them, business parters and clients want to work with them.

Furthermore, since humble leaders can put others before themselves—they can listen completely to dissenting perspectives and realize when another idea is better than their own, or see alternative approaches that no one else recognizes—the quality of their work is consistently much higher.

Things that are coachable, and things that aren’t so coachable

I’m constantly coaching my directs on communicating, prioritizing, presenting, managing upwards, setting expectations, and so on, and I’ve found that all of my directs can get better at all of these things with training and practice.

However, humility seems to be an innate quality that’s very difficult to influence or instill. It’s a lot trickier to help someone develop humility—especially people who are passionate about their work.

So how do you cultivate humility in your team’s prospective leaders? That’s a tough question, with many, many possible answers—but there are two things that I’ve found to be pretty effective.

Schedule regular 1-on-1 meetings

The first is to make sure you’re regularly having 1-on-1 meetings with all of your direct reports. 1-on-1 meetings are great opportunities for individual coaching and development, and for building trust between yourself and your directs.

This last point is crucial, as it will yield enormous dividends later on when you’re coaching them. Even if you’re giving difficult feedback to one of your team members, they’ll be much more receptive since they trust you. It’s a positive feedback loop that compounds momentum on many levels.

Give them a chance to fail autonomously

Another thing that I’ve found works well is learning what kind of challenges they’re really interested in. What kind of stuff do they like to work on? Are they interested in a certain type of project, learning a new methodology, experimenting with a new technology?

You can learn this by—surprise!—asking them in your 1-on-1 meetings. Then, find a way to give them some degree of responsibility and ownership of some aspect of a current or upcoming project that’s related to this interest.

This will give your directs a chance to “spread their wings,” help them practice autonomy and prioritization…and often gives them a chance to fail.

Which will help them develop humility.

Jared Spool on Websockets, the invention of new things, experimenting with those new things, and why designers should learn to code:

Learning enough code to play around with websockets isn’t about learning production-quality coding skills. It’s tinkering in the garage, not building a new car for Toyota. That’s all that’s necessary here. Enough code to learn what the tools can do and speak intelligently to our peers in development…Designers don’t need to learn to code. However, designers that learn to code will be the ones leading us to better user experiences.’

I agree. It’s one of the reasons I originally learned how to code, it’s why I insist on sharing front-end code with engineering teams, and it’s why—now that I’m beginning to lead and manage teams—designers with coding skills always find themselves floating to the top of my lists.

As Jared described, this is not because I expect my designers to ship production ready code (although I’m cool with that, too…all three of my designers, Hao, Dustin, and Shiho, dabble in code, and two of them regularly ship to production), or to be responsible for engineering duties (that’s why Ava and Ryan are on the team).

The reason is because designers who code—who are curious about and tinker with technology—are always the ones who produce the most interesting, innovative, and successful work. This is simply because they understand the technology better—they know what it’s capable of, and where it can be pushed.

They don’t create pictures of ideas that may or may not work. They create functional prototypes and experiments that show the idea in action, that validate or invalidate the idea before it’s committed to engineering, and that always, always, always lead to more interesting and innovative ideas down the road.

Combined with their sensibilities and skills as designers, this familiarity with the technology allows them to see, pursue, and capitalize on incredibly valuable opportunities that no one else would noticed.

The first Imagineers

As I said in a series of tweets yesterday, I’ve come to associate designers who code with the first Disney Imagineers.

When Disney was first building Disneyland, he quickly found that conventional architects and engineers wouldn’t be enough to achieve his visions for the park. So he did what he always he found himself blocked: he turned to the artists in his animation studio.

Walt’s original, hand-picked Imagineers were designers, animators, and background artists who tinkered with mechanical engineering, model-building, and kinetic sculptures. Walt recognized them as kindred spirits, and realized that their unique approaches to solving creative problems would be crucial to Disneyland’s success.

He brought them over to WED Enterprises (which later became Walt Disney Imagineering) and assigned them to work on rides, design attractions, build audio-animatronic robots, and even write songs and screenplays.

Being asked to do too much

I understand why some designers don’t want to learn to code, of course. For one, the thought of learning to code can be intimidating, defeating, and demoralizing—especially if you find yourself less than technically inclined, or, hell, just flat out bored by code.

But even more, it could open you up to abusive and destructive scenarios in which you’re asked to simply do too much, to shoulder responsibilities that should simply be distributed over more people. And if you ever find yourself working for an employer who expects more than is ethical of you, you should absolutely not stand for it.

But ultimately, coding is just another skill. Just like any other design technique, methodology, or piece of software. And the fact is, refusing new skills—and reinforcing professional segmentation based solely around skill sets—will always be inherently limiting.

Skills are just tools

Those first Disney Imagineers didn’t segment themselves based on their skills.

If they had, animator X. Atencio would have pushed back on Walt when he was assigned to write a song for Pirates of the Caribbean.

He would have said, “Look Walt, I’m an animator. I don’t write songs or screenplays. If you want a song, hire a songwriter.”

And then we wouldn’t have the song “Yo-Ho (A Pirate’s Life For Me),” which X. Atencio wrote.

And we probably wouldn’t have The Haunted Mansion at all—Atencio not only wrote the script that unified the long-suffering attraction, he also wrote it’s theme song, “Grim Grinning Ghosts.”

The first Imagineers didn’t segment themselves based on their skills because the understood their jobs were not the sums of their skills. Their true job was to create. To tell stories. Their eclectic skills in mechanical engineering, technology, animatronics, and song-writing were simply tools that helped them do that job.

This is a pretty inspired use of Gifs to create a more immersive and haunting photo editorial.

We commissioned photographer Annie Flanagan, currently based in Williston, N.D.— the heart of the boom — to capture what it feels like to be a part of it. Her visual reporting reminds us that there is nothing natural about the impact of an economic boom; familiar landscapes are forever altered.

Last summer at SIGGRAPH, Pixar presented a paper called “Stylizing Animation by Example,” which details research and new technology that could allow CG animators to create animated films that look hand painted. The amazing video below demoes the new technique.

Their retroactive experiments on footage from Up are kind of funky, but the ice skater animation that they created specifically for this technique is stunning. It would be awesome to see Pixar do a film completely in a painterly style (especially for those of us who remember back when Glenn Keane’s Rapunzel project for Walt Disney Animation was supposed to be a painterly film, before he was removed from the project and it became Tangled).

However, Cartoon Brew raises a couple of interesting points. Is the evolution from hand-made animation to CG animation to CG animation that looks like hand-made animation progress or regression?

Pixar has also posted the full contents on their research paper to their web site.

A recent post on The Atlantic about the two teenagers behind @HistoryInPics:

It might be easy to get mad at Di Petta and Cameron over how they’re using Twitter to build such huge, dedicated audiences, but the people who are really profiting from the profusion of copyrighted image sharing are the big social networks, two of which are now publicly traded companies, and another with a private multi-billion dollar valuation. Who really deserves the scorn—the two best players in the game or the people who own the stadium?

Content, and its value, is becoming blurrier and blurrier.

Warm Gun 2013 was incredible. I’m honored to have had the opportunity to get up and ramble about two subjects that are very dear to me—data and design—and to have been able to meet so many incredibly talented, and incredibly nice, people.

If you were unable to join us in person, 500 Startups (the people behind WarmGun) recorded every single one of the talks and posted them to YouTube.

Here’s my talk, “Challenging Data Driven Design” / “Data Helps You Make Decisions” (I’m a terribly procrastinator when it comes to naming my talks), in which I share some stories about using data to make decisions, and struggle with a mutinous clicker.

500 Startups also posted my slide deck to Slideshare.

This was my third time speaking at a conference, and the first time in which I’d given this particular talk. I think it went pretty well, in spite of some mid-talk curve-balls, but I won’t lie…it was absolutely terrifying. This was the largest crowd I’d spoken to yet: 500 entreprenuers and designers were in attendance. And the conference venue was very beautiful, and very, very well lit, making it very easy to see all 500 pairs of eyes staring back at me as I talked.

Still, though, for the first time giving this talk I’m pretty satisfied. That being said, if you watch the talk and have any feedback to share, or suggestions for how I might improve the next go, I’d really love to hear them. Hit me up on Twitter or drop me a line.

Also, if you have a conference or event coming up and think I might make a good addition to the roster, I’d love to hear more. Get in touch.

Luke Wroblewski:

Removing texture and depth forced the rest of the visual design to work harder to create meaningful distinctions between the various elements on screen. I think this is a key reason why designing for iOS7 is harder.

This post is not only a really interesting behind-the-scenes look at the iOS7 redesign of Polar, it’s also a very thoughtful retrospective on the ramifications of enforced simplicity in the design process.

Cap Watkins:

Next time someone asks what you’re working on, show them. No excuses, no caveats. Just, “Here’s where I’m at, these are the problems I’m trying to solve, I’m kind of getting hung up on this one part at the moment. What do you think?” Accept the feedback and suggestions, mull them over, listen for repeat pieces of feedback, have spirited debates. Soon, that feedback loop will be even more sacred to you than your process ever was.

In my experience—especially working at a crazy, complicated place like Amazon—everything Cap says in this post is 100% true.