Tag: communication

links for 2009-02-19

  • Beckhard’s Change Equation
    Three factors must be present for meaningful organizational change to take place. These factors are:

    D = Dissatisfaction with the status quo;
    V = Vision of what is possible;
    F = First, concrete steps that can be taken towards the vision.
    R = If any of these factors are missing or weak, then you’re going to get resistance.

    (tags: leadership)
  • Leading Change: Remember the Marathon Model
    It is important for leaders of organizations going through change to realize the ‘lag time’ between where they are in the process and where others in the organizations are in the process.

    The higher a leader sits in an organization the more quickly he or she tends to move through the change process. Because they can see the intended destination before others even know the race has begun, senior managers can forget that others will take longer to make the transition: letting go of old ways, moving through the neutral zone, and, finally, making a new beginning.

    (tags: leadership)

links for 2009-02-17

  • Non-Hierarchical Management (Aaron Swartz’s Raw Thought)
    Lots of good stuff, including this gem:

    Firing people isn’t just about saving money, or petty things like that. It’s the difference between a great organization and a failure. Ineffective people drag everyone else down to their level. They make it so that you can’t take pride in what you’re doing, so that you dread going into work in the morning, so that you can’t rely on the other pieces of the project getting done. And assholes, no matter how talented they may be, are even worse. Conversely, there are few things more fun than working hard with a really nice, talented group of people.

    (tags: entrepreneurship productivity business)

You improve your code. What about yourself?

I laid out part of a framework for improving Gentoo in my last post. As many of you kindly noted, I explained what I wanted to do but did a poor job of convincing you why it needs to happen. That’s what I’m going to begin doing in this post.

As this post’s title says, when you develop code, you generally want it to be the best code possible. You also want to improve it over time if it’s not yet up to the highest standards. This holds doubly true when you’re doing this for free in an open-source project. First, there’s no time pressure to pound out minimally working code, so you can take the time to make it beautiful. Second, everyone else can look at your work, so you can’t hide ugly code in a dusty corner somewhere as you might be able to in proprietary software.

These same concepts hold true for you, not just your code. When you’re contributing to an open-source project, everyone sees what you do and how you do it. Strive to make yourself beautiful in the context of open-source development. What’s that mean? Always challenge yourself, grow as a person, and learn new skills. Just as beautiful code perfectly suits its purpose, beautiful developers perfectly suit their purpose. Their skills and actions exemplify how open-source developers should act.

If you’re optimizing code, you know that you can’t optimize what you can’t measure. That’s why profilers and other methods of instrumentation exist. This concept has a parallel in your personal development. Your instrumentation is goals, and what you’re measuring is your performance against your own goals. The purpose of this, as with code, is to optimize performance for your relevant metrics. How do you know whether you’ve improved unless you’re profiling yourself? What you’re left with if you don’t set goals and track progress against them is that frustrating comment people always say, “It just feels faster.”

Steps toward improving Gentoo

Having the right people in the right places pursuing the right goals is key to Gentoo’s success. Keeping in mind the Pareto principle (20% of the effort produces 80% of the results), I’ve come up with some ideas. The core of these ideas is creating a development community composed only of top-notch contributors and putting the entire Gentoo project into a cycle of continuous improvement, from the bottom up.

Each team and project should have goals. A good goal is SMART (Specific, Measurable, Attainable, Relevant, and Time-bound). That means “Maintain foo packages” is a poor goal, because you cannot answer it in a quantitative way and it has no time limit. One example of a good goal is “6 months from now, 90% of new bugs will be closed within 2 weeks of their report.” Another example is “3 months from now, 100% of our packages will be bumped within 1 week of release, or a bug will exist describing why not.” Progress toward goals should be checked once a month by the team lead and reported to the project lead (or to the council, if no project lead exists).

Each team member should have goals. The performance of that contributor in the context of that team should be measured. People who aren’t up to the team’s high standards (measured by failure to meet goals) should receive coaching from the team lead. There should be a concrete plan for improvement, committed to by both sides, for how these people will reach the high standards they aren’t hitting yet. After a plan exists, failure to improve within 3 months will result in their departure from the team. At the team lead’s judgment, people may be removed without going through coaching if they are considered a lost cause. Progress toward goals should be checked once a month by the team lead.

To minimize the chance that an underperforming developer was simply not in the right place, each developer gets 3 chances to find the right place in Gentoo. Upon removal from the first 2 teams, the team lead will report what happened to the project lead (or to the council, if no project lead exists) and to developer relations. On the 3rd strike, you’re out.

Council members and project leads should take responsibility for mentoring the next generation of leaders. Just as team leads are helping to improve individual developers, so the next tier of leadership should be developing team leads into strong project leads and council members. Nobody sticks around forever, and we need to be ready for when even our most critical developers move on. It’s far better to have too many strong potential leaders than to have a vacuum that’s filled by a poor leader.

