Let’s make sure we’re choosing our tools for the right reasons

I recently got back from CSS Dev Conf where I gave a presentation about migrating our site to Object-Oriented CSS. The project wasn’t easy and the outcome isn’t perfect but despite all of the challenges we faced, I came away convinced that it was the right thing to do.

Many of the talks I saw at the conference also included clear indications that the ideas behind OOCSS were pervading the sites and organizations represented there. It wasn’t always mentioned by name and at least as often it was other similar approaches like SMACSS or BEM that were touted but the idea of modularizing CSS was definitely a common theme.

One of the most interesting aspects of the conference was that almost all of the presenters were there because their presentation pitch has been voted in by the attendees. That means that the talks given were representative of what members of the community wanted to hear about and not just what the conference organizers decided. Developers are asking for better ways of structuring, developing, and maintaining CSS and these modular CSS approaches seem to be a welcome answer.

Despite this, there are people in the industry who have expressed concerns about the OOCSS approach. I was specifically asked for my opinion about this article by Ben Darlow: Cargo Cult CSS. I think he does a great job of capturing common criticisms about OOCSS and so I wanted to offer a response to this particular article because it would serve as a broader answer to concerns that have been expressed elsewhere.

Semantics

One of the most common objections raised about OOCSS is that it forces us to use classes which are not semantic.

To me, this point hinges on an equivocation. When people refer to semantics in web development, it is almost always shorthand for content semantics. We were trained to value content semantics over all else and this has formed the basis of our best practises for years. Based on that narrow definition of semantics, OOCSS does suggest that we use non-semantic class names. But this fails to consider that “semantics” simply refers to conveying meaning. It is only associated with content because we’ve made it that way.

The way I explain OOCSS is that it is about embracing visual semantics. CSS is a language used to express layout and design and basing it on content semantic class names is actually conflating two different things. We sacrifice scalability in our CSS if we force it to be tied to a vocabulary that represents a different set of concepts.

Allowing for the concept of visual semantics does not replace the concept of content semantics. They are both valid and important. We should strive to convey as much meaning as possible in all of our code. In some cases we have tailor-made mechanisms such as HTML tags for content semantics, data attributes for data semantics, or ARIA attributes for behavioural semantics. In other cases we have fewer options to express meaning. Because the class attribute is so flexible and not definitively tied to a specific meaning, I don’t see any reason not to make as much use of it as possible. Microformats use classes to convey content meaning that can’t be expressed any other way. OOCSS uses classes to convey visual information. These are not mutually exclusive.

Performance

To me, performance is the least compelling aspect of OOCSS. Nicole Sullivan has argued for the performance benefits, but in the projects that I’ve worked on in the last few years we’ve had far bigger performance issues to deal with than small improvements in file size or repaint speed. If you are focused on the just the performance benefit of OOCSS (or lack thereof), you may be overlooking the more important benefits like clarity, reusability, and maintainability.

You Can Still Do It Wrong

Getting OOCSS right is not easy, especially because it is so unfamiliar. Don’t make the mistake of dismissing the technique based on bad examples or slippery slope arguments. Darlow offers this warning:

<span class=”display-block blue-box font-arial color-blue solid-blue-border padding-20">Party like it’s 1999!</span>
<span class=”display-block blue-box font-arial color-blue solid-blue-border padding-20">Hey, have you checked K10K.net lately?</span>
<span class=”display-block blue-box font-arial color-blue solid-blue-border padding-20">Wassuuuuuuup!</span>

“This might seem like an extreme example, but it’s the logical conclusion of a CSS framework methodology that abandons semantic class names and selectors in the pursuit of ‘modularisation’.”

I have never written any code like this and anyone that does has failed to understand OOCSS. To suggest that this is the “logical conclusion” of the approach says more about the author’s grasp of the concepts than it does about the concepts themselves.

Writing OOCSS is much more like programming than we’re used to in our style sheets and comes with some of the same challenges. Getting naming and granularity right are some of the most challenging aspects of object-oriented programming and object-oriented CSS but I’ve never seen the former dismissed because of it. Moving from table-based layouts to CSS was just as challenging and we made plenty of mistakes early in the process. The fact that it is difficult and that we can find poor examples doesn’t negate the underlying principles, it just points to how new and different this approach is.

Sticking With What Works

We’ve been building web sites with our current set of standards for about a decade now and some see this as evidence that OOCSS is unnecessary. Darlow puts it like this:

“Front-end developers have been quietly and successfully building large-scale web projects without the use of a CSS framework methodology for years. The fact that such projects have managed to avoid the use of OOCSS, BEM and others demonstrates that there are other effective ways of working.”

The counter-argument is that ours is an ever-changing field and tools and techniques will always be evolving. It’s part of what we signed up for entering this field and it is one of the most appealing parts to a lot of developers. In fact, Darlow himself perhaps puts it best when he says in the same article:

