Dave DeRuchie makes a strong case that we need to put down our phones and get rid of distractions in meetings:

When you accept a meeting invitation, accept that your attention and focus for that time is also blocked. Avoid distractions that take your focus from the subject matter at hand. Be more connected to what you are doing by being less connected.

There’s another way to look at this. See, we’re distracted in meetings because we don’t find them that valuable, so we try to fill the time with multitasking activities that we feel do add value. So if this becomes a thing - if we agree and communicate that a meeting blocks out not just our time but also 100% of our attention and focus - well, that places a huge burden of responsibility on the meeting organizer. If you’re going to arrange a meeting, and you expect everyone to pay attention without distraction, you’d better make sure that it’s a meeting worth having - agenda, solid outcomes, everyone contributing, etc. Otherwise we’ll come after you and demand our attention back.

I’ve written about Dhanji R. Prasanna excellent post on Google Wave and working at big companies before, but I wanted to come back to something he said that I just can’t get out of my head. In one section he talks about a topic I care about very much - what motivates people to do great work. I really like his perspective on the importance of incremental progress:

[As] a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria.

I like the analogy of these small wins as Deus Ex Machina:

[It means] “God out of the machine”; a seemingly inextricable problem is suddenly and abruptly solved with the contrived and unexpected intervention of some new event, character, ability, or object.

It’s so important for large teams to celebrate those wins with the people they work with every day - and to call out the “characters” responsible for accomplishing Deus Ex Machina. It is hard to get that right in large organizations because the invisibility of individual team members and the pressures to move on to The Next Thing aren’t naturally conducive to this type of behavior. But it’s possible if you work at it.

Whether you keep some champagne in a fridge, send out company-wide emails thanking people personally, or ring a bell every time code gets deployed (ok, that last one is lame, sorry), being in a large organization isn’t an excuse for acting like a faceless corporation.

John D. Cook writes some scary true words in Productivity and negative space:

People who fracture their time putting out fires seem more productive, or at least more responsive, than the people who block out time to think. It’s harder to notice someone not being frantic. Thinkers don’t fare well in environments that reward activity more than accomplishment.

This is such a huge problem in big corporations today. People who are running from meeting to meeting are perceived to be more productive than those who sit at their desks working all day[1]. And the problem is worse for programmers - very few managers understand what they do, so it’s hard for them to stomach days and days of solid coding without seeing something “tangible” (in their view).

It all comes back the difference between Makers and Managers, and how the Makers should be evaluated on completely different criteria than the Managers. Criteria that reward the quality of what they make, not the number of status updates they give.

(link via Graham Poulter)

---

1. I’m not saying that people who have a lot of meetings are necessarily less productive, just that those who are not in meetings are “out of sight, out of mind”, and therefore not seen as particularly productive.  â†©

It’s not possible to get to know a man just by reading a book about him. And yet, that’s what many of us are trying to do with the Steve Jobs biography. To be fair, we do this whenever we hear stories about people. We tend to forget that ther’s more to a person than the scraps of information we can extract about them from others. This isn’t necessarily a bad thing, but we must place our opinions in the proper context.

I realize that my thoughts on Steve Jobs are not only based on imperfect words on a page, but I’m also reading those words through the biased lens I use to perceive the world. At best, I’m getting an interpretation of a copy of who he really was. And I’m ok with that, because even feint copies of an original can teach us things, which is why we read these human stories in the first place.

So with that disclaimer out of the way, I believe that Steve Jobs’s genius was rooted in two main character traits: Insanely great taste, and an inability to compromise on that taste at all. This inspires me, but the way his unwillingness to compromise came out of him also makes me extremely uncomfortable.

Jobs’s impeccable taste was evident from very early on:

[T]he Macintosh team came to share Jobs’s passion for making a great product, not just a profitable one. “Jobs thought of himself as an artist, and he encouraged the design team to think of ourselves that way too,” said Hertzfeld. “The goal was never to beat the competition, or to make a lot of money. It was to do the greatest thing possible, or even a little greater.” He once took the team to see an exhibit of Tiffany glass at the Metropolitan Museum in Manhattan because he believed they could learn from Louis Tiffany’s example of creating great art that could be mass-produced. Recalled Bud Tribble, “We said to ourselves, “˜Hey, if w’re going to make things in our lives, we might as well make them beautiful.’”

