Alvin Hsia’s What I Learned In My First Year as a Product Designer is a good refresher and reminder about what’s important when working with others. This point is worth discussing further:

Make a deliberate effort to cultivate empathy for other team functions and be able to explain your designs to whoever it is you’re talking to, in their terms. It’s ok to use design jargon as long as you’re able to educate others on what the impressive-sounding words you use actually mean. Break down how your designs fit into the context of what they do and/or company goals. This requires you to get inside the mind of people in a variety of functions and gain a basic understanding and appreciation of what they do and can manifest itself in many ways.

Two books were a really big deal when I was in high school. The first is Stephen Covey’s The 7 Habits of Highly Effective People. Everyone was reading this thing. I was obsessed with the book, and even read all the prequels and sequels — although the only title I can remember is First Things First, because it just seemed way too obvious to me at the time. I even bought the Covey Daily Planner™ (or whatever it’s called) and kept it up religiously. Paper — how cute.

The other book that was a big deal is To Kill A Mockingbird. I must have read it 10 times as part of English class. Up to then, most of my reading was confined to a very limited set of prudish Afrikaans authors. To Kill A Mockingbird was different. It awoke in me an obsession with words and reading that I’m thankful for to this day.

I bring this up because both these books — as different as they are — have served me well over the years in my career. All because at their core, they have the same theme: empathy. I’ve long forgotten the 7 habits — except for one:

Seek first to understand, then to be understood.

And I don’t remember much from To Kill A Mockinbird, except for this passage:

You never really understand a person until you consider things from his point of view — until you climb inside of his skin and walk around in it.

More than 20 years after reading the books, these are the phrases I can’t get out of my head, especially if I’m tempted to get frustrated when someone doesn’t “get” the reasoning behind one of my designs. Instead of going into defensive mode, I’ve learned to hold back and simply say: Tell me more about that. Trust me, this is a magical, powerful phrase. It shows that you want to understand, that you don’t know everything, that your only desire is to make the product better. It breaks down aggression, it improves communication, it teaches you things.

I’m not perfect at this — I admit that I sometimes still lose my cool. But whenever I have the wherewithal to seek first to understand, then to be understood, I come out the other side a better designer. And I think that’s worth sacrificing a bit of pride for.

---

If you’re a business that would like to reach Elezea’s audience, have a look at my sponsorship opportunities.

I nodded along vigorously to Cap Watkins’s The Fight:

What I’ve come to realize in the past two years is how important it is to find a company and a product worth fighting for. To find a team that is dedicated to delivering the best product they can, despite the bumps, the frustrations, the exhausting moments along the way. Hurdles and failure are totally unavoidable. Having a resilient team around you working on a product you all believe in will make those hurdles easier to clear. They’ll turn failure into a learning opportunity. Great teams working on products they’re passionate about will back you up when you’re exhausted and cover for you when you’re frustrated.

When you find a team like this, hold on for dear life.

Joel Spolsky:

Even though Fog Creek, Trello, and Stack Exchange are now three separate companies, they are all running basically the same operating system, based on the original microprocessor architecture known as “making a company where the best developers want to work,” or, in simpler terms, treating people well.

What a great post about a great product and a great outlook on corporate culture. I wish Joel would start blogging regularly again…

Managers, take note:

Employees are vastly more satisfied and productive, it turns out, when four of their core needs are met: physical, through opportunities to regularly renew and recharge at work; emotional, by feeling valued and appreciated for their contributions; mental, when they have the opportunity to focus in an absorbed way on their most important tasks and define when and where they get their work done; and spiritual, by doing more of what they do best and enjoy most, and by feeling connected to a higher purpose at work.

This isn’t rocket science, but an important reminder. It’s similar to Jocelyn Glei’s conclusion in What Motivates Us To Do Great Work?:

For creative thinkers, [author Daniel] Pink identifies three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). All three are intrinsic motivators. Even a purpose, which can seem like an external motivator, will be internalized if you truly believe in it. […]