“You’re a professional web developer. You don’t write in Notepad any more, so don’t restrict yourself from using the best tools to do your job. … Read up and see how it’s being done elsewhere; broaden your knowledge.”

In that quotation, he is making the exact opposite argument for recent innovations like CSS preprocessors. To suggest that we should stick solely with what has worked historically in some cases but broaden our knowledge in others doesn’t really make sense. We should always be looking for ways to improve our work and not dismiss new ideas simply because we’ve been able to manage without them.

Avoiding IDs

The suggestion made by some OOCSS proponents that you avoid using IDs gets a lot of attention. I don’t see this being nearly as controversial as it has been made out to be. For one thing, this advice is sometimes misrepresented as being about avoiding IDs for everything when it actually only refers to avoiding IDs for CSS selectors. IDs are still perfectly valid for use with forms, for in-page anchoring, for JS hooks, etc… They just become problematic within the principles and practices of OOCSS.

It’s also important to understand that this recommendation follows the rest of the instructions about how to write OOCSS. I would never tell a front-end developer to stop using IDs without providing the context of how to write CSS without relying on them. Within the framework of OOCSS, this idea becomes practically trivial. I haven’t written a selector that relied on an ID in years not because I fear them or don’t understand them but because I don’t want or need them.

OOCSS is not Perfect

While I will gladly use and defend OOCSS, I will also acknowledge that it has limitations.

The biggest weakness of OOCSS is a direct side-effect of its greatest strength. By fixing the meaning of our classes to refer to predefined visual patterns, the only way to change how a particular element looks on our page is to change the classes applied to it. That means that we’re actually editing HTML to make design changes.

While this may just be unusual in some cases, it can cause real problems in others where we may not have as much control over our markup as we do our CSS. For my project, we ran head-first into this issue because we were working with a CMS that, unsurprisingly, templated our markup. In our case, though, we wanted to be able to apply different themes to a page depending on what part of our organization was providing the content. Before OOCSS this would have been easy. I could apply a different style sheet that used similar selectors (based on content semantic classes) to style the page however I want. Now, though, I can’t change the design without changing the markup and I can’t change the markup without changing the CMS template.

In our case, we solved this by employing Sass and its @extend directive. This is actually where Darlow and I agree. CSS preprocessors are very useful tools and make modularising your code much easier. We differ, though, in how that relates to OOCSS. While he would argue that this makes it unnecessary, I would say that they are complementary (as does Nicole Sullivan).

Find What Works

I’m an advocate for OOCSS (and other similar modular CSS approaches) but try not to be dogmatic about it. Finding solutions to tough problems is basically a developer’s job description so we should have as many tools in our toolbox as possible. There may be valid reasons why this approach isn’t the best option in your situation. Just be sure you’re making that evaluation based on a compete understanding of what OOCSS is (and isn’t), and not misconceptions.

This post was also published via Medium

"Change is hard" is a cliché. Living through change means uncertainty, challenge, and effort and those aren't always welcome. What I actually want to talk about, though, is the other side of that cliché: that causing change is hard.

I often see well-intentioned and well-delivered presentations meant to change behaviour. I've heard people passionately and intelligently argue for ways we should change. I've seen concepts taught clearly and concisely to help educate people about new ways of working. I suspect that in few of these cases has the result been equal to the expectation. Despite having a great idea and presenting it in a compelling manner, people are frustrated by what seems like a stubborn lack of change.

That frustration is understandable but in it we can often forget that what we're trying to change are people. Change is hard for people. We aren't all simple, rational actors who will always act in our own best interest or be swayed by a logical argument. Getting people to change is incredibly hard, especially if you don't acknowledge their nature. The good news is that if you understand that nature, you have a powerful tool to help engender change.

One of my favourite non-fiction books is Switch by Dan and Chip Heath. It's all about this topic and provides great techniques and examples to help drive change when change is hard. I'm going to be discussing what's in the book here but at a very high level. I strongly recommend reading the whole thing as it is clear, quick, and very practical.

The Elephant and Rider

The first thing the authors present is a model for how our mind works. Somewhat strangely, they suggest that we think of ourselves as an elephant and rider (This model actually comes from The Happiness Hypothesis by Jonathan Haidt but they use it as the foundation of their approach). If you think of an elephant and rider, you can probably guess at some aspects of their relationship. The rider is able to see further and plan a route but the power and size of the elephant are necessary to actually make the trip. The rider ostensibly directs the elephant but if there were something the elephant wanted to do, the rider wouldn't have much choice.

In us, the rider represents our rational, logical self. We plan. We analyze. We consider. This is a strength and a weakness. While being able to make logical decisions is what allows us to manage uncertainty, we also have a tendency to over-analyze and become paralyzed when faced with too much information or choice. The elephant is our emotional self. It is powerful but reactive. It can drive us incredible lengths but is easily distracted and tends to focus on short-term gain.