He understood the intersection of beauty, art, and technology perhaps better than anyone before him (have you notice how recently everything is starting to look like an Apple product?). But his inability to compromise on his almost-perfect taste manifested itself in being a bit of a jerk sometimes. By now, everyone knows the stories about how mean Jobs could be to his employees. My current favorite is the anecdote of what happened when Bruce Horn decided to leave the company. It summarizes Jobs’s volatility so perfectly:

When Horn went in to say goodbye, Jobs told him, “Everything that’s wrong with the Mac is your fault.” Horn responded, “Well, actually, Steve, a lot of things that are right with the Mac are my fault, and I had to fight like crazy to get those things in.” “You’re right,” admitted Jobs. “I’ll give you 15,000 shares to stay.” When Horn declined the offer, Jobs showed his warmer side. “Well, give me a hug,” he said. And so they hugged.

This kind of story is typical throughout the book. He was able to go from “you’re doing crap work!” to “let’s hug” in less than 10 seconds. What makes me uncomfortable is how effective this erratic management style appears to have been. I almost wish we could point to Steve Jobs and say, “see how destructive it is when you’re mean to people?” But her’s the thing: it worked. The Mac team were some of the most brilliant engineers on the planet, because only the good ones were able to survive Jobs’s wrath. And Jobs knew this:

But Jobs had latched onto what he believed was a key management lesson from his Macintosh experience: You have to be ruthless if you want to build a team of A players. “It’s too easy, as a team grows, to put up with a few B players, and they then attract a few more B players, and soon you will even have some C players,” he recalled. “The Macintosh experience taught me that A players like to work only with other A players, which means you can’t indulge B players.”

Even the team themselves seemed to be ok with this style in the end (yes, they were the A players who “survived”, but still):

“As every day passes, the work fifty people are doing here is going to send a giant ripple through the universe,” he said. “I know I might be a little hard to get along with, but this is the most fun thing I’ve done in my life.” Years later most of those in the audience would be able to laugh about the “little hard to get along with” episodes and agree with him that creating that giant ripple was the most fun they had in their lives.

So the source of my extreme discomfort with the Steve Jobs story is that I so desperately want to believe that being a jerk to people isn’t a good way to get the best out of them. But Jobs showed that it certainly is a way to get extraordinary results from a smart, dedicated team. My sense is that not many people can pull this off because you have to be able to back up that behavior with the level of taste that he possessed. This could be the reason why most managers who resort to jerk behavior don’t get the same results from their teams - they have no taste.

For my part, I’m going to take the safer road and stick with the advice given in What Motivates Us To Do Great Work?:

For creative thinkers, [there are] 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.

I probably won’t make as big of a dent in the universe as Steve Jobs did, but that’s going to have to be ok.

Aaron Swartz in a great piece called Steve Jobs and the Founder’s Pain:

Something that’s perfect just feels much, much better than something that’s almost right. When I’m doing something myself, I can just sit there and work at it until it’s exactly right. It’s embarrassing to launch a product with a bug in it! It physically hurts when I realize that’s what I’ve done. But as projects and companies grow, there are more and more people in between me and those tiny details. And then I face a choice: do I keep complaining until something’s perfect or do I just let go and consider it somebody els’s problem?

The people who are not content to make it somebody else’s problem are the ones who end up changing the world.

(link via @vhata)

I love the Automattic Creed that all their employees have to sign before they join the company:

I will never stop learning. I won’t just work on things that are assigned to me. I know ther’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything.

I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company.

I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

(h/t to @SwimGeek for the link)

This is going to sound like such a lame “management guru” thing to say, but it’s true: the cultural fit of the people you hire is more important than their past experience or absolute skill level. I’ve seen this time and time again. If I have a choice between hiring someone who is highly skilled in their work but doesn’t display humility and a genuine drive to learn more, and someone who knows enough to know that there is much to learn and they’re hungry to get there, I’ll choose the latter every time.

