The words “responsible” and “accountable” are often used interchangeably in everyday language, but they can connote different things, especially when used in the context of work. Others have written about the difference between the two.

Merriam-Webster defines the difference as: “responsible” implies holding a specific office, duty, or trust; “accountable” suggests imminence of retribution for unfilled trust or violated obligation.

My own feelings lie closer to those of Christopher Avery, who says: I prefer to use the word Accountability to refer to making, keeping, and managing agreements and expectations. And I prefer to use the word Responsibility for the feeling of ownership.

I’ve found it can be easy for people to feel responsible for their work, especially when the work is going well or has high visibility. People want to make their mark on projects and add value to a team. This is how you end up in a room full of people who all think they are the owner of a project.

However, things get dicey when a project isn’t going so well. What happened to all those people who were responsible? Often times, they’re nowhere to be found and their leaders do not hold them accountable. In some cases, the mere fact that they were on a high profile project means their names are on the shortlist to head up the next one!

Holding people accountable for their work isn’t just about punishing failure. As frequently discussed elsewhere, failing can be a critical part of the creative process and avoiding failure at all cost may result in a systemic lack of innovation in a company’s culture. Instead, leaders should try to create a culture that values risk-taking but is accurately able to identify the reasons for failure and work with those accountable to improve in the future.

Creating a company culture where people are both responsible and accountable can be challenging but is worthwhile.

First, the analysis is spot-on, with one major exception that I’ll get to shortly. Before that, though, I’ll add one more point in favor to Chrome’s “close-on-the-right” behavior: favicons. Safari doesn’t display favicons at all. This distressed me to the point that when I used Safari as my primary browser, I installed an add-on that added them back in. That’s yet another point for Chrome.

However, the article’s conclusion of striving for “least-funky behavior” doesn’t really take into account just how funky it is for the “close” button to be on the upper right of a window in OS X. I’m with John Gruber on this one: close goes on the left in OS X. He goes into more detail about his thoughts, which articulates my own beliefs better than I could.

I believe this boils down to the frequent trade-off of consistency versus the “best” design. I’ve often run into scenarios where I’ve had to choose between consistency (either inside the application I’m designing, or matching an application to the overall platform it lives in) and what I felt like was the best solution to a design problem. I don’t know if there’s a universal right answer to this question, but I often find my own design sense landing on the side of consistency.

In Chrome’s case, it’s clear that a designer thought about Chrome’s tabs in detail and made a decision to go with what he or she thought was the best flow for the user. The result is a fantastic experience in Windows and a good one in OS X, with some additional funkiness.

I used this analogy to describe my thoughts on the situation to a friend: it’s like if a US city ran some studies and determined that the “best” design for stoplights was the reverse of what we already use. That city then decided to buck the trend and build all their stoplights in the reverse order used in the study. Maybe it makes more sense if someone were to never leave that city, but as soon as you drive to the next city over, it’s disorienting.

I witnessed many changes during my time there, with some being more successful than others. None, however, were as big as the recent announcement to partner with Microsoft. I think the jury’s still out on how successful this partnership will be, but I have a few thoughts on it.

First, on a personal level, I am disappointed Nokia won’t be putting more effort into MeeGo. I spent the end of my career at Nokia working on MeeGo and would have liked to see real people use the applications I worked on. I believed MeeGo had some aspects that would make it a viable alternative to Android and the iPhone.

However, I understand and largely agree with Nokia’s decision to abandon their own platforms and move to Microsoft’s. Symbian was dead in the water, and building up a thriving MeeGo platform and developer ecosystem would have been a great challenge. So great, it seems, that the Nokia leadership didn’t believe they could accomplish it. Nokia has many smart and capable employees, but they might have been spread too thin in the massive organization to carry out this type of work. A smaller, more focused, organization working on Windows Phone may be able to create a solid phone.

Will this risk pay off? As a hardware vendor, Nokia will have to compete directly against the Chinese hardware manufacturers. This will be a challenge, but Nokia has always been strong in the supply and manufacturing area. With Microsoft’s software expertise and Nokia’s hardware experience, they’ve got a good shot.

Even though I had the song memorized and ready to go, I got a near-zero recognition rate. On one hand, I was surprised more people hadn’t seen the video (40 million views on YouTube and counting), but on the other, I was a dead ringer for your average redneck.

It did get me thinking about Halloween costumes for future years. I’ve been interested in light-related art installations for a while now (you might see me occasionally link them on my Twitter feed), but have recently come across some wearable light-related projects.

For example, one talented designer built a functioning replica Daft Punk helmet. It’s beautiful:

While the creator of this helmet built his own circuit boards, I recently learned about Arduino, a small, programmable circuit board that can be used to sense its environment and control lights, sounds, and other software. I haven’t had the chance to play with one, but it seems like it has the potential to be a great side project.

For example, check out this light-up suit using an iPhone to control an Arduino board. I think building something like that would be a lot of fun for a Halloween costume.

Finally, Kanye West performed at the 2008 Grammy Awards in a glowing jacket and glasses, as seen here:

When I watched this performance, I was mesmerized by the light show and his outfit. I’ve been interested in replicating his outfit since then. I’ll try to use his jacket and these other projects as inspiration for my own work.

The tournament was hosted by Justin.tv and staffed by a small army of volunteers. 48 teams participated in three brackets, and the tournament ran smoothly and surprisingly quickly.

Dan and I won our first game and lost the second to a team that made it to the finals. We both had a ton of fun and met a bunch of fellow Starcraft enthusiasts. I hope to return for a future tournament.

Tom Wujec, the speaker, has facilitated this exercise over 70 times with a wide variety of people. His talk focuses on which groups consistently perform poorly (recent business school graduates) and which groups perform well (children in kindergarten). He’s got some great explanations of why this is and how to apply this information to other design challenges. It’s a fun talk, and worth watching.

I ran a similar challenge with a group of 20 designer colleagues at Nokia. I used slightly different rules: no marshmallow, and instead of building a vertical tower, teams had to build a horizontal cantilever off their table.

The purpose of the exercise was to build cross-team relationships and foster a design community across multiple organizational silos. This group of designers would go on to meet monthly as a design community, and this initial exercise helped break the ice and begin relationships. Ironically, as the facilitator, all the participants knew me, but the challenge didn’t let me get to know many of them!

Over a year later, I ran into a designer who had participated in the challenge. He said it was the most memorable design meeting out of the lot and that his co-workers still brought it up.

Watching the TED talk has inspired me to run the challenge again, and I highly recommend it to any group searching for a fun team-building exercise.

The hour-long lab meeting ended up energizing me in a way I hadn’t expected. The projects being discussed were all very interesting, impactful, and wide-ranging. They included Peace Dot, a program to highlight work that increases peace around the world; Mobile Health 2010, a conference bringing together people using mobile technology to change health behavior; and the Behavior Grid and related Behavior Wizard, a systematic framework for describing behavior change.

The lab members spoke passionately and insightfully about their work, and served as a reminder of how much I value those types of discussions. I hope to bring that type of passion and intellectual excitement into my life more regularly. And if I need a boost, there’s always the lab.

I’m going to start with a simple portfolio section and build it up over time. Similarly, I plan to continue to customize the theme and add relevant features.

Finally, now that things are up and running, I plan to start blogging. I’m still not sure what the domain of these entries will be, other than generically “interesting to me.” I anticipate the first batch will be follow-ups on Twitter posts where I want to discuss something for more than 140 characters.

For now, all that’s here is this post.  In the future, look out for my portfolio, a blog, and who knows, maybe some other stuff.  The portfolio is in the works and will hopefully spring into existence in the near future.

Until then, good night, and good luck.