In order to get people to change, we need to appeal to both the rider and the elephant. By their nature, they respond to different things. Those rational arguments you're making might appeal directly to the rider but ignore the elephant. That may earn you head-nodding but it's likely that the people you've "convinced" won't have the conviction to change when they need it. Powerful emotional pleas may energize the elephant but don't offer the rider a clear idea of where to go. You may get change, but not the change you were aiming for. If we can engage both the elephant and the rider, we can give people all the tools they need to change.

Directing the Rider

Since the rider is responsible for analysis and planning, we need to make a rational appeal that guides both of those processes. We also need to avoid letting the rider become paralyzed by indecision. Our goal is to clearly direct the rider to where we want them to go.

To start to figure out how to do this, we can Follow the Bright Spots. Is there anywhere the change has already taken place? Is there anywhere where people seem more motivated to make this change? If we can find examples of what has worked elsewhere, we can use that knowledge in our own situation. Focus on what has worked for them and how you can leverage it in your own situation. We can also look at our own situation. Although it isn't where we want it to be, it probably also isn't the complete opposite. Identify any small steps that have already been taken in the right direction and use those to build on. It can be very motivating for people to see that they're already part way down the path (note that this sense of accomplishment would resonate with the elephant as well).

One important note: bright spots aren't always seen as a good thing. When we see others enjoying the success that we want, our initial reaction can be jealousy ("why can they do it and I can't?") or cynicism ("are they cheating?"). This is natural but is extremely counter-productive for what you're trying to accomplish. Remember, that other success means that the change you are fighting for has already happened somewhere! That's actually a huge boost to what you're trying to do. Make those people your allies and you will have a better idea of how to drive your own change.

To provide the clear direction that the rider needs, there are two things we have to focus on. The first is to Script the Critical Moves. The rider's weakness is being faced with too much choice. We need to whittle down the number of things that have to be done and express them in a way that is so clear that there can be no mistake about what to do next. This is the problem with admonishments like "eat healthy". The direction is so nebulous that it becomes impossible for the rider to decide what to do. Focusing on small, simple choices that lead to the goal is far more effective. Compare "drink skim milk instead of 2%" to "reduce fat intake": the former is clear and easily actionable while the latter leaves the rider mired in indecision.

The second is to Point the Destination. The rider is the planner. He or she will do a lot of the work to figure out how to get somewhere if they have a clear idea of where they're going. Again, clarity is key here. The destination needs to be articulated so that it leaves no room for misunderstanding. KPIs tend to be used as destinations (e.g. "Increase sales by 10%") and while they may be clear, they fail to make any kind of connection with the elephant. The destination we want to point to should also be one that inspires an emotional connection. This could be through hope or awe or pride but a destination has to be a place we want to strive for.

Motivating the Elephant

The elephant needs to feel the change. The elephant is a near-boundless source of energy for change but only if we can motivate it to expend that energy. The elephant isn't interested in facts or figures so we instead need to Find the Feeling. If we can find and foster the emotion for the change, people become engaged in the process. Why should people care about this change? How can you frame it in a way that appeals to our humanity? A great example of this for me is around accessibility. I know why we should do it and I know how we can do it but the first time I actually saw someone struggle with our site because of their vision impairment, it hit me right in the gut. It evoked an empathetic response that you will never get from explaining why it's important.

The elephant is directed by emotion and will value short-term gains over longer-term thinking. To put this to use for us, we need to Shrink the Change. When we succeed, we are inspired. When we are inspired, we are motivated to do more. If we can earn quick wins, we can build the elephant's momentum by creating hope. When we want to drive change, we need to set small, achievable goals in the service of the bigger picture to coax the elephant down the path and reinforce behaviour. An example of this is using something like the Pomodoro Technique to tackle a large task. By only agreeing to a small, set amount of time to work on something (e.g. "I'll just do the dishes for 5 minutes then take a break"), we avoid being overwhelmed by the whole and can earn a quick win. This progress inspires us to do more and to see that any large problem is normally just a set of much smaller (and more manageable) ones.

In addition to shrinking the change, we can try to Grow the People. When people make decisions, they very often base those decisions on their identity. There are numerous factors that make up our identity (e.g. "I am a Canadian", "I care about the environment", "I'm bad with money") and when people make decisions they are really trying to determine "am I the kind of person that does this?" Despite seeming so fundamental, identity is surprisingly malleable. If we can get people to believe they are the type of person who would make this change, they are able to choose with their identity. This involves reinforcing the aspects of the identity that align with the change and making sure that the identity is supported by action. For example, if our department wanted to foster collaboration through promoting that as part of our identity, people driving that change would need to act like people who care about collaboration. Through setting the example and reinforcing the idea, the members of the department may start to take on "we are people who collaborate" as part of their identity.

Shaping the Path

