They specifically allow multiple proposals in their call for speakers

This is good news for people like me, constantly shifting between disciplines and generally pursuing several big topics of interest at a time. I’d not had a chance so far to go to the conference: even though the paper I co-authored last year had been selected, I eventually ran into some schedule conflict and the other co-author went and delivered alone. This explicit invitation to submit multiple entries meant that I could suggest a conference on innovation, a mini-conference about web standards adoption, and a workshop on ubiquitous techs, and not worry about which would be more appropriate than the others.

They didn’t flinch when they saw me sending in different topics

In retrospect, I should probably have guessed that they were expecting experts to suggest several sessions in different formats (conference, workshop, mini-conference) in the same area of interest. This is how the amazing Denis will be presenting three different sessions on Web Accessibility throughout the conference.

They’re inviting me to speak!

I will be giving a talk-discussion on the challenges of innovation in an organization dedicated to keeping its staff busy and productive – a great excuse to talk about innovation, its history, the frameworks that work, those that don’t…

See you there!

My answer: of course we are – any company with a hierarchy will be. The main reason is that “promotion” in our industrial society, generally means “You’re really good and experienced at your job? Now stop doing it and start managing a bunch of people”.

And the fact is, most people are really, really bad managers. A manager should be leading by building trust and a culture of excellence/results/you-name-it, mentoring, empowering and setting clear objectives. Instead, when put in such a position, most will fail to build trust – instead they put process over people, waver on objectives, micromanage and bully. Management is hard. Management is the art of losing control.

And if you’re not doing too badly at the middle-management role, wait until you’re promoted to an executive role with the massive responsibilities it involves and the strategic leadership it demands…

Don’t like the sound of this?

1. Build a team culture where promotion does not necessarily equate management, but “here is a new challenge for you”,
2. mitigate the negative effects of hierarchy by adopting a less-hierarchical structure and Agile, Iterative and Incremental processes.
3. …or stay small.

I was once chatting with the architect in a small-ish (20 people) tech company. Asked about the size and structure of their group, he told me “Everybody codes here, except for the accountant and the CEO. The latter used to code, but he was so bad at it, we made him in charge of everything else”.

In panic, people try to replace the lost order of the organic process, by artificial forms of order based on control.

– Christopher Alexander, in The Timeless Way of Building

Don’t Panic. Change is on the Way.

My document sucked.

It was well received by the colleagues and managers I showed it to, but behind the thanks and praise it was clear that their real opinion ranged from “tell me something I don’t know” to “too much bullsh*t”, via “not ambitious enough”. Truth is, it was a messy mix of half-baked vision for our management, sales points for our account managers, and a hodgepodge of ways to make our team better at tackling this challenge.

Back to the drawing board. This time however, I did what I do best: gather people, make consensus emerge, and synthesize it into something even better. First, I stripped my document of all its grandiloquent sales stuff, all the operational ideas, and rewrote it as a manifesto: a simple, five sentence-long, explanation of my vision: ubiquity (beyond mobile), freedom (in the mobile context), usefulness here and now, platform independence, and simplicity.

Then, one by one, I took each team in a large room with a blackboard, and had them work on the following exercise. I gave them the manifesto and drew three columns on the blackboard: Strengths, Weaknesses, and Wishes.

In the first column we were to list all the strengths that would help us fulfill the manifesto I’d given them: their own strengths, their team’s, the company’s – opportunities, too. Likewise for weaknesses. And in the third, I wanted them to tell me the wishes they had, what they thought we needed to make it happen, what solutions they had to our weaknesses, what could enable or empower us.

Those used to strategic planning will have of course recognized a bastardized version of the SWOT (or SPOT) analysis. The venerable tool can be very useful with business-oriented people, but it has often appeared to baffle of scare away others, so my version tries to be a gentler, kinder SWOT.

Because it was easier to hijack existing teams’ meetings than to gather random groups one by one, I had a chance to observe the different reactions and dynamics of our designers, developers, etc.

The designers (our UX and Art team) came first, and had a fairly balanced approach. The weaknesses they pointed out were rather focused on emotion and perception, and their third column was very clearly about wishes – about how they would like to work and what they would like to play with – and not so much on solutions.

Then came the conseil team (advisors, account managers and strategists) and although not the largest team, they were rather prolific. Their view was mostly focused on business – their first column had more opportunities than strengths, and their last column was very much about partnerships, market and process, yet I think it is fair to say that their insight embodied the whole team rather well.