As creative thinkers, we want to make progress, and we want to move big ideas forward. So, it’s no surprise that the best motivator is being empowered to take action.

The post I wrote this weekend on software development belief systems in corporate environments has been in my head for quite a while, I just hadn’t been able to write it up until yesterday. As often happens with these things, I noticed three articles in that past 24 hours that tie in really nicely with that post.

The first is Jeff Weiner’s Avoiding the Unintended Consequences of Casual Feedback, which talks about the kind of feedback executives should give to their teams:

Years ago, a former direct report of mine helped bring this point home. While he and his team welcomed my input, he observed that oftentimes what I thought was a take-it-or-leave-it remark would create a massively disruptive fire drill. Up until that moment, I had no idea my opinion was being weighted so heavily.

To address the issue and to ensure that the team and I were on the same page with regard to situations like that, we developed three categories to describe any feedback I provided (either in conversation or via email): One person’s opinion, strong suggestion, or mandate.

Next is Michael Lopp’s Chaotic Beautiful Snowflakes, which talks about the unintended work that managers often create without even knowing it:

The fact is that you significantly underestimate the amount of work that you generated this morning. You could document and communicate the obvious work, but you can’t document all the unexpected side effects of your actions. In a large population of people, it’s close to impossible for an individual to perceive and predict the first order consequences of their well-intentioned actions let alone the bizarre second order effects once those consequences get in the wild.

Finally, there’s John Maeda and Becky Bermont’s Building a Design Culture in an ‘End-Up’ Technology World, which talks about the elements of a good design culture in larger corporations:

In the end, building a great design culture is not the goal in and of itself. What it does is allow a company to recruit great designers, and then supports their ability to build great products, along with their counterparts in product and technology. Start-ups and end-ups may each think that they other has an easier time building or sustaining a design culture, but it takes work at any stage of the game.

All three articles are great companion pieces to what I wrote yesterday. I realized this morning that even though the traffic on yesterday’s post wasn’t huge, it will always be a personal favorite of mine, because it documents a lesson learned from a lot of sweat and frustration. And those are often the best lessons you can teach yourself.

Executives in corporate environments have one of three belief systems about software development. To build successful products it is essential for product managers to understand what belief system their executive team subscribes to.

• Belief system #1: We have to build these features and they have to be live by this date.
• Belief system #2: We have to be live by this date — what features can you get done by then?
• Belief system #3: We have to release these features next — how long will it take to get that done?

Belief system #1 is the most common, and it is poison. It usually goes along with a distorted Steve Jobs “reality distortion field” complex, and the only thing it produces is crappy software and burnt-out teams who feel distrusted and undervalued. A product manager’s first job is to move the executive team away from belief system #1.

Belief system #3 is the ideal scenario for most large corporations1. Software development and the product manager’s role are usually well understood in such environments. The product team gets to present their market-driven ideas to the executive team, who can focus on what they do best: providing perspective, vision, and assistance with prioritization. This allows product teams to set their own schedules based on what everyone agrees needs to be done as they balance what’s best for users, the business, and the technology.

Belief system #2 is not ideal, but it is certainly better than #1, and I’ve learned that it is impossible to move executive teams from belief system #1 to belief system #3 without the interim step of belief system #2. The logical jump from #1 to #2 is easier to influence since product managers only have to deal with one variable: the constraints of time.

If a release date is fixed2 product managers shouldn’t spend time trying to move out the date to accomplish everything the executive team wants them to. Instead, spend time explaining that the release date is a horizontal line. All features above the line gets done by the date, and all features below the line don’t, and will have to wait for a future release. Explain that the development team can only do a limited number of things in a given time frame, and if some feature suddenly becomes a must-have, one of the other features have to move “below the line”.

This might seem like a trivial concept, but that’s because we’re software people. Most executive teams have a really difficult time with this because software development in agile environments is fairly new to them.