The elephant and rider are a part of their environment and in order to drive change, we need to consider that environment. In terms of the analogy, the environment is the path that the elephant and rider are on. If we can change the environment so that the elephant and rider have less environmental resistance along the path we want them to take, then they have to expend much less energy to get there and will be more compelled to do so.

The first approach is the Tweak the Environment. It's astounding how small a change to the environment is required to affect change. My desktop computer at home has been where I've done all things digital for many years. Some months ago, I got a tablet. I now use my desktop maybe once every week or two while I use my tablet every night. There are a number of reasons for such a radical change but for me one of the most significant is start-up time. My desktop takes about 30 seconds to start up. My tablet is instant. In the grand scheme of things, 30 seconds is nothing and yet it has prompted an almost complete change in my behaviour. Extremely small obstacles in our environment can have extremely large affects on the choices we make. If you are trying to incite a particular behaviour, examine the environment to see if there are any changes you can make to remove obstacles to that behaviour. If you are trying to diminish a certain behaviour, see if there are any obstacles you can add (this would be like freezing your credit cards in a block of ice). Be aware, however, adding obstacles when there is no clear, compelling alternative will just lead to frustration.

Another approach is to Build Habits. When people act out of habit, the behaviour comes for "free". There is no cognitive load involved so it doesn't cost the actor any of their energy or willpower. There are entire books written on this subject (The Power of Habit by Charles Duhigg is a good one) but one simple idea is to make use of triggers. If we create can strongly connect an action to a specific circumstance, it can quickly build a habit. For example, what's the first thing you do when you sit down in your car? Hopefully it's putting on your seat belt. Sitting in the car is a trigger for doing up our seat belt and it has become so ingrained we just perform the action automatically when we get into that situation. If we wanted to get people submitting their time cards on time, we could link the action of submitting your time card to receiving the email from Scheduling on Monday morning. Eventually people will habitually perform the action when the see the trigger.

Finally, we can employ peer pressure in a good way if we Rally the Herd. Surrounding people with evidence that their peers are engaging in the behaviour you are promoting provides powerful social pressure to conform. It becomes much harder to resist change if it makes you an outsider to do so. This can be accomplished by highlighting examples of success and eventually indicating how few areas are left that still need to change (e.g. "95% of our department has already switched!"). Changes to behaviour are contagious so we need to people to be able to see the new behaviour taking hold.

Driving Change

Driving change is hard. There's a significant danger that people will give up on promoting their great ideas because of the frustration inherent in trying to drive change. We are all worse off if those people who are passionate enough to try to make things better are stymied in their efforts. While there is no magic solution, fully appreciating the bizarre and contrary nature of the people you're trying to change will make you more effective. If you're already frustrated, you may not want to hear something that sounds like "try harder" but what this all comes down to is that there is only one person we can actually change: ourself. The purpose of these techniques isn't mind control; they are just a way to help people change themselves. So if we can't change ourselves enough to consider new approaches to drive the change we want, how can we expect anyone else to change for us?

Consider this thought experiment. What if you wrote down what you thought your role on your team is. Then every member of your team wrote down what they thought your role on the team is. If you all shared what you had written, would the answers be consistent? If they weren't, how do you think that would play out in your team dynamics? What if a second question were asked: how well are you performing in that role? Would those results be consistent? What impact would variation in the first set of answers have on the second set of answers?

When I imagine this scenario I am immediately struck by how difficult this conversation could be but also how valuable it would be to have this information out in the open.

On the one hand, people might be forced to say things or hear things they aren't comfortable with. They may have to face a reality that they have been consciously or unconsciously avoiding. It would also require a level of trust, honesty, and openness we don't necessarily have with our team.

On the other hand, it would expose assumptions we've made individually and replace them with shared understanding. A team whose members are clear about their responsibilities and how well their team was functioning would be able to address those realities directly and improve upon them together.

Good Reasons to Not Communicate

I think it's safe to say that open communication is seen as an extremely important aspect of any relationship, be they personal or business. "Transparency" in particular is a term that is being used a lot these days as something to strive for. And yet I think we still feel that we aren't getting clear communication from those around us. If we were willing to, we would even be able identify in ourselves times and situations where we shy away from being clear and honest.

I think the wrong conclusion to draw from this is that we or those around us are bad people. Far more often, I think the decision to limit communication is made for seemingly good reasons. Being honest and open is difficult and puts us in difficult situations. It often takes more strength than we think we have. We can convince ourselves that something can go without saying in order to avoid a situation we don't feel prepared for. There can be an element of self-preservation as well: we never have to face criticism, justify ourselves, or risk being wrong if we don't truly communicate.

I'm not being facetious about calling these good reasons. They can feel very compelling when we're forced to make a decision about how (or if) we communicate something. That makes it all the more important that we understand the price we are paying in avoiding communication.

The Cost of Not Communicating