Third team I had the exercise with were the project managers. They were passionate, finding very few strengths but working a lot on issues and solutions. Not surprisingly, their focus was a lot on the way we work, with a lot of good ideas for tools and processes. One bizarre aspect of their analysis is that I could take the result of their brainstorm, slap a completely different title on it such as “innovation”, “profitability” or “efficiency”, and it would work just as well. Albeit great, their reflection had not much, if anything at all, to do with the question of ubiquity or mobile projects.

Finally, I worked with the developers, and was in for yet another surprise. Never have I seen a group so blatantly and immediately focus on solutions, without bothering with the expression of the problem first. They had, I think, the best ideas, most concrete and easiest to apply – but I had to struggle to get them to define the problems they were fixing, and had to fight even more to squeeze out a few items for the “strengths” column. The old “if it ain’t broken don’t fix it” motto applied here, and the dev team really didn’t understand why we should spend any time on things that work just fine until I hinted that perhaps it would be wise for them to show how apt their team was at taking this challenge on.

I came out of the whole exercise with the most amazing material. The second version of my document, albeit by no means perfect, is in a complete different league from the first. But I also came out of it a little jarred and alienated by the exercise in stereotypes, and vowing never again to conduct it in ways that favour groupthink within company subcultures.

I don’t want to stalk you, either, so knowing that you keep checking into a handful of places is not on my agenda. A few marketers may be very happy to know that, but do you really want them to know that you keep going to that lovely italian restaurant every tuesday before going to the movies?

I don’t care where you are right now, because I’m not there, and if I were, I’d want a smarter, less loud and noisy and crass way for the two of us to have a chance encounter. I don’t want to witness you flashing your underwear – repeatedly; but I do like the idea of a serendipity engine.

I want foursquare to be bought out and become semi-abandonware, and I want dopplr to thrive. Not the other way around.

Une version française de cet article, intitulée Trois modèles d’innovation, est disponible sur le Pheromone Lab.

Google

A current poster child of innovation management, Google has been following the McKnight and 3M doctrine: every employee is entitled to dedicate 20% of their time to experiment on projects of their liking. The most promising projects started by googlers may have a chance of becoming Google products, while the rest is still a good source of training. Also interesting is the pollination and competition factors: because employees need to “sell” their work to their colleagues through a peer-review system directly inspired from academia, a sane (?) competition atmosphere keeps everyone working their best.

I do not know, however, if Google employees are forced to deliver 5 days’ worth of work in 4 days, whether this 20% is done as overtime, or whether the sanctuary of “free time” is actually respected.

Stefan Sagmeister

Notable designer Sagmeister once decided that a way to keep his design team creative was to take a sabbatical year off every 7 years. During his year off, he usually travels, toys with ideas and prototypes, builds fun projects – all without the usual pressure of having to deliver.

I ignore, however, if Sagmeister pays his staff during that sabbatical, or if they all go and work elsewhere for a year and get hired back when he comes home…

Ferran Adria and El Bulli

In terms of culinary hype, few restaurants match Barcelona’s “El Bulli”, a restaurant that opens only 6 months a year. Adria and his team spend the other 6 months experimenting in their lab, slowly and carefully designing the next season’s menu. And when they get back, all reservations for the year are usually filled within the span of a day.

Alas, it seems the Michelin 3-stars restaurant will be closing soon… by lack of profits? Or to try and reinvent itself?

Investing in time

What do these three organizations have in common? They all invest time – giving their employees a chance to escape the daily grind of production and experiment. The main difference is how long, and how frequent, is that “free time”: 1 year every 7 years, 6 months a year… or 1 day a week?

Fast forward a few years to a new job, a different working context, and I find myself realising that mistakes I see around me are too often due to people’s incapability to say “no”. Being afraid to say no (when it matters) to colleagues, clients, boss, users or subordinates generally leads to one thing: the loss of trust and respect. So here’s a patchwork of situations when saying “no” is actually the right thing to do.

Management is the art of saying “no”

A few years back, I recall becoming fairly upset at my management: I would get myself invited to the directors’ meeting to bring up, again and again, issues which I thought were of the utmost importance. The management would agree with me that the issue was indeed a big problem, and usually proceeded to pat me on the head and encourage me to keep doing my best. Why weren’t they helping me fix a situation they agreed was noxious?

I later learned the mechanics of about any decent manager:

1. Are you coming to me with a problem but no solution? Go away.
2. Are you coming to me with a problem and some vague solution you kind of would like to brainstorm about? I’ll reply “no”.
3. Are you coming to me with a problem, and a set of solutions you’re ready to defend if I challenge you, and ready to improve if I embrace them? Let’s talk

