Posts Tagged ‘leadership’
I’m running for the Gentoo council this year, and I wanted to post my “platform” here: who I am, why I’m running, how I see the council, and how I see Gentoo.
For anyone newer, I’d like to first introduce myself and my history with Gentoo. Over the past 8 years, I’ve spent time doing pretty much everything in Gentoo, from maintaining ebuilds to writing documentation and leading teams and projects. I’ve been a recruiter in devrel, served as desktop manager (back when we had top-level project managers, before GLEP 39), and later chaired the council. I also started the clustering team, led X11 maintenance for about 5 years (when I designed the modular X eclass and wrote all 400+ new modular packages as we transitioned from the old XFree86), spent a term as a foundation trustee, and acted as project manager for our ever-controversial GUI installer.
One of my primary roles at the moment is running our participation in the Google Summer of Code, one of our major sources of both income and new developers. Since I took over 3 years ago, we’ve more than doubled the size of our program (we have 15 students this year!) and greatly increased the proportion of students who eventually become Gentoo devs to roughly 67%.
At this point, I’m convinced I can make the biggest difference to Gentoo in two ways: focusing on specific projects like the git transition and improved eclass testing rather than ebuild maintenance (which we have tons of people doing), and leading Gentoo to greatness as a council member, where I’m in the best position to accomplish that goal.
On my last two terms as a council member, I was extremely active in council-related issues both on mailing lists and at meetings, rather than just showing up at meetings to vote and then disappearing into the sunset. I strongly believe that through preparation and accountability, we can have a more productive council, but this requires a true commitment on the part of every member.
Creating a great community
I see this as an area where the council can set direction for all of Gentoo, both through the positive examples of its members and by taking a stand against anything we won’t stand for in our community. The council should be providing guidance to devrel and userrel on what kinds of behaviors should be encouraged and what kinds shouldn’t be tolerated.
Additionally, we should begin collecting metrics on our community so we know where we’re going. Many other projects (and even distributions) do this already, to give them clues of when things are going wrong, what things are going right, etc.
Making progress now instead of waiting years for perfection
There’s a lot of ongoing projects and GLEPs that have been dragging on for years because people want a “perfect” solution. One personal example is the git transition, where I’ve already made this mistake in spending quite a bit of time trying to get a perfect repository layout working when we could have just done a simple conversion of the whole tree and put it in one repo (the current plan, with some changes).
GLEP 55 is another one. There are some times when any decision is better than no decision.
Removing bureaucracy in favor of more agile development & meritocracy
We all know that GLEP 39 needs some changes. I think that most devs just want to Get Stuff Done without fighting with policies, waiting around forever for votes, not getting majorities without any clear direction, and so forth. I believe that our devs vote in the council because they want those people in charge and trust the council members to do what they think is right, including deciding on changes to GLEP 39 to improve how we run things.
I favor a switch to a smaller group more along the lines of the Linux kernel, with a very small leadership core and more of a hierarchy than a huge committee.
Along the same lines, I favor a switch to a more meritocratic approach such as the lead appointments we’ve been discussing recently. Gentoo isn’t a country government that needs to provide for every sick and needy person in its geography; it’s a nonprofit with specific goals it needs to accomplish and should be run as such. In general, companies, including nonprofits, don’t have checks and balances or long, drawn-out votes. What they do have is a board of trustees at the top, which can replace the leadership when it deems necessary.
Another major problem is the lack of continuity in our leadership, mainly because the whole group is re-elected en masse every year. At a minimum, even if we can’t do the above changes, we should switch to a 2-year term and have half the council up for election each year so new councils can start out quickly.
Promoting innovation from individual developers instead of expecting it to all come from the top
As I mentioned above, one of my focuses now is working on interesting standalone projects. I hope that every developer does the same; in addition, or besides whatever you do every day (maintain ebuilds, write/translate docs, etc.), consider starting a new project that has a clear end in sight and that will help Gentoo get better. It doesn’t have to be anything big; and the great thing about projects with a finite length is that you actually finish them at some point.
Getting rid of policies that were created for a single incident, because they should only exist for patterns of repeated problems
A common problem in Gentoo is feeling like a one-time problem can’t be fixed without making a big policy about it, why it can’t be done, what will happen if it’s done again, etc. If you’ve been around Gentoo for a while and start reading through our developer docs, you’ll be able to connect a specific name and instance with pretty much every line that says something like “Don’t do stupid thing X” and “Don’t do ridiculous thing Y.”
I think part of this is rooted in a fear, for lack of a better word, to take personal responsibility for an action; instead, people want a rulebook to point at and say “That’s wrong” so the rulebook is the bad guy.
But rulebooks should only be for the common cases, the patterns, the problems that keep coming up over and over. One-time problems only deserve one-time solutions.
The goal of leadership is to produce superior results on purpose and that makes leadership a results contest. The challenge of leadership is to persuade and motivate those they lead to produce the results they want. When people voluntarily and enthusiastically do what their leaders ask them to do and the desired results are achieved, leaders are considered to be effective and successful! The question is how do leaders really get others to voluntarily and enthusiastically produce the desired results? There are many parts to this puzzle, but there is none greater than a condition I describe as Strategic Presence.
“OSS concentrates on the software, not the problems the software can solve: Take a look at an OSS site, any OSS site. You’ll see a whole lot of talking about the software, the implementation of the software, the source code for the software, how you can contribute to the software, etc. You’ll almost never see anything about the problem domain — the assumption is that, if you’ve stumbled upon the site, you already know you have a software problem.”
Innovation is not the job only of the leader. For innovation to happen at all levels and from followers as well, a leader must look to steer what is needed for a change or direction, but should never limit how to come about doing that. The adversity that exists in a team is far greater than any leader will ever have and so the possibilities and ideas generated from the whole group are always more than the leader could generate on their own. For this reason, it is especially important for a leader to not only allow innovation at all levels, but encourage and promote it as well. This will bring forth more ideas, more possibilities and enable more people amongst the followers to start having practice and interest in the decisions, risks and change as well.
True leadership is about taking people to a place that they would not go to by themselves. Good leaders provide that by delivering and demonstrating purpose, direction, goals and guidance that is well beyond a supervising role alone. These are the areas that I feel make direction vital to leadership.
Planning and Communication
Direction cannot be given if it is not known by the leader in the first place. And a leader cannot lead if they don’t give a direction for people to follow them. This creates a big requirement to do something about that by using techniques, tools and resources to provide and develop that direction.
2. As the team or project leader, pay extra attention to the basic mechanics of good meeting and project management. The importance of agendas, role clarification, project charters, action items, and documentation all magnify when leading a virtual team. For a one hour conference call, expect to spend 4X the time in “administrative” preparation and follow-up.
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.
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.
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.
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.”