As we are making a decision about whether to communicate or not, the cost of not doing so is hard to take into account because it won't be felt immediately. The cost is subtle and insidious and comes in the form of assumptions we may not be aware of.

Our assumptions are where we have filled gaps in our knowledge. In order to act, we need a foundation of knowledge regarding the environment we're acting in so that we know things like rules and priorities. When we are missing some of that knowledge, we make assumptions based on observation in that environment or extrapolation from other environments.

In our jobs and in our lives, we are constantly required to make decisions and perform actions based on available information. Those actions are often observed by others or directly affect them. If we all knew everything there was to know about every situation then the rationale for every action would be obvious. As it is, though, there will always be a great deal of information we aren't aware of. Seeing someone act in a situation we aren't familiar with may be inscrutable but it doesn't bother us because we don't expect to understand. In a situation we are familiar with, however, we do expect to understand actions people take and can respond negatively when we don't.

Think of the last time you saw a co-worker do something you didn't understand and how you reacted. You may have questioned their intelligence, their fit for their role, or their motives. Our workplace is an environment we expect to understand. We wouldn't be able to function in such a complex system without thinking we had a handle on how it worked. What if, though, you and your co-worker didn't have a shared understanding of that environment? What if they are just as intelligent, qualified, and motivated as you but are operating under different assumptions?

That brings us back to that experiment. There is no shortage of big questions that could be asked to expose and challenge our assumptions. How is our team perceived? What is our purpose? How am I perceived? What can I do better? Asking and answering those questions is not easy but there is a real cost to not doing so. Through experiencing a transition into Agile at my workplace, I've been amazed to see the transformative power that challenging assumptions has. Even just realizing that there are assumptions being made and that people might not share an understanding is profound.

Despite working in different roles and in different organizations, questions around motivation seem to be asked consistently. How do we motivate our workforce? How can I stay motivated about my work? Why are some people more motivated than others?

My thinking on the subject was radically changed a number of years ago when I first read a book called Drive by Daniel Pink. It's a Gladwell-esque look at the topic of motivation and is a book I find myself reflecting on often and recommending to people regularly (I own two copies and both are leant out right now).

Traditional business practises often fail to understand that people are driven by intrinsic motivation. Management attempts to motivate people using carrots and sticks under the presumption that people are little more than livestock that just need to be herded in the right direction. In Drive, Pink argues that this is not just ineffective but actually detrimental to the engagement and productivity of a workforce¹. In fact, management's role should not be to get people to work, it should be to let people work.

As evidence, we can look at one of the many examples of people doing "work" without any external pressures. Take for instance open source development. Developers in paying development jobs go home after work and do more development without any promise of salary, bonus, performance review, or promotion. Why is this the case and what can learn from it to improve our workplace? Pink identifies three factors we need to be present in our work for us to feel motivated to do something: autonomy, purpose, and mastery. When these needs are met, people are more motivated, engaged, and productive.

Autonomy

Autonomy is the ability to make our own decisions about what we do. It is the antithesis of micro-management. When people are given the freedom to apply their own skills and experience to solve a problem instead of being prescribed a solution, they feel greater ownership of the outcome and more engagement in the process.

Allowing autonomy for employees involves trust and a relinquishing of control but is not meant to encourage anarchy. A task is still bounded by constraints and expectations are still set for what is to be delivered but the how of that delivery should be left to the person or team doing the work. The more latitude we have in the solving of the problem itself, the more motivated we are to work on it.

Purpose

If the purpose of a task is clear, it encourages quality. We must be able to understand why we are doing something and see its value in order to want to deliver our best. We want to believe that we are contributing to something worthwhile that is bigger than ourselves.

It is important that the purpose of the work be felt in a personal way and not just described in vague notions of it being "good" or "serving the user/client". Purpose can't just be handed down as a corporate edict, it must visible in the decisions that are made and the actions taken in the environment around us.

Mastery

We feel rewarded for working on a task when we can see that we are gaining some level of mastery by doing it. We want to work on things that will improve our skills and challenge us in new and different ways. In ideal cases where the difficulty of a job and the environment we have to work on it are optimal we can achieve "flow", which is a state known to confer major benefits for productivity and enjoyment.

Tasks that are too simple or repetitive don't offer opportunities for growth and so are less appealing. While not everything we need to do can be perfectly tuned for our mastery needs, a role that provides more opportunity for personal growth is far more appealing than one that doesn't.

What can we do?

Back when I wrote about delivering value, I discussed the need for a team lead to multiply value by having a positive effect on all of their team members. To me, creating an environment where all of these factors are present is the single most important way to do this. If you are in a position where you can help shape the environment for a team, I strongly encourage you to consider what level of autonomy, purpose, and mastery your team members have and how it can be increased.