We recently went through an exercise to define our team values, and in many ways it’s similar to Automattic’s creed. I won’t bore you with the whole thing, but here are the main points. This is how we want other people to describe our team:

• We are zealots about quality
• We have autonomy to do what’s best for the product, its users, and our business
• We have a high fix:complain ratio
• We have a healthy work/life perspective
• We are empathetic to the core

The relationship between a healthy culture and doing great work is causal, not simply correlation. Good culture is the prerequisite for great work to happen, and actually causes it. Alan Cooper recently address this issue in a great article called The pipeline to your corporate soul:

If you want to improve the quality of your website, app, or software, you need to also improve the quality of your organization. You need to ferret out the people who play politics but don’t get things done. You need to squash bureaucracy that stops innovation with doubt and red tape. You need to eliminate the energy drains, systemic distortions, and toxic people that force others to act like corporate drones instead of like entrepreneurs with a vested interest in success.

If you put a bunch of talented, energetic, ambitious people together and make it easy for them to collaborate and do great things, they will. I haven’t seen a single example of great work preceding a clearly defined and healthy culture - even if it’s just an unspoken understanding between two startup founders. Spending time on getting your culture right is worth the effort.

Jason Mesut made quite a few waves this week with his presentation Truth and Dare - Out of the echochamber into the fire. It’s definitely worth your time so I recommend you click through and read it before you continue here. Ther’s a lot to like and a lot to think about.

Jason explicitly asks for feedback and counter-arguments, so I do want to address one slide in particular, shown below:

Now, I might be putting the puzzle together wrongly here, but since these slides came out right after I published a two-part series on Smashing Magazine called “Breaking Down Silos”, I’m going to assume h’s talking about those articles. If my assumption is wrong this is going to be really awkward, but oh well.

So, let’s look at why Jason is calling this concept “naive”. I wasn’t at the presentation, so all I have to go on is his bullet points.

Organisations are complex

Of course organizations are complex, and if anyone tries to argue otherwise they’ve never worked in one. But I never said that this is simple:

There are no shortcuts to breaking down silos. You can’t fix the environment if the organization doesn’t understand the problem. You can’t improve the development process if the right environment doesn’t exist to enable healthy guidelines. You have to climb the pyramid brick by brick to the ultimate goal: better software through true collaboration.

I don’t propose “7 steps to a happier you” in the article. I propose a process of understanding the problems and unique needs of the organization, followed by a tailored solution that takes those unique needs into consideration.

People are better in small groups

I absolutely agree, and that’s why prioritization at an organizational level needs to take this into account and empower small teams to do the work without interference. Her’s what I said in the article:

[Once strategic priorities are set], projects would move to small dedicated teams, which would have complete ownership of the design and implementation. The product council sets the priorities, not the details of implementation”Š””“Šthose are up to the teams themselves.

I go on to talk about the importance of autonomy and the meaning people find in their work when they work in these small groups.

Change takes too long

I don’t understand the argument here, so maybe this is one of those “voice-over required” points. But if the argument is that change takes too long so we shouldn’t even try, I don’t buy it. Her’s how I end the article, again acknowledging how difficult it is:

Building collaborative environments is not easy, because change management is not easy. But the positive outcomes of doing this far outweigh the pain of making it happen. You’ll end up with happy, creative teams that feel a sense of ownership over what they’re building and a sense of pride in its quality.

I’d also like to point out that I wasn’t being academic in these articles. Everything I wrote is based on principles we’ve tried and applied in real life in the organizations where I’ve worked. There’s always room for improvement and growth, but this wasn’t a theoretical exercise.

I know this doesn’t matter that much in the bigger scheme of things, and I admit that the only reason I’m even writing about it is a slight irritation with the word “naive”. But if Jason is indeed referring to my article (again, this is going to be really awkward if he’s not) I at least wanted to clarify my viewpoint.

So there that is.

When I lived in Australia there was an ad for Pizza Hut that ran about 5 times a day for over a month. It featured Dougie the delivery guy — always on time, always courteous, always immaculately dressed. As he hands over the pizza and gets his money, he asks, “So… how’s about a tip?”

The customer thinks for a bit, starts closing the door, and then says: “Work hard; be good to your mother.”

