One of the awesomest new features in the revamped Rypple system is the ability for anyone to send kudos to anyone else. Kudos are a very simple, fun way to thank people for being amazing, doing a great job, going above and beyond the call of duty, etc.

It might sound sort of silly or contrived, but it turns out that a simple note of appreciation really can have a huge impact. Since I’ve started using Rypple to send out kudos, I’ve received a few notes from folks telling me that I’ve basically made their day. It’s a little thing, and doesn’t really take more than a couple of minutes out of your day, but it can really make a difference. We don’t often get genuine, heartfelt, positive feedback, so it’s really incredibly energizing when we do.

Everyone with a Rypple account (which is anyone, since everyone can sign up) can log in and send kudos to anyone with an email address. It’s totally wide open and anyone can do it — so if you have a few minutes sometime today, think of someone who’s done something awesome, head over to Rypple, and send them a kudos. The more you do it, the more fun it becomes.

Benoit Girard has offered to develop some materials to help new people learn about Mozilla and how to get involved. He’s looking for feedback about the initial topics he’s outlined over on his weblog. It would be really great if people could take a quick look and help him out.

Last week, I asked for suggestions about possible screencast/video introductions we should produce to help people learn about Mozilla, our tools, our methods, and how to get involved with the project. It was pointed out (and rightfully so) that we already have quite a few resources along these lines, they’re just scattered and hard to find.

So, in addition to getting new content produced to help people, I’m going to start collecting existing materials together and figuring out how to make those easier to find and use.

I’ve created a new page on wiki.mo called Learning Mozilla, listing on it some of the useful things I already know about. Now I need your help: if you know of other resources that would be useful for someone who wants to learn more about Mozilla, please take a few moments to add it to the page or leave a note (with a URL) in the comments here.

Anything and everything is great — I’ll dig for more content as I can, and I’ll take it upon myself keep the page cleaned up and organized, so don’t worry too much about where to list things or how to format stuff. Just add the links and we’ll sort out the rest as we go.

Feedback is an interesting thing. Critical feedback, while incredibly valuable and vital to improving and learning, can also sort of gut you. And working out in the open — in this crazy transparent fishbowl that is the Mozilla project — critical feedback can often come fast and furious. It’s great, of course, and absolutely fundamental to how we do things, but it does require a thick skin, and it can be profoundly exhausting at times.

On the other hand, positive feedback is absolutely energizing. Those moments where someone goes out of their way to say “thanks” or “awesome job” or “you rock” really does make it all worthwhile. Feeling appreciated — knowing that someone genuinely cares about and values the work you do — can often make the difference between something being a burden or a joy. For me, receiving positive feedback is the most powerful motivator out there — more so than money, fame, or anything else.

Rypple (which we use at Mozilla) recently built a new feedback mechanism into their service called “kudos” that you can use to send someone a quick “thanks”, “you’re awesome”, or “you rock” sort of message. The message you send is visible to everyone in the organization, so serves as a public note of appreciation. Other people can comment on the kudos as well, so there’s a way to quickly add a “+1″ or otherwise pile on the love. You can read more about the Rypple kudos feature (and an ongoing contest they’ve launched to promote it) over at WorkplaceHero.com.

The Rypple kudos system really is fantastic. We don’t often go out of our way to publicly acknowledge the awesome things our coworkers do, but Rypple has given us a fun, fast, simple, lightweight, and unintimidating way to do so. If you haven’t checked it out yet, you should — take a minute to send a kudos and make someone’s day :)

Johnathan Nightingale and Rob Campbell recently put together fantastically useful screencast introductions to Bugzilla (Johnath) and Firebug (Rob). The response to these has been phenomenal, so I’ve been gathering suggestions for other screencasts we could put together to help people learn about our tools, code, culture, community, and so on.

So far, people have suggested the following:

• Lifecycle of a Bug – introduction to the stages involved in fixing a bug from start to end
• Building Firefox – introduction to getting the Firefox source code and compiling it, while going over the basics of hg
• Test Frameworks – introduction to the different test frameworks we use, and how to write a basic test in each of them
• Drinking from the Firehose – how to stay on top of the news, difference between “stream of development and ideas” and “announcments”, how to understand things like what the next milestone is
• Bugzilla for Developers: Getting your patch into the product – how to nom for review; how to determine if you need to nom for approval, blocking, etc.; writing tests; checkin wrangling; watching the tree.
• Gaining Traction – how to publish that wicked cool idea you have; how to rally people around it to see if there’s interest; moving from idea to implementation
• How to navigate the code using MXR/DXR
• How to use and contribute to MDC
• Writing your first automated test
• How to do your own screencasts/videos
• Mozilla Developer Tools & Workflow
• How to optimize edit/compile/test loops
• Presentation tips & tricks

