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