No, you’re right, it’s not a very funny ad. Nevertheless the words have stuck in my head for over a decade now. Because I realise that in life, as in business, these might be the only two non-negotiable rules we all need to adhere to in order to be successful at what we do. Work hard. Be good to your mother.

Work hard

I recently made the mistake of using the hasthag #leadership in a tweet. I immediately got 5 auto-follows, and they all fit the same profile:

• Their bios all had some version of the term “leadership coach” in it.
• They all had more than 20,000 followers, and they followed almost exactly the same number of people themselves. (This is, of course, because they auto-follow everyone who mentions the word “leadership”, and automatically unfollows that person if they don’t follow back in about 3-4 days)
• They all tweet excessively, usually through API’s that generate random “inspirational” quotes every few minutes.

They basically automated their social media presence, and fine, that works for them. But that doesn’t inspire me. Mitch Joel says the following in a brilliant post called Wanting Something:

In the end, the majority of the answer is not about the talent or the ability to pull a thought together, it’s about the commitment. The blank screen does not care… it’s agnostic. If you write, good for you. If you don’t, good for you. That being said, if you keep at it… If you use these platforms to think deeply about what you’re about and why you think your industry is the way it is, then slowly over time you’ll find your groove and your talent will shine.

Sadly, most people want it fast and easy. That’s good news for those who are truly committed to it, because they’re the ones who actually get what they want.

Or, as Dave Duarte says in The Ultimate Social Media Strategy is Not Having One:

Ultimately, social media is not just a set of technologies to be mastered, it is a cultural reality to be engaged with. It promises to expose the corrupt and reveal the extraordinary, and if nothing else it is guaranteed to keep us on our toes. It is chaotic, unpredictable, and uncontrollable. So the best social media strategy, then, is not a strategy at all, it is to be purposeful, ethical, and transparent and let our communications and behaviours flow from that.

Those are the people I admire, and the ones I want to follow on Twitter and in life. The ones who show up every day, work hard to get better at what they do, and don’t look for shortcuts.

Be good to your mother

Well, not just your mother, but everyone around you. Be nice. There really is no excuse to be rude to people on Twitter or elsewhere on the web. But of course, you only have to spend 2 minutes reading comments on YouTube to give up the dream of a civil Internet forever.

In a great post on commenters online, Dmitri Fadeyev quotes the following Thomas More passage from Utopia:

Ther’s a rule in the Council that no resolution can be debated on the day that it’s first proposed. All discussion is postponed until the next well-attended meeting. Otherwise someon’s liable to say the first thing that comes into his head, and then start thinking up arguments to justify what he has said, instead of trying to decide what’s best for the community. That type of person is quite prepared to sacrifice the public to his own prestige, just because absurd as it may sound, h’s ashamed to admit that his first idea might have been wrong””when his first idea should have been to think before he spoke.

If only we could follow this rule before we reply/comment, the web would be such a nice neighborhood. Sure, it would probably be less interesting as well. And maybe I’m getting old, but I’d actually prefer nice at this point.

By the way, this doesn’t mean we shouldn’t criticize where it’s appropriate. It just means we should be respectful when we do it. As Mike Monteiro says in Giving Better Design Feedback:

Good feedback is not synonymous with positive feedback. If something isn’t working for you, tell the design team as early as possible. Will they be hurt? Not if they are professionals. A good designer will argue for their solution, and then will know when to let go.

By all means, be respectful, but don’t hold back in order to spare an individual’s feelings. Taking criticism is part of the job description. The sooner they know, the sooner they can explore other paths.

So make this your motto for a week or two, and seek out those who do the same. Who knows, maybe a nice Internet is out there after all.

About a week ago I had a discussion with a colleague in our development team about the new product development process we rolled out a few months ago. One of the words he used to describe the new process is fair.

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession.

Loads of articles have already been written about the characteristics of a good Product Manager (see the end of this post for links to some of them). They’re all fantastic, and I go back to them constantly when I’m in the hiring process or looking for personal development areas. But I’ve never been able to find the one characteristic that I think a PM simply cannot do without. I now think that fairness is that characteristic. Here’s why.