What other screencasts or video introductions do you think would be useful for learning Mozilla and getting involved with the project and community?

Just jumping on the adblocking yea/nay blogging train: I don’t block ads. I could but I don’t bother. Most of the time they don’t bother me unless I’m trying to read a long article, at which point I use Readability, which is infinitely better than an adblocker for that situation.

Before Readability

After Readability

Note: Readability runs fine on Minefield if you use Nightly Tester Tools to force-install. There’s also a bookmarklet version if you don’t want to install an add-on.

One of the most important parts of my week is my one-on-one (1:1) meeting with Dan, my manager. These meetings generally only last around half an hour, and it’s time extraordinarily well spent. In that half hour we catch up, discuss projects and status, review priorities, troubleshoot blockers, checkpoint against our quarterly goals, and use the time to give each other feedback. It might sound like a pretty dense 30 minutes, and that’s because it is. Our 1:1 meeting is a tightly packed conversation that establishes and reinforces my direction, priorities, and motivation. As a remotie*, I would be lost without it.

The actual meeting is only part of the story, however — while the meeting only lasts for half an hour, I do some prep work the day before. This prep work mostly involves reviewing my projects and goals, writing out what I want to talk about, and sending those notes to Dan so he can review them before we meet. I find this process extremely useful.

Over the months I’ve established a more-or-less standard format for my 1:1 prep notes that includes five fairly straightforward sections:

• Accomplishments & status
• Blocked/Waiting on
• To do over the next week
• Areas to develop
• Quarterly goal tracking

Accomplishments & status: This is where I do a quick rundown of my current projects, with one or two sentences covering what I’ve managed to get done in the last week and what the current status looks like.

Blocked/Waiting on: This is where I list the projects I’m stuck on and why, or other things that are blocking progress — either waiting on resources, people, feedback, or whatever else. Having this section is absolutely vital — if I’m blocked on something, we can usually talk it through so I get unstuck, or Dan can figure out what he can do to help.

To do over the next week: By writing out a short list of specific things I plan to work on over the next week, Dan and I can make sure that I’m working on the right things and am prioritizing things properly. This doesn’t take a lot of time to go over, and since we checkpoint on this every week there usually aren’t any changes, but sometimes my task list gets rejigged slightly if other things have come up elsewhere in the organization.

Areas to develop: Usually this is a one or two sentence “big picture” sort of thing. Dan and I talk about longer-term career development once every month or two, discussing what I need to do or develop in order to progress, become more effective, and have more impact. In this part of my prep notes I take a few minutes to review how I think I’m doing in relation to what we discussed and jot down what I believe I need to focus on improving the most.

This section gives Dan a chance to do some career development coaching. While we normally deal with this part of the meeting in a matter of minutes, it’s profoundly useful — this is an incredibly quick and easy way for me to get ongoing lightweight feedback from Dan on a regular basis.

Quarterly goal tracking: We establish a set of goals each quarter, and every week Dan and I review progress on the ones I own and am driving. I find this useful because regularly checkpointing against my goals helps me make sure I’m focusing on the right things. By reviewing these weekly, we can also make ongoing course corrections where needed. Life rarely happens exactly according to plan, and priorities and projects can shift. It’s far better to review and adjust things weekly than to do a single review late in the quarter just to realize that things got off track (at which point the panic sets in).

Video chat: Another thing I should mention is that Dan and I have our meetings using Skype video. We used to just use the phone, but Dan talked me into using video chat and it’s really much, much better. As a remotie, being able to get “face time” like this is way more important than I thought — not only is the communication much higher bandwidth, there’s a psychological impact I can’t really explain. I just feel more connected to the rest of the company, which is both surprising and fantastic. If you’re remote, you should really try using video chat for your 1:1 meetings…I can almost guarantee that it’s more useful than you expect.

And that’s about it. Having developed the habit of prepping for my 1:1 meetings this way, it only takes me about 15-20 minutes to write up my notes to send to Dan, and it makes our meetings incredibly focused and useful. If you’re not sure you’re getting the most out of your 1:1s, you might try something like this — a half hour of prep work on your part for a half hour meeting can have a huge impact.

Do you have particularly awesome 1:1 meetings? What makes them awesome? What tips would you give to people who would like their meetings to be more useful?

