"If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."
- Antoine de Saint-Exupery
'Nuff said.
6: Performance=Results
We take accountability to meet commitments and deliver services better, faster, cheaper.
"Results" are a funny thing. The more you get them, the more you want them. The more you see them around you, the more you aspire to have them yourself. But "results" are terribly misunderstood and misrepresented.
Let's take a quiz. Which of the following are results which equate to a stellar performance?
Employee...
Answer? None of the Above.
Performance=Results. Trying is wonderful, but doesn't serve a purpose when attempting to build and develop effective people. We hold ourselves and others accountable to real performance measures, not just our perception of how hard they "tried." This allows people to know where they stand and where they need to be in concrete ways.
Don't get me wrong. Holding people accountable for performance is hard--especially at the Church. But it's a critical thing which pays dividends.
A manager does his employees a disservice by not being accurate in performance appraisals, and by over-rewarding "effort" instead of "results." I had a guy work for me for a few years who frankly only worked 20 hours per week. He also was quite an annoying person to be around. But he delivered. He delivered big! I wasn't interested in his (lack of) effort. I was interested in his results and he delivered! The hours thing never bothered me, though it bothered some of our team members. My advice to them is (and was) get over it! If you want that kind of leniency, then deliver!
"Trying" or "going the extra mile" does have some benefits which are important.
Don't mistake my comments as a plea to stop trying. :) Or as an excuse to put in less than an honest day's work for an honest day's pay. But the benefits of "trying" and "showing up on time" start to fade over time in the face of consistent failure. At some point you have to change your approach or change what you do.
How to judge when to do that? Performance=results!
"Results" are a funny thing. The more you get them, the more you want them. The more you see them around you, the more you aspire to have them yourself. But "results" are terribly misunderstood and misrepresented.
Let's take a quiz. Which of the following are results which equate to a stellar performance?
Employee...
- finds a problem with a production system. he doesn't get it fixed but stayed all night to try.
- is consistently at work before 7:00am and consistently leaves after 6:30pm. never takes vacation.
- is well liked by customers despite managing a team of people who aren't able to deliver.
Answer? None of the Above.
Performance=Results. Trying is wonderful, but doesn't serve a purpose when attempting to build and develop effective people. We hold ourselves and others accountable to real performance measures, not just our perception of how hard they "tried." This allows people to know where they stand and where they need to be in concrete ways.
Don't get me wrong. Holding people accountable for performance is hard--especially at the Church. But it's a critical thing which pays dividends.
A manager does his employees a disservice by not being accurate in performance appraisals, and by over-rewarding "effort" instead of "results." I had a guy work for me for a few years who frankly only worked 20 hours per week. He also was quite an annoying person to be around. But he delivered. He delivered big! I wasn't interested in his (lack of) effort. I was interested in his results and he delivered! The hours thing never bothered me, though it bothered some of our team members. My advice to them is (and was) get over it! If you want that kind of leniency, then deliver!
"Trying" or "going the extra mile" does have some benefits which are important.
- It's motivational to the rest of a team.
- It can help you keep a positive outlook.
- It keeps you focused on "hard to obtain" results, even in the face of failure.
- Etc, etc, etc.
Don't mistake my comments as a plea to stop trying. :) Or as an excuse to put in less than an honest day's work for an honest day's pay. But the benefits of "trying" and "showing up on time" start to fade over time in the face of consistent failure. At some point you have to change your approach or change what you do.
How to judge when to do that? Performance=results!
Cool Jobs in Church I.T.
[One job added below.]
Greetings.
We have a number of cool jobs available at the Church and I wanted to share some of the key ones with you.
For all of these jobs, check out the Church's jobs web site, or click on the links below.
I'm hiring a business manager or chief of staff. This person will be a member of the Office of the CIO. S/He will run staff meetings, help write strategic plans, work on goals & metrics, troubleshoot, etc. This role will be my right-hand (wo)man, help write presentations, drive the agenda for executive council reports, etc. I need a superstar in this role--someone who has had significant responsibilities in an I.T. shop before, is very versatile and is great with people.
We're looking for a couple of lead program managers. Most of our work is divided into portfolios: Missionary, Temple, Finance, Supply Chain, etc. Each portfolio has dev, qa and infrastructure resource dedicated to it, but all of these resources report into their own discipline silos. The Lead Program Manager is like a CIO for each portfolio. He works with the customer to create strategic plans, marshalls and directs the resources, sets & manages to schedules, and manages the projects (or manages the people who manage the projects). These roles are future CIOs. A certain technical aptitude is required as the scope is limited to a set of projects which are relevant to that portfolio and therefore we expect the LPM to be more on top of the projects from a technical perspective than a CIO would normally be. The three we're looking for are: HR, Finance and Supply Chain. All have major iniatives which will be understaken in the next two years and all need superstars to manage the portfolio.
We always need superb architects. We have a number of them now, but we'd love more! If you're a technical genius (or at least on the pathway) then consider an Architect position at the Church!
We need great Linux or Unix experience. One example of a job is here.
Finally, we're looking for senior development directors (like this one and this one), and managers like here and here. If you have significant experience managing development teams, then we're interested in you. We expect strong technical aptitude, the ability to recruit and grow employees, good architectural skills and terrific management skills.
[Joel: We are also rolling out Sharepoint in our enterprise and are looking for Sharepoint engineers.]
Greetings.
We have a number of cool jobs available at the Church and I wanted to share some of the key ones with you.
For all of these jobs, check out the Church's jobs web site, or click on the links below.
I'm hiring a business manager or chief of staff. This person will be a member of the Office of the CIO. S/He will run staff meetings, help write strategic plans, work on goals & metrics, troubleshoot, etc. This role will be my right-hand (wo)man, help write presentations, drive the agenda for executive council reports, etc. I need a superstar in this role--someone who has had significant responsibilities in an I.T. shop before, is very versatile and is great with people.
We're looking for a couple of lead program managers. Most of our work is divided into portfolios: Missionary, Temple, Finance, Supply Chain, etc. Each portfolio has dev, qa and infrastructure resource dedicated to it, but all of these resources report into their own discipline silos. The Lead Program Manager is like a CIO for each portfolio. He works with the customer to create strategic plans, marshalls and directs the resources, sets & manages to schedules, and manages the projects (or manages the people who manage the projects). These roles are future CIOs. A certain technical aptitude is required as the scope is limited to a set of projects which are relevant to that portfolio and therefore we expect the LPM to be more on top of the projects from a technical perspective than a CIO would normally be. The three we're looking for are: HR, Finance and Supply Chain. All have major iniatives which will be understaken in the next two years and all need superstars to manage the portfolio.
We always need superb architects. We have a number of them now, but we'd love more! If you're a technical genius (or at least on the pathway) then consider an Architect position at the Church!
We need great Linux or Unix experience. One example of a job is here.
Finally, we're looking for senior development directors (like this one and this one), and managers like here and here. If you have significant experience managing development teams, then we're interested in you. We expect strong technical aptitude, the ability to recruit and grow employees, good architectural skills and terrific management skills.
[Joel: We are also rolling out Sharepoint in our enterprise and are looking for Sharepoint engineers.]
Book Club: The Extraordinary Leader
Has anyone read The Extraordinary Leader by Zenger and Folkman? I'm just starting.3/21/07 I finished reading this book last weekend.I enjoyed most of the book. The flow of the book goes like this:
There were some points in the book which really resonated with me. The one thing I didn't like was the seemingly exclusive approach to defining good leadership by surveys. How do we know if a leader is good? Because his people say he is. There were some attempts to show a few studies which indicated that extraordinary leaders are X% more effective, but at the end of the day it seemed like extraordinary leaders were always judged by the percentage of employees who rated them at Y% or higher in given competencies.
- Extraordinary leaders are monumentally better than merely good leaders.
- There are a number of competencies which extraordinary leaders possess.
- To be an extraordinary leader, you don't have to possess all of these competencies; you just have to be extraordinary at several of them.
- Key leadership competencies have complementary competencies which work extra well together (great technical aptitude goes well with the ability to express ones' self).
- Rather than focusing on our weaknesses, we should focus on making our good attributes extraordinary and improving the competencies which are complementary to our extraordinary ones.
There were some points in the book which really resonated with me. The one thing I didn't like was the seemingly exclusive approach to defining good leadership by surveys. How do we know if a leader is good? Because his people say he is. There were some attempts to show a few studies which indicated that extraordinary leaders are X% more effective, but at the end of the day it seemed like extraordinary leaders were always judged by the percentage of employees who rated them at Y% or higher in given competencies.
I tried to think of how else you might judge whether someone is an effective leader and found that it's a difficult challenge.
After just accepting the premise I ended up enjoying the book.
5: Know Your Role
I understand my role, act decisively, and encourage others to do the same.
The fable goes something like:
You’ve probably heard a version of this story. It’s a well-known tool used to instruct teams using various agile methodologies how to run meetings. The idea is that the individuals who have deliverables or dependencies (the pigs) get to speak. The people who are ancillary or are not otherwise obligated in the current iteration (the chickens) do not. If you're not aware of these rules, you may goof up an iteration planning meeting or a daily scrum.
My intent is not to give a lesson in software methodology. I'm making the point that everyone needs to “know his role” for an organization to work like a machine.
Lack of role clarity in an organization results in bad stuff:
It is my job to facilitate and communicate role definition across the I.T. organization. However it is the employee’s job to understand her role—or if there isn’t role clarity to demand it, either by seeking guidance from a manager or by working directly with the people with whom overlap or gaps are most likely.
Once roles have been established and people understand their scope of responsibility, they need to feel empowered to act decisively. It’s better to make a bold move and be wrong then to be lulled into inaction by fear.
What happens if your peers don’t understand their jobs effectively, and thus throwing it over the fence to them dooms your work to stagnation? One of the tenets of our “know your role” belief is that we help others to understand their roles in a non-threatening way.
The fable goes something like:
A chicken and a pig decide to go in as partners in a new restaurant. One day they are arguing about whether the restaurant should be called "Oinker and Cluck's" or "Cluck and Oinker's." The chicken argues that he is the brains behind the organization, that he is delivering over 50% of the funding and that C comes before O in the alphabet.
The pig argues that in a “Ham and Eggs Restaurant” that he, the pig, is actually committed, whereas the chicken is merely involved.
You’ve probably heard a version of this story. It’s a well-known tool used to instruct teams using various agile methodologies how to run meetings. The idea is that the individuals who have deliverables or dependencies (the pigs) get to speak. The people who are ancillary or are not otherwise obligated in the current iteration (the chickens) do not. If you're not aware of these rules, you may goof up an iteration planning meeting or a daily scrum.
My intent is not to give a lesson in software methodology. I'm making the point that everyone needs to “know his role” for an organization to work like a machine.
Lack of role clarity in an organization results in bad stuff:
- redundant work
- missed deliverable
- turf battles
- lack of accountability (finger pointing)
It is my job to facilitate and communicate role definition across the I.T. organization. However it is the employee’s job to understand her role—or if there isn’t role clarity to demand it, either by seeking guidance from a manager or by working directly with the people with whom overlap or gaps are most likely.
Once roles have been established and people understand their scope of responsibility, they need to feel empowered to act decisively. It’s better to make a bold move and be wrong then to be lulled into inaction by fear.
What happens if your peers don’t understand their jobs effectively, and thus throwing it over the fence to them dooms your work to stagnation? One of the tenets of our “know your role” belief is that we help others to understand their roles in a non-threatening way.
Tech Talk Agenda
We've finalized the tech talk agenda and are pretty excited about it.
We will start with a 15 minute intro where we talk about some of the projects we work on, some stuff on methodology & process, some high level technology explanations and some things on community and where we plan to go. These slides will be available afterward.
Then we will break up into groups. There will be a number of breakout sessions: open source, networking, data center, software methodology, family history, interaction design, etc. You will choose which group you want to attend. The director or manager will give a five minute presentation then do 20 minutes or so of Q&A. We'll then switch so you can go to a second breakout session. Repeat.
Finally we'll meet back together in the cultural hall for refreshments and a panel Q&A.
We've received quite a lot of feedback about these sessions. We will be posting notes from the session, however we will not be recording them. We will also be doing these in other areas and this won't be the last time we'll be doing them in Utah. Several have mentioned they may be travelling into town. While I think they're going to be great, I'm not sure they're worth great expense in either time or money to attend.
One final note. I've mentioned this several times, but I want to be clear. This is not a feature feedback session or focus group. If you have great ideas for MLS or any other Church app this is not the venue. We are creating more venues and tools for this kind of feedback, but this isn't it.
Look forward to seeing some of you!
We will start with a 15 minute intro where we talk about some of the projects we work on, some stuff on methodology & process, some high level technology explanations and some things on community and where we plan to go. These slides will be available afterward.
Then we will break up into groups. There will be a number of breakout sessions: open source, networking, data center, software methodology, family history, interaction design, etc. You will choose which group you want to attend. The director or manager will give a five minute presentation then do 20 minutes or so of Q&A. We'll then switch so you can go to a second breakout session. Repeat.
Finally we'll meet back together in the cultural hall for refreshments and a panel Q&A.
We've received quite a lot of feedback about these sessions. We will be posting notes from the session, however we will not be recording them. We will also be doing these in other areas and this won't be the last time we'll be doing them in Utah. Several have mentioned they may be travelling into town. While I think they're going to be great, I'm not sure they're worth great expense in either time or money to attend.
One final note. I've mentioned this several times, but I want to be clear. This is not a feature feedback session or focus group. If you have great ideas for MLS or any other Church app this is not the venue. We are creating more venues and tools for this kind of feedback, but this isn't it.
Look forward to seeing some of you!
Design Lessons from the Tooth Fairy
I appreciated this post by Ted, one of our interaction designers and a fellow Microsoft alum.
Subscribe to:
Posts (Atom)