Book Club: The Culture Code
The Culture Code is an amazing read. I don't claim to agree with everything that Rapaille writes, but it's undeniably interesting. The author comes off as a little cocky and presumptuous. If you can get past that, then if part of what you do requires understanding a market then you would do well to read this book.
Washington Post article on the global LDS Church
Recently, Washington Post London burea chief Mary Jordan published this article on the expanding global nature of the Church.
It's a great article. It names the Internet as one of the tools that is allowing the Church to reach people who wouldn't have heard about the Church before.
We occasionally post links to articles like this on newsroom.
It's a great article. It names the Internet as one of the tools that is allowing the Church to reach people who wouldn't have heard about the Church before.
We occasionally post links to articles like this on newsroom.
Bad systems or wrong people?
A key principle in one of my favorite books, Good to Great, is described metaphorically as "getting the right people on the bus." When a manager is trying to move toward a vision, the most important thing he can do to be successful, I believe, is to have great people along for the ride. You can cover an awful lot of organizational weakness by having great people. Some managers feel threatened by surrounding themselves with great people. I try to always hire people who are smarter and more capable than myself. It makes my job much easier and increases my organization's effectiveness.
Hiring great people isn't a panacea, however. It's easy to thwart even the most proficient employee by surrounding him with ineffectual or slow systems. By system, I mean interdependent process and tools--not just tools. Too many times I've hired someone who was very successful in one context, only to see her become frustrated and ineffectual with the context I hired her into.
When facing a situation where an employee seems not to be working out, first consider the system you've surrounded him with. Does she have the tools she needs to be successful? Is he clear on his role? Are you running interference for her? Does he have the time he needs to do his job or is he spending his time floundering in administrivia?
Good managers fix systems first and employees second. In the coming weeks, I'll talk about some of the systems an I.T. shop can focus on improving.
Hiring great people isn't a panacea, however. It's easy to thwart even the most proficient employee by surrounding him with ineffectual or slow systems. By system, I mean interdependent process and tools--not just tools. Too many times I've hired someone who was very successful in one context, only to see her become frustrated and ineffectual with the context I hired her into.
When facing a situation where an employee seems not to be working out, first consider the system you've surrounded him with. Does she have the tools she needs to be successful? Is he clear on his role? Are you running interference for her? Does he have the time he needs to do his job or is he spending his time floundering in administrivia?
Good managers fix systems first and employees second. In the coming weeks, I'll talk about some of the systems an I.T. shop can focus on improving.
New Internet Safety Podcast
Dr. Charles Knutson, a computer science professor at BYU, has started a new podcast called Internet Safety Podcast where he talks about safe driving on the Internet. The first few episodes deal with what kinds of things kids are exposed to on the Internet and some techniques for coping.
Check it out.
Check it out.
Weight Loss Contest at Work
Almost a year ago, I posted on a contest that a friend of mine at work started in order to help people lose weight. Mark Barsocchini reminded me in the comments to that post that I never closed the loop.
The contest lasted 3 months.
105 people started the contest but only 38 survived to the end.
The group lost 1123 pounds!!
The person who lost the most lost 61 pounds.
8 people beat Tadd, even though Tadd personally lost 39 pounds.
You can see some of details here. What a great contest!!
The contest lasted 3 months.
105 people started the contest but only 38 survived to the end.
The group lost 1123 pounds!!
The person who lost the most lost 61 pounds.
8 people beat Tadd, even though Tadd personally lost 39 pounds.
You can see some of details here. What a great contest!!
Book Club: Primal Leadership
I've been reading Primal Leadership and it is exceptional.
It's written by the same gentleman who wrote Emotional Intelligence. He discusses why some people are better at dealing with emotional issues like empathy and self-awareness then others and also discusses how to improve our skills in these areas, both as individuals and as groups.
It's written by the same gentleman who wrote Emotional Intelligence. He discusses why some people are better at dealing with emotional issues like empathy and self-awareness then others and also discusses how to improve our skills in these areas, both as individuals and as groups.
LDS Connected Update
A couple of weeks ago, I blogged about an unofficial LDS group in LinkedIn called LDS Connected. We're now up to 749 connections! When you go into the group in LinkedIn, only 500 show up. That's because they've hard-coded the list to 500.
If you go to advanced search and search within the group, it will search all 749 (and rising) contacts.
If you go to advanced search and search within the group, it will search all 749 (and rising) contacts.
2007 General Conference Memories
I enjoyed Joseph Walker's memories of General Conference in the Deseret Morning News. What are some of your memories from this last conference? (video or otherwise :) ).
2007 General Conference Memories
I enjoyed Joseph Walker's memories of General Conference in the Deseret Morning News. What are some of your memories from this last conference? (video or otherwise :) ).
Video Blog Experiment
Let's try an experiment.
For those who have an inclination, I'd love to hear/see video blogs which chronicle your reactions to this last general conference.
Please post a link to your video in the comments. I assume 90% of you will use good judgement and avoid abusive language, criticism or clips from copyrighted material. For the other 10%, I will review each post before allowing it be live in the comments. If the clips are 30 minutes long, it will take me a lot longer to view them all. A couple of minutes each might be more like it. :)
Have fun! This will be an interesting test. Share your comments/feelings with the world!
[Joel: Thanks to Justin, our one and only attempt at the video experiment so far!]
For those who have an inclination, I'd love to hear/see video blogs which chronicle your reactions to this last general conference.
Please post a link to your video in the comments. I assume 90% of you will use good judgement and avoid abusive language, criticism or clips from copyrighted material. For the other 10%, I will review each post before allowing it be live in the comments. If the clips are 30 minutes long, it will take me a lot longer to view them all. A couple of minutes each might be more like it. :)
Have fun! This will be an interesting test. Share your comments/feelings with the world!
[Joel: Thanks to Justin, our one and only attempt at the video experiment so far!]
Video Blog Experiment
Let's try an experiment.
For those who have an inclination, I'd love to hear/see video blogs which chronicle your reactions to this last general conference.
Please post a link to your video in the comments. I assume 90% of you will use good judgement and avoid abusive language, criticism or clips from copyrighted material. For the other 10%, I will review each post before allowing it be live in the comments. If the clips are 30 minutes long, it will take me a lot longer to view them all. A couple of minutes each might be more like it. :)
Have fun! This will be an interesting test. Share your comments/feelings with the world!
[Joel: Thanks to Justin, our one and only attempt at the video experiment so far!]
For those who have an inclination, I'd love to hear/see video blogs which chronicle your reactions to this last general conference.
Please post a link to your video in the comments. I assume 90% of you will use good judgement and avoid abusive language, criticism or clips from copyrighted material. For the other 10%, I will review each post before allowing it be live in the comments. If the clips are 30 minutes long, it will take me a lot longer to view them all. A couple of minutes each might be more like it. :)
Have fun! This will be an interesting test. Share your comments/feelings with the world!
[Joel: Thanks to Justin, our one and only attempt at the video experiment so far!]
LDS Connected at LinkedIn
LinkedIn is a "social networking" web site. That's "fancy techie talk" for a web site which allows you to make and maintain connections with others who use the same web site.
You can put some information about yourself into LinkedIn and then invite others to "connect" with you. Once you're linked to others, you can (with permission) get introduced to their contacts, and to their contacts' contacts, and so on.
I have only 196 contacts listed in LinkedIn right now (I usually try to keep it to people I actually know or people who have been specifically recommended to me). My contacts have a collective 23,100 contacts. And my contacts' contacts have a collective 1,494,100 contacts. Amazing.
One of our enterprising program managers, in partnership with LDS Employment Services, created a group in LinkedIn called LDS Connected. If you follow this web site, you can affiliate yourself with the group. This means that when people search the group "LDS Connected" they will find you. Currently about 411 people have joined the group. I suspect this number will go much higher once word gets around.
You can put some information about yourself into LinkedIn and then invite others to "connect" with you. Once you're linked to others, you can (with permission) get introduced to their contacts, and to their contacts' contacts, and so on.
I have only 196 contacts listed in LinkedIn right now (I usually try to keep it to people I actually know or people who have been specifically recommended to me). My contacts have a collective 23,100 contacts. And my contacts' contacts have a collective 1,494,100 contacts. Amazing.
One of our enterprising program managers, in partnership with LDS Employment Services, created a group in LinkedIn called LDS Connected. If you follow this web site, you can affiliate yourself with the group. This means that when people search the group "LDS Connected" they will find you. Currently about 411 people have joined the group. I suspect this number will go much higher once word gets around.
LDS Connected at LinkedIn
LinkedIn is a "social networking" web site. That's "fancy techie talk" for a web site which allows you to make and maintain connections with others who use the same web site.
You can put some information about yourself into LinkedIn and then invite others to "connect" with you. Once you're linked to others, you can (with permission) get introduced to their contacts, and to their contacts' contacts, and so on.
I have only 196 contacts listed in LinkedIn right now (I usually try to keep it to people I actually know or people who have been specifically recommended to me). My contacts have a collective 23,100 contacts. And my contacts' contacts have a collective 1,494,100 contacts. Amazing.
One of our enterprising program managers, in partnership with LDS Employment Services, created a group in LinkedIn called LDS Connected. If you follow this web site, you can affiliate yourself with the group. This means that when people search the group "LDS Connected" they will find you. Currently about 411 people have joined the group. I suspect this number will go much higher once word gets around.
You can put some information about yourself into LinkedIn and then invite others to "connect" with you. Once you're linked to others, you can (with permission) get introduced to their contacts, and to their contacts' contacts, and so on.
I have only 196 contacts listed in LinkedIn right now (I usually try to keep it to people I actually know or people who have been specifically recommended to me). My contacts have a collective 23,100 contacts. And my contacts' contacts have a collective 1,494,100 contacts. Amazing.
One of our enterprising program managers, in partnership with LDS Employment Services, created a group in LinkedIn called LDS Connected. If you follow this web site, you can affiliate yourself with the group. This means that when people search the group "LDS Connected" they will find you. Currently about 411 people have joined the group. I suspect this number will go much higher once word gets around.
New Stake Technology Specialist Web Site
The Church has released a new web site dedicated to stake technology specialists.
Click here to peruse.
We will be improving it over time. The next big feature will be forums where specialists can ask and answer technical questions.
Click here to peruse.
We will be improving it over time. The next big feature will be forums where specialists can ask and answer technical questions.
Online Scriptures
Over at LDS Tech, Tom Welch has posted an article on some of the power features of the online scriptures. Check it out.
Digital Media Peril: Redux
I received a number of thoughtful responses to my last post (Digital Media Peril) which discusses the dangers of having all of your pictures and movies on your computer rather than in shoe boxes in your closet. Folks should feel free to keep posting comments there, but I'm going to summarize some principles I see emerging in the thread and some additional thoughts I've had.
1. Start now. Some solution is better than no solution. The risking losing your pictures and videos is a very real danger. Get it fixed now. There is a risk that if you implement a sub-optimal solution with the intention to "fix it" later that you'll get complacent and never get around to fixing it. Or that the solution won't work in 10, 20, 50 years. It's better to do something instead of nothing and to continue evaluating your solution and looking for something better.
2. Redundancy. Implement multiple solutions to cover yourself in case one goes awry.
3. Online backup. I think online backup is a great way to go: Flickr, Mozy, .mac, whatever. You get the added benefit of easy photo sharing. There is a risk that you'll put all of your content up on some web site and that it will close down. 1) I think the likeihood that a mass storage web site will disappear with no warning, without someone purchasing the assets & customers, etc., is very low. 2) Create a redundant solution. I think this is a great solution.
4. Share, share, share! Share your media with as many friends, family, neighbors, or co-workers as you can reasonably do without irritating people. The more you spread your media out, the easier it will be to re-create your photo library if digital medial disaster ever strikes.
5. CD/DVD. CDs and DVDs aren't great long-term solutions, but they're fine in the short-term. You can buy software which will make them easier to recover if they fail, but you'll still want to make sure this is a backup, not a primary measure. Make sure you have a place to send discs that is away from your home (work, family home, etc.) Try to re-create your discs every few years as the long-term failure rate of this media is high.
6. Hard Disk. Some people just use hard drives in their home to back everything up. This is a quick solution which is easy to automate. It doesn't give you offsite archival, and hard drives can fail, just like discs can. But it's a great backup plan or redundancy strategy.
7. Prints. Pictures are still wonderful! Just because you're saving everything digitally, doesn't mean you can't make prints! If you make prints of your favorite pictures, you're no worse off than you were before you started this digital craziness.
Feel free to add your thoughts!
1. Start now. Some solution is better than no solution. The risking losing your pictures and videos is a very real danger. Get it fixed now. There is a risk that if you implement a sub-optimal solution with the intention to "fix it" later that you'll get complacent and never get around to fixing it. Or that the solution won't work in 10, 20, 50 years. It's better to do something instead of nothing and to continue evaluating your solution and looking for something better.
2. Redundancy. Implement multiple solutions to cover yourself in case one goes awry.
3. Online backup. I think online backup is a great way to go: Flickr, Mozy, .mac, whatever. You get the added benefit of easy photo sharing. There is a risk that you'll put all of your content up on some web site and that it will close down. 1) I think the likeihood that a mass storage web site will disappear with no warning, without someone purchasing the assets & customers, etc., is very low. 2) Create a redundant solution. I think this is a great solution.
4. Share, share, share! Share your media with as many friends, family, neighbors, or co-workers as you can reasonably do without irritating people. The more you spread your media out, the easier it will be to re-create your photo library if digital medial disaster ever strikes.
5. CD/DVD. CDs and DVDs aren't great long-term solutions, but they're fine in the short-term. You can buy software which will make them easier to recover if they fail, but you'll still want to make sure this is a backup, not a primary measure. Make sure you have a place to send discs that is away from your home (work, family home, etc.) Try to re-create your discs every few years as the long-term failure rate of this media is high.
6. Hard Disk. Some people just use hard drives in their home to back everything up. This is a quick solution which is easy to automate. It doesn't give you offsite archival, and hard drives can fail, just like discs can. But it's a great backup plan or redundancy strategy.
7. Prints. Pictures are still wonderful! Just because you're saving everything digitally, doesn't mean you can't make prints! If you make prints of your favorite pictures, you're no worse off than you were before you started this digital craziness.
Feel free to add your thoughts!
Digital Media Peril
In one of our wards in Seattle, a family's house burned down. Of all the needs that family had, the one that I remember was a request for people to come up with pictures of the family members.
This prompted many discussions in the ward and community about how to protect pictures, journals and keepsakes in the event of a fire.
We're faced each day with a growing, and increasingly more dangerous, threat to our personal memories: digital media. Digital media isn't just for techno-hobbyists anymore. billions of pictures are being amassed on the hard drives of people all over the globe. The only trouble is that too many people aren't being careful.
If we were to do a straw poll of ten individuals who have computers in their homes, I would wager (if I were a wagerer) that nine of the ten are taking digital pictures and that only three of those nine regularly backs them up. Remember, I'm talking about normal people now, not just nerds. Whatever the exact numbers, there are many, many people who are not backing up their digital pictures and it's scary.
My daughter had the chance of a lifetime to play the young Helen Keller in The Miracle Worker at probably the largest, most successful theatre in Salt Lake City. It was a big deal. We took many pictures before and after the shows: the cast goofing around, people getting their makeup on, actors posing for the camera, etc.
Recently we went back to look at the pictures, and they were gone. Somehow they had disappeared from the computer and I hadn't backed up since those pictures were taken.
The ending is a happy one--I found digital copies of the pictures on an old laptop I had copied them to for some reason, but the episode (and my near-death experience when I told my wife I couldn't find the pictures) reminded me to make regular and frequent backups of our digital pictures and videos.
I hope you are doing the same!!
Spread the word...
(Feel free to share your methods for archiving media in the comments section.)
This prompted many discussions in the ward and community about how to protect pictures, journals and keepsakes in the event of a fire.
We're faced each day with a growing, and increasingly more dangerous, threat to our personal memories: digital media. Digital media isn't just for techno-hobbyists anymore. billions of pictures are being amassed on the hard drives of people all over the globe. The only trouble is that too many people aren't being careful.
If we were to do a straw poll of ten individuals who have computers in their homes, I would wager (if I were a wagerer) that nine of the ten are taking digital pictures and that only three of those nine regularly backs them up. Remember, I'm talking about normal people now, not just nerds. Whatever the exact numbers, there are many, many people who are not backing up their digital pictures and it's scary.
My daughter had the chance of a lifetime to play the young Helen Keller in The Miracle Worker at probably the largest, most successful theatre in Salt Lake City. It was a big deal. We took many pictures before and after the shows: the cast goofing around, people getting their makeup on, actors posing for the camera, etc.
Recently we went back to look at the pictures, and they were gone. Somehow they had disappeared from the computer and I hadn't backed up since those pictures were taken.
The ending is a happy one--I found digital copies of the pictures on an old laptop I had copied them to for some reason, but the episode (and my near-death experience when I told my wife I couldn't find the pictures) reminded me to make regular and frequent backups of our digital pictures and videos.
I hope you are doing the same!!
Spread the word...
(Feel free to share your methods for archiving media in the comments section.)
Internet in the Home
Having talked to many parents about their approaches to managing Internet usage in their homes, I'm confident that despite the potential dangers of the Internet many families aren't doing anything or are doing far too little to protect their families.
I'd like to open this post up to you:
Have at it...
NOTE: Nothing that you read in this post should be construed as an endorsement (or condemnation) of any product by either myself or by the Church. This is an opportunity for you to share information with each other. You should do your own research and analysis before purchasing any product listed here.
I'd like to open this post up to you:
- What are you doing to control and monitor Internet usage?
- What products have you used and would you recommend? Which would you not recommend?
- What resources have helped or continue to help you?
Have at it...
NOTE: Nothing that you read in this post should be construed as an endorsement (or condemnation) of any product by either myself or by the Church. This is an opportunity for you to share information with each other. You should do your own research and analysis before purchasing any product listed here.
Book Club: Hard Facts, Dangerous Half-Truths & Total Nonsense
It's easy to find advice. Consultants, trainers and authors offer more than we can consume. This book by Pfeffer & Sutton, authors of The Knowing-Doing Gap, attempts to teach us how to know what advice to accept.
360 Reviews
I've adopted a management technique which I feel adds significant value to my direct reports. I've been doing this for many years, both in my current job and also at Microsoft before this.
360 reviews
This is hardly a new or novel tool, but I think it's worthwhile to explain the approach.
Twice per year I talk to all of my direct reports. I ask them for feedback on me and I ask them for feedback on each other. I explain very carefully that all feedback will be kept confidential, but I strongly urge each to take issues with their peers directly to their peers. Still, there is a place for confidential feedback and this is an appropriate venue for that.
I then meet with each of the direct reports of my direct reports. I typically set this up in 15 minute increments. These are obviously much more effective when I send an email explaining what I'll be doing. I request that the individual come prepared to discuss both the strengths and weaknesses, not only of their boss, but also of their boss' peers.
Often, an individual won't say anything meaningful. I ask probing questions to try to bring out feedback, but I'm very careful not to "lead" the discussion to arrive at some pre-conceived notion I have in my head. Questions I ask include the following:
These are just a few examples, but it's important to ask these probing questions as people initially feel uncomfortable with this approach. They feel like they're "squeeling" on their boss. It's critical that you make it clear to people that this is a way to help these people improve; it's not punitive. I try to enlist my directs to get the message out that they want hard feedback.
Once I've gathered all of the feedback, I synthesize it, roughly categorize it and then put it into summary form. I then give it back to the employee to whom it's directed. It might look something like the following:
As I go through this with them verbally, I will paranthetically add my own comments: I agree with this perception, I don't agree with this perception, I've noticed this example, etc. Examples of those are italicized above.
The last time I did this, I tried it via email. It was good and bad. It was good because I think people prepared more. However I didn't like losing the interactivity.
One last thing. If you've never had your boss do this for you, ask him/her to do it! It's a lot of work, but it's a great tool for your own personal development.
360 reviews
This is hardly a new or novel tool, but I think it's worthwhile to explain the approach.
Twice per year I talk to all of my direct reports. I ask them for feedback on me and I ask them for feedback on each other. I explain very carefully that all feedback will be kept confidential, but I strongly urge each to take issues with their peers directly to their peers. Still, there is a place for confidential feedback and this is an appropriate venue for that.
I then meet with each of the direct reports of my direct reports. I typically set this up in 15 minute increments. These are obviously much more effective when I send an email explaining what I'll be doing. I request that the individual come prepared to discuss both the strengths and weaknesses, not only of their boss, but also of their boss' peers.
Often, an individual won't say anything meaningful. I ask probing questions to try to bring out feedback, but I'm very careful not to "lead" the discussion to arrive at some pre-conceived notion I have in my head. Questions I ask include the following:
- Imagine the perfect "VP of Whatever Your Boss Does." What is the difference between your current boss and that perfect boss.
- Tell me some of the feedback your boss has given you that has helped you improve.
- How often do you have one-on-ones with your boss?
These are just a few examples, but it's important to ask these probing questions as people initially feel uncomfortable with this approach. They feel like they're "squeeling" on their boss. It's critical that you make it clear to people that this is a way to help these people improve; it's not punitive. I try to enlist my directs to get the message out that they want hard feedback.
Once I've gathered all of the feedback, I synthesize it, roughly categorize it and then put it into summary form. I then give it back to the employee to whom it's directed. It might look something like the following:
- You're very well liked by your direct reports. They're very loyal.
- One said she'd follow you anywhere.
- Another said you inspire him to improve.
- Others outside of your organization are afraid of you.
- One person said: "I get hives whenever he walks down the hall oustide my office."
- Another said: "I have nightmares about this person."
- You're generally recognized as being highly capable, technically. I saw this myself in the way you handled the such-and-such project.
- There is a perception that you continually miss deadlines. While the data doesn't show this, you should understand that this perception exists.
- One person believes you steal money from poor people. I don't agree with this one, but you should know that at least one person has this perception.
- Your peers generally feel like you're weak at follow through and strong at motivating.
- And so forth.
As I go through this with them verbally, I will paranthetically add my own comments: I agree with this perception, I don't agree with this perception, I've noticed this example, etc. Examples of those are italicized above.
The last time I did this, I tried it via email. It was good and bad. It was good because I think people prepared more. However I didn't like losing the interactivity.
One last thing. If you've never had your boss do this for you, ask him/her to do it! It's a lot of work, but it's a great tool for your own personal development.
Book Club: The Anatomy of Peace
And now another leadership book by Arbinger Institute. Can't get enough of the stuff.
Ward Web Site
Many of you probably don't know that members in the United States and Canada have a ward web page on lds.org.
Before I go any further, let me just say that we'll be working on a version for all international units. Don't expect it until at least 2008. But in the meantime, the current version works for those in the U.S. and Canada and many people don't even know.
You get features like:
It's a great tool for your ward! The key is that the ward leadership and councils need to use it.
If your ward isn't using the ward web site on lds.org then ask them to start. Teachers should be updating their lessons plans, the calendar should be kept up-to-date, and so forth. This is a wonderful and only takes a little effort to get people using it.
One known issue is that the signup process is a little arduous. A member needs to know his/her membership number (can be found on your temple recommend if you have one) and confirmation number. Both pieces of data can be obtained from your ward clerk.
In the future, we will make this process easier.
Check it out by clicking here..
Before I go any further, let me just say that we'll be working on a version for all international units. Don't expect it until at least 2008. But in the meantime, the current version works for those in the U.S. and Canada and many people don't even know.
You get features like:
- News and information from your ward and stake.
- Ward and stake calendar (integrated with a calendar from Church HQ).
- Lesson schedules.
- Membership and leadership directories.
- Addresses for missionaries serving from your ward.
It's a great tool for your ward! The key is that the ward leadership and councils need to use it.
If your ward isn't using the ward web site on lds.org then ask them to start. Teachers should be updating their lessons plans, the calendar should be kept up-to-date, and so forth. This is a wonderful and only takes a little effort to get people using it.
One known issue is that the signup process is a little arduous. A member needs to know his/her membership number (can be found on your temple recommend if you have one) and confirmation number. Both pieces of data can be obtained from your ward clerk.
In the future, we will make this process easier.
Check it out by clicking here..
The Myth of Youth
Who uses instant messaging? Reads blogs? Publishes blogs? Uses MySpace? Who buys stuff online or downloads videos?
Kids, right?
Piper Jaffray recently executed a survey of a sample of the 232 million Internet users in North America. By extrapolating the data, they estimate that over 100 million use instant messaging, over 100 million read blogs and almost 100 million participate in one or more social networking sites.
I assume there are close to 11 million teenagers in North America. So who is using all of these services?
You! You're coming home from work, putting the kids to bed and plugging in. It's interesting because many of you probably think about stuff like blogs as something you do, but that isn't that common. Fact is that it's way more common than people think.
[Joel: My quick assumption of 11 million teenager users was wrong. The data says there are actually closer to 30 million.]
Kids, right?
Piper Jaffray recently executed a survey of a sample of the 232 million Internet users in North America. By extrapolating the data, they estimate that over 100 million use instant messaging, over 100 million read blogs and almost 100 million participate in one or more social networking sites.
I assume there are close to 11 million teenagers in North America. So who is using all of these services?
You! You're coming home from work, putting the kids to bed and plugging in. It's interesting because many of you probably think about stuff like blogs as something you do, but that isn't that common. Fact is that it's way more common than people think.
[Joel: My quick assumption of 11 million teenager users was wrong. The data says there are actually closer to 30 million.]
LDS.ORG
We've begun thinking about what is next for LDS.ORG. As we do this, we'd love to get your input.
Take a minute and answer the following two questions. Our team will read each response.
1) What is the Church doing well with the Internet?
2) What is the Church not doing well with the Internet?
Feel free to forward these questions. We'd love all the thoughtful responses we can get!
Take a minute and answer the following two questions. Our team will read each response.
1) What is the Church doing well with the Internet?
2) What is the Church not doing well with the Internet?
Feel free to forward these questions. We'd love all the thoughtful responses we can get!
Book Club: Wikinomics
I just started reading this one and am loving it. It can be dry and redundant, but the examples of commerical entities using mass collaboration are worth wading through a few moments of drudgery.
Pleasing the Customer(s)
When I worked in the mobile devices division at Microsoft we had an ongoing discussion about who our customer was for our mobile device offerings:
So which are the customers? Answer: All.
Customer: Anyone who lays a legitimate claim to directing your software development work.
Imagine how difficult it is to develop requirements for any one of the "customers" listed above. Now imagine creating requirements which balance all of the needs of the competing interests. Ugh.
We face a similar, though not so extreme, challenge in I.T. We have internal customers (typically product managers) who work for the departments we serve. They have their own management chain who have opinions of what work should be done and how. We have our own management chain which has its opinions. And then, of course, we have the end-users for whom we're collectively building the software. Pile on top the fact that "knowing what one wants in the software" is not an inherent skill. It's something most people think they do well, but don't.
So what to do? Here are some suggestions:
Having multiple customers can be a great challenge, but when you mostly satisfy most of them (in priority order) you accomplish something which brings great satisfaction.
- The carrier (e.g. Sprint, Verizon, AT&T, etc.) upon whose network the device would run.
- The OEM who would make the hardware (Dell, HP, Motorola, etc.).
- The kid who would use it.
- The parent who would buy it for the kid.
- The department(s) within Microsoft which might profit from services sold through the device.
- The random executive or product manager who had an opinion of what features should be on the device.
- And of course: ourselves!
So which are the customers? Answer: All.
Customer: Anyone who lays a legitimate claim to directing your software development work.
Imagine how difficult it is to develop requirements for any one of the "customers" listed above. Now imagine creating requirements which balance all of the needs of the competing interests. Ugh.
We face a similar, though not so extreme, challenge in I.T. We have internal customers (typically product managers) who work for the departments we serve. They have their own management chain who have opinions of what work should be done and how. We have our own management chain which has its opinions. And then, of course, we have the end-users for whom we're collectively building the software. Pile on top the fact that "knowing what one wants in the software" is not an inherent skill. It's something most people think they do well, but don't.
So what to do? Here are some suggestions:
- Start with high level requirements. Make sure you understand what the goal of the project is. Stand firm on this point, and don't relent for any amount of begging, threatening or bribery. Get the value proposition documented in plain English and make sure your customers, all up and down their management chain, agree. Treat this with the utmost importance and respect. It will become your rock later on when disconnects occur between product managers and their management. The value isn't so much in having a tool to cover yourself. Rather, documented requirements help you help the customers get on the same page about what is expected.
- Always be an advocate for the end-user. It's your solemn duty. Whomever your customer is, they care about the end-user, even if they don't understand how to delight them. Use whatever tools you choose or have available: focus groups, usability studies, contextual inquiry, intuition, whatever. Just make sure you understand the user(s) of the system and that you champion them at every turn. Your customers will thank you (though maybe later).
- Use functional prototypes to narrow the "gap of misunderstanding" up front and get everyone on the same page about what is to be built.
- Prioritize your customers. Understand which is most important to satisfy and take care of the high priority features for the high priority customers first.
- "Just say no" to executive/management pet features. Executives appreciate those who "speak up." If someone in your management chain tries to get you to add or subtract features and you know in your toes that its the wrong direction, then push back! If you've said your piece with all vigor of heart and the answer is still no, then press forward--you've done the right thing by speaking up. If having done so becomes a "career limiting move" then you may have the wrong management anyway. I speak from experience. The people in our organization typically take great pleasure in pushing back on me.
Having multiple customers can be a great challenge, but when you mostly satisfy most of them (in priority order) you accomplish something which brings great satisfaction.
mormon.org Beta
The beta release for the new mormon.org was released this weekend. Have a look.
We started the revamp several months ago. This is a great example of using a high fidelity functional prototype to understand what we were building up front, thereby decreasing development time.
The key new features include video testimonies from actual converts of the Church and an online chat where people who are interested in the Church can chat with members to learn more about the Gospel. We've been pilot testing the chat feature for several months and have already seen several people join.
We started the revamp several months ago. This is a great example of using a high fidelity functional prototype to understand what we were building up front, thereby decreasing development time.
The key new features include video testimonies from actual converts of the Church and an online chat where people who are interested in the Church can chat with members to learn more about the Gospel. We've been pilot testing the chat feature for several months and have already seen several people join.
Tech Talk Last Night
We had another tech talk last night in Mountain View, CA. About 30 or so people registered--almost 40 showed up. We had folks from:
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
- Cisco
- Ebay
- Dreamworks
- Oracle
- Barclays
- The State of California
- Sun Microsystems
- Sprint
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
Tech Talk in Mountain View
Just a reminder that we're having a tech talk in Mountain View, CA this next week. If you have time, head over to the lds tech site and register so we know how many people to expect.
The Maintenance Monkey
Maintenance. Call it bug fixing. Call it "keeping the wheels on." Call it warranty. Call it whatever you want.
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Well, sure it's a bug! You promised me the ability to report and this is a report I need!"
"It's only a few hours, huh? I don't want to go back for approval. Just do it this once, wontcha?"
"Um. Hey Fred. Uh... Listen... I know you're working on a new project, but I was in the neighborhood and happened to have these tickets to the playoffs..."
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Book Club: The Mormon Way of Doing Business
I've heard The Mormon Way of Doing Business by Jeff Benedict is a pretty interesting book. I'm going to give it a try.
Has anyone read it? What do you think?
Has anyone read it? What do you think?
Big Iron-y
Scale. Reliability.
When you're in enterprise I.T. you care a lot about those words--sometimes too much.
Like most I.T. shops, we have a very complex environment: multiple hardware, os, database and programming languages. You'd expect a fair number of outages.
Some of our biggest outages this year, however, came as a result of (or were made worse by) our attempts to insulate ourselves from outages or to provide better scale:
So what do you do? Introducing additional protection introduces additional points of failure. Is it worth it?
What's your experience?
When you're in enterprise I.T. you care a lot about those words--sometimes too much.
Like most I.T. shops, we have a very complex environment: multiple hardware, os, database and programming languages. You'd expect a fair number of outages.
Some of our biggest outages this year, however, came as a result of (or were made worse by) our attempts to insulate ourselves from outages or to provide better scale:
- The network load balancer to our data center failed. Luckily we were redundant, right? Wrong. The redundant load-balancing element failed, too. BUT it didn't know it failed so the system thought it was operating, but we were actually down. It took us 30 minutes to realize our applications were down because of the failed load balancer.
- We had an eerily similar situation happen with a database load-balancing solution.
- We use a storage area network (SAN) primarily to allow us to scale storage at a cheaper price. These SAN cabinets are big iron city. Guess where four of our biggest outages this last year happened. That's right: our SAN. We've since moved to a new vendor for storage.
So what do you do? Introducing additional protection introduces additional points of failure. Is it worth it?
What's your experience?
Managing complexity
A few weeks ago Joel warned you that there would be occasional guest posts - I am the first volunteer. The brief bio on beta.tech.lds.org should provide you with some understanding of my experience and biases. In this post, I leverage those experiences and biases to offer some observations about complexity....
One of the attributes I failed to develop during my academic training was a proper appreciation for the perils of complexity. I recall creating code that was fast, efficient, and utterly un-maintainable. In the academic context this seemed fine, since I was typically the only one maintaining the code, it was rarely used beyond the end of the class, and system failure affected only my grade. However, over the past 15 years my professional experience has changed my perspective and caused me to value simple, understandable, and maintainable solutions over those which lack the foregoing traits yet are fast, efficient, and theoretically “robust.” I offer the following observations relative to the impact of complexity on the reliability, maintainability, and scalability of the systems we create.
What can be done to help manage complexity or mitigate its impact? I doubt there is a silver bullet, but the following concepts have been helpful to me.
How has complexity manifest itself in the environments in which you work? What are you doing to manage it? Is it hypocritical for a complex post to extol the virtues of simplicity?
One of the attributes I failed to develop during my academic training was a proper appreciation for the perils of complexity. I recall creating code that was fast, efficient, and utterly un-maintainable. In the academic context this seemed fine, since I was typically the only one maintaining the code, it was rarely used beyond the end of the class, and system failure affected only my grade. However, over the past 15 years my professional experience has changed my perspective and caused me to value simple, understandable, and maintainable solutions over those which lack the foregoing traits yet are fast, efficient, and theoretically “robust.” I offer the following observations relative to the impact of complexity on the reliability, maintainability, and scalability of the systems we create.
- Humans cause failures. In my experience, human failure is a more likely cause of downtime than the failure of a physical component. However, we often try to increase system availability by adding redundancy to mitigate for component failure. This redundancy has the collateral impact of adding complexity, which unfortunately increases the likelihood of human failure. I’m not sure we always end up net positive on the availability scale.
- Control planes, which manage highly redundant environments, are often themselves single points of failure. The likelihood of control plane failure generally increases as the component redundancy becomes more complex.
- Failure modes are difficult to predict and detect. As a result, sometimes secondary components go unused during primary component failure.
- With redundant systems, we assume that the joint probability of multiple independent failures is small. Unfortunately, the assumption of independence is often incorrect.
- Complex systems are difficult to scale. RFC 3439 quotes Mike O’Dell, the former Chief Architect of UUNET, as saying, “Complexity is the primary mechanism which impedes efficient scaling, and as a result is the primary driver of increases in both capital expenditures and operational expenditures.”
- And finally, an observation by Willinger and Doyle et al: “…we point out a very typical, but in the long term potentially quite dangerous engineering approach to dealing with network-internal and -external changes, namely responding to demands for improved performance, better throughput, or more robustness to unexpectedly emerging fragilities with increasingly complex designs or untested short-term solutions. While any increase in complexity has a natural tendency to create further and potentially more disastrous sensitivities, this observation is especially relevant in the Internet context, where the likelihood for ‘unforeseen feature interactions’ in the ensuing highly engineered large-scale structure drastically increases as the network continues to evolve. The result is a complexity/robustness spiral [i.e., robust design → complexity → new fragility → make design more robust → …] that—without reliance on a solid and visionary architecture—can easily and quickly get out of control.”
What can be done to help manage complexity or mitigate its impact? I doubt there is a silver bullet, but the following concepts have been helpful to me.
- Use a crutch to force yourself to remember what is important. My crutch was a note hanging on the side of my monitor to remind me that supportability, maintainability, and reliability were more important than performance and efficiency – not that the last two were not important – they were just not the most important.
- Document what you are doing as you are doing it. If your solution is simple it should be easy to describe. Consider the documentation process a litmus test for simplicity.
- Avoid tight coupling and interdependence. Focus on isolation, separation, and modularization.
- You are more likely to be successful tailoring your system to the capabilities of your operators than tailoring the capabilities of your operators to your system.
- Use automation, but continue to be vigilant about managing down the underlying complexity that the automation is abstracting.
- This one is going to be controversial: sometimes you have to make hard tradeoffs in which you abandon some amount of functionality (and possibly redundancy) to maintain simplicity. This involves understanding the difference between what you can do and what you should do.
- "Make everything as simple as possible, but not simpler." -- Albert Einstein.
How has complexity manifest itself in the environments in which you work? What are you doing to manage it? Is it hypocritical for a complex post to extol the virtues of simplicity?
Tech Talk in Mountain View, CA
Our next tech talk will be in Mountain View, CA on April 25th. Some of us will be in the area for a conference so we're doubling up.
You will find all of the details here.
Look forward to seeing some of you folks from California!!
You will find all of the details here.
Look forward to seeing some of you folks from California!!
Guest Posters
Occasionally you'll see a guest poster on this site. When you do you'll know it because a) the IQ of the post will seem much higher than typical and b) the author's name will be listed.
Take it easy on them!
Take it easy on them!
A Peculiar I.T. Shop
In many ways the Church's I.T. operations resemble those of a normal company:
The Church is peculiar in that each of these systems is enormously more complicated than it might be for a typical company because each of them potentially supports millions of members of the Church, people who aren't considered "employees."
Let me give you a few examples.
Network systems which support operations. Our team provides the networks for the buildings where Church employees work and for our data centers. The networking needs here are pretty typical. However consider the number of chapels around the world. They all need some measure of connectivity either for the ward clerk system (MLS) or for family history centers. All broadband connections into chapels are required to use centrally-filtered internet access. Layer upon the sheer numbers of network connections the complexity of having networks in countries like the Philippines and some of the islands of the South Pacific, places where the network infrastructure isn't as robust as it is in other countries.
Email systems. Providing an email system for Church employees is no big deal--standard stuff. However we provide email for all of the LDS missionaries across the world and for local ecclesiastical leaders.
Workflow applications. The Church has some pretty typical workflow applications: budgeting, ERP, policy management, intranet content creation, etc. But we're also creating applications for use by all of the Church members. In the United States and Canada missionaries now sign up for their missions using an online tool. Once an assignment is made by our Church leadership this tool facilitates all of the logistics of getting them to the right place at the right time with the right preparation. We'll be providing more and more of these applications to Church membership over time to help decrease time spent in Church administration.
Financial & HR applications. Along with the solutions we use to manage the general ledger, pay taxes, manage facilities, et al (all typical stuff), we must also track both the donations of the members worldwide and the dispersion of those funds for welfare, missions, building construction, and so forth. With the number of units and the variety of currencies, you can imagine how complex this task is.
Training. Finally, we don't just provide training for employees. We provide teaching & training resources for members and for local ecclesiastical leaders worldwide. LDS.ORG and other Church-sponsored web sites garner over 50 million unique page views per month (not including FamilySearch). You can't get much more mission critical than supporting the 11:00pm Saturday LDS.org rush to prepare talks and Sunday school lessons for the next day. :)
By conventional measures, the I.T. operation which supports Church employees should be simple and routine. But our "extended workforce," I guess you could call it, increases the complexity of our I.T. operations significantly, requiring that we act a lot bigger than we are.
It's one of the things that makes our jobs so fun!
- Network systems
- Email systems
- Workflow applications
- Financial & HR applications
- Training
The Church is peculiar in that each of these systems is enormously more complicated than it might be for a typical company because each of them potentially supports millions of members of the Church, people who aren't considered "employees."
Let me give you a few examples.
Network systems which support operations. Our team provides the networks for the buildings where Church employees work and for our data centers. The networking needs here are pretty typical. However consider the number of chapels around the world. They all need some measure of connectivity either for the ward clerk system (MLS) or for family history centers. All broadband connections into chapels are required to use centrally-filtered internet access. Layer upon the sheer numbers of network connections the complexity of having networks in countries like the Philippines and some of the islands of the South Pacific, places where the network infrastructure isn't as robust as it is in other countries.
Email systems. Providing an email system for Church employees is no big deal--standard stuff. However we provide email for all of the LDS missionaries across the world and for local ecclesiastical leaders.
Workflow applications. The Church has some pretty typical workflow applications: budgeting, ERP, policy management, intranet content creation, etc. But we're also creating applications for use by all of the Church members. In the United States and Canada missionaries now sign up for their missions using an online tool. Once an assignment is made by our Church leadership this tool facilitates all of the logistics of getting them to the right place at the right time with the right preparation. We'll be providing more and more of these applications to Church membership over time to help decrease time spent in Church administration.
Financial & HR applications. Along with the solutions we use to manage the general ledger, pay taxes, manage facilities, et al (all typical stuff), we must also track both the donations of the members worldwide and the dispersion of those funds for welfare, missions, building construction, and so forth. With the number of units and the variety of currencies, you can imagine how complex this task is.
Training. Finally, we don't just provide training for employees. We provide teaching & training resources for members and for local ecclesiastical leaders worldwide. LDS.ORG and other Church-sponsored web sites garner over 50 million unique page views per month (not including FamilySearch). You can't get much more mission critical than supporting the 11:00pm Saturday LDS.org rush to prepare talks and Sunday school lessons for the next day. :)
By conventional measures, the I.T. operation which supports Church employees should be simple and routine. But our "extended workforce," I guess you could call it, increases the complexity of our I.T. operations significantly, requiring that we act a lot bigger than we are.
It's one of the things that makes our jobs so fun!
Interviewing
Whatever you think about the book Good to Great it's hard to argue one of its premises--that great companies don't exist without great people. I'm a believer.
In my experience a great engineer can be equal to two, three or even more average engineers. They have good attitudes. They're productive. They do things right and minimize re-work. They're not defensive. They communicate with others effectively. They look for things to do when they've got spare capacity. They're easy to talk with. And they inspire others. I just love them. People like this are easily worth what their skills and experience demand in the market.
So how do you find them?
That's the key, huh? With a crack (or even average) HR department, finding people to bring in for interviews isn't terribly difficult. It's a little harder at the Church as the intersection of individuals who have temple recommends, want to live in Utah, have the skills & aptitudes we're looking for and are willing to work for less than market wages is small. Still we're able to get people in the door. A good HR department will not only bring many people in the door, but a healthy percentage of them will turn out to be the folks we want to hire.
Once folks are in the door for interviews, however, the hard work begins for the rest of the team. People do not inherently know how to interview. Discovering "great people" in an interview is not intuitive. It takes training, preparation and a good measure of thoughtfulness.
Here are some suggestions that can improve your interviewing techniques.
These are just a few ideas. The one point I'd get across is this: take recruiting and interviewing seriously. Getting great people is the most important thing you can do as a manager or as an organization.
What additional tips do you have?
In my experience a great engineer can be equal to two, three or even more average engineers. They have good attitudes. They're productive. They do things right and minimize re-work. They're not defensive. They communicate with others effectively. They look for things to do when they've got spare capacity. They're easy to talk with. And they inspire others. I just love them. People like this are easily worth what their skills and experience demand in the market.
So how do you find them?
That's the key, huh? With a crack (or even average) HR department, finding people to bring in for interviews isn't terribly difficult. It's a little harder at the Church as the intersection of individuals who have temple recommends, want to live in Utah, have the skills & aptitudes we're looking for and are willing to work for less than market wages is small. Still we're able to get people in the door. A good HR department will not only bring many people in the door, but a healthy percentage of them will turn out to be the folks we want to hire.
Once folks are in the door for interviews, however, the hard work begins for the rest of the team. People do not inherently know how to interview. Discovering "great people" in an interview is not intuitive. It takes training, preparation and a good measure of thoughtfulness.
Here are some suggestions that can improve your interviewing techniques.
- Interviewing for experience is one of the biggest mistakes people make. You can read someone's experience on a resume. Prepare prior to the interview by reviewing the resume carefully. Don't waste your time asking questions you could have found out with a little preparation.
- Figure out what you're going to ask ahead of time. Write down the questions you'll ask and think about what you're trying to discover with each question.
- Save time to write down your feedback after the interview. It helps you process the information you've gathered and will help down the line when you're looking back.
- Smart candidates ask lots of questions and keep the interviewer talking. People love to talk about themselves. I've had many, many managers tell me they loved such-and-such candidate, where afterward I've asked detailed questions and found the person was duped into telling the candidate about his job, the organization, his family, the weather, what's it like to live in Utah, etc. The "sell" you think you're accomplishing with an interview like that just isn't that important.
- I look for three things when interviewing a candidate: intelligence, passion for technology, attitude. Finding questions that test the second two is easy. The first is more difficult. I like asking problem-solving questions. In my opinion, questions that require an "a-ha" moment, some flash of non-intuitive or non-deducible inspiration, aren't that useful. I prefer questions where you can watch them think. Encourage them to think out loud and/or to use the board. And I'm perfectly willing to let the candidate stew while they think through the hard questions. You need people who can think.
Leave your technology biases at home. So they love Linux and you don't--so what? So they use a different editor than you do, or they put their curly braces in the wrong place--so what? I don't care if a candidate speaks COBOL, Java, .net, Ruby, Fortran, Forth, LISP, or any other language, for that matter. A candidate's opinion on which operating system is most secure is just not super relevant. If she can solve problems then her technical biases don't matter.- Ask real questions--even simple ones. It helps you see them think in context. If you're hiring a developer, ask them coding questions. If you're hiring an architect, have them create architectures. If you're hiring a business manager, have them write a business plan with you.
Try to use the same questions for a set of applicants coming through for the same job. It lets you get a relative view.
These are just a few ideas. The one point I'd get across is this: take recruiting and interviewing seriously. Getting great people is the most important thing you can do as a manager or as an organization.
What additional tips do you have?
NorthTemple@SXSW
Some of the members of the Church's interaction design team will be at the South by Southwest conference (SXSW) again this year. They're having a get together. If you'll be there, go by and say hello.
Tech Talk in Bay Area?
Several of our directors will be in the bay area April 22 - April 26. We are considering a tech talk there if there is enough interest.
The tentative agenda would be:
Please respond to this post if a) you’d be interested in attending a tech talk in the bay area or b) if you have a suggested venue. We’ve had these on site at a vendor location in the past and that has worked quite well.
[Deleted my comment asking people not to post requests for tech talks in other locations as it sounded a little snooty. Thanks to the reader who pointed that out.]
Thanks!
The tentative agenda would be:
- Keynote (joel)
- Infrastructure breakout (dave)
- Development breakout (david)
- Interaction Design breakout (tadd)
- Community breakout (tom)
- Building to building video breakout (pete)
Please respond to this post if a) you’d be interested in attending a tech talk in the bay area or b) if you have a suggested venue. We’ve had these on site at a vendor location in the past and that has worked quite well.
[Deleted my comment asking people not to post requests for tech talks in other locations as it sounded a little snooty. Thanks to the reader who pointed that out.]
Thanks!
Customization
My background is in software development so my first inclination in solving a business problem is to turn to custom software. I have to fight that urge as off-the-shelf applications are often more cost effective than custom-developed ones.
Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry's collective wisdom. Plus you have many more users testing "your" code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said "if they match your business processes." If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we've needed to make a change to a COTS application, we've customized the tool. It's so easy to do! You don't have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple "configuration" (read: write code) and publish the changes out to production in the tool that's already been pushed there. It's typically that easy.
But is it worth it?
Firstly, you can rarely build what you'd REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That's when you feel it in your pocket book. We've been riding the upgrade train of our ERP system for years. We've made many, many customizations. They're necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn't have been smarter to write the software yourself instead of purchasing an expensive COTS application. I'm coming to the conclusion that the answer is no for many COTS applications.
Here's the credo we're developing at the Church wrt COTS applications.
This approach isn't always a popular one:
But we think it's the best one for us.
Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry's collective wisdom. Plus you have many more users testing "your" code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said "if they match your business processes." If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we've needed to make a change to a COTS application, we've customized the tool. It's so easy to do! You don't have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple "configuration" (read: write code) and publish the changes out to production in the tool that's already been pushed there. It's typically that easy.
But is it worth it?
Firstly, you can rarely build what you'd REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That's when you feel it in your pocket book. We've been riding the upgrade train of our ERP system for years. We've made many, many customizations. They're necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn't have been smarter to write the software yourself instead of purchasing an expensive COTS application. I'm coming to the conclusion that the answer is no for many COTS applications.
Here's the credo we're developing at the Church wrt COTS applications.
- Buy over build when possible, but only if we're willing or able to bend our business process to match the tool we would be purchasing. When customizing, abstract code from the COTS application (and especially the DB tables) when extensions are necessary.
- We look carefully at the number and severity of customizations we'll have to build and if we determine that they will pass a certain threshold, we decide to build.
This approach isn't always a popular one:
"We've already got an ERP system! Let's use it!"
"The vendor promises a smooth upgrade path!"
"The tools are soooo simple!"
But we think it's the best one for us.
LDS.ORG
We apologize for the slowness of lds.org the last two weekends. We've recently moved to a new infrastructure and haven't yet figured out the right configuration for caching and garbage collection.
If there are any Websphere/Vignette experts out there, make yourself known in the LDS.ORG forum over at our tech web site!
Thanks for your patience.
If there are any Websphere/Vignette experts out there, make yourself known in the LDS.ORG forum over at our tech web site!
Thanks for your patience.
7: Make It Easy
We communicate clearly, avoid complexity in our solutions and improve & follow processes so that it is easy to work with ICS.
What an industry we work in! How many emails did you send 15 years ago? How many web pages did you surf? For most of us the answer is zero. Can you now imagine a world without computer technology? So much has changed in such a small amount of time.
All of you techies will probably understand 100% of the following conversation.
Matilda: Whatcha doin?
Orpheous: Surfing the web.
Matilda: Did you know Google uses AJAX?
Orpheous: Yup, but they also use a lot of C.
Matilda: Man, they must be using a serious DBMS.
Orpheous: Yeah, I have a friend who writes SQL for them.
Matilda: They don't use ADO do they?
Orpheous: Yeah right. And their servers run on DOS.
Matilda: LOL.
Matilda: I just got a new mobile device!
Orpheous: A blackberry or a palm?
Matilda: Pocket PC. And it supports both GSM and CDMA!
Orpheous: Cool. Does it support WAP?
Matila: Oh yes! And straight TCP/IP!
Orpheous: Dude. That's sweet.
Matilda: Did you just call me dude?
Orpheous: LOL
Matilda: Is your PC still slow?
Orpheous: Yeah, I was in the middle of a DEFRAG and I got a blue screen.
Matilda: Whoa. Did you update your BIOS?
Orpheous: No, I couldn't find the EXE.
Matilda: Why were you using NTFS instead of FAT?
Orpheous: Hey, do I bug you about using AIX instead of Red Hat?
Matilda: No. But your company doesn't have the same ITIL requirements we do.
Orpheous: At least we're PCI compliant. What's that got to do with the OS?
Matilda: Nothing. Couldn't think of something better.
Orpheous: By the way who did you work with in implementing ITIL?
Matilda: IBM and HP.
Orpheous: Nice...
Read it again and think about that same conversation 20 or even 10 years ago. Many of these acronyms and names weren't even invented then. As our technology changes, our technical jargon changes.
And it's inevitable that some of that jargon makes its way into the consumer lexicon: IM, surfing the web, email, bugs, text (as in the verb).
Acronyms and short names are obviously useful. For people who already understand the technology you're talking about, they're easier on the tongue. But this friendly way of talking about technology belies an underlying complexity which we too easily foist on our customers.
Let's face it--engineers love complexity. I was conducting a new employee orientation yesterday. In going around the room introducing ourselves one of our exceptional new software engineers talked about one of his favorite home hobbies: aerodynamics.
?
I didn't even realize that could be a hobby. He enjoys learning all the math and physics involved with making stuff fly. Don't get me wrong--what a cool and admirable hobby, but it puts a fine point on the fact that engineers are perfectly comfortable with complexity. This fact has two unfortunate consequences, both of which lead to frustration for I.T. customers.
First, our complexity, while delightful and "fun" for us, is confusing and unnecessary to our customers. They want simple answers when they ask simple questions. They don't want technobabble. They want cheap, workable, simple solutions when they come to us with problems. We must shelter customers from complexity in any form. This is not to say we should hide the truth or cover up problems, but these things can be talked about in an easier-to-understand way.
Second, we often create complex processes and bureaucracy to protect ourselves and our customers from the complexity that comes with the territory. This irony is one which alienates our customers further, rendering us "hard to work with," "slow" and "imposing." Process definition and adherence is critical for an I.T. department of any size, but particularly so with ours, given both our depth and breadth of technology usage. But not all process is good process. We should be continually striving to simplify and measure our processes to make sure we're hitting the mark for our customers.
Simplicity. It's the name of the game in I.T. That's why our seventh and final cultural belief is "Make It Easy!"
What an industry we work in! How many emails did you send 15 years ago? How many web pages did you surf? For most of us the answer is zero. Can you now imagine a world without computer technology? So much has changed in such a small amount of time.
All of you techies will probably understand 100% of the following conversation.
Matilda: Whatcha doin?
Orpheous: Surfing the web.
Matilda: Did you know Google uses AJAX?
Orpheous: Yup, but they also use a lot of C.
Matilda: Man, they must be using a serious DBMS.
Orpheous: Yeah, I have a friend who writes SQL for them.
Matilda: They don't use ADO do they?
Orpheous: Yeah right. And their servers run on DOS.
Matilda: LOL.
Matilda: I just got a new mobile device!
Orpheous: A blackberry or a palm?
Matilda: Pocket PC. And it supports both GSM and CDMA!
Orpheous: Cool. Does it support WAP?
Matila: Oh yes! And straight TCP/IP!
Orpheous: Dude. That's sweet.
Matilda: Did you just call me dude?
Orpheous: LOL
Matilda: Is your PC still slow?
Orpheous: Yeah, I was in the middle of a DEFRAG and I got a blue screen.
Matilda: Whoa. Did you update your BIOS?
Orpheous: No, I couldn't find the EXE.
Matilda: Why were you using NTFS instead of FAT?
Orpheous: Hey, do I bug you about using AIX instead of Red Hat?
Matilda: No. But your company doesn't have the same ITIL requirements we do.
Orpheous: At least we're PCI compliant. What's that got to do with the OS?
Matilda: Nothing. Couldn't think of something better.
Orpheous: By the way who did you work with in implementing ITIL?
Matilda: IBM and HP.
Orpheous: Nice...
Read it again and think about that same conversation 20 or even 10 years ago. Many of these acronyms and names weren't even invented then. As our technology changes, our technical jargon changes.
And it's inevitable that some of that jargon makes its way into the consumer lexicon: IM, surfing the web, email, bugs, text (as in the verb).
Acronyms and short names are obviously useful. For people who already understand the technology you're talking about, they're easier on the tongue. But this friendly way of talking about technology belies an underlying complexity which we too easily foist on our customers.
Let's face it--engineers love complexity. I was conducting a new employee orientation yesterday. In going around the room introducing ourselves one of our exceptional new software engineers talked about one of his favorite home hobbies: aerodynamics.
?
I didn't even realize that could be a hobby. He enjoys learning all the math and physics involved with making stuff fly. Don't get me wrong--what a cool and admirable hobby, but it puts a fine point on the fact that engineers are perfectly comfortable with complexity. This fact has two unfortunate consequences, both of which lead to frustration for I.T. customers.
First, our complexity, while delightful and "fun" for us, is confusing and unnecessary to our customers. They want simple answers when they ask simple questions. They don't want technobabble. They want cheap, workable, simple solutions when they come to us with problems. We must shelter customers from complexity in any form. This is not to say we should hide the truth or cover up problems, but these things can be talked about in an easier-to-understand way.
Second, we often create complex processes and bureaucracy to protect ourselves and our customers from the complexity that comes with the territory. This irony is one which alienates our customers further, rendering us "hard to work with," "slow" and "imposing." Process definition and adherence is critical for an I.T. department of any size, but particularly so with ours, given both our depth and breadth of technology usage. But not all process is good process. We should be continually striving to simplify and measure our processes to make sure we're hitting the mark for our customers.
Simplicity. It's the name of the game in I.T. That's why our seventh and final cultural belief is "Make It Easy!"
Yearn for the vast and endless sea!
"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.
- 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.
Java Stack
We've talked before about the Java Stack we're using at the Church. I thought I'd list the key components we're using. Feedback is welcome.
Spring 2.0 (http://www.springframework.org/): Spring is our lightweight application development framework.
Hibernate 3.2 (http://www.hibernate.org/): Object/Relational Persistence. Hibernate abstracts developers from the database by allowing the developer to create an object to code against while Hibernate takes care of the database stuff underneath. We've recently started using the Java Persistence API (JPA) over Hibernate and it has dramatically improved our ability to quickly pump out database applications.
JSF - RI implementation (https://javaserverfaces.dev.java.net/): From wikipedia: JavaServer Faces (JSF) is a Java-based Web application framework that simplifies the development of user interfaces for Java EE applications.
Facelets (https://facelets.dev.java.net/): I've talked before about our Interaction Designers. They are expert with tools like Photoshop, but they also crank out xhtml and css. Facelets allows us to drop their code into the actual projects so the developers don't have to re-write what the designer has already done.
Ajax4JSF (https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/): JSF extension which has a lot of commonly used Ajax features integrated into JSF components.
G4JSF (https://ajax4jsf.dev.java.net/nonav/ajax/gwt/gwt-cdk.html): JSF extension which maintains an integration library for the Google Widget Toolkit (GWT) and JavaServer Faces (JSF) that wraps Google widgets into JSF components to fully leverage both technologies. We're not using it currently, but we're looking into it for some future projects.
Log4j (http://logging.apache.org/log4j/docs/): A logging framework we use to allow us to use config files to create logging statements in our code that disappear at run-time. It also logs to a variety of device types.
EasyMock (http://www.easymock.org/): We've developed an environment-agnostic testing framework/harness using EasyMock.
Maven 2.0 (http://maven.apache.org/): We love Maven. We used to have one guy managing the build of a couple of projects. One person now manages 30 or so projects and we're adding more projects all the time. We've also pretty dramatically increased our level of reporting.
Spring 2.0 (http://www.springframework.org/): Spring is our lightweight application development framework.
Hibernate 3.2 (http://www.hibernate.org/): Object/Relational Persistence. Hibernate abstracts developers from the database by allowing the developer to create an object to code against while Hibernate takes care of the database stuff underneath. We've recently started using the Java Persistence API (JPA) over Hibernate and it has dramatically improved our ability to quickly pump out database applications.
JSF - RI implementation (https://javaserverfaces.dev.java.net/): From wikipedia: JavaServer Faces (JSF) is a Java-based Web application framework that simplifies the development of user interfaces for Java EE applications.
Facelets (https://facelets.dev.java.net/): I've talked before about our Interaction Designers. They are expert with tools like Photoshop, but they also crank out xhtml and css. Facelets allows us to drop their code into the actual projects so the developers don't have to re-write what the designer has already done.
Ajax4JSF (https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/): JSF extension which has a lot of commonly used Ajax features integrated into JSF components.
G4JSF (https://ajax4jsf.dev.java.net/nonav/ajax/gwt/gwt-cdk.html): JSF extension which maintains an integration library for the Google Widget Toolkit (GWT) and JavaServer Faces (JSF) that wraps Google widgets into JSF components to fully leverage both technologies. We're not using it currently, but we're looking into it for some future projects.
Log4j (http://logging.apache.org/log4j/docs/): A logging framework we use to allow us to use config files to create logging statements in our code that disappear at run-time. It also logs to a variety of device types.
EasyMock (http://www.easymock.org/): We've developed an environment-agnostic testing framework/harness using EasyMock.
Maven 2.0 (http://maven.apache.org/): We love Maven. We used to have one guy managing the build of a couple of projects. One person now manages 30 or so projects and we're adding more projects all the time. We've also pretty dramatically increased our level of reporting.
Tech Talks
Let's talk in person. Some of the directors in our group and I are having "tech talks" in various locations to discuss with I.T. professionals the technologies that serve the Church's enterprise. System engineers, software developers & testers, interaction designers, and other techies may enjoy these discussions.
The first round of tech talks will focus on:
This will be an inside look at how we build, design and implement the Church's technology solutions. No need to RSVP. Feel free to invite your interested friends and colleagues. NOTE: This will NOT be a discussion of MLS features. Most ward clerks will not be interested in these discussions.
I wish we could travel to meet and network with all of you fascinating people, but the logistics make it impossible. We're beginining with two locations and hopefully, with success, we'll make this a tradition and eventually visit more of you across the country. We will be posting excerpts from the evening so those who can't be there in person can follow with the discussion.
I look forward to meeting those of you who can make it!
Salt Lake City
January 18th, 6:30pm
Joseph Smith Memorial Building, 10th Floor
Note: Please park at the ZCMI center
Provo
January 23rd, 6:30pm
BYU 8th Stake Center (1021 South 500 West)
Future locations (probably Seattle and Bay Area) and dates to be announced.
The first round of tech talks will focus on:
Communications (Satellite, IP telephony, wireless and building connectivity)
Software development at the Church
Infrastructure and data center issues
Interaction Design
This will be an inside look at how we build, design and implement the Church's technology solutions. No need to RSVP. Feel free to invite your interested friends and colleagues. NOTE: This will NOT be a discussion of MLS features. Most ward clerks will not be interested in these discussions.
I wish we could travel to meet and network with all of you fascinating people, but the logistics make it impossible. We're beginining with two locations and hopefully, with success, we'll make this a tradition and eventually visit more of you across the country. We will be posting excerpts from the evening so those who can't be there in person can follow with the discussion.
I look forward to meeting those of you who can make it!
Salt Lake City
January 18th, 6:30pm
Joseph Smith Memorial Building, 10th Floor
Note: Please park at the ZCMI center
Provo
January 23rd, 6:30pm
BYU 8th Stake Center (1021 South 500 West)
Future locations (probably Seattle and Bay Area) and dates to be announced.
4: Speak Up
I professionally challenge, ask questions, propose alternatives, and exchange feedback.
I love to get together with groups of employees and just talk. Recently I gathered a group, and we just chatted. It was fun. I intentionally asked a tough question to see what the response would be. I was surprised and frankly delighted when the group came up with an answer that seemed like a pretty thoughtful, non-typical answer--an answer I thought made sense. I had really pushed for them to be honest so I felt pretty good that the group was thinking in a new way, what I thought was a healthy way. Here’s the thing. I really, honestly wanted to know what people thought.
Later I found out that there was some grumbling afterward and that a few people had been afraid or unwilling to speak their minds–they wanted to appear like they were aligned with what they thought I wanted; they wanted to be good soldiers.
That's a shame. Yes, I'm not partial to complaining and whining. Yes, people need to get on the bandwagon when decisions are made and be supportive. But that doesn’t equate to a gag order!
If there’s anything I value, it’s opinions! And reason! And guts! Speak Up is our fourth cultural belief, and people do it far too infrequently.
Don’t get me wrong. Speaking up isn’t easy. Obviously I'm not as approachable as I think I am if people aren't willing to always speak their minds. But it's someting we're trying consciously to improve.
Speaking up for the sake of speaking up doesn’t help anyone, including ourselves. We just come off as wanting to hear ourselves talk. Have you met people who spend brain cycles trying to consider what question will make them sound most intelligent? What a waste that is. Better to use our brains to try to understand things better and to solve problems.
It starts with a sincere thought. Speaking up when you have a sincere thought, even if it seems like a stupid one, is delightful to the ears. The thought you’re thinking is often the thought others are thinking. It’s the ones that seem really stupid, the one that everyone is unwilling to ask, that will often add the most value to a group. Or those creative thoughts which cause people to think in a different way. those are great ones, too!
The next step is to just blurt it out! If you have a thought, if you seek understanding, if you disagree, then for heaven’s sake–say so!! It’s ok to press your point. And it’s ok to acquiese. The key is to propel the discussion and the thinking (both the group’s and your own) forward!
Conversation is like ping pong. You serve it up, you wait for the return and then you shoot it back over. You can’t position your paddle in a certain place and hope the ball comes to you. You’ve got to take the ball where it shows up. If your "opponent" gives you massive back spin, you probably don’t want to "top" the return or it will end up in the net. We need to adapt. Likewise, we should use the same sort of verbal volleying when communicating.
We can't just talk. We need to turn our ears on when communicating; really listen. We need to really try to understand the point of the person we're talking to; we may very well find that we actually understand them better as a result. Or we may find that we can help them remove the straw from between their ears. In any case, we'll BOTH be better off if we listen.
I desperately crave push back. And we should all do the same. We're striving in our group to improve upon our cultural belief of Speaking Up!!
I love to get together with groups of employees and just talk. Recently I gathered a group, and we just chatted. It was fun. I intentionally asked a tough question to see what the response would be. I was surprised and frankly delighted when the group came up with an answer that seemed like a pretty thoughtful, non-typical answer--an answer I thought made sense. I had really pushed for them to be honest so I felt pretty good that the group was thinking in a new way, what I thought was a healthy way. Here’s the thing. I really, honestly wanted to know what people thought.
Later I found out that there was some grumbling afterward and that a few people had been afraid or unwilling to speak their minds–they wanted to appear like they were aligned with what they thought I wanted; they wanted to be good soldiers.
That's a shame. Yes, I'm not partial to complaining and whining. Yes, people need to get on the bandwagon when decisions are made and be supportive. But that doesn’t equate to a gag order!
If there’s anything I value, it’s opinions! And reason! And guts! Speak Up is our fourth cultural belief, and people do it far too infrequently.
Don’t get me wrong. Speaking up isn’t easy. Obviously I'm not as approachable as I think I am if people aren't willing to always speak their minds. But it's someting we're trying consciously to improve.
Speaking up for the sake of speaking up doesn’t help anyone, including ourselves. We just come off as wanting to hear ourselves talk. Have you met people who spend brain cycles trying to consider what question will make them sound most intelligent? What a waste that is. Better to use our brains to try to understand things better and to solve problems.
It starts with a sincere thought. Speaking up when you have a sincere thought, even if it seems like a stupid one, is delightful to the ears. The thought you’re thinking is often the thought others are thinking. It’s the ones that seem really stupid, the one that everyone is unwilling to ask, that will often add the most value to a group. Or those creative thoughts which cause people to think in a different way. those are great ones, too!
The next step is to just blurt it out! If you have a thought, if you seek understanding, if you disagree, then for heaven’s sake–say so!! It’s ok to press your point. And it’s ok to acquiese. The key is to propel the discussion and the thinking (both the group’s and your own) forward!
Conversation is like ping pong. You serve it up, you wait for the return and then you shoot it back over. You can’t position your paddle in a certain place and hope the ball comes to you. You’ve got to take the ball where it shows up. If your "opponent" gives you massive back spin, you probably don’t want to "top" the return or it will end up in the net. We need to adapt. Likewise, we should use the same sort of verbal volleying when communicating.
We can't just talk. We need to turn our ears on when communicating; really listen. We need to really try to understand the point of the person we're talking to; we may very well find that we actually understand them better as a result. Or we may find that we can help them remove the straw from between their ears. In any case, we'll BOTH be better off if we listen.
I desperately crave push back. And we should all do the same. We're striving in our group to improve upon our cultural belief of Speaking Up!!
Subscribe to:
Comments (Atom)