Just as my 5-year old exits her Dora the Explorer phase (to replace it with “Let it go! Let it gooooo!”), my 2-year old enters hers with the force of a thousand purple monkeys. So, look, I read a lot of Dora books these days. Recently Penny the Pony’s Big Race has been quite the hit. It’s about Dora trying to get her horse to… wait, who am I kidding. I’m sure you care about the plot as much as I do.

Anyway, there’s one part of the story that irritates me way above my average annoyance levels with these books (which is already quite high). Dora, Boots, and Penny are trying to cross a mud pit, but Penny is a bit scared. This is where we pick up the narrative:

Let’s reflect on this for a moment. Penny is scared of jumping across the logs, because she thinks she might slip and fall into the mud. Dora’s proposed solution is infuriating:

Uh-oh! Penny is afraid that the logs might be slippery. Let’s count the logs as she walks across so she won’t be worried.

How is that a good solution? There are a number of things you could do to solve Penny’s fear of the slippery logs. They could walk around the mud pit. They could make sure the logs are more secure. They could give Penny special horse-shoes that increase friction. Look, I don’t know, I’m not an expert at horses jumping over logs, but I’m sure there are people who are, and who could come up with a good solution for the problem. Counting the logs to distract Penny is a pretty superficial and condescending approach to address this particular problem.

The thing is, this is all too often how managers operate in the context of their teams. Oh, you’re unhappy with the culture of the company? Let’s throw a company BBQ. On a Sunday afternoon. You’re concerned that the product development process is not optimal? Let’s hire another development manager. Instead of spending time to understand the cause of the anxiety communicated by team members, managers often rely on distraction or easy answers that give the illusion of a solution, but is nothing more than a way to check a box to say that they “did something.”

I read two really good management articles recently that are relevant here. The first is Gregg Satell’s What To Do While You’re Waiting For Steve Jobs (beware, that’s a Forbes link, so you’re going to have to do a lot of clicking around to dismiss all the things that try to distract you from reading it). He says this about treating people with respect:

If you expect your employees to be motivated to do their jobs well, you’d better treat them with dignity. Leadership is not the art of getting people to do what you want, but inspiring them to want what you want.[…] While many leaders believe that they can bend the organization to their will, that’s rarely true.  Being a jerk doesn’t make you Steve Jobs, it just makes you a jerk.

The second is Lindsay Holmwood’s It’s not a promotion — it’s a career change. It’s a great post and you should read the whole thing, but I want to quote most of the opening in full, because it’s great:

Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.

You exist to remove roadblocks and eliminate interruptions for the people you work with. You exist to listen to people (not just hear them!), to build relationships and trust, to deliver bad news, to resolve conflict in a just way.

You exist to think about the bigger picture, ask provoking and sometimes difficult questions, and relate the big picture back to something meaningful, tangible, and actionable to the team.

You exist to advocate for the team, to promote the group and individual achievements, to gaze into unconstructive criticism and see underlying motivations, and sometimes even give up control and make sacrifices you are uncomfortable or disagree with.

You exist to make systemic improvements with the help of the people you work with.

If I could summarize the advice in these articles, and what I’ve personally experienced about good managers vs. bad managers, I’d say this. If someone on your team complains that they’re worried about slippery logs across a mud pit, don’t tell them you’ll count loudly as they jump to distract them from the fear. Instead, take the time to understand the cause of their fear, and help them solve the real problem behind that fear.

In other words, don’t be like Dora. She’s a terrible manager.

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.