• remotie: noun, a person who works in a different geographic location than his/her manager.

Readability is a Firefox add-on that improves the experience of reading long articles in your browser by getting all the extraneous cruft out of the way. I use it every single day and love it to bits.

Here, for example, is a screenshot of what a typical Harvard Business Review article looks like in Firefox (Persona: Save the Bees Plz by monorail cat):

Old Crufty

With the Readability add-on installed, all I have to do is hit a quick keyboard shortcut (alt-cmd-R) and the page will reload and be reformatted by Readability. It looks like this:

New Clean

It’s just so, so much better. arc90, you have made a great thing. Thanks :)

I stumbled across an article called “Your Greater-Than-Yourself Project” by Steve Farber, and it was interesting enough that I bought the book.

The premise is fairly simple: You can help make the world a better place by finding and mentoring someone who you feel has amazing potential and help make them as successful as possible (ideally, of course, to be “greater than yourself”).

The greatest, most successful and well-respected leaders that I’ve encountered in my two decades of consulting, advising, writing, and speaking are not just helpful: they’ve come to understand that the true measure of their greatness as leaders is their ability to develop leaders who go on to surpass them — who rise to a level greater than themselves in skill, influence and ability.
– Steve Farber

The article outlines six pieces of advice to help you get started, which are expanded upon (in a roundabout way) in the book. It’s a fantastic premise, but I’d be curious to see how it works in action. The book doesn’t really get into a whole lot more detail — it’s written as a parable which makes for a quick read but glosses over the nitty-gritty. Worth reading, either way.

Drive, by Dan Pink, is a book about what really motivates us and why, and I believe that anyone who leads a team, community, or open source project would benefit from reading it.

It turns out that extrinsic incentives — the old “carrots and sticks” system of punishments and rewards — really don’t motivate us very much at all. This isn’t to say that things like money, benefits, promotions, and bonuses aren’t important, but science tells us that after a certain level (i.e. when pay is already fair and equitable), extrinsic motivators aren’t really all that effective.

True motivation is something at once more simple and more complex. Intrinsic incentives — those motivations that come from within and are part of our fundamental character and make up — are the real reason we strive to excel, why we take such satisfaction in producing exceptional work, and are what lie behind our real passions and drives.

Pink postulates that there are three elements to intrinsic motivation: Autonomy, Mastery, and Purpose.

The first element, Autonomy, is based on the observation that people are more likely to be engaged in and passionate about something if they are free to be self-directed — allowed not only to choose what they work on, but to find their own solutions, strategies, and approaches to the work involved. Pink puts forth “four Ts” where autonomy and self-direction matter: task, time, technique, and team.

Compare these two situations: In the first, you are asked to work on a project you select, on your own schedule, using methods you choose, and with a team that you recruit. In the second, you are asked to work on something you’re not interested in, on a schedule someone else sets, using methods you have no influence over, and with people you can’t trust, don’t like, and find difficult to work with. Which would you find more motivating? Where would you do your best work? Autonomy is an absolutely fundamental part of motivation.

Mastery, Pink’s second element, is based on his belief that we each have an innate “desire to get better and better at something that matters”. This drive is what lies behind that seemingly magical state known as “flow” — where time falls away when you’re working on a clear task that is just challenging enough without being frustratingly difficult. When our tasks are just slightly beyond our current level of mastery we are inspired to push ourselves to get better and accomplish ever greater things.

The third element, Purpose, provides a grounding context for the other two. “Autonomous people working toward mastery perform at very high levels. But those who do it in the service of some greater objective can achieve even more.” If you believe that what you’re doing has a purpose larger than yourself — say, as an example, ensuring there is choice and innovation on the internet and safeguarding the future of the open web — you’re going to be even more motivated to accomplish amazing things.

The book mentions both Wikipedia and Firefox as examples of what people can accomplish when driven solely by intrinsic motivation. All three elements are present: contributors are autonomous (entirely self-selecting and able to scratch whatever itches they like), highly skilled and driven to continually get better at what they do, and they usually have a pretty fundamental belief in the purpose and importance of the larger project. Working together over several years, the people involved with these projects have accomplished what most sane people would have believed was impossible only a few years ago. Intrinsic motivation is powerful, powerful thing.

If you’re interested in understanding the power of intrinsic incentives (and, to some extent, the dangers of extrinsic incentives) and harnessing those to motivate your team or open source community to even greater feats of awesome, I think Drive is definitely worth reading.