PJ McCormick UX Manager at Amazon, Speaker, Cancer Survivor

Anyone that knows me know I’m a massive Pixar nerd, and would not be surprised that I find their open source graphics library, Open Subdiv, amazingly fascinating and worth sharing.

In particular, there’s something that makes my nerdy heart giddy about getting the chance to crawl through their Github repo.

I don’t force standardization in tools on the UX team that I manage at Amazon. I encourage the individuals on my team to use whatever tool works best for them.

What I do force them to do, however, is to work very closely together. I have very few hard-set rules, but one of the few I have is that everyone on my team has to collaborate very closely together, even (especially) folks from different job classes.

This has two very nice side-effects: first, it encourages a lot of experimentation with different types of tools and workflows. Since there’s no official standardization or beaurocracy for the individual team members to worry about, there’s nothing stopping a dev, designer, or prototyper from taking a new tool out for a spin, and they’re not punished or reprimanded if the experimentation doesn’t go well.

The second side-effect is that it transfers ownership of any (un-official) standardization decisions to the team members. It democratizes the whole process. Since I am forcing them to work so closely together, they naturally have to address the issue of collaborating effectively across work materials. And they inevitably come up with more interesting, effective, and powerful workflow solutions to this fundamental question than I would have been able to prescribe from my position outside of the day-to-day work.

The end result of these two side-effects is that the team can rapidly innovate process and workflow improvements and quickly adopt cutting-edge tools–and, on the flip-side, abandon tools or processes that have outlived their use. In the long-run, this easily pays-off any short-term productivity losses that come from constantly taking new tools out for a spin.

In October, I had the honor of speaking at the first ever LevelUp Con, run by my friends at MadGlory Interactive. It was easily one of the best and most professionally run conferences I’ve had the pleasure of attending, as either a speaker or attendee.

Here’s a video of the talk I gave there. You can also see videos from some of the other presenters on LevelUp’s Vimeo account.

From an interview in 2005:

He seems curiously Zen about [the decline of hand-drawn animation]. “If it is a dying craft we can’t do anything about it. Civilisation moves on. Where are all the fresco painters now? Where are the landscape artists? What are they doing now? The world is changing. I have been very fortunate to be able to do the same job for 40 years. That’s rare in any era.”

A very mature perspective for someone who’s devoted their working life (and, from all accounts, copious amounts of his personal life…) to the dying craft in question.

“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.