Finally, all of our goals should flow downward in a logical manner from the Gentoo mission & vision through projects to teams and individual developers. Gentoo’s perennial problem is a lack of focus. Any work that is inconsistent with our goals should be stopped, and we should rededicate our time to things that tie in with where we want to be next year and 5 years from now. To ensure this, goals at each level should be reviewed by whoever’s at the next level up to make sure things make sense at a global level all the way down, like a waterfall.

Now is a good time to re-read the Gentoo philosophy. I find it extremely powerful and compelling, and I hope you feel the same. We should live this philosophy every day in our work with Gentoo, and every aspect of our work should grow from it:

Every user has work they need to do. The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit. Our tools should be a joy to use, and should help the user to appreciate the richness of the Linux and free software community, and the flexibility of free software. This is only possible when the tool is designed to reflect and transmit the will of the user, and leave the possibilities open as to the final form of the raw materials (the source code.) If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy.

Put another way, the Gentoo philosophy is to create better tools. When a tool is doing its job perfectly, you might not even be very aware of its presence, because it does not interfere and make its presence known, nor does it force you to interact with it when you don’t want it to. The tool serves the user rather than the user serving the tool.

The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don’t you love it when you find a tool that does exactly what you want to do? Doesn’t it feel great? Our mission is to give that sensation to as many people as possible.

I’ve run out of time for tonight. Most of what I’ve written is about forward progress rather than improving individual developers, so I’ll try to write more about that another time. I think we need know how we’re doing if we ever want to improve, so this investment into goals and thinking about performance is worthwhile. What do you think?

Gentoo: New release, “new” leadership

I wrote an article discussing Gentoo’s new release and new council for this week’s LWN.net. If you’ve read my earlier blog posts and other posts on Planet Gentoo regarding 2008.0, there won’t be a whole lot of new information. It’s designed as analysis of recent Gentoo events for people who don’t already follow Gentoo development.

If you aren’t already subscribed to LWN.net, get on it. It’s my #1 source for Linux- and open-source-related news, and it saves me huge amounts of time that I would otherwise spend in cesspools like Slashdot. =)

P.S. Anyone going to OSCON, let me know via a comment here or my contact info.

Early coverage of Gentoo 2008.0

Here’s links to a few places that posted announcements for 2008.0. Go there and get involved by voting and commenting!

Gentoo 2008.0 makes the Digg frontpage
Gentoo 2008.0 makes the Digg frontpage

There’s also a ton of talk about Gentoo 2008.0 happening on Twitter, which I’m following through the Summize search engine with a search for gentoo. I’m also following blogs talking about Gentoo, and I have a news search for Gentoo that I expect to pick up more later once more journalists pick up the news.

Update 1: Added Phoronix, thanks to Denis Dupeyron (Calchan).

Update 2: Added OSNews

Update 3: Added OStatic, Heise, Linux Format, Clubic, FOSSWire, DesktopLinux.com, Linux Magazine (UK)

Update 4: Added InternetNews.com

Update 5: Added Open Source Pixels, Techgage

Update 6: Added LinuxNews.pl, Programas Livres

Update 7: Added Linux Journal, Linux1.no, PettiNix, Linux.org.ru

Update 8: Added ZDNet.co.uk, DistroWatch Weekly

Developers give existing Gentoo council a mandate

I said this briefly on the gentoo-dev list, and I want to expand on it here. The council is Gentoo’s leadership, and it’s composed of 7 people elected by all Gentoo developers using a Condorcet-style ranking vote. Of the 7 people on the old council, 5 of them decided to run again and every single council member who ran was re-elected.

This is significant because the re-election was forced over miscommunication about a meeting, and this created some serious conflicts with a sentence in the Gentoo Linux Enhancement Proposal that created the current structure, including the council. I consider this a mandate, showing that Gentoo developers have confidence in the existing leadership doing what’s best for Gentoo.

This was your chance to say yes or no, and you gave us a resounding yes. Since it isn’t often we hear much from the vast majority of developers, this really means a lot to me in saying which directions we should go, based on who you voted for (graphs here). My interpretation is that you like what’s going on now and where we’re talking about going. I’d really love to hear more input from those of you who don’t normally speak up, though. What can we do for you?

P.S. The 2008.0 release is out.

How to run an effective meeting on IRC

Since my election to the Gentoo Council, I’ve become the de facto meeting chair and secretary. Over the past 6 months or so, I’ve learned a lot about what works well in online meetings (often by virtue of doing the opposite). By no means have I mastered this, but here’s some of my discoveries along the way.