The role of fairness in effective product management

Let’s look at one definition of the word fair:

fair. adjective. free from favoritism or self-interest or bias or deception.

Free from favoritism

One of the fastest ways to become ineffective in a PM organisation is to start playing favorites with a particular internal group, product line, or user base. As soon as people sense that you are not looking at all ideas and input equally and fairly, a lack of trust inevitably follows. And without trust, you’ll have to work a lot harder (and longer) to bring people along for the ride on your roadmap.

Free from self-interest

If you start doing things purely with reasons like “because I want to” or “because I’m being measured by this metric,” that same lack of trust happens very quickly. You cannot be effective by nursing your own pet projects and ignoring all the other needs around you.

Free from bias

This often happens when PM’s get news they don’t want to hear — especially from the user research team. If something doesn’t test well, don’t make up reasons why you are right and the users are wrong. Do the right thing and realign the design.

One of the hardest skills for a PM to learn is to take their own emotions and feelings out of the equation when it comes to decision making. Yes, a lot of gut feel goes into a product vision, but that cannot be based on personal preferences or preconceived ideas.

Free from deception

This one seems obvious, but you see it often, especially when it comes to metrics and assessment. Don’t ignore/distort negative data or make a problem someone else’s fault. The PM’s job is to own a product — and this means owning its successes and its failures. You’ll gain trust and respect if you not only claim the successes, but also acknowledge the failures and commit to do it better next time.

The elements of fairness in product development

The PM role is often referred to as “the great diplomat,” and with good reason. It is our responsibility to balance a variety of needs from inside and outside the business, and somehow turn that into a roadmap that delivers business value as well as meets user needs. A focus on fairness accomplishes that goal:

• Fairness to users. Approach users with respect, openness and transparency. Understand their needs, and explain to them when you’re doing something that makes it more difficult for them to meet those needs. (Don’t be like Twitter and hide behind reasons like “consistent user experience.”)
• Fairness to the business. Do everything you can to understand the needs of marketing, merchandising, customer support, etc. Pull them into the planning process, be clear about how projects are prioritised, and help them adjust to that process so that they can define their project goals in the right way to get on the roadmap.
• Fairness to technology. Don’t force the development team to make the technology do things it’s not capable of doing. Understand the technical debt in the organisation, and work actively to make those improvements part of regular development cycles.

A lot of this comes naturally in good product managers, but we need to be conscious of it every day. Fairness is a table stakes characteristic for an effective product manager. If you do it right, the real work of building great product can begin. But if you don’t, you’re dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

More characteristics of good product managers:

• Recruiting Product Managers
• The desirable characteristics of a Product Owner
• Owning an Agile Product

As an enthusiastic (but mediocre) runner, I’ve been thinking a lot about the similarities between marathons and product management.  With all this focus on sprints, we sometimes forget that as one sprint runs into the next one, and the next one, and the next one, at some point it doesn’t feel like a sprint at all any more.  And before you know it you’re tired, overworked, and excessively grumpy — basically teetering on the edge of sanity.  There has to be a better way, right?

So when it comes to long runs, I think you can plot the relationship between distance covered and your level of joy as follows:

In general, you start off feeling great.  But as the first mile progresses, you start getting weird thoughts.  “What have I done?” “This is the stupidest decision I’ve ever made!” “I’m going to die!!!” And by the time you finish the first mile, you’re ready to collapse in a crying heap of shame.  But then something strange happens: you start enjoying yourself.  You hit your stride, you look around, you enjoy the scenery and the people… And before you know it you think that you can carry on like this for forever.

But of course, you can’t. At some point, things start going South again, and you feel like you’re never going to be able to finish. A downward spiral of self-doubt ends with a dose of endless self-pity in the dark depths of hell. And you’re ready to give up again. But then you see it: “1 mile to go.” And suddenly everything feels ok again. You pick up speed and race across the finish line like the champion that you know you are. And you say, “That was great! When can we do it again!”

This is a post about what I call First Mile Problems and Last Mile Problems in day-to-day Product Management.  If you replace “Distance” with “Project timeline”, and “Joy” with “Sanity level” in the graph above, I think you’ll have a good overview of what it means to be a PM. And the problems you experience at the beginning of a project are often distinctly different from the problems you experience later on. So I’m hoping that we can help each other here, and hopefully end up with a graph that’s a little more… stable.