For every one of us, though, I think it's important to look at how well our needs in these areas are being met. We are all responsible for performing our jobs to the best of our ability and slogging through work without being engaged isn't productive or healthy. If necessary, we need to push to have these needs recognized and find ways to carve out more autonomy, purpose, or mastery where we can. For me, in writing articles like this I have the autonomy of dictating the topic and schedule, a purpose in sharing knowledge and ideas, and am gaining mastery in writing and communication skills. It's not explicitly in my job description to do so but I'm driven purely by my own motivation while still delivering value to the organization.

Finally, if you've made it this far I strongly recommend reading Drive. It goes into much more detail and offers evidence to back up the claims I'm making. You can watch the author give a TED talk on the subject or see an animated synopsis.

¹ I'm cherry-picking a bit here. There are cases where external motivators are beneficial to productivity but they are where tasks are generally simple and routine. When tasks require problem solving or creativity (as ours do), intrinsic motivation has a far more positive effect.

I have more things to do than time to do them. I know I'm not alone in this. We are constantly fielding requests, interruptions, notifications, communications, and distractions. Being able to prioritize how we spend our time is essential. It's so essential, that we actually ask in our boarding interviews how candidates prioritize competing tasks.

Here's a technique I've been using that you may find helpful (or at least be able to put in your back pocket for your next interview).

Urgent vs. Important

First, we need to distinguish between what is urgent and what is important. Urgent tasks are those that demand our attention. Important tasks are ones that are truly valuable. All tasks have some level of urgency and importance but it is extremely easy to be distracted by in-your-face urgent tasks at the expense of ones that are actually important.

By way of analogy, consider this scenario:

You are a medieval hero sworn to protect your monarch. The most important thing you can do is protect that monarch's life. It is your duty and the good of the land depends on it. When your monarch is kidnapped, you spring into action and find the keep where they've been imprisoned. Innumerable enemy guards stream from the fortress and you battle valiantly against the tide. Although your skills are legendary, their sheer numbers will eventually overwhelm you.

You face the extremely urgent task of defending yourself against each of these guards. However, constantly facing these tasks won't ever help you complete your one important objective: rescuing the monarch. By focusing on the important, other options may become available but you must be willing and able to forgo the urgent. By beating a retreat now, perhaps a more clandestine approach becomes viable. Only by prioritizing the important task can it ever be accomplished.