It bears repeating that one of the biggest mistakes a product manager can make is to try to change people’s belief systems from #1 to #3 without first taking them through the logic of #2. That said, once a project has been completed successfully using #2, the shift to #3 is usually fairly easy to make. That’s because the executive team had the opportunity to get a glimpse of how much better the software can be if “required” features aren’t shoved down a funnel that cannot withstand the pressure.

If you work in a large corporation, identify your executive team’s software development belief system, then guide them to #3. Your product, your business, and your team’s morale will be better for it.

---

1. I.e., most practical and pragmatic. I’m talking specifically about corporations with >100 employees, not startups. ↩

2. And don’t get me wrong, there can be legitimate reasons for fixed release dates. ↩

In The Surprisingly Large Cost of Telling Small Lies Rebekah Campbell looks at the problem with lying in the context of entrepreneurship and creating products:

Peter maintains that telling lies is the No. 1 reason entrepreneurs fail. Not because telling lies makes you a bad person but because the act of lying plucks you from the present, preventing you from facing what is really going on in your world. Every time you overreport a metric, underreport a cost, are less than honest with a client or a member of your team, you create a false reality and you start living in it.

And it’s extremely difficult to get out of that reality once you’ve created it.

Steven Sinofsky wrote some excellent advice for product managers in his post Shipping is a Feature: Some Guiding Principles for People Who Build Things. I especially like this part:

A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options.

But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever.

The flip side of this is, of course, that the organization needs to agree that product managers have the autonomy to make these kinds of decisions.

John Maeda on The Great Discontent:

I’ve never met anyone who is good at what they do creatively and is super-confident.

Well, that’s a relief. Because I’m not feeling particularly confident right now. He goes on to say this:

If you have audacity and take on a risk, it means you don’t know what you’re getting into; you’re walking through a door, into a dark room, with no idea what’s there. If you have courage, it means that you know exactly what’s behind that door; there’s something dangerous, hard, and it’s going to make you really uncomfortable.

I don’t know if I’m audacious, courageous, or just plain crazy, but in case you were wondering why it’s been so quiet here over the past couple of weeks, it’s because I just moved from Cape Town to Portland, and today started a new job as Director of Product at HealthSparq. I’m excited about the move and the role, but also pretty nervous about the dark room I’m walking into. But I guess that’s what makes life exciting. That not knowing that keeps us pushing to find our own limits so we can break through them.

I expect things to stay a little bit slow on Elezea for another week or so. This week is obviously crazy, next week I’m speaking at Industry Conf, and after that things will hopefully return to a reasonably regular posting schedule. I just felt that I probably owed you guys an update.

Thanks for caring.

Lee Hutchinson, who was a system administrator at Boeing at the time of the space shuttle Columbia disaster in 2003, looks back at that tumultuous time in a long but absolutely fascinating article for Ars Technica:

In August 2003, the Columbia Accident Investigation Board (CAIB) issued its final report. Behind the direct cause of the foam strike, the report leveled damning critiques at NASA’s pre- and post-launch decision-making, painting a picture of an agency dominated by milestone-obsessed middle management1. That focus on narrow, group-specific work and reporting, without a complementary focus on cross-department integration and communication2, contributed at least as much to the loss of the shuttle as did the foam impact. Those accusations held a faint echo of familiarity—many of them had been raised 17 years earlier by the Rogers Commission investigating Challenger’s destruction.

The report also asked a team at NASA to figure out what a rescue plan might have looked like:

To put the decisions made during the flight of STS-107 into perspective, the Board asked NASA to determine if there were options for the safe return of the STS-107 crew.

The rest of the article explains the possible rescue plan in detail. If you have any interest in science or space exploration this is a must-read.

I found the article particularly interesting because I had just finished reading my favorite novel of the year so far: The Martian by Andy Weir. The article echoed a lot of the concepts mentioned in the novel, which gave me a new appreciation for the story. I highly recommend this surprisingly plausible and funny book as well.

---

1. See, this is a problem everywhere, not just in software development… ↩

2. This too. ↩