-
The Return on Management ratio
ROM can be expressed as the following equation: ROM = Productive energy released divided by management time and attention invested.
This ratio—which is more of a metaphor than an exact calculation—provides a framework for evaluating your strategic focus on daily tasks. Is your energy invested in activities that best contribute to your organization’s productivity and overall performance? If not, you are likely not spending your time on the “right” opportunities and challenges.
In the case of developing employees, the ROM ratio suggests that managers spend the most time working with the people that contribute the most and add the most value to the organization. This group would consist of both star performers and solid contributors. Based on such an assessment, the third group, your low-potential, low-performing employees (or C players), would merit the least management time and energy because they benefit the organization the least.
-
Excellent post on specific ways to help different kinds of people improve, with links to even more specifics for "A," "B," and "C" players.
Author: Donnie Berkholz, Ph.D.
Chief Architect, Sabre. Founder & Chief Analyst, Platify Insights — the industry-analyst firm for technology platforms. Veteran product & technology leader.
links for 2009-03-10
-
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.
Intuitive packaging is vital to Gentoo
A post I made on the Gentoo development list last night deserves your attention because it illustrates a key aspect of Gentoo. I want to make sure it’s preserved instead of lost in mailing-list archives. This is in reply to a proposal to move a significant portion into a series of variables instead of being written as scripted functions:
I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand.
One of the key reasons people use Gentoo is that ebuilds are so easy to “get” for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions.
Gentoo is a distribution for advanced Linux users, or those who want to become advanced. Having packaging scripts that are easy to learn lowers the barrier to entry to editing them, which vastly increases our number of potential developers. It additionally comprises a key part of Gentoo’s ease of customization by allowing people to easily write their own packages or modify existing ones for their purposes. When users do this, it creates a natural pathway from building software by hand to editing ebuilds to becoming a Gentoo developer. The more difficult it is to learn how to write packaging scripts, the more of your potential developer base you repel.
links for 2009-03-08
-
“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 CommunicationDirection 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.
links for 2009-03-07
-
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.
links for 2009-03-04
-
“What many people don’t realize is that the bikeshed effect is, in fact, a form of procrastination. And it can suck in highly technical developers, along with everyone else.”
links for 2009-03-01
-
9. Learn how to lead meetings. Meetings are where we “show up” as a leader. Like presentation skills, there’s a science to meeting management that can be learned. And honing your meeting leadership skills helps you become a better meeting participant. Ask a skilled trainer to teach you "facilitation" (how to lead a discussion) skills.
You can help get Gentoo into the Summer of Code
This year, let’s try something different! I posted a rough draft of our organization application on the Gentoo wiki, in hopes that we can all work together to improve it over the next week. Applications are due starting March 9, and earlier is better. Here’s a list of questions that you can help answer:
- Why is your group applying to participate? What do you hope to gain by participating?
- What criteria do you use to select the members of your group? Please be as specific as possible.
- Has your group participated previously? If so, please summarize your involvement and any past successes and failures.
- What questions/requests do we want in our application template for students, in addition to the GSoC application?
- What is your plan for dealing with disappearing students?
- What is your plan for dealing with disappearing mentors?
- What steps will you take to encourage contributors to interact with your community before, during, and after the program?
- What will you do to ensure that your accepted contributors stick with the project after the program concludes?
Go to the wiki, and help Gentoo’s application rock!
links for 2009-02-27
-
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
links for 2009-02-26
-
So the useful question is not “how many hours do you work?” but “how much energy do you put into your work?” Other useful questions that come with it are:
* How much of your daily energy do you spend increasing your total energy? Do you feel you spend enough? Do you feel you spend it on the right things?
* How much of your daily energy do you waste each day? How do you define waste? Is all that waste really unproductive or does it have some beneficial side-effects? Are those side-effects sufficient to justify spending that energy?
* Do you spend energy on things which actively hurt you?
* Has your daily energy increased or decreased in the last 6 months? year? 5 years?Any of these questions is more worthwhile than “How many hours do you work each day?”
-
There's a sort of Gresham's Law of trolls: trolls are willing to use a forum with a lot of thoughtful people in it, but thoughtful people aren't willing to use a forum with a lot of trolls in it. Which means that once trolling takes hold, it tends to become the dominant culture. That had already happened to Slashdot and Digg by the time I paid attention to comment threads there, but I watched it happen to Reddit.
News.YC is, among other things, an experiment to see if this fate can be avoided. The sites's guidelines explicitly ask people not to say things they wouldn't say face to face. If someone starts being rude, other users will step in and tell them to stop. And when people seem to be deliberately trolling, we ban them ruthlessly.
Striving for greatness 