In the words of past W3C colleague Dan Connolly: Management is the art of saying No. The refusal ritual is not just a tool for busy managers to manage their budget, it can actually be a very powerful way to lead and enforce a culture and the organization’s objectives. I recently found one such example in the book Collaboration by Morten Hanser, which devotes a whole chapter to “when not to collaborate”.

Saying no to your boss

Remember saying yes to that one week-end of work, because there was a project to rush out of the door? Remember saying yes to helping that colleague with his or her work, even though it had nothing to do with your own assignments? Remember saying yes to working a little longer that week, because the workload was particularly high?

Either of those taken separately are examples of chivalrous, courageous behaviour, and for some of us, there is absolutely no issue, and we will keep saying yes, yes, yes… until…

Remember ending up in the “hero syndrome” situation, where you burn out because you’ve said yes to too much, because everyone around you started taking you for granted, because you’ve been so good at doing so much that it would be a shame to call for help?

The biggest challenge of my work career – and my whole life, actually – may have been to learn this lesson. To know the freedoms I value, to stand my ground on the compromises I am not ready to make, and to be subtle but clear when I am making an exception. Learning to say no has made me a more respected and liked colleague, not less… and a happier person, too.

Saying no to your users

When you are building a product, the game usually goes like this: you realise that in order to succeed you somehow have to listen to your users/customers. So you listen, and boy do those customers have requests and great ideas. So you start adding all those features, considering any complaint as a life-threatening bug, burning money and time to keep up with the demands. What you usually end up with is an inconsistent, ugly, unusable patchwork of a product (hello, Photoshop!) which customers eventually desert.

The point of course is not to shun everything your customers demand and pretend you know better – it’s about upholding the clear vision you have for the product and, as the 37signals folk would say, Make each feature prove itself and show that it’s a survivor.

I like what Steve Jobs (himself a terrible dragon of a manager, apparently) has to say about innovation: innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we’ve been thinking about a problem. It’s ad hoc meetings of six people called by someone who thinks he has figured out the coolest new thing ever and who wants to know what other people think of his idea.
And it comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.

For more on this, I very much recommend going through Stephanie’s slideset on “Defying the Itch to Stitch”, where she explains how a great product is not about outdoing the competition, but about creating an original vision for your product.

Saying no to your clients

Likewise, in an agency or freelance context, most of us are often terrified of saying no to clients, in fear that they might just get someone else to work with them, someone more accommodating.

That may happen if you behave like an asshole, or keep saying “no” without ever making a convincing case for it, or bringing valuable alternatives.

But as my experience shows without a doubt: only juniors and amateurs always say yes; the expert will think things through, sometimes agree, sometimes say no and suggest a better alternative, and earn respect in the process.

What do you think? Has is your experience of saying “no” been a positive one? Share your insight in the comments, but remember the rule: all your comments have to start with “yes, and”…

A few weeks ago, Apple, a leader in sales of mobile devices, apparently started contacting selected developers with one message: stop assuming that you are building applications for 320x480px screens.

Score one for flexible design.

So, how can one create applications that would feel and work great in the current fragmented market of web devices? I’ve had, for a long time now, a hunch that web standard technologies such as HTML and CSS had the answer. HTML and CSS were made to meet this challenge, to build interfaces that scale, to cascade differently according to the media. The new CSS3 Media Queries pushes this capability quite far already, and I have been looking forward to experimenting more with it.

I was surprised, however, by a very interesting new trend: HTML+CSS+JS are being used not as the final UI layer for web applications, but instead as a programming language to be compiled into other languages (such as objectiveC, Java etc.) and the deployed, with native UI look and feel, onto a variety of devices.

This is the strategy currently followed by Nitobi’s PhoneGap and Appcelerator’s Titanium, both of which allow development using the basic Web technologies and JavaScript API, and package the result into “native apps” for iPhone, Android (and blackberry).

This could be a very exciting development for web standards as base layers for everything on the web… including applications that have very little to do with the Web paradigm. And for designers and developers, this could be the solution to the conundrum of flexible design and multi-platform development.

Score two for flexible design.

To help me avoid the mistake, I keep repeating to myself this simple sentence, inspired by the insightful David Rollert:

In a war, a general will have a goal (e.g. achieve fast victory with minimal losses and no civilian casualty), which combined with an analysis of the situation will result in a strategy (e.g. play the surprise effect, blitzkrieg, etc). The strategy will then be put to effect on the ground through tactics (e.g. attack here, attack there, and reinforce defences there to alleviate the potential impact of a counterattack).

If I’m not too far off, I hope this may help me ban misuse of the dreaded s-word from most of my daily conversations. Wish me luck.

P.S.: nothing wrong with not being a strategists. Any war will need many more able tacticians than strategists.

P.P.S.: make love, not war.