Some tips for leadership mentoring
People ask me for all sorts of tips on leadership mentoring. How do you get someone to magically make good organizational leadership decisions because you think they have management/leadership potential? Many managers simply hand the person a management job and see what they can do. I've found that that works in very few cases. There are some alternatives. Here are some of mine:
1) Force potential managers to make tough decisions when they don't have to and when the pressure is off. If they can start to see how to make good decisions in this way, they'll make good decisions when the pressure is on.
Here's something I like to do (straw man example): The CEO or COO asks me for advice on a thorny personnel issue or operating decision. The COO sends me an email with some background and the question. I read it, think about it and come to my own conclusion/decision. Then I call in someone that I'm "mentoring" to be a tech leader and say, "Read this and tell me what you think and what you'd do." If I think they're a little off, I say, "Well what about x-factor? How does that impact your thinking?" And push on them. In this way they begin to see management level information, and understand how decisions get made at that level and what orthogonal things they need to look at to make good decisions.
Caveat a) Make sure that your management peers or bosses (COO/CEO in the example) know that you're mentoring these people and that you have complete confidence that the information will remain in confidence. I suspect you shouldn't be mentoring them if that's not the case.
Caveat b) Be prepared to change your own mind. Occasionally someone comes up with an answer out of left field that I hadn't thought of, and it's better than what I had come up with. Get over your ego, discuss that with the mentee, tell them good job and that his/her idea will be the one to run with. If you feel comfortable with it, get your mentee exposure for the idea. I have on occasion told the original asker, "Well, I decided to discuss it with Josh, and he came up with X. I think it's a great idea and concur."
2) Push on people in odd leadership positions. One of my favorite things to do is to tell a development team (that I've recently begun managing) that we're going to have rotating team leads. Maybe one person per quarter, or more usually I have one developer as team lead for the duration of a project.
Developers invariably ask me for a well defined set of guidelines clearly defining "team lead." Don't be tempted here. I generally drive them nuts by giving them a very loose definition: "Manages x, coordinates with me, etc." I do this on purpose. I understand that it's a little frustrating, but I want to see what the individual team leaders come up with. I want to see how expansive they'll be in the role. Most people are somewhat smart (if not, then why are they working for you?). Given that, they often come to me with issues to work out before deciding them, and I can help them figure it out rather than correct a bad decision after. Of course I encourage them to do this before they start. Also of course, I watch carefully and nudge when someone needs nudging.
Give people an out. Not everyone is cut out for organizational leadership roles. Tell them that they don't have to do it and that there are no penalties for declining. I've had very few of these, but some people want to be high quality contributors, and some people want to be "field" leaders rather than organizational ones. Ye olde square peg...
More to the point, I almost always learn a great deal about each person. I've found that few people when thrust into a team lead position, operate exactly as I had expected. I've had team leads that were the quietest, most shy people turn into big time jokesters. People I thought were probably worthy of being fired were suddenly stars. More importantly, we all see new valuable leadership skills come from nowhere. The team members see these from their peers and sometimes incorporate or reject these styles and ideas. Almost everyone becomes either a better team member or team leader in this process.
3) Get odd with exercise: One thing I've found works great with younger organizations is do some mental stuff that gets people out of what they perceive is their job. At the Open Source Lab, we had weekly brain teasers and exercises that I put together just to see what happens. One week it was, "Explain Hemi engine type and its valve setup to the team." Another was, "Debate the pros and cons of outsourcing from organizational and economic perspectives." Stuff like that. Some people I thought were sub par employees turned out great and I learned that they were probably in the wrong place and also had real leadership potential.
Anyway, this list is by no means exhaustive. I've seen lots of things that other managers have done with varying success. Find ways to get people leadership skills before you give them leadership jobs. If they are already there, then mentor them. But usually just throwing someone in the pool is a bad recipe.
And for all of us blowhards out there: No campy stuff. Skip the trust falls.
1) Force potential managers to make tough decisions when they don't have to and when the pressure is off. If they can start to see how to make good decisions in this way, they'll make good decisions when the pressure is on.
Here's something I like to do (straw man example): The CEO or COO asks me for advice on a thorny personnel issue or operating decision. The COO sends me an email with some background and the question. I read it, think about it and come to my own conclusion/decision. Then I call in someone that I'm "mentoring" to be a tech leader and say, "Read this and tell me what you think and what you'd do." If I think they're a little off, I say, "Well what about x-factor? How does that impact your thinking?" And push on them. In this way they begin to see management level information, and understand how decisions get made at that level and what orthogonal things they need to look at to make good decisions.
Caveat a) Make sure that your management peers or bosses (COO/CEO in the example) know that you're mentoring these people and that you have complete confidence that the information will remain in confidence. I suspect you shouldn't be mentoring them if that's not the case.
Caveat b) Be prepared to change your own mind. Occasionally someone comes up with an answer out of left field that I hadn't thought of, and it's better than what I had come up with. Get over your ego, discuss that with the mentee, tell them good job and that his/her idea will be the one to run with. If you feel comfortable with it, get your mentee exposure for the idea. I have on occasion told the original asker, "Well, I decided to discuss it with Josh, and he came up with X. I think it's a great idea and concur."
2) Push on people in odd leadership positions. One of my favorite things to do is to tell a development team (that I've recently begun managing) that we're going to have rotating team leads. Maybe one person per quarter, or more usually I have one developer as team lead for the duration of a project.
Developers invariably ask me for a well defined set of guidelines clearly defining "team lead." Don't be tempted here. I generally drive them nuts by giving them a very loose definition: "Manages x, coordinates with me, etc." I do this on purpose. I understand that it's a little frustrating, but I want to see what the individual team leaders come up with. I want to see how expansive they'll be in the role. Most people are somewhat smart (if not, then why are they working for you?). Given that, they often come to me with issues to work out before deciding them, and I can help them figure it out rather than correct a bad decision after. Of course I encourage them to do this before they start. Also of course, I watch carefully and nudge when someone needs nudging.
Give people an out. Not everyone is cut out for organizational leadership roles. Tell them that they don't have to do it and that there are no penalties for declining. I've had very few of these, but some people want to be high quality contributors, and some people want to be "field" leaders rather than organizational ones. Ye olde square peg...
More to the point, I almost always learn a great deal about each person. I've found that few people when thrust into a team lead position, operate exactly as I had expected. I've had team leads that were the quietest, most shy people turn into big time jokesters. People I thought were probably worthy of being fired were suddenly stars. More importantly, we all see new valuable leadership skills come from nowhere. The team members see these from their peers and sometimes incorporate or reject these styles and ideas. Almost everyone becomes either a better team member or team leader in this process.
3) Get odd with exercise: One thing I've found works great with younger organizations is do some mental stuff that gets people out of what they perceive is their job. At the Open Source Lab, we had weekly brain teasers and exercises that I put together just to see what happens. One week it was, "Explain Hemi engine type and its valve setup to the team." Another was, "Debate the pros and cons of outsourcing from organizational and economic perspectives." Stuff like that. Some people I thought were sub par employees turned out great and I learned that they were probably in the wrong place and also had real leadership potential.
Anyway, this list is by no means exhaustive. I've seen lots of things that other managers have done with varying success. Find ways to get people leadership skills before you give them leadership jobs. If they are already there, then mentor them. But usually just throwing someone in the pool is a bad recipe.
And for all of us blowhards out there: No campy stuff. Skip the trust falls.
Categories: Leadership, Main
Rules 3, 4, and 5
Rules 3, 4, and 5 are a block.
3) Take care of the people who work for you. The Team comes first.
4) Take care of the user/customer.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last.
They sound mostly self-explanatory. They are. But the order is important.
3) Take care of your team: This goes equally for members of the team as for blowhards. Team members must look out for each other, and sometimes to the exclusion of other important things. Most managers hate this, but if you want team cohesion, taking care of a teammate is more important than taking care of something the boss wants. This one can be tough for even the most magnanimous managers. But if you really want to have a great team, get over yourself. If a team wants to take a half day to help a team member move when the manager wants to do something else like have some stupid trust falls, or read Steven Covey in a circle while quietly saying, "Namaste," your best bet is on the moving. And then go burn your Steven Covey books. I'm just kidding. Sort of.
4) Take care of the customer: Again it's obvious, but also the order is messaging in itself. The team comes first. You need a good team to take care of the customer. A cohesive team works together to nail customer needs. Period. Some blowhards' first instinct is that "the customer always comes first." Well, if you haven't got a good team, the customer gets crap.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last: At the end of the day, you are an organization that needs the team's skills, and the cohesiveness of the team. Usually executing well on 3 and 4 require little execution for rule 5. But sometimes you have to do rule 5 stuff too. But it's last. We'll call it Jason's Heirarchy of Corporate Needs. Except instead of that really important stuff like Physiology, Safety, Love, it's Team, Customer, Blowhards. And no, just reading Steven Covey and doing trust falls to please your boss doesn't count.
Distinction: "The people you work for" is not just about the blowhards/bosses. It's also about the company as a whole. The fuzziness is intentional to be broad enough to cover both.
For the aspiring blowhards: Team rule three is critical. Make sure your team feels truly taken care of from their peers (no backbiting, politics, etc) and from their managers (no backbiting, politics, etc). Keep your teams from getting depth charged. If customers are unruly, ask the customers to deal with you directly. This isn't that hard, but it seems to be one of the leadership functions most massively missed in today's corporate culture.
This is directly in support of Rules 1 and 2. Content and effective.
3) Take care of the people who work for you. The Team comes first.
4) Take care of the user/customer.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last.
They sound mostly self-explanatory. They are. But the order is important.
3) Take care of your team: This goes equally for members of the team as for blowhards. Team members must look out for each other, and sometimes to the exclusion of other important things. Most managers hate this, but if you want team cohesion, taking care of a teammate is more important than taking care of something the boss wants. This one can be tough for even the most magnanimous managers. But if you really want to have a great team, get over yourself. If a team wants to take a half day to help a team member move when the manager wants to do something else like have some stupid trust falls, or read Steven Covey in a circle while quietly saying, "Namaste," your best bet is on the moving. And then go burn your Steven Covey books. I'm just kidding. Sort of.
4) Take care of the customer: Again it's obvious, but also the order is messaging in itself. The team comes first. You need a good team to take care of the customer. A cohesive team works together to nail customer needs. Period. Some blowhards' first instinct is that "the customer always comes first." Well, if you haven't got a good team, the customer gets crap.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last: At the end of the day, you are an organization that needs the team's skills, and the cohesiveness of the team. Usually executing well on 3 and 4 require little execution for rule 5. But sometimes you have to do rule 5 stuff too. But it's last. We'll call it Jason's Heirarchy of Corporate Needs. Except instead of that really important stuff like Physiology, Safety, Love, it's Team, Customer, Blowhards. And no, just reading Steven Covey and doing trust falls to please your boss doesn't count.
Distinction: "The people you work for" is not just about the blowhards/bosses. It's also about the company as a whole. The fuzziness is intentional to be broad enough to cover both.
For the aspiring blowhards: Team rule three is critical. Make sure your team feels truly taken care of from their peers (no backbiting, politics, etc) and from their managers (no backbiting, politics, etc). Keep your teams from getting depth charged. If customers are unruly, ask the customers to deal with you directly. This isn't that hard, but it seems to be one of the leadership functions most massively missed in today's corporate culture.
This is directly in support of Rules 1 and 2. Content and effective.
Categories: Leadership, Main
Cloud Storage Application Quadrant
What? Yet another storage quadrant? We already got at least one each from all storage analysts we know: the truly independent ones, the supposedly independent ones ... and the other ones as well.
Most of those quadrants do have a common trait, however. They all focus on vendors, their capability, their technology, their maturity, and quite frequently their wallet. Yet that isn't necessarily going to help prospective customers move forward in the positioning, understanding and ultimately practical use of cloud storage for their applications.Why can't we - just for once - try to look at things through customers eyes, as they are wading through tons of cloudy propositions trying to sort out what infrastructure they need for the apps they'd like to deploy?
At Caringo we've been using the following graphic a lot within our presentation materials. It presents the three basic functional areas that CAStor, as content storage infrastructure, is involved in. As a matter of fact, any content storage platform will need to get involved with these.Now let's just bend this graphic a bit, first to this:
... and then this:
Voilà! Instant quadrant, showing the access and tiering expanse used (or required) by an application. To demonstrate the concept, let's map a few actual application areas, including a couple Caringo reference accounts.
The Swedish National Music Collections are tasked with the (indefinite!) preservation of all Swedish music related documents and recordings. They use CAStor as a general purpose archive, which is easily drawn on the quadrant as covering both shared and public access to a certain degree, covering secondary and protection (back up and/or archiving) tiers. (http://www.smus.se)
The Johns Hopkins University Center for Inherited Disease research archives genomic sequencer information while keeping it available to researchers. Shared access, most of three tiers. Easy! (http://www.caringo.com/customer_jhu.html)
Looking at a couple more private applications: Mozy is an EMC owned, internet cloud based personal backup service, which is easily identified as private access, protection tier. Caringo's own CloudFolder is an HSM client moving inactive files off the local hard disk into a CAStor private cloud. When the disk or the machine is lost, it can also go recover the files, so it spans both the secondary and protection tiers.
In general, enterprise email archiving has both a private and a shared access aspect to it (compliance may require centralized email search), it offloads email servers so it is a secondary tier, while safeguarding it as well (protection tier).
Summarizing, what we're trying to accomplish here is to lay out applications on top of two essential dimensions of a cloud storage infrastructure to get a better intuitive understanding of the infrastructural requirements.
Why don't you try to model your own applications on here in relationship to their underlying storage. Does it make sense? Tell us about it!
Because your reflections and opinions - as always - are most appreciated.
-- Paul
Most of those quadrants do have a common trait, however. They all focus on vendors, their capability, their technology, their maturity, and quite frequently their wallet. Yet that isn't necessarily going to help prospective customers move forward in the positioning, understanding and ultimately practical use of cloud storage for their applications.Why can't we - just for once - try to look at things through customers eyes, as they are wading through tons of cloudy propositions trying to sort out what infrastructure they need for the apps they'd like to deploy?
At Caringo we've been using the following graphic a lot within our presentation materials. It presents the three basic functional areas that CAStor, as content storage infrastructure, is involved in. As a matter of fact, any content storage platform will need to get involved with these.Now let's just bend this graphic a bit, first to this:
... and then this:
Voilà! Instant quadrant, showing the access and tiering expanse used (or required) by an application. To demonstrate the concept, let's map a few actual application areas, including a couple Caringo reference accounts.
The Swedish National Music Collections are tasked with the (indefinite!) preservation of all Swedish music related documents and recordings. They use CAStor as a general purpose archive, which is easily drawn on the quadrant as covering both shared and public access to a certain degree, covering secondary and protection (back up and/or archiving) tiers. (http://www.smus.se)
The Johns Hopkins University Center for Inherited Disease research archives genomic sequencer information while keeping it available to researchers. Shared access, most of three tiers. Easy! (http://www.caringo.com/customer_jhu.html)
Looking at a couple more private applications: Mozy is an EMC owned, internet cloud based personal backup service, which is easily identified as private access, protection tier. Caringo's own CloudFolder is an HSM client moving inactive files off the local hard disk into a CAStor private cloud. When the disk or the machine is lost, it can also go recover the files, so it spans both the secondary and protection tiers.
In general, enterprise email archiving has both a private and a shared access aspect to it (compliance may require centralized email search), it offloads email servers so it is a secondary tier, while safeguarding it as well (protection tier).
Summarizing, what we're trying to accomplish here is to lay out applications on top of two essential dimensions of a cloud storage infrastructure to get a better intuitive understanding of the infrastructural requirements.
Why don't you try to model your own applications on here in relationship to their underlying storage. Does it make sense? Tell us about it!
Because your reflections and opinions - as always - are most appreciated.
-- Paul