First Mile Problems

1. Aligning the team

One of the toughest challenges in Product Management is getting everyone on the project team working in the same direction towards the same vision. Sure, you all like each other and work well together, but how do you take all those differing opinions, stop the brother/sister-like bickering, and get to work? This isn’t something I’ve completely figured out, but I do think some of the answer lies in what Business Week calls I-shaped people.

We’ve all hear about T-shaped people — those who have a deep understanding of one specific topic, and a basic knowledge of a broad range of different topics. But I-shaped people are different:

These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between.

[They are able to] rise above the specifics of a particular problem to think about them in a more abstract, and in some ways, more general way.

I-shaped people are able to build consensus around the team’s direction because they’re able to not only see  where the product is going, but they’re also stuck in the weeds enough to have credibility to make the day-to-day decisions. I look at it this way:

When you set the vision for the product, keep your head in the clouds:

• Communicate the vision clearly to the team, don’t expect they’re just going to implement whatever you tell them to do. Bring everyone along for the ride — it will make the vision better, and keep everyone invested in what you’re doing.
• Show how you plan to get there, so that the team knows it’s more than a pipe dream. Use broad strokes to communicate ordered priorities that will get the team to the vision. Which brings me to my next point…
• Use pictures. It doesn’t matter what kind. Sketches, wireframes, hi-fi mocks, whatever it takes to get the message across and allow everyone to have the same vision in their heads. Not showing at least some framework is a recipe for running into trouble in the last mile.
• Above all, remain flexible. The vision is a plan, and nothing more. Things will change. New ideas will come up. The interface will change. That’s more than ok — it’s a good thing. But you have to start walking in the right direction, otherwise you’ll never get anywhere.

When you get going on the project, keep your feet on the ground:

• Be in the details. Understand every pixel on the page. Know about every single Jira ticket. Show that you care about the journey, not just the destination. Be there for your team to remove every and any roadblock that might come up and prevent them from making progress.
• Communicate clear expectations, then trust your team. If you did your job right, you hired a team of amazing people. So don’t second-guess them. Ask questions, but allow the designer to defend his/her decisions, and trust them as long as the thought process makes sense.
• Most importantly, don’t hover. This is a hard one for me, but don’t stand over the designer’s shoulder. I have a rule — if a designer has Photoshop/Fireworks open, I stay away. They’ll come to me when they’re done. As the excellent article World Wide Mush points out: “If you want to foster creativity and excellence, you have to introduce some boundaries. Teams need some privacy from one another to develop unique approaches to any kind of competition. Making everything open all the time creates what I call a global mush.” Designers need time to design on their own before they share their thoughts with the rest of the team.
• And finally, learn what you don’t know. This one might be a little controversial, but I tend to agree with Six Revisions in their post Should Web Designers Know HTML and CSS: “Web designers should know HTML/CSS ”” even if it’s just limited to the fundamentals ”” for the sake of being able to create web designs and web interfaces that work on the medium.” If you don’t know how to code, learn. You don’t have to be great at it, you just need to understand it. If you came from a technical background and don’t know much about UX design principles, LEARN it. It will garner respect, make you more effective, and above all, result in better products.

I want to end this section with a final word on trust, which is a topic that’s very close to my heart. The site “99%” recently posted a fantastic article called What Motivates Us To Do Great Work. It’s a must-read for all managers of creative teams. The crux is this:

For creative thinkers, [there are] three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). All three are intrinsic motivators.

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.

When it comes to recommendations for creative leaders, [authors of a recent study] don’t mince words: “Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources.” In short, give your team members what they need to thrive, and then get out of the way.

Like I said: trust, don’t hover…

2. Stakeholder buy-in

Once you have team alignment on the project and the vision, it’s time to turn your attention outward and focus on stakeholder buy-in. This part of the process often makes me feel like I’m on the wrong end of a very angry mob. It’s a stage when Product Managers need to use all the communication skills they can muster. Because when it comes to design, everyone has an opinion.