What works well:

  • Send out a draft agenda in advance (say, 1 week). This helps avoid confusion and disorganization at the meeting, and it also allows you to have no “open floor” section at all, because all topics should have come up when you posted the draft. Settle on a final agenda a couple of days in advance.
  • On the draft, say who should attend the meeting to discuss each topic.
  • Be specific about the topic, so you stay focused during the meeting.
  • For each topic, have a very specific goal of what will be accomplished at that meeting. If it’s a decision, exactly what will the vote be? If it’s a discussion, what points do we want to get out of it, and why is it happening during the meeting instead of on mailing lists?
  • Prepare. All of the information needed to make a decision should be readily available by the time the meeting comes along. To aid this, say on the draft agenda what information will be needed.
  • Stay relentlessly on topic. Cut off diverging threads early on, before everyone gets involved.
  • During the meeting, get an action plan for each topic: What’s the next step? Who’s responsible for it? When will they have it ready? Make sure the person responsible personally commits to this–don’t just assign it to them.
  • Take notes, and post a public summary. This summary informs and reminds people of the progress made and what progress needs to be made next. By being posted publicly, it also allows for discussion, clarification and correction.
  • Keep track of unresolved topics, and keep bringing them up over and over so they can’t slip through the cracks.

What works poorly:

  • Request topics on a mailing list, but don’t collate them into an agenda until after the meeting’s started.
  • Do your best to ensure that people relevant to a topic don’t even know it’s going to be discussed, or don’t tell them what information you need from them.
  • Have vague topics, so nobody’s really sure what you’re supposed to be talking about or what you want to get out of it. Feel free to branch out into anything that seems related, or really anything at all.
  • If a topic isn’t resolved by the end of the meeting, forget about it. If it’s important, it’ll come up again, right?
  • Don’t tell anyone what the results of the meeting were. If you have to release something, make it as hard to comprehend as possible, like an IRC log instead of a summary.

It took a lot of pain and wasted time for me to figure out the value of doing things right, and I’m still working on getting some of the above points right, so I want to save you that same pain.

Do you have any more points to add? Please do so in the comments. Thanks!

How to win friends and influence people

Recently I mentioned Paul Graham’s essay on how to disagree, which described types of disagreement. This post will instead really tell you how to disagree without making enemies, and more generally how to get along well with people.

Here’s a summary of Dale Carnegie’s outstanding book (with the same title as this post), which has been a top-selling communications book for the past 70 years. These techniques don’t sound terribly original or mind-blowing. Instead, they are elegant and straightforward, which makes them easy to remember. I’ll also tell you which principles I think are the most important.

Fundamental techniques in handling people

  1. Don’t criticize, condemn or complain.
  2. Give honest and sincere appreciation.
  3. Arouse in the other person an eager want.

These ideas lay the groundwork for everything else. The overall focuses of the entire book are:

  • Encourage the positive things people do, instead of disparaging the negative.
  • Talk about what other people want, instead of what you want.

6 ways to make people like you

  1. Become genuinely interested in other people.
  2. Smile.
  3. Remember that a person’s name is to that person the sweetest and most important sound in any language.
  4. Be a good listener. Encourage others to talk about themselves.
  5. Talk in terms of the other person’s interests.
  6. Make the other person feel important–and do it sincerely.

The most important points from this group are 1 (be interested in others) and 5 (talk in terms of their interests).

12 ways to win people to your way of thinking

  1. The only way to get the best of an argument is to avoid it.
  2. Show respect for the other person’s opinions. Never say, “You’re wrong.”
  3. If you are wrong, admit it quickly and emphatically.
  4. Begin in a friendly way.
  5. Get the other person saying “yes, yes” immediately.
  6. Let the other person do a great deal of the talking.
  7. Let the other person feel that the idea is his or hers.
  8. Try honestly to see things from the other person’s point of view.
  9. Be sympathetic with the other person’s ideas and desires.
  10. Appeal to the nobler motives.
  11. Dramatize your ideas.
  12. Throw down a challenge.

Important points here are 3 (admit your mistakes), 4 (begin friendly), and 8 (step in their shoes).

9 ways to change people without giving offense or arousing resentment

  1. Begin with praise and honest appreciation.
  2. Call attention to other’s mistakes indirectly.
  3. Talk about your own mistakes before criticizing the other person.
  4. Ask questions instead of giving direct orders.
  5. Let the other person save face.
  6. Praise the slightest improvement and praise every improvement. Be “hearty in your approbation and lavish in your praise.”
  7. Give the other person a fine reputation to live up to.
  8. Use encouragement. Make the fault seem easy to correct.
  9. Make the other person happy about doing the thing you suggest.

The first 5 points here are the most important, although all of these ones are important.

Conclusion

Best of luck to you in applying these principles to your own life!