(This is inspired by and paraphrased from http://abetterlife.quora.com/How-to-master-your-time-1)

Using Urgency and Importance for Prioritization

The simplest way to benefit from thinking this way is just to acknowledge that there is a difference between urgent and important. Understand that just because something is demanding your attention right now doesn't actually mean it's the most valuable way to spend your time. This little bit of perspective makes it easier to reject a distraction or say no to a request to help you stay on top of what you need to do.

We can go further, though. If we think of urgency and importance as being binary properties (i.e. a task is important or it's not), then we can come up with a grid to classify any task we face.

(image from http://leap-start.com/urgent-vs-important/)

Ideally, we can stay focused on tasks that are important and not urgent to keep stress down and enable longer terms thinking. Tasks that are urgent and important need to be dealt with quickly but can hopefully be avoided by managing them early (i.e. before they become urgent). Tasks that are urgent but not important should be ignored, avoided, or delegated so that they don't waste your time.

Personally, I think that urgency and importance are more of a spectrum and I needed a way of prioritizing tasks based on these relative values. For my own use, I created a spreadsheet where I could list my tasks and then assign values from 1 to 5 for urgency and importance. I also added a column for effort (again, a value from 1 to 5). It doesn't really matter what the number means, I just wanted an easy way to indicate that something was more important or more urgent than something else. I then generate a score for each task based combining importance and urgency and then dividing by effort so that quicker tasks get a higher score. Whatever task has the highest score is what I work on.

My own version is an Excel file but I've created a Google spreadsheet that you can copy and try yourself. Excel has more robust conditional formatting so I can actually highlight the item in the list with the highest score. I couldn't figure out how to do that with Google.

If All Else Fails

There is overhead to this technique and I sometimes fall prey to analysis paralysis or simply being overwhelmed. In the end, doing something is better than doing nothing. A while ago I created a very simple web app that just picks a random task from the list you provide. It can be surprisingly liberating. If that sounds like it's more your speed, you can try it out here: What Should I Do?.

I have this idea of a hypothetical work unit. One work unit is the amount of value an average worker adds in a given time frame. This is similar to idea of Story Points and Velocity in Agile. The average number of Story Points a team accomplishes in a sprint becomes their Velocity. We can look at a worker's value in the same way. Whatever the arbitrary meaning of value is in a given job, we could theoretically designate workers as providing a certain number of work units. An average worker adds one unit of value. An above average worker might add 2 or 3 units. A below average worker might add a half or a quarter unit.

The point of any such designation is not about evaluating or ranking any particular person. I couldn't tell you how many units an individual provides because the concept is too ambiguous. You may have some sense that someone adds more value than someone else but scoring isn't where I'm going with this.

Where I think this gets interesting is that I don't feel that everyone simply adds value. In arithmetic, we have addition, subtraction, division, and multiplication. I think these concepts become an interesting way to think about relationships and value in the workplace.

Doing the Math

Addition is straightforward. A worker doing a job adds value. This is obviously important and having people that add value are crucial to any team. Some people may add more value than others but any added value has a net positive effect on the team and the work.

What about subtraction? What does it mean to consider someone subtracting work units? Taking a rock and putting it at a desk confers zero work units to a team. There is no value being added but there is also no value being taken away. Someone that subtracts is actively removing work units from a team.

A subtractor might be a worker who doesn't add much value on their own and also actively distracts or disrupts others from their work. Workers like this are not of benefit to a team and, if they couldn't be turned into adders, would ideally be removed.

That said, subtractors might simply be new to a team or an industry. Their subtracting of value could represent time spent by other team members (who would otherwise be adders) helping to educate and acclimate instead of directly adding value in terms of work units.

That is not to say that these efforts are without benefit. It is an investment to spend time turning someone from a subtractor (or a low adder) into a higher adder. I'm using "value" in the context of this discussion to simply mean the sum of all work units and not true value in any universal sense.

Division has a much more significant negative impact on a team. While subtraction could be in the form of a future investment, a team member would be considered a divider if they have a net negative effect on the whole team. People who cause serious deficiency on a team by creating a toxic environment, reducing morale, or otherwise diminishing the effectiveness of many individuals would be arithmetically dividing overall work units delivered by some factor (a quarter, a half, etc…). It is (thankfully) rare that one team member should have such a significant impact on their entire team. If the situation does arise, however, it should be dealt with swiftly to limit major impairment to a team.

If a divider can reduce value delivered by members of an entire team, then a multiplier can increase the value delivered by all of those members. This could be by improving working conditions, streamlining processes, or inspiring more valuable team interaction. Note that a multiplier is not just a prodigious worker. A single worker can provide a great deal of value to a team through their output but this only makes them a high adder, not a multiplier. A multiplier doesn't necessarily produce work units of their own so a team of solely multipliers wouldn't be overly effective (zero multiplied by a high number is still zero).

Delivering Value in Different Roles

What's perhaps most interesting about these designations is that certain roles on a team fall under certain designations more readily than others. A worker on a team would need to be exceptional (and not necessarily in a good way) to be a divider or multiplier. What one particular team member does is not that likely to affect all team members. Getting work done affects the overall value of the team but doesn't really have a direct impact on a fellow team member's ability to get work done.

Contrast that with the role of a team lead (this could be something like a manager, scrum master, or a technical lead depending on the type of team). Almost by definition, the actions of a team lead affect all of the members of a team. If a team lead provides value to a team, that is probably through facilitating team members in getting work done. If a team lead is providing good tools, processes, and leadership, then every member of the team can add more value and the team's overall value is multiplied. The opposite is also true. A team lead that provides little value to a team could easily divide the team's overall value by impeding (even subtly) every member of that team. A team lead might manage to be an adder or subtractor but it is much more likely that they are having a more profound impact on the team.

In Practice

So what practical application is there in any of this thinking? For me, this framework helps to crystallize thoughts I have about roles and responsibilities:

• Developers should be adders, senior developers should be high adders, and architects should be multipliers.
• Onboarding is what turns new subtractors into adders. Having a good system means value can be added sooner.
• Having the right people in the positions that affect more team members is crucial. A divider as a team lead is a much more significant problem than a subtractor as a team member.
• Multiple layers of management can mean that team leads have an exponential effect on sub teams.
• A team lead that is not multiplying is underperforming.

The last point is what is most significant for me. The UI Architect role at the CBC is as much a leadership role as a technical one. Too often, I've been feeling like I'm adding more than I'm multiplying (some days, not even that). It may still confer benefit to the team but it's not what I'm here for. It's gotten me thinking about how I can do things differently to maximize the value I bring my teams. I haven't figured out any definitive answers but I have some ideas about what I might need to focus on:

• Communicating to larger groups or entire teams at once to avoid repeatedly transferring the same knowledge
• Working more on improving processes and tools than just using them
• Thinking bigger about what we could be doing instead of being mired in what we are doing

None of these are groundbreaking. Despite my exhaustive preamble, my conclusions aren't novel. What I'm choosing to do, however, is a bit different. This blog is going to be a forum to express some personal views about what I see around me. It will likely be opinionated and speculative but I'm hoping it will inspire some thought and discussion in the name of moving things forward and providing more value to more people.

Napoleon + Interface Design

"Orders must not be easy to understand. They must be impossible to misunderstand." - Napoleon

I recently saw that quote get tweeted by Tim Ferris and it immediately crystallized some ideas I've been having about interface design.

My work involves building web sites and, more often than not, they include some sort of content management system so our client can maintain the site once we're finished. That means that we're not only developing an interface between the site and its visitors, but also one between the site and its administrators. Despite serving very different purposes, the biggest commonality is that everyone makes mistakes. Designing an interface could simply be an exercise in creating easy paths to accomplish goals but at its best it needs to address what happens when users stray from those paths. If you can anticipate the mistakes people could make then you can eliminate them. This adds a significant element of empathy to interface design. Users aren't going to think like you and you need to be able to be able to see past your own context to understand what someone without your training or experience might do.

Thankfully, this insight can be gained through testing or, even better, actually interacting with users. When I go to train our clients on the content management systems we've built them, I always come away having learned a great deal about potential pitfalls from the questions that get asked.

For Napoleon, misunderstood orders could cost lives. Today, misunderstood interfaces can cost money. A lot of money. Silicon.com recently wrote about how Expedia earned an extra $12 million a year by removing a confusing form field. The "Company" field in the checkout form was just ambiguous enough to confuse some users and cause them to incorrectly complete the form. Removing the field, and thus the misunderstanding, turned the form into one Napoleon would have approved of.

Counting Crows + Plato

Way back in the late nineties, I was a Counting Crows fan. They had produced two great studio albums and 1998 saw the release of Across a Wire, a two-disc live album. To me, this album was a revelation. My favourite thing about going to a concert (and, by extension, hearing a live album) was when the songs sounded different from the original album version and this record had that in spades. The band played with almost every aspect of their songs: tempos shifted, arrangements differed, and even lyrics changed. I thought it was a impressive display of musical prowess. Then the lead singer, Adam Duritz, says this in the middle of the acoustic set:

"We're playing some of these electric songs because they've changed so much and because I think we really know how to play them now."

That stopped me. The songs had changed? They know how to play them now? It sounded like the songs somehow existed outside of the band and they were simply trying to capture them as opposed to them being the band's creations that they had dominion over. I'd never thought of music like that before.

I was recently reminded of Plato's Theory of Forms while reading The Disappearing Spoon by Sam Kean (the book isn't really relevant to this discussion but I thought I'd mention it because it's a very entertaining read). In brief, the Theory of Forms is that there exist perfect Forms of all things in a realm that we cannot experience. This realm has archetypes of a perfect tree, a perfect circle, the perfect colour blue and so on. All the things that we experience are our best approximations and interpretations of these Forms. The chair that you are sitting in is an attempt to mimic the perfect chair-iness of the chair Form.

I've come to think of great music and great musicians in similar terms to the Theory of Forms. I'm always the most fascinated when it seems like the music has an existence of its own. I'm always the most impressed when musicians have the skill to give music that bigger context by revealing versions that all manage to capture the recognizable Form of a song and yet are completely distinct. I think of the best live shows as capturing this kind of struggle of great musicians trying to harness and express great music that is bigger than them.

One of the best places I know to experience bands channeling the Forms of their music is La Blogotheque's Take-Away Shows. It's a series of performances where bands play in unusual locations and circumstances. They may not have their usual equipment or set-up but you can always recognize the expression of their music. Where else can you see Mumford and Sons translate their song into French and serenade a Parisian woman? What does Arcade fire sound like in an elevator? Search through the full list to find a band that you know and hear a form that their music can take.

What is this all about?

I read a short story many years ago that has stuck with me and provided some of the motivation behind this site. Sadly, I've lost the book and can't remember either the story's title or the author's name so I can't properly credit the person for the influence they've had on me. The story goes like this: A man comes to the conclusion that God speaks to us through randomness and so seeks to find more and more perfect examples of randomness that he can use to decipher God's message. I found the premise interesting but one aspect that really struck me was that the protagonist has been sure since his childhood that his name was spelled with a silent six (i.e. Dav6id). It was a simple idea but one that was also seemed extremely profound. Considering it was like an epiphany: expanding my mind in a direction it hadn't been before. At the end of the story (spoiler alert) the man, through studying quantum physics, is able to receive a message from God who confirms his theory and tells him that he's right about the six in his name.

My default mode of thinking seems to involve relationships. I often use analogies, metaphors and comparisons to understand or explain and simple things frequently remind me of seemingly unrelated ideas. What I occasionally end up with are interesting and unusual connections that get me thinking in a new way. My intention is to document some of that thinking here to help me crystallize these notions and to (hopefully) provide interesting reading for anyone else.

I feel like this all sounds very heavy and intellectual. In fact, the inputs into my compulsively dot-connecting mind are relatively mundane so instead of coming up with new grand philosophical designs, I've been forming links between Dan Pink's research on motivation and yogurt or Counting Crows and Plato (okay, I guess Plato is pretty heavy). I'm not really sure what's going to come next but if it seems interesting, it will end up here. Enjoy!

Update: Thanks to the hivemind at Ask Metafilter, the story has been identified as "The Spade of Reason" by Jim Cowan. Thanks interwebs!