So this is where we need to talk about the phenomenon of Design by Committee.

If you haven’t seen the Oatmeal comic How A Web Design Goes Straight To Hell, you need to go read that first, and then come back here — it’s a perfect summary of the problem. The ultimate post on this problem has also already been written, so I’m not going to spend too much time on it — just go read every word in Why Design by Committee Must Die in Smashing Magazine. I do want to highlight a couple of areas in that article, and add some of my own comments.

One of the main problems we have in web design today is that everyone thinks they’re a designer. With coding it’s different — not everyone can code. But design is different. Like art, everyone has an opinion on design. You like it or you don’t. And because you have this immediate visceral reaction to a design, it’s tempting to confuse that with knowing what makes a design good. But that’s simply not true.

As posts like Designing for the Mind and  Gestalt Principles Applied to Design have shown, what makes a design “good” has very little to do with taste, and everything to do with the proven psychology of visual perception. “Pretty” is a small part of design compared to applying the principles of solid user experience design to an interface. So please, let’s leave design to the people who are trained in this stuff. Have I mentioned the importance of trust?

The Smashing Magazine article ends with this advice, which I agree with:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

On a practical level, this is how I apply that piece of advice:

• Respond to every piece of feedback. This is tiring, but essential. Regardless of how helpful it is, if someone took the time to give you feedback on a design, you need to respond to it.
• Note what feedback is being incorporated. Be open to good feedback, don’t let pride get in the way of a design improvement, and let the person know what feedback is being incorporated.
• Explain why feedback is not being taken. If a particular piece of feedback is not being taken, don’t just ignore it. Let the person know that you thought about it, and explain the reason(s) for not incorporating that feedback. It’s hard to get upset at you if you explain clearly why you’re taking the direction you’re going with. And if you’re not sure how to defend the decision…
• Use the user experience validation stack to defend decisions. Read the post Winning a User Experience Debate for more detail, but in summary, try to first defend a decision based on user evidence — actual user testing on the product. If that’s not available, go to Google and find user research that backs up the decision. In the absence of that, go back to design theory to explain your direction. I mentioned some sample posts above that should be helpful, and also check out The Psychologist’s View of UX Design.

When it comes down to it, everything once again comes back to trust, and a clear definition of roles and responsibilities. Senior management needs to trust their hiring judgment, trust their Product Managers, and give them the authority to make decisions for the projects they are responsible for. And, of course, hold them accountable if those decisions end up being wrong. It’s all we want: give us the tools we need to get the best possible product out the door, and hold us accountable if we’re not successful.

Last Mile Problems

Ok, so let’s assume you have a team that’s moving along, working away on a project, and all the stakeholders are bought in, so you’re on a roll. But it is almost inevitable that things will get rocky again towards the end of the project. Here are some Last Mile Problems and thoughts on how to deal with them.

1. People issues

I probably don’t even have to describe this one. We all know what happens. People get tired and cranky. They start distrusting each other. A small mistake creeps in and the whole team jumps in to point it out. Whatever the catalyst, the outcome is all too familiar — a team that fights more than they work. So what do you do?

I’m not a fan of self-help books at all. Let me start by saying that. But a previous manager recommended Crucial Conversations — Tools for Talking when Stakes are High to me, and it’s been one of the most helpful books I’ve ever read. You have to read it cover to cover, but in summary, it describes how, when people are put in situations where they feel threatened for one reason or another, they react in one of two ways:

• Silence. When things get rough, some people simply withdraw, either by going quiet, glossing over the issues, or masking what’s really going on by changing the subject and talking about other things.
• Violence. Others resort to attacks (both directly or indirectly through passive aggressive behavior), putting labels on people (“he’s an idiot who writes bad code…”), or trying to control the situation without considering the opinion of others.

Both of these responses are destructive and not conducive to good teamwork.  So the rest of the book focuses on how to deal with those behaviors.  How do you create a safe environment where everyone feels they can voice their opinion without feeling disrespected or unvalued? I’ve found the following process really helpful in situations of team conflict:

