Have a wonderful Christmas and holiday. I'm thankful for the Savior. I love him and honor his name.
Wonderful. Counselor. The Everlasting Father. The Prince of Peace.
3: Know My Customer
I know my customers, those in the field and those at headquarters.
I'm an engineer; or I was formerly one. Well at least I used to write code for a living. And that gives me insight into a secret engineering credo: we are our own customers!
You see proof of this secret all over the software you use.
Example 1: You click on a button and receive an error message like the following: Function lpzWinRandomFunction returned 0xfe02facd.
Example 2: What should be simple functions (like mail merge) in popular software programs actually require end-users to write "code" in order to get them to work properly (e.g. if/then/else statements, db queries, formatting).
Example 3: Features which have major bugs are left in the software with the excuse that: "It doesn't happen all that often--and the user can just re-start or re-boot. No big deal..."
This kind of stuff is infuriating. It's why software development gets such a bad reputation. Consumers don't tolerate that kind of negligence with their toaster or with their TV. But the industry has been conditioned to tolerate it with software.
We're trying valiantly to be different in our department. Warning: we're not remotely perfect on what I'm going to talk about here. But this is why we have this principle listed: so that we can put it in the forefront of our department's focus.
Good software development starts with understanding one's customer. This can be quite a difficult endeavor. One can always question who the customer is: Is it the Product Manager requesting the solution or feature? Is it his management? Is it the end-user using the feature(s)? And what do we do when priorities conflict among those three. This is a continual struggle for us.
We're doing a couple of things to help with this problem and to better understand our customers.
1) We're dedicating development resources to customers (or portfolios of customers who have similar businesses). We don't actually change the reporting relationship of those developers, moving them to those departments. Not moving them allows us to keep the ability to have a career path and to create centers of excellence in development methodologies, good coding & qa practices, etc. But we leave developers focused on a customer from one project to the next. Critical context is retained as developers continue to understand a customer deeper and deeper.
2) We're dedicating infrastructure generalists to customers so that customers don't have to wade through the technical silos that infrastructure specialization demands.
3) We're designing iteratively, relying on prototypes. This allows us to have a great idea of what the customer is looking for before we ever start coding heavily.
4) We engage users in testing. We try to take each iteration from our dev environments, through test and staging and into production each milestone. We then ask our users (or subsets of our users) to help us test the bits.
5) We test internationally. This is a hard mindset to change for us. Because the development team is in the U.S., it's easy sometimes to think of the international areas last. We're trying to change that and simultaneously design and ship our solutions in the U.S. and at least a couple of other countries simultaneously. We can't always do it all of the time, but we're doing better at doing a few simultaneously to make sure we iron out localization bugs.
6) We're trying to focus on "listening." It's easy for engineers to be arrogant--to think we know better than others. But that can't be the case. We have to listen or we can't really understand what problems we (and our customers) are trying to solve. Some of the times we have to listen "between the lines," so to speak, where a customer knows that something is wrong, but they aren't quite sure what it is--or what the solution might be. This is an art we practice.
I know it sounds cliche--that we need to "know our customers," but it's a focus that we've needed in our department and one that we're improving upon.
I'm an engineer; or I was formerly one. Well at least I used to write code for a living. And that gives me insight into a secret engineering credo: we are our own customers!
You see proof of this secret all over the software you use.
Example 1: You click on a button and receive an error message like the following: Function lpzWinRandomFunction returned 0xfe02facd.
Example 2: What should be simple functions (like mail merge) in popular software programs actually require end-users to write "code" in order to get them to work properly (e.g. if/then/else statements, db queries, formatting).
Example 3: Features which have major bugs are left in the software with the excuse that: "It doesn't happen all that often--and the user can just re-start or re-boot. No big deal..."
This kind of stuff is infuriating. It's why software development gets such a bad reputation. Consumers don't tolerate that kind of negligence with their toaster or with their TV. But the industry has been conditioned to tolerate it with software.
We're trying valiantly to be different in our department. Warning: we're not remotely perfect on what I'm going to talk about here. But this is why we have this principle listed: so that we can put it in the forefront of our department's focus.
Good software development starts with understanding one's customer. This can be quite a difficult endeavor. One can always question who the customer is: Is it the Product Manager requesting the solution or feature? Is it his management? Is it the end-user using the feature(s)? And what do we do when priorities conflict among those three. This is a continual struggle for us.
We're doing a couple of things to help with this problem and to better understand our customers.
1) We're dedicating development resources to customers (or portfolios of customers who have similar businesses). We don't actually change the reporting relationship of those developers, moving them to those departments. Not moving them allows us to keep the ability to have a career path and to create centers of excellence in development methodologies, good coding & qa practices, etc. But we leave developers focused on a customer from one project to the next. Critical context is retained as developers continue to understand a customer deeper and deeper.
2) We're dedicating infrastructure generalists to customers so that customers don't have to wade through the technical silos that infrastructure specialization demands.
3) We're designing iteratively, relying on prototypes. This allows us to have a great idea of what the customer is looking for before we ever start coding heavily.
4) We engage users in testing. We try to take each iteration from our dev environments, through test and staging and into production each milestone. We then ask our users (or subsets of our users) to help us test the bits.
5) We test internationally. This is a hard mindset to change for us. Because the development team is in the U.S., it's easy sometimes to think of the international areas last. We're trying to change that and simultaneously design and ship our solutions in the U.S. and at least a couple of other countries simultaneously. We can't always do it all of the time, but we're doing better at doing a few simultaneously to make sure we iron out localization bugs.
6) We're trying to focus on "listening." It's easy for engineers to be arrogant--to think we know better than others. But that can't be the case. We have to listen or we can't really understand what problems we (and our customers) are trying to solve. Some of the times we have to listen "between the lines," so to speak, where a customer knows that something is wrong, but they aren't quite sure what it is--or what the solution might be. This is an art we practice.
I know it sounds cliche--that we need to "know our customers," but it's a focus that we've needed in our department and one that we're improving upon.
Amazing People
Tadd Giles and I have worked together for nearly 10 years. Tadd has always been a passionate man with bundles of infectious energy. He's purely amazing. He now manages the interaction design team for the Church.
When I first met him and hired him to come join a new group I was going to be managing he was a large man. When I saw him a couple of months later on his first day on the new job, he had become an exercize and "eating right" machine, and had shed many pounds.
Fast forward to today. Somewhere along the way he fell into old habits or whatever and put a few pounds back on. So what does Tadd do?
Tadd has started a contest he calls "Win a Shuffle." He will weigh himself on 12/31/06. He invites his co-workers, family and friends to do the same. He will then weigh himself on 3/31/07. Tadd will personally buy an ipod shuffle for anyone who loses more weight (as a percentage of total body weight) than Tadd during that period.
?!
You read correctly. Over 70 people and counting have signed up so far. This is amazing to me on so many counts. First, Tadd will probably win. He's just that determined. Second, he's not requiring anyone to weigh themselves in front of him. He's just trusting in people's good will. Third, he's willing to put his money where his mouth is, and it could frankly end up being a whole lotta money. Fourth, he has inspired many people to join him; and those people will lose weight along with him. If he wins, he wins! If he loses, he still wins!! That kind of inspiration is flat-out inspirational to me. He's even created a simple web site to track progress so everyone can help encourage one another. I love it! Finally, his creativity and charisma are astounding. Yes, he got the idea from the show The Biggest Loser, but who comes up with implementing the same idea in his own company with his own peers with a web site and a cash-out-of-his-own-pocket prize? Answer? Tadd.
I'm sorry. This has really nothing to do with technology at the Church. But I thought I'd share because I think it's pretty cool. Go Tadd! And go everyone who is joining in the endeavor!
Comments
Wow. The response to the blog has been outstanding. I knew there were many interested in technology at the Church, but I didn't realize the interest would pick up this quickly.
I'm moderating the comments personally initially so I'm inundated. I'll try to answer the questions as I can. Forgive me if I'm slow. :)
I'll probably be a little more selective when I turn comments on so as not to encourage feedback in cases where I won't have time to answer.
Thanks so much for your interest!
I'm moderating the comments personally initially so I'm inundated. I'll try to answer the questions as I can. Forgive me if I'm slow. :)
I'll probably be a little more selective when I turn comments on so as not to encourage feedback in cases where I won't have time to answer.
Thanks so much for your interest!
2: Receive Revelation
I call down the Lord's help in doing my work to aid in exalting the human family.
This is the second of the attributes we use to describe the culture we want to embrace at the Church's I.T. department.
We work for the Church which means we work for the Lord. We believe we have the right to call on him to help guide us in our work. And we do it. We start many meetings with prayer. Each Monday morning our I.T. leadership staff meeting begins with a "spirited" hymn, a prayer and a spiritual thought. We often have general authority devotionals in our all-hands meetings where we have opportunities to be instructed and to receive inspiration.
There is ample opportunity to receive revelation in an environment rich with spiritual nutrients. It's one of the great blessings of working at the Church, though it has taken some getting use to on my part.
NOTE: I originally referred to the Church's environment as being "rich in spiritual fertilizer" but some of my staff thought that was probably inappropriate. :)
This is the second of the attributes we use to describe the culture we want to embrace at the Church's I.T. department.
We work for the Church which means we work for the Lord. We believe we have the right to call on him to help guide us in our work. And we do it. We start many meetings with prayer. Each Monday morning our I.T. leadership staff meeting begins with a "spirited" hymn, a prayer and a spiritual thought. We often have general authority devotionals in our all-hands meetings where we have opportunities to be instructed and to receive inspiration.
There is ample opportunity to receive revelation in an environment rich with spiritual nutrients. It's one of the great blessings of working at the Church, though it has taken some getting use to on my part.
NOTE: I originally referred to the Church's environment as being "rich in spiritual fertilizer" but some of my staff thought that was probably inappropriate. :)
New LDS Newsroom Web Site
Last night we went live with a refresh of the Church newsroom web site. The old one is here, and the new one is here.
This is an example of a complete re-write of a web site with new technology, new content and a new supporting content management process. This solution took only a few months and, going forward, requires no development to update content.
The audience of the web site is "news media, opinion leaders and the public."
We're still working on a few bugs so be patient with us.
This is an example of a complete re-write of a web site with new technology, new content and a new supporting content management process. This solution took only a few months and, going forward, requires no development to update content.
The audience of the web site is "news media, opinion leaders and the public."
We're still working on a few bugs so be patient with us.
Book Club: Leadership and Self-Deception
I've just started reading Leadership and Self-Deception, Arbringer Institute. Has anyone read it? If so, I invite your comments. If not, grab a copy and join me in reading it!
Subscribe to:
Posts (Atom)