• Commit to seek a mutual purpose. Recognize that there is a problem, and get the team to commit to fixing it and not just sweep things under the rug.
• Recognize the purpose behind the strategy. If different people on the team want different things, ask them to explain why they want this done a certain way. Even better if this can be phrased from a user’s perspective. For example, saying “I want this button to be red because I believe it will convert better” shows that the purpose behind the strategy is to increase conversion.
• Invent a mutual purpose. After everyone voiced the purpose behind their strategy, discuss a purpose everyone can agree on, before looking at specific tactics/strategies to get there. For example, if one team is concerned about conversion and the other team about user confusion, can you bring those together, and invent a purpose that encompasses both ideas? Can the purpose be to reduce drop-off while staying within the site’s visual style guide?
• Brainstorm new strategies. Once you know what the purpose is, the team can brainstorm solutions that will fulfill that purpose. Continuing our example, move the discussion away from button color, and find ways to move elements around to reduce user confusion and drop-off, while committing to testing different button colors and adjusting the style guide based on whatever the data says.

I used an imperfect example to explain those points, but the principles work — give it a try!

2. Delivery issues

Stress-levels rise as delivery dates approach, especially if it looks like those dates aren’t going to be met. The first thing we need to clear up is that humans are horrible at estimation (here’s a very interesting post trying to solve that problem). I think the solution to this kind of stress is, as controversial (yet recently very popular) as it is, to do away with detailed estimates.  Tom Fishburne sums it up really well in his post Waterfall Planning:

It’s important to know the business inside and out and have a clear trajectory where w’re headed.  But there is a point where planning becomes overplanning.  All that time spent planning is time spent not doing.

Gantt charts are particularly problematic in this regard, as summed up by another great post called Project Managers, Not Calendar Monkeys:

I’ve been working on a way to balance the benefits of Gantt charts (ability to input dependencies and adjust an entire schedule with the push of a button) with the best way to communicate project schedules to clients. Most people can’t read a Gantt chart, and no client should have to. Gantt charts are more useful for planning next steps than providing an at-a-glance project status anyway.

So what’s the solution? I don’t think we really know yet. I am all for planning and knowing where you’re going, as I pointed out earlier in this post. But I think holding a team to specific deadlines isn’t the right way to increase velocity, and results in more stress than it’s worth. So what’s the alternative? I think you build (and sell to executives) a team driven by different types of goals:

• Build a team driven by priorities, not timelines. Know what are the most important things to work on, work on those first, and move on to the next thing. Have goals (that can include timelines), but realize that things can change. Trust your team that they will work towards those goals, and then knock off the priorities one by one. Of course there will be deadlines driven by external pressures, but keep those at a high level so that the team has a clear goal to focus on. This will ensure better quality (because you’re not cutting corners and rushing to get things done) and higher velocity (because everyone is focused on doing the right things in the right order).
• Build a team driven by action, not meetings. In progress meetings, I prefer to represent my team so that they can go on with their work uninterrupted. If someone wants to attend the meeting and speak for themselves, that’s fantastic, but I don’t think it should be a requirement that everyone on the team be present for strategy and update meetings. Note that this is different from working design meetings, where actual solutions are being produced. A meeting where you walk out with a deliverable (a sketch, a wireframe, a product requirement) is a good meeting. All others should be handled by the Product Manager/Owner so that the team can go about their business uninterrupted.

Speaking of which, allow me to bring in one more voice of reason on meetings, Mike Monteiro. In his excellent post The Chokehold of Calendars he writes:

Meetings may be toxic, but calendars are the superfund sites that allow that toxicity to thrive. All calendars suck. And they all suck in the same way. Calendars are a record of interruptions. And quite often they’re a battlefield over who owns whose time.

Make sure the focus is on working, not telling other people what you’re working on.

So there that is

As I read through this post again, I realize there might be some resistance to some of these ideas. Not that anything I said here is particularly new, but because I know there are several counter-arguments that can be made to these points. That’s exactly how it should be.

I’d love to get some input on this, particularly ideas and tips on how you’ve been able to deal with some of these problems. This is all a work in progress, as I assume it will be until the end of time.

This post is based on a recent talk I gave at the South African Scrum User Group, entitled Roadmap to serenity - How to stay sane as a Product Owner.