Notes from the recent Engineering Leadership SIG Meeting, November 18, 2010.
Tools for Team: A Panel Discussion on Collaborative Tools for Product Development
Co-Moderators: Ron Lichty & Tam Nguyen
Panelists: Sasha Ovsankin, Sandeep Jain, Chris Lunt, David Etheridge
Introduction by Tam Nguyen
Short presentation by Steve of Agile Learning Labs – note that there is a CSM course this weekend – with Chris Sims
Panel (see full names above)
Sasha is with a medical imaging startup
Chris is VP-Engineering with ReadyForce, his 8th startup
Sandeep’s focus is on productivity
David is working on Enterprise rollout
Ron: It’s hard not to be regretful after acquiring a tool and rolling it out, isn’t it?
Poll of audience: tools of interest?
Requirements management; project management, bug tracking, document management, lifecycle management, Agile support tools, defect/requirements tracking (customer-facing), adoption analytics, compliance (quality/conformance), wireframing, code review tools / 3-way merge tool, architecture / design patterns, code metrics, web conferencing
Question A: Creating Requirements and Selection Criteria
How do you know what you’re looking for?
Chris: ask peers, people I trust
Sandeep: it varies by stage (of the development group & company)
Sasha: transparency – “it just works”; allows everyone to see all the data;
Enjoyable to use
Sandeep: minimize overhead for developer
Sasha: input should be where the information happens
[discussion of whether these tools are “collaborative” tools]
Requirements-related tools ---
David: written requirements … Engineering response to PRD – the manager or leader has to break it down into sentences, then link tasks to each one;
It requires a human to understand the requirements!
Sasha: … and requires agreement by multiple groups
Selection: consensus – try it out; find an advocate who sells it to the team
The panel is generally in favor of SAAS, rather than on-premises servers/services
Question B: Adoption – How does adoption fail?
Chris: need cross-functional support (e.g., Product Management)
What are key success factors?
David: no greater burden than today (for users)
Ron: intersection between team & company vs. tools? Q: a lot of contractors with backgrounds using different tools – how to deal with this?
Sasha: has to be easy to learn / use
Chris: assign a peer to help the contractor get integrated with team & tools
Sandeep: embed the process in the tools
David: (regarding “resistance”) I make an agreement with my engineers: you enter (task) data, and I will deal with the upper management demands [on your time]
Question C: Favorite tools / recommended tools
Sasha: Pivotal Tracker; Freemind (mind mapping);
Tam: Xmind (mind mapping)
Chris: TRAC – wiki / source browser; (Redmine – not as good); GIT (but it doesn’t move back in time so well); Selenium (web testing)
Sandeep: SWplanner / HP Quality Center; Perforce; TeamTrack
David: Jira + Subversion, Bamboo, Crucible, Fisheye, Bugzilla + Yahoo Sprint Mgr
Audience questions
(Note: the audience had no major users of Rally Agile tools, Sprint 360)
(Cooperation tools, like wikis, blogs: wiki – about 50% use them; blogs – about 6 people out of 50 in the audience)
Sasha: continuous integration – an important part of Agile;
[unknown]: get Product Managers to write acceptance criteria
David: described using a Plan of Record (vs. PRD and Engineering response); tell executives “let them [engineers] solve puzzles” and get out of the way; if the PRD is too detailed, they will get passive-aggressive on you.
Much agreement from the audience on having seen PRDs that said too much about what to build (and how), rather than what function is to be delivered
--------------------------------------------------------------
John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.
John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010. http://bit.ly/9pX1wS
For more information, please visit his website at http://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.
More...
Sunday, December 5, 2010
Thursday, November 18, 2010
Action is what manifests a choice amongst infinite possibilities [Corinne Rattay]
I listen a lot to people in leadership positions, many of them being senior management in high-tech companies. What they tell me are stories of lack of empowerment, of how they "felt stuck" between "too clear" directions from a powerful GM, CTO or CEO and, on the other side, their Engineering organizations, remote or local. I'm borrowing some of their words here.
In fact, these senior Engineering leaders knew what wasn't working and what needed to happen to move their teams out of burnout, general frustration or acceptance of mediocrity. I'm sure you have experienced or seen situations such as this one. Their main problem was the same as what we see in nature all the time. Things remain as they are for usually a very long time until, one day, something new happens. A different idea, a new concept, a quantum leap. Who knows what I'm talking about?
We've noticed that quantum leaps happen as soon as a "catalyst" comes into play. I won't go into the details whether the catalyst is purely passive (as in a chemical reaction) or on the contrary very active inside the company into which he or she was brought in by the senior Engineering leader who finally has had the courage to step up and yell, at least in his or her imagination, "enough is enough, things have to change now!".
The truth is that action is what manifests a choice. Our world is a wonderful creation of infinite possibilities. As Albert Einstein had already taught us so well about the relativity of all things, even of time and space, I firmly believe that there is no absolute right or wrong. Everything must be seen from one or another perspective and it is futile to look for an absolute or so called "objective" perspective. Out of all the possibilities of how situations can evolve, humans have a tendency of wishing for a change in one way or another. Let's call it a "desire".
There's nothing wrong with having desires, actually this is a good thing since doing so drives imagination. And "imagination is more important than knowledge", as was adequately remarked by Albert Einstein also a long time ago.
So what is the key message to understand here? It is that action, yes, even a simple little action, done consistently from this moment onward, is the first step of manifesting a choice and moving towards a desire which we have. It's that simple: nothing changes from knowledge or imagination alone, but it is action that sets things apart.
The moment that we decide to act despite fear rather than waiting for the fear to go away or for the right moment to come (trust me it never will), this is when we set change into motion. What is it that you as a leader would like to change, specifically, and what are you waiting for?
------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
In fact, these senior Engineering leaders knew what wasn't working and what needed to happen to move their teams out of burnout, general frustration or acceptance of mediocrity. I'm sure you have experienced or seen situations such as this one. Their main problem was the same as what we see in nature all the time. Things remain as they are for usually a very long time until, one day, something new happens. A different idea, a new concept, a quantum leap. Who knows what I'm talking about?
We've noticed that quantum leaps happen as soon as a "catalyst" comes into play. I won't go into the details whether the catalyst is purely passive (as in a chemical reaction) or on the contrary very active inside the company into which he or she was brought in by the senior Engineering leader who finally has had the courage to step up and yell, at least in his or her imagination, "enough is enough, things have to change now!".
The truth is that action is what manifests a choice. Our world is a wonderful creation of infinite possibilities. As Albert Einstein had already taught us so well about the relativity of all things, even of time and space, I firmly believe that there is no absolute right or wrong. Everything must be seen from one or another perspective and it is futile to look for an absolute or so called "objective" perspective. Out of all the possibilities of how situations can evolve, humans have a tendency of wishing for a change in one way or another. Let's call it a "desire".
There's nothing wrong with having desires, actually this is a good thing since doing so drives imagination. And "imagination is more important than knowledge", as was adequately remarked by Albert Einstein also a long time ago.
So what is the key message to understand here? It is that action, yes, even a simple little action, done consistently from this moment onward, is the first step of manifesting a choice and moving towards a desire which we have. It's that simple: nothing changes from knowledge or imagination alone, but it is action that sets things apart.
The moment that we decide to act despite fear rather than waiting for the fear to go away or for the right moment to come (trust me it never will), this is when we set change into motion. What is it that you as a leader would like to change, specifically, and what are you waiting for?
------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
Sunday, October 31, 2010
Soliciting Engineering Leadership Horror Stories [Robert Lasater]
Today being Halloween, we are soliciting Engineering Leadership Horror Stories. We'd like your scariest, most frightening experiences as an engineering leader.
There are several caveats. Your story must have some edifying or redeeming quality. We are not soliciting gripe fests or posts that just slam coworkers.
Here are some suggestions for what we would like to see. Maybe you were able to take that terrifying situation and transform it into something at least somewhat positive. Or maybe the situation was too far gone to salvage, but you have insights into how to recognize (and prevent) something similar.
Also, because your story may be sensitive, we would welcome anonymous posting. However an anonymous posting will require a lengthier review process. So if you request anonymity, give us a few days to post your submission.
Please email your Engineering Leadership Horror Stories to rlasater@hotmail.com. We accept Word documents, HTML text and simple text files.
And as always, we reserve the right to edit, modify or even not accept proposed posts.
---------------------------------------------------------------
Robert Lasater maintains the blog for theEngineering Leadership Special Interest Group of the SD Forum.
More...
There are several caveats. Your story must have some edifying or redeeming quality. We are not soliciting gripe fests or posts that just slam coworkers.
Here are some suggestions for what we would like to see. Maybe you were able to take that terrifying situation and transform it into something at least somewhat positive. Or maybe the situation was too far gone to salvage, but you have insights into how to recognize (and prevent) something similar.
Also, because your story may be sensitive, we would welcome anonymous posting. However an anonymous posting will require a lengthier review process. So if you request anonymity, give us a few days to post your submission.
Please email your Engineering Leadership Horror Stories to rlasater@hotmail.com. We accept Word documents, HTML text and simple text files.
And as always, we reserve the right to edit, modify or even not accept proposed posts.
---------------------------------------------------------------
Robert Lasater maintains the blog for theEngineering Leadership Special Interest Group of the SD Forum.
More...
Tuesday, October 12, 2010
True Win-Win Commitment [Corinne Rattay]
In business, people often claim their willingness to offer win-win deals. Whether you're in the market for buying a new car as a consumer as I did last week, or whether you're interested in a specific solution or service from a preferred vendor when you're acting in your professional role, the words of "win-win" sound pretty good, even reassuring in a way. But let me ask you, what is a true win-win commitment according to you, really?
Maybe the question to ask ourselves first is why would anyone want to pursue anything else, such as win-lose or even lose-lose alternatives. I've seen many cases like these and I'm sure so have you. And, in all sincerity, I've probably occasionally acted in such less noble ways, unconsciously or even consciously. We are all on a path towards continual improvement and growth, aren't we after all?
I'd like to get concrete at this point. With our focus on Engineering Leadership what could this situation look like, if I may borrow a real-life case?
Let's say a company's executive team has the dilemma of needing to please a major customer generating $500 million of revenue this year and being requested to add a few vital software features into its current software release due next month. The release without those features is eagerly expected by a large percentage of the company's customer base and is on schedule to function according to expectations. The account team has just informed the GM and EVP that this major customer can only effectively deploy the release with these client-specific features due to certain late discoveries. Furthermore a significant portion of the projected revenue can only be recognized with general-availability software releases which are accepted as functional by the major customer. Sounds familiar?
If you have lived or are living in this kind of environment, some first thoughts may storm through your mind right now.
As a Product Manager your focus will be on initial software requirements coming from the customer and the account team. As VP of Engineering you are worried about the impact of last-minute code additions in sensitive parts of the software and the inability to perform full screening on the modified code. As Regional VP of Sales your concern is your major customer's success and continued business if the features don't make it into this release or if the software turns out to be defective with the additional features. As VP of Operations you are getting headaches but are willing to accommodate within your means regarding the logistical aspects of software distribution. As Program Manager you are seeing an equation now with last minute variables that don't add up with success unless someone puts together a miracle.
If you are a member of the Executive team a few scenarios may come to your mind immediately:
(1) accommodate the major customer, impair all other customers by delaying the release, maintain release quality & predictability of quality
(2) accommodate the major customer, keep the release on time, stretch the Engineering organization, accept reduced predictability of SW quality
(3) release official software on-time, maintain release quality & predictability of quality, work with major customer using additional beta releases in parallel containing these required changes while possibly deferring large revenue projections for your own company to the next fiscal year
(…) and there are more creative ones with the firm understanding that this may only be a one-time exception to the standard process and policies.
Reality, or life in itself, isn't simple. Add to it the wisdom that there is no such thing as a "one-time-only exception" because it will invariably set a new standard for the future inside the company.
So what can this real-life scenario teach us about the topic of a win-win commitment? Why is this concept so crucial in business and even beyond in our personal lives? What is so powerful about the concept of true win-win commitment that people get so attracted to working with other people who make it a habit of practicing this concept? Why does business and money flow so much better in this way?
Over the past eighteen months I've focused extensively on understanding human psychology and leadership in much more advanced and accelerated ways than my previous hi-tech industry leadership experience may have offered me. Healthy humans want to trust and want the other person to be trustworthy. And we would all live in harmony with this idea if many of us hadn't been deceived and over time had derived a world model of scarcity and survival of the fittest. Consider how society in general defines "winning". Whether you look at sports games where we all want to see one team win, this does infer that the other one may need to lose. Isn't this how most people, maybe not you or me, approach life?
Let's come back to our hi-tech company example: should the company's current quarter bottom line win and the executive team decide to implement the custom changes in a rush to keep the projected revenue while shielding obvious process shortcuts from the major customer and everyone else? How may this decision affect the company's reputation once software stability issues are discovered by most customers and they turn out to lose? Should the shareholders lose in the end once the company's reputation has been affected? Should the major customer lose and be blamed for not having specified these additional requirements explicitly? Should the company lose the projected revenue this quarter? Is there really a way that everyone can win in this case?
How do most people make decisions when a win-win deal isn't obvious to all involved parties? May they get emotional and be driven by fear of missing out on a possible gain? What is your personal experience with people you've worked with so far? Some may say "you can't please everybody" and they are certainly right. Some may state that "it would all have been easier if someone had done a better job discovering the issues earlier", effectively pushing responsibility away with blame.
The truth is that there is never an absolute beginning for the appearance of a specific problem. Don't things just unfold naturally until they reach an arbitrary threshold for someone to call it a problem? In life is there really such a thing as perfection? It is my belief that there are just opportunities to grow for the conscious executive and to maintain integrity and hard-earned trust with every single customer, with the various internal teams inside the company and indirectly with the long-term shareholders. His or her role is to be creative while involving true teamwork and openness with the major customer in this case and seek the best for all parties over time.
The readiness to put a significant portion of the projected quarterly revenue at stake when openly approaching the major customer may be the very key ingredient for actually both securing short-term revenue while also gaining incredible future business not even imagined. Add to this the continued trust gained from all customers over the past as well as the long-term gains for the company's shareholders when the executive team continuously meets and exceeds its previously established standards.
If I wanted to summarize I'd say "treat all other people the way you want to be treated even if it may seem at a cost to you. It takes courage, but in the end we all win."
------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
Maybe the question to ask ourselves first is why would anyone want to pursue anything else, such as win-lose or even lose-lose alternatives. I've seen many cases like these and I'm sure so have you. And, in all sincerity, I've probably occasionally acted in such less noble ways, unconsciously or even consciously. We are all on a path towards continual improvement and growth, aren't we after all?
I'd like to get concrete at this point. With our focus on Engineering Leadership what could this situation look like, if I may borrow a real-life case?
Let's say a company's executive team has the dilemma of needing to please a major customer generating $500 million of revenue this year and being requested to add a few vital software features into its current software release due next month. The release without those features is eagerly expected by a large percentage of the company's customer base and is on schedule to function according to expectations. The account team has just informed the GM and EVP that this major customer can only effectively deploy the release with these client-specific features due to certain late discoveries. Furthermore a significant portion of the projected revenue can only be recognized with general-availability software releases which are accepted as functional by the major customer. Sounds familiar?
If you have lived or are living in this kind of environment, some first thoughts may storm through your mind right now.
As a Product Manager your focus will be on initial software requirements coming from the customer and the account team. As VP of Engineering you are worried about the impact of last-minute code additions in sensitive parts of the software and the inability to perform full screening on the modified code. As Regional VP of Sales your concern is your major customer's success and continued business if the features don't make it into this release or if the software turns out to be defective with the additional features. As VP of Operations you are getting headaches but are willing to accommodate within your means regarding the logistical aspects of software distribution. As Program Manager you are seeing an equation now with last minute variables that don't add up with success unless someone puts together a miracle.
If you are a member of the Executive team a few scenarios may come to your mind immediately:
(1) accommodate the major customer, impair all other customers by delaying the release, maintain release quality & predictability of quality
(2) accommodate the major customer, keep the release on time, stretch the Engineering organization, accept reduced predictability of SW quality
(3) release official software on-time, maintain release quality & predictability of quality, work with major customer using additional beta releases in parallel containing these required changes while possibly deferring large revenue projections for your own company to the next fiscal year
(…) and there are more creative ones with the firm understanding that this may only be a one-time exception to the standard process and policies.
Reality, or life in itself, isn't simple. Add to it the wisdom that there is no such thing as a "one-time-only exception" because it will invariably set a new standard for the future inside the company.
So what can this real-life scenario teach us about the topic of a win-win commitment? Why is this concept so crucial in business and even beyond in our personal lives? What is so powerful about the concept of true win-win commitment that people get so attracted to working with other people who make it a habit of practicing this concept? Why does business and money flow so much better in this way?
Over the past eighteen months I've focused extensively on understanding human psychology and leadership in much more advanced and accelerated ways than my previous hi-tech industry leadership experience may have offered me. Healthy humans want to trust and want the other person to be trustworthy. And we would all live in harmony with this idea if many of us hadn't been deceived and over time had derived a world model of scarcity and survival of the fittest. Consider how society in general defines "winning". Whether you look at sports games where we all want to see one team win, this does infer that the other one may need to lose. Isn't this how most people, maybe not you or me, approach life?
Let's come back to our hi-tech company example: should the company's current quarter bottom line win and the executive team decide to implement the custom changes in a rush to keep the projected revenue while shielding obvious process shortcuts from the major customer and everyone else? How may this decision affect the company's reputation once software stability issues are discovered by most customers and they turn out to lose? Should the shareholders lose in the end once the company's reputation has been affected? Should the major customer lose and be blamed for not having specified these additional requirements explicitly? Should the company lose the projected revenue this quarter? Is there really a way that everyone can win in this case?
How do most people make decisions when a win-win deal isn't obvious to all involved parties? May they get emotional and be driven by fear of missing out on a possible gain? What is your personal experience with people you've worked with so far? Some may say "you can't please everybody" and they are certainly right. Some may state that "it would all have been easier if someone had done a better job discovering the issues earlier", effectively pushing responsibility away with blame.
The truth is that there is never an absolute beginning for the appearance of a specific problem. Don't things just unfold naturally until they reach an arbitrary threshold for someone to call it a problem? In life is there really such a thing as perfection? It is my belief that there are just opportunities to grow for the conscious executive and to maintain integrity and hard-earned trust with every single customer, with the various internal teams inside the company and indirectly with the long-term shareholders. His or her role is to be creative while involving true teamwork and openness with the major customer in this case and seek the best for all parties over time.
The readiness to put a significant portion of the projected quarterly revenue at stake when openly approaching the major customer may be the very key ingredient for actually both securing short-term revenue while also gaining incredible future business not even imagined. Add to this the continued trust gained from all customers over the past as well as the long-term gains for the company's shareholders when the executive team continuously meets and exceeds its previously established standards.
If I wanted to summarize I'd say "treat all other people the way you want to be treated even if it may seem at a cost to you. It takes courage, but in the end we all win."
------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
Sunday, October 10, 2010
Magical Thinking and the Zero-Sum Roadmap [Rich Mironov]
Recent conversations at several clients highlight an often-repeated set of magical thinking: beliefs by internal clients that development resources are infinite, and beliefs by product managers that prioritization can convince anyone otherwise. Both are wrong, but seductive. Here goes…
The starting point for this conversation is the typical product roadmap: crammed full of prioritized work and heavily negotiated with the development team. Almost every optional item has been postponed, and there’s still some risk of delay. This is a product plan with no “white space,” no large chunks of unallocated engineering capacity, no slop or slush funds or hidden treasure.
More...
The starting point for this conversation is the typical product roadmap: crammed full of prioritized work and heavily negotiated with the development team. Almost every optional item has been postponed, and there’s still some risk of delay. This is a product plan with no “white space,” no large chunks of unallocated engineering capacity, no slop or slush funds or hidden treasure.
More...
Monday, October 4, 2010
How to become a successful Leader, and how to get started from where I am right now? [Corinne Rattay]
Humans admire successful leaders. From the well-known names of history to specific people in our industry, or maybe even inside the company we are currently working for, there are people we simply admire. If I asked you who holds such a special place for you, at least one person’s name would pop up in your mind within the first 10 seconds, wouldn’t it?
This is the Engineering Leadership Special Interest Group (ELSIG) of the Software Development Forum (SDForum). So I’ve decided to write about leadership, a topic which is very dear to my heart. You’ll understand more once you get to know me.
In my managerial hi-tech career I’ve had to lead teams of over 100 engineers across Silicon Valley, US East Coast and India towards putting out the best possible version of Network Operating Systems under tremendous time and budget pressure. Those of you who are at VP or director level can relate to this. What had never been done before needed to be approached boldly. And I’m sure your responsibilities may even be more challenging and exciting. Yes, excitement is an important driver isn’t it?
Maybe you have dreamed of engaging into a bigger leadership role at your present level in your career, wanting to become a little bit more like some of the inspiring leaders you’ve observed in your industry or company. I have at least, to be completely honest with you. I’ve wanted to become a successful leader myself for a long time. Not necessarily to play at the same level as the ones I admired, but at least become a better leader than I considered myself to be at that time. And I’ve struggled, as you can imagine. So, did that mean that true leadership wasn’t for me?
With your permission let me make in innocent guess here: I could assume that the people who have become successful leaders in our surrounding environment (i.e. company, industry, personal sphere, …) have all had a clear vision, clear goals and somehow were either incredibly skilled or fortunate to be on a path filled with success after success. It somehow looks like it, doesn’t it?
If you’re like me, you may object intellectually that this assumption isn’t reality. So how did these successful leaders get to where they are today? What is it that you or I had to or have to do differently compared to before this moment of decision?
Maybe you are an influential leader already and are merely reading this out of curiosity (which successful leaders typically do) or you are experiencing some resistance at this point in your life and I may simply share with you what I have learned over time which would have made life so much easier for me back then.
The first thing you should know about me is that I’ve made many mistakes and learned greatly from them. The truth is that I didn’t even have a clear vision of what successful leadership was really about. I’m not embarrassed to say today that a few years back I equated “successful” with “me” being successful, with “me” being “significant” (yes, let me cut right to it) in just the ways I saw successful leaders as being people “significant” to me in my eyes.
If I could only share one key insight with you, it would be that I’ve learned that successful leaders don’t focus on their own significance but on the significance and success of what they stand for. What they envision is so much bigger than their individuality in their own eyes. That’s why they succeed in making things so much better for everyone.
Ok, but let’s get back to where you and I may be right now. So can we grow towards the character, charisma and passion that come with the role of a successful leader? Yes, you probably know intellectually that this is indeed a possibility. How to get started though when one doesn’t have a clear vision, clear goals and the necessary skills (yet)?
I’ve learned a few crucial insights through personal experience, which I’d like to share with you in order to assist in whatever way may be useful on your journey if you choose so. In summary the most crucial ones I believe are below:
Skills of course are important also to become a successful leader. The key to really understand here is that they are not what is needed first on this journey. Speaking in front of a large audience, speaking up in a tense meeting and disagreeing for the sake of something bigger at stake, you name it. The truth is that you’ll acquire all the needed skills along your path as I have and am still doing.
In fact, this is a never-ending journey of personal and professional fulfillment once we’ve understood what life really is about.
----------------------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
This is the Engineering Leadership Special Interest Group (ELSIG) of the Software Development Forum (SDForum). So I’ve decided to write about leadership, a topic which is very dear to my heart. You’ll understand more once you get to know me.
In my managerial hi-tech career I’ve had to lead teams of over 100 engineers across Silicon Valley, US East Coast and India towards putting out the best possible version of Network Operating Systems under tremendous time and budget pressure. Those of you who are at VP or director level can relate to this. What had never been done before needed to be approached boldly. And I’m sure your responsibilities may even be more challenging and exciting. Yes, excitement is an important driver isn’t it?
Maybe you have dreamed of engaging into a bigger leadership role at your present level in your career, wanting to become a little bit more like some of the inspiring leaders you’ve observed in your industry or company. I have at least, to be completely honest with you. I’ve wanted to become a successful leader myself for a long time. Not necessarily to play at the same level as the ones I admired, but at least become a better leader than I considered myself to be at that time. And I’ve struggled, as you can imagine. So, did that mean that true leadership wasn’t for me?
With your permission let me make in innocent guess here: I could assume that the people who have become successful leaders in our surrounding environment (i.e. company, industry, personal sphere, …) have all had a clear vision, clear goals and somehow were either incredibly skilled or fortunate to be on a path filled with success after success. It somehow looks like it, doesn’t it?
If you’re like me, you may object intellectually that this assumption isn’t reality. So how did these successful leaders get to where they are today? What is it that you or I had to or have to do differently compared to before this moment of decision?
Maybe you are an influential leader already and are merely reading this out of curiosity (which successful leaders typically do) or you are experiencing some resistance at this point in your life and I may simply share with you what I have learned over time which would have made life so much easier for me back then.
The first thing you should know about me is that I’ve made many mistakes and learned greatly from them. The truth is that I didn’t even have a clear vision of what successful leadership was really about. I’m not embarrassed to say today that a few years back I equated “successful” with “me” being successful, with “me” being “significant” (yes, let me cut right to it) in just the ways I saw successful leaders as being people “significant” to me in my eyes.
If I could only share one key insight with you, it would be that I’ve learned that successful leaders don’t focus on their own significance but on the significance and success of what they stand for. What they envision is so much bigger than their individuality in their own eyes. That’s why they succeed in making things so much better for everyone.
Ok, but let’s get back to where you and I may be right now. So can we grow towards the character, charisma and passion that come with the role of a successful leader? Yes, you probably know intellectually that this is indeed a possibility. How to get started though when one doesn’t have a clear vision, clear goals and the necessary skills (yet)?
I’ve learned a few crucial insights through personal experience, which I’d like to share with you in order to assist in whatever way may be useful on your journey if you choose so. In summary the most crucial ones I believe are below:
- a clear direction you feel compelled moving into will do perfectly in the absence of a fully developed vision; you can refine and make things concrete along the path.
- get in touch with the person you want to become; catch yourself acting like him/her every once in a while and rejoice yourself; be passionate about it.
- getting started is not a matter of skills but of clarity of the path you want to pursue and the level of motivation for yourself; have absolute clarity of why you want to be on this path and what you’ll need to give up if you don’t.
- take one step at a time instead of overwhelming yourself; don’t try to swallow the entire mountain or elephant in one bite; let things unfold, make one thing better than it is today through your own action and keep doing it consistently.
- adopt a “responsibility vs. victim” attitude; whatever happens around you, understand that you still have the freedom of choice of how to respond.
- cultivate your value system; develop integrity, trust and passion for what you do and for the people you’re interacting with
Skills of course are important also to become a successful leader. The key to really understand here is that they are not what is needed first on this journey. Speaking in front of a large audience, speaking up in a tense meeting and disagreeing for the sake of something bigger at stake, you name it. The truth is that you’ll acquire all the needed skills along your path as I have and am still doing.
In fact, this is a never-ending journey of personal and professional fulfillment once we’ve understood what life really is about.
----------------------------------------------------------------------
Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com
More...
Sunday, September 26, 2010
Whose English is it Anyway? [Kimberly Wiefling]
My work takes me from my home in the San Francisco Bay Area, where more than 50% of the people living here don’t speak English at home, to Japan and elsewhere around the world nearly every month. I have the distinct honor and pleasure of working with people from all over the world, and recently had an incredible adventure with 37 people from 12 different countries who all came together as a global team to propose the future direction of their company. It’s an incredible experience to work with such a diverse group, and a heck of a challenge due to the most basic of reasons – we all speak different languages.
Even though all members usually speak some version of “English”, it might as well be Klingon. There’s the traditional British English, and many more, including Australian English, New Zealand English, South African English, Canadian English, English of “the islands”, African English, Singapore English, East Indian English, as well as heavily accented versions of Spanish English, German English, French English, and the worst of the worst – American. Without modifications, or an interpreter, no sustained meaningful communication is possible among these disparate groups.
If you’re a native English speaker, working in a global team, you need to stop speaking English. Stop speaking YOUR English, that is – if you want to understand, and be understood by your colleagues. Delving a bit more deeply into the various versions of the so-called “shared language” called English based on my own personal experience:
Americans – Strictly speaking you don’t speak “English”. You speak “American”. It’s different. Just listen to someone from New Zealand speaking English and you’ll know exactly what I mean. Or catch a couple of idiom-laden blurbs of British English from a person from the UK. You won’t understand what they’re saying, and they’ll be horrified when you start talking about your“fanny pack”.
UK People – For people who didn’t grow up with British English as their native language, no one will have a clue what you mean when you start complaining about the “tallback” that delayed your arrival at work.
East Indian Colleagues – As an American Native English speaker, I reluctantly admit that I can’t understand more than 70% of “Hinglish” because the emPHAsis is on a difFERent sylLAble than I am accustomed to.
Singapore – “Singlish” is musical and beautiful, but – unless I watch your lips every moment, and assure that my attention doesn’t drift in the least – I can only understand about 50% of what you are saying.
Australians – It’s not as bad as listening to someone from Texas or Georgia, but it’s pretty tough to understand you, mates!
New Zealand Colleagues – Really, I get such a headache focusing on what you are saying that it makes the Australian accent seem almost easy to understand. As I mentioned previously, listening to you is not quite as challenging as understanding people from my own country who hail from Texas or Georgia, but it’s pretty darn demanding.
There are other examples, but you get the idea. I don’t want to beat a dead horse (sorry, I couldn’t resist).
The former CEO of ABB, Percy Barnevik, stated that the official language of the company was “bad English”. I almost agree, but I reject the negative connotations of “bad English” in favor of “Global English”. And a CEO of a Korean company advised his people that it’s more important to speak badEnglish than good Korean.
Although I’m sure that most people assume that they are perfectly understandable to others when they speak English (especially my American colleagues!) in my experience they all might as well be speaking entirely different languages. The solution is not to speak English. The solution is for ALL of us to STOP speaking English and START speaking GLOBAL English.
I’m not a linguist, but here’s a few things I’ve learned about effective communications among global teams:
- Do your L.A.P.S.s.s.s!
- Loud – Speak loudly so people can at least receive the soundwaves.
- Attention – Make sure you visually make contact with the person you’re talking with before starting to speak to them. Eye contact varies greatly across cultures, and can be uncomfortable, but is critical to beginning a conversation.
- Pause – Many non-native English speakers are “translating in their head”. Although not ideal, it’s a reality that they will need a few seconds to grock (sorry!) what you said.
- Slow – Speak slowly . . . painfully slowly. Imagine you are speaking in molasses, then slow down even more.
- Simple – Use simple words. Native English speakers use over 5000 different works, but non-native speakers use something like 500 – 1500. Don’t go showing off your vocabulary if you want to be understood.
- Short – Short sentences. No long-winded phraseology, with obscure references to previous clauses.
- Smile – If they can’t understand you, at least they’ll like you!
- No idioms, slang, obscure references.
- Don’t never use no double negatives!
In my experience, it’s not just European, Asian, South American or African people who need to change how they communicate. EVERYONE needs to adopt Global English in order to assure that 21st century global company teams can understand each other.
STOP speaking English. If you are a so-called “native” English speaker, DEFINITELY stop speaking English! START speaking GLOBAL ENGLISH. It’s better for you, it’s better for your colleagues, it’s better for your company, and it’s better for your business profitability.
If we truly are going to realize the dream of a global economy where we collaborate across time zones and cultural boundaries for mutual benefit, we ALL need to change the way we communicate. Let’s not wait for “other people” to change so that it’s easier for us to communicate. Let’s all share the responsibility for improving communication and moving toward a truly global economy.
It’s in ALL of our best interests to make the pie bigger instead of arguing over who gets the crumbs. That win-win scenario begins with speaking a common language, and it's not as easy as just saying "English". It's GLOBAL English. Give it a shot (sorry again!).
Originally published on CareerShorts.com where Kimberly has been invited to contribute blogs periodically on global leadership and project management.
More...
Tuesday, September 21, 2010
Project Manager Meets The Steering Committee [Glen Gage]
Situation: You, the project manager, have just been called to represent your project at the next IT Steering Committee meeting, a meeting that includes the CEO and is held once every three months.
It can be daunting to be called before a group of 'C' levels, VPs and other executives when you aren't used to it. When you are used to it it's even worse because any naive thoughts you may have had of a group making reasoned business decisions based on open dialog and fact have long since evaporated. Steering Committees are some percentage true to their charters and the other percentage a hot bed of corporate politics. The percentages vary from company to company and within companies, from month to month.
Your first thoughts upon receiving the invitation were mixed--pride and fear. Good. Appropriate. The devil on your left shoulder whispered in your ear "Don't worry, it's no big deal. You know what's going on in the project, just relax and go to the meeting. They just want to tell you what a good job you're doing." The angel on your right shoulder whispered "This is a big deal. Get prepared, thoroughly prepared."
The first thing you did right when your manager told you your presence was expected at the next IT Steering Committee meeting was to ask why. When the answer was vague (your manager isn't on the committee) you did the second right thing, you arranged a few minutes with the project's sponsor (who is on the committee) to find out why and ask a number of other questions.
The answer to 'why' might range from "Project Managers are invited randomly so that they get the experience of executive level dialog and exposure to the management team. It is all a part of our employee development program" (not likely) to "This is a critical project and not everyone feels they have a handle on it." (whoops, is your communication plan not working?) to any number of reasons. The important thing is to find out why they want you there so that once you are there you can satisfy them.
I'll tell you now that you performed well because you listened to the angel on your right shoulder and because you knew in advance not only why you were invited, but what senior executives want in general.
What do they (Executives) want in general? They want the project finished and the benefits on which it was sold accruing. You and others may want the project for the project itself, after all its your job for the moment. They don't, it's a means to an end, full stop. What they want from you: competence, in control, working to achieve the benefits for the company promised by the project (vs. the details of the project.) Be aware that they look at project managers as commodities. One PM isn't working swap another in. It can't be that hard to learn MS Project, right? I don't think this way but most of them do.
Let's look back on your performance and see why it went well...
The sponsor told you you were invited because Sales was questioning the importance of the project, especially in light of the recent three month delay. You also found out where you were in the agenda, who else would be there, what they thought of the project, how to dress, how early to show up, the fact that it would be a good idea to have a few slides to show and a hand-out, and that your sponsor was a good guy and would support you. Then you were on your own.
You prepared your message and you visualized the end result. You practiced over and over in your mind driving to work. You did a dry run with your spouse. You prepared simple materials to hand out--bullet points and pictures, the detailed information planned for verbal delivery, detailed documentation written in case you had to distribute something. You made sure your project binder was up-to-date and indexed and you brought it to the meeting.
During the meeting you kept your cool and always appeared attentive and interested, but never cock-sure. You watched the body language.
Here is what happened:
You were introduced by the chair, the CIO. You had barely started when the VP of Sales interrupted. "These damn IT projects are like the pork and barrel Congress. Full of fat and low on delivery. For example, look at functions 12.1.4.5 and 12.1.4.6, if I can navigate this requirements spec properly! Where the hell did they come from?" You wanted to say "Then why did you sign off on the requirements document, you monkey?" but you didn't. Instead, you went to your project binder, found the data, and were able to say "Those functions were proposed by Mr. Bell A. Whistle at the user workshop held in Atlanta last month. The full group approved them as items with significant business benefit but not essential for version one. The development cost was estimated as low so they were included in the User Requirements Document for version 1." Then you stopped talking. Good, you answered his question. Everyone knows the Sales VP signed off and everyone knows he was represented at the workshop.
You continued with your presentation. The delay in your project was due to a change request from Sales that took several weeks to clarify, and this was your next topic. Your sponsor had coached you on how to phrase this part of your presentation. After your brought up the delay and why, the room went nuts--finger pointing, accusations, red faces. You did your job, you stayed out of it. As project manager you need to navigate politics, but it is not your job to resolve it, certainly not at the level you saw being played out before your eyes. You soaked it all in and kept an expression that communicated interest and professional concern. In fact the argument had little to do with your project.
When the dust settled you had an action item to modify the functionality of the software slightly and the direction that if the supplier gave you a hard time you should refer them to the sponsor. You began to finish your presentation but it was clear from the expressions in the room that the reason you'd been invited had been taken care of. You asked if there were any questions. There weren't. You thanked everyone and went back to work.
End note:
This little tale had a happy ending. Sometimes it doesn't, and sometimes there isn't anything you can do about it. In my tale there is an assumption that your project was approved because the steering committee 'power field' leaned toward supporting it. Sometimes, very rarely, but in my experience, projects are approved to discredit the sponsor. If that had been the case in my tale above you would still have survived because everyone (who counts) would know why your project was crushed, and everyone would respect the fact that you kept your cool and professionalism.
-------------------------------------------------------------------
Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career.
Mr. Gage teaches a variety of project management classes in partnership with Fog City Consulting. These classes count toward Personal Development Units (PDUs) with the Project Management Institute (PMI). Links to these classes can be found on his web site https://sites.google.com/site/gageinnovation
I would love to hear from you. If you found an article interesting or not, please comment. Thanks in advance!
Contact information for Mr. Gage can be found on http://www.linkedin.com/in/glengage
Article Source: http://EzineArticles.com/?expert=Glen_Gage
More...
It can be daunting to be called before a group of 'C' levels, VPs and other executives when you aren't used to it. When you are used to it it's even worse because any naive thoughts you may have had of a group making reasoned business decisions based on open dialog and fact have long since evaporated. Steering Committees are some percentage true to their charters and the other percentage a hot bed of corporate politics. The percentages vary from company to company and within companies, from month to month.
Your first thoughts upon receiving the invitation were mixed--pride and fear. Good. Appropriate. The devil on your left shoulder whispered in your ear "Don't worry, it's no big deal. You know what's going on in the project, just relax and go to the meeting. They just want to tell you what a good job you're doing." The angel on your right shoulder whispered "This is a big deal. Get prepared, thoroughly prepared."
The first thing you did right when your manager told you your presence was expected at the next IT Steering Committee meeting was to ask why. When the answer was vague (your manager isn't on the committee) you did the second right thing, you arranged a few minutes with the project's sponsor (who is on the committee) to find out why and ask a number of other questions.
The answer to 'why' might range from "Project Managers are invited randomly so that they get the experience of executive level dialog and exposure to the management team. It is all a part of our employee development program" (not likely) to "This is a critical project and not everyone feels they have a handle on it." (whoops, is your communication plan not working?) to any number of reasons. The important thing is to find out why they want you there so that once you are there you can satisfy them.
I'll tell you now that you performed well because you listened to the angel on your right shoulder and because you knew in advance not only why you were invited, but what senior executives want in general.
What do they (Executives) want in general? They want the project finished and the benefits on which it was sold accruing. You and others may want the project for the project itself, after all its your job for the moment. They don't, it's a means to an end, full stop. What they want from you: competence, in control, working to achieve the benefits for the company promised by the project (vs. the details of the project.) Be aware that they look at project managers as commodities. One PM isn't working swap another in. It can't be that hard to learn MS Project, right? I don't think this way but most of them do.
Let's look back on your performance and see why it went well...
The sponsor told you you were invited because Sales was questioning the importance of the project, especially in light of the recent three month delay. You also found out where you were in the agenda, who else would be there, what they thought of the project, how to dress, how early to show up, the fact that it would be a good idea to have a few slides to show and a hand-out, and that your sponsor was a good guy and would support you. Then you were on your own.
You prepared your message and you visualized the end result. You practiced over and over in your mind driving to work. You did a dry run with your spouse. You prepared simple materials to hand out--bullet points and pictures, the detailed information planned for verbal delivery, detailed documentation written in case you had to distribute something. You made sure your project binder was up-to-date and indexed and you brought it to the meeting.
During the meeting you kept your cool and always appeared attentive and interested, but never cock-sure. You watched the body language.
Here is what happened:
You were introduced by the chair, the CIO. You had barely started when the VP of Sales interrupted. "These damn IT projects are like the pork and barrel Congress. Full of fat and low on delivery. For example, look at functions 12.1.4.5 and 12.1.4.6, if I can navigate this requirements spec properly! Where the hell did they come from?" You wanted to say "Then why did you sign off on the requirements document, you monkey?" but you didn't. Instead, you went to your project binder, found the data, and were able to say "Those functions were proposed by Mr. Bell A. Whistle at the user workshop held in Atlanta last month. The full group approved them as items with significant business benefit but not essential for version one. The development cost was estimated as low so they were included in the User Requirements Document for version 1." Then you stopped talking. Good, you answered his question. Everyone knows the Sales VP signed off and everyone knows he was represented at the workshop.
You continued with your presentation. The delay in your project was due to a change request from Sales that took several weeks to clarify, and this was your next topic. Your sponsor had coached you on how to phrase this part of your presentation. After your brought up the delay and why, the room went nuts--finger pointing, accusations, red faces. You did your job, you stayed out of it. As project manager you need to navigate politics, but it is not your job to resolve it, certainly not at the level you saw being played out before your eyes. You soaked it all in and kept an expression that communicated interest and professional concern. In fact the argument had little to do with your project.
When the dust settled you had an action item to modify the functionality of the software slightly and the direction that if the supplier gave you a hard time you should refer them to the sponsor. You began to finish your presentation but it was clear from the expressions in the room that the reason you'd been invited had been taken care of. You asked if there were any questions. There weren't. You thanked everyone and went back to work.
End note:
This little tale had a happy ending. Sometimes it doesn't, and sometimes there isn't anything you can do about it. In my tale there is an assumption that your project was approved because the steering committee 'power field' leaned toward supporting it. Sometimes, very rarely, but in my experience, projects are approved to discredit the sponsor. If that had been the case in my tale above you would still have survived because everyone (who counts) would know why your project was crushed, and everyone would respect the fact that you kept your cool and professionalism.
-------------------------------------------------------------------
Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career.
Mr. Gage teaches a variety of project management classes in partnership with Fog City Consulting. These classes count toward Personal Development Units (PDUs) with the Project Management Institute (PMI). Links to these classes can be found on his web site https://sites.google.com/site/gageinnovation
I would love to hear from you. If you found an article interesting or not, please comment. Thanks in advance!
Contact information for Mr. Gage can be found on http://www.linkedin.com/in/glengage
Article Source: http://EzineArticles.com/?expert=Glen_Gage
More...
Monday, September 6, 2010
A Journey of 1000 Miles is Still 1000 Miles Long [Rich Mironov]
It's easy to confuse actual progress with intentions to make progress.
Why point out the obvious? I've just come out of another agile conversation where prospective clients confused "we want to build better software faster" with "we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features."
So paraphrasing Confucius, "A journey of a thousand miles begins with a single step, but is still a thousand miles long. Even at twice your normal walking speed, be prepared for a very long slog."
For context, nearly every software development team would like to be more productive, ship better product, and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind - with months (years) of unmet customer requirements and technical debt. Shovelfuls of postponed promises piled in a heap. Which means that calls for better development processes are usually in the context of big, ugly backlogs and long-suffering customers.
So the unstated question in these meetings is "how do we catch up to where we were already supposed to be? Can a better process (in the future) also erase our previous shortfalls?" Stated that baldly, it seems naive. Yet the emotional logic is very real. Everyone wants a fresh start, a reset, a mulligan. Surely an outside expert or shiny new process will catch us up. Or not.
Consider a hypothetical software team that sporadically ships product, has run up a stack of technical debts, missed some customer commitments, and needs a series of process improvements. Business needs are pressing, so there's no option to halt development for a radical retooling.
You might try some combination of these:
Pick one small thing as a demonstration, and make it successful. For example, if we're having trouble planning and estimating, then identify one very small project for careful planning and estimation. Focus the team on completing just that - mostly on time and reasonably on spec. This becomes our existence proof for improvement: having done a better job once on something small, we can do it again. (After all, a journey of a thousand miles...)
Ruthlessly prioritize. There are years of backlogs to address, and our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements are truly the most important. For everything else, 'nice to have' translates to 'not this year.'
Don't confuse small with big. As soon as a few tiny things start arriving on schedule, internal stakeholders will be lobbying for massive overhauls. ("If the engineering team can rewrite a report in a week, can't they re-architect all of our business processes in a month?")
Be transparent. Explain your 'do one small thing right' strategy to all internal stakeholders. (To be fashionable, you can call it 'agile.') Remind everyone that we still have 998 miles to go, but we're picking up the pace.
Share small improvements with customers. They are likely to be hungry for any good news, and eager for you to succeed. Gather some applause for your team. Customers don't really expect you to fix everything at once, but need some sense of progress.
Do your math. If we have two years of backlogs to work through, and we double our development speed, then it may take a year to catch up. Avoid magical thinking.
Celebrate the positive. Regardless of the starting point, your teams need a sense of progress and optimism. Highlight small triumphs, applaud people who are doing the right things, divert attention from yourself.
And wear comfortable shoes. There's a lot of walking to do. Because Confucius also said that "no matter where you go, there you are.
Find some improvements that you can make now, and establish a trend. Most long-term issues are solved with incremental changes and successes, not through one big fix.
Crossposted at http://www.mironov.com/1000miles/
Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com .
More...
Why point out the obvious? I've just come out of another agile conversation where prospective clients confused "we want to build better software faster" with "we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features."
So paraphrasing Confucius, "A journey of a thousand miles begins with a single step, but is still a thousand miles long. Even at twice your normal walking speed, be prepared for a very long slog."
For context, nearly every software development team would like to be more productive, ship better product, and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind - with months (years) of unmet customer requirements and technical debt. Shovelfuls of postponed promises piled in a heap. Which means that calls for better development processes are usually in the context of big, ugly backlogs and long-suffering customers.
So the unstated question in these meetings is "how do we catch up to where we were already supposed to be? Can a better process (in the future) also erase our previous shortfalls?" Stated that baldly, it seems naive. Yet the emotional logic is very real. Everyone wants a fresh start, a reset, a mulligan. Surely an outside expert or shiny new process will catch us up. Or not.
So What Do We Do Now?
Consider a hypothetical software team that sporadically ships product, has run up a stack of technical debts, missed some customer commitments, and needs a series of process improvements. Business needs are pressing, so there's no option to halt development for a radical retooling.
You might try some combination of these:
Pick one small thing as a demonstration, and make it successful. For example, if we're having trouble planning and estimating, then identify one very small project for careful planning and estimation. Focus the team on completing just that - mostly on time and reasonably on spec. This becomes our existence proof for improvement: having done a better job once on something small, we can do it again. (After all, a journey of a thousand miles...)
Ruthlessly prioritize. There are years of backlogs to address, and our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements are truly the most important. For everything else, 'nice to have' translates to 'not this year.'
Don't confuse small with big. As soon as a few tiny things start arriving on schedule, internal stakeholders will be lobbying for massive overhauls. ("If the engineering team can rewrite a report in a week, can't they re-architect all of our business processes in a month?")
Be transparent. Explain your 'do one small thing right' strategy to all internal stakeholders. (To be fashionable, you can call it 'agile.') Remind everyone that we still have 998 miles to go, but we're picking up the pace.
Share small improvements with customers. They are likely to be hungry for any good news, and eager for you to succeed. Gather some applause for your team. Customers don't really expect you to fix everything at once, but need some sense of progress.
Do your math. If we have two years of backlogs to work through, and we double our development speed, then it may take a year to catch up. Avoid magical thinking.
Celebrate the positive. Regardless of the starting point, your teams need a sense of progress and optimism. Highlight small triumphs, applaud people who are doing the right things, divert attention from yourself.
And wear comfortable shoes. There's a lot of walking to do. Because Confucius also said that "no matter where you go, there you are.
SoundByte
Find some improvements that you can make now, and establish a trend. Most long-term issues are solved with incremental changes and successes, not through one big fix.
Crossposted at http://www.mironov.com/1000miles/
Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com .
More...
Monday, August 16, 2010
Suppressing Your Feminine Side May Be Bad for Business [Kimberly Wiefling]
About 15 years ago a woman I barely knew, the wife of a coworker, was listening to me describe the challenges I faced as a project manager at Hewlett Packard. “You’re not using your feminine power!” she suddenly pronounced, as if she’d just discovered the cause of some mysterious chronic illness I’d been suffering from for a lifetime. My first reaction was, “Use my feminine power? I sure hope not!” Since I was obviously perplexed, she further explained that this included nurturing behaviors like bringing food and drinks to meetings, and expressing other characteristics that I’ve heard described as “soft skills” by HR pros. I guessed I missed that in the job description.
You see, I was working in high-tech, and for over a decade I’d painstakingly stamped out any semblance of femininity in my work. After earning a masters degree in physics, a field in which women are almost as scarce as on-time schedules, I’d entered the high-tech engineering world, a profession with an equally abysmal track record of attracting women. Why on earth would I want to associate myself - in any way - with anything female in my work? I was sure I would appear weak and ineffective to my colleagues, and quite possibly my salary would decrease.
Maybe I was being a little paranoid, but until recently, I have done my best to ignore the gender issue in my career. I've steered clear of “radical feminism,” and I most certainly didn’t want to be perceived as “nurturing.” However, this past year I’ve been working on a book project, Scrappy Women in Business, which prompted me to reflect on the role of women in the workplace, and my own experience as a female in a predominantly male work environment. As a result of this, and the changing nature of the work environment, I’ve come to value what my wife’s colleague called my "feminine power." But my initial hesitancy wasn't completely unfounded, given the research on women in the workplace.
Even If I’m Not Nurturing, Chances Are People Will Think I Am
It turns out that it might not matter whether I am nurturing or not – being a woman, it’s likely that I will be perceived as nurturing by CEOs and other top executives. Catalyst, the leading global nonprofit dedicated to expanding opportunities for women in business, published a study in 2005 under the intriguing title Women "Take Care," Men "Take Charge:" Stereotyping of U.S. Business Leaders Exposed. Their research demonstrated that, although women and men often lead in similar ways, they are perceived very differently by both male and female senior executives. Regardless of the reality, women are perceived to be better at supporting and rewarding while men are perceived to be better at delegating and influencing upward.
Unfortunately, these unconscious biases impact the perception of competence and fitness for promotion, though with the growing emphasis on teamwork and collaboration these days, I’m not sure in which direction. We can, however, measure the results by observing the difference in participation of women and men at various levels in the professional world, and in the relative compensation of women and men.
Justice is Blind
Back in the 1970’s women represented only 10% of the musicians in an orchestra. That number has risen over the years to over 35%, and a Princeton University study in the year 2000 found that a big chunk of that gain was due to the switch to blind auditions. When the decision-makers can’t see whether the musician is a women or a man, more women are hired. And a study by The Anita Borg Institute on the recruitment, retention, and advancement of technical women found that women are sometimes preferentially eliminated during the resume review process, even if the interview process is unbiased. Another study specifically comparing evaluations of resumes by randomly assigning a woman’s name found that resumes bearing a woman’s name were rated lower by both women and men. (Perhaps women should use initials instead of first names on resumes, or hiring managers should have the names masked before reviewing them.)
Of course we’re all biased in many ways. All human beings are. Our assumptions and beliefs unconsciously influence our decisions, and our brains are clever enough to keep this process hidden from us so that we think we are making rational decisions based on the facts. Don’t think you’re biased? You can find out in about 15 minutes. Harvard University’s “Project Implicit®” provides a test in exchange for using your data in their studies. You will be randomly assigned one of a variety of bias studies, but you can repeat the process to experience them all. Based on experimenting with this several years ago, I found that I have a slight tendency to associate technical topics with women. Go figure!
Just Because You’re Paranoid Doesn’t Mean People Aren't Out to Get You
According to US Department of Labor statistics, only 10% of employed engineers were women at the turn of the century (2001). And while the salary differential in engineering has largely disappeared, the employment differential remains large in all but the life sciences. Even project management remains a profession with some degree of gender disparity—in both employment and pay. The 2010 PMI Salary Survey suggests that only 40% of US project managers are women (based on survey responders), and that the salaries of women project managers are “considerably lower” than that typical for men (about 10%). Karen Klein’s 2005 article “It’s a Women’s World, Too” does make the point that women are entering the project management profession at rates around double that of men, but still acknowledges that female project managers face barriers to success that are peculiar to women, such as excessive humility and a tendency towards self-criticism.
In spite of the possible risk, and because I’m past typical childbearing age (something executives admit is a real barrier for women in hiring and promotion in off-the-record true confessions), I’m less inclined to eschew my feminine qualities in my work these days. I’ve found that these qualities have become increasingly valued for their importance in delivering extraordinary business results. The incredible diversity of teams, increased focus on alliances and partnerships, the growth of open innovation, crowd-sourcing, and collaboration on a massive scale (facilitated by the internet), have all made people keenly aware of the power of group genius and the importance of a more collaborative style of leadership. I’ve noticed that the work I do as a project manager increasingly involves facilitating interaction rather than giving direction; perhaps it was always about that and I just didn’t notice because I was suppressing my nurturing side.
It turns out that female versions of leadership improve bottom line business results. Companies with higher proportion of women on their top management teams enjoyed 35% greater ROE (Return on Equity) than those with the lowest. Although I’m wary of the trap of stereotypes, in the past couple of years I began to wonder if maybe women and men really do lead in some fundamentally different way. And, with more profit at stake, I hope it’s something that can be learned by anyone, even nurturing-averse me.
There are plenty of pop psychology discussions about gender differences, including the somewhat unimaginatively titled “Are Women Better Project Managers Than Men” on the Toolbox for IT Project and Program Management Blog. Puh-LEESE! This kind of conversation is similar to my Japanese friends asking me to describe Americans. “Which one?” I ask. Like all simplistic questions, the answer to whether men or women are better project managers is, “It depends.” It depends on which woman, or which man, and which project, and in which situation. While statistics can help us understand trends in the aggregate, it’s foolish to apply that data to any specific individual or situation. Those who carelessly apply averages to individuals do both parties an injustice. Let’s not deepen the gender divide by participating in these kinds of debates. Instead, let’s look at facts.
The Road to the Top Winds Uphill All the Way
Is there gender bias at work in project management, and the business world in general? In my project leadership role I make it a practice to focus on the results produced, not the intentions of my team. Customers care about results, not intentions. I think the same approach may work well in this situation. I have no real way of knowing whether there is bias in the process, but I do know that there is a difference in the outcome – the participation and compensation of women relative to men. The measurable data from Catalyst certainly demonstrate a disparity:
• Percentage of women in the U.S. labor force: 46.3%
• Percentage of women in management, professional and related occupations: 50.6%
• Percentage of female Fortune 500 corporate officers: 15.4%
• Percentage of female Fortune 500 board seats: 14.8%
• Percentage of female Fortune 500 top earners: 6.7%
• Percentage of female Fortune 500 CEOs: 2.4%
Of course, root cause analysis is important, but the root cause of being overweight has been well known for years and still I can’t lose 5 kilograms. I personally don’t care whether the remaining disparities between women and men in project management—and the business world in general—are a result of accident, unconscious bias, or a devious plot. The causes no longer interest me. Making and measuring progress does. What’s measured tends to get attention, and frequently improves.
Good intentions or accidental bias can no longer be acceptable as a defense for inequitable results. After all, if I accidentally run you over and land you in the hospital, you’re just as injured as if I’d driven purposely in your direction with intent to harm.
The Coming Shortfall in Working Age Population in the Developed World
Based on a report by the Stanford Center on Longevity, (PDF) it looks to me like it’s in all of our best interests to make workplaces more attractive to human beings in general, and—in fields where they are under-represented—to women in particular. In a decade or two, the shortage of working-age people will be an economic crisis in some parts of the world. Japan and Germany in particular will face at least a 20 percent shortage in the coming decades (That’s why I don’t worry about women’s equality in the workplace in Japan – it’s coming!). We'll need everyone's participation if businesses are going to successfully meet the challenges facing humanity.
The Anita Borg Institute found that technical women leave their companies in mid-career at twice the rate of men. (Read more about this and the reasons why if you like.) Companies are losing women, especially at the mid-career stage. Catalyst reported that women cite four major reasons why companies lose female talent: “lack of flexibility (51%); glass ceiling issues (29%); unhappiness with work environment (28%); and feeling unchallenged in their jobs (22%). Only 5% report being downsized and only 3% say they were victims of sexual harassment.”
Of course, the workplace isn’t all that hospitable to men either. A Gallup Institute study on wellbeing concluded that 77% of all workers hate their jobs. HATE! Wow. That’s much worse than being unhappy with the work environment or feeling unchallenged in a job. I’m no expert at organizational development or the link between worker satisfaction and profit, but I’m guessing this is NOT good for project success or bottom line profits. A little more nurturing probably wouldn’t hurt any of us, or our chances for project success either.
If Being More Nurturing Will Increase Project Success, Bring on the Nurturing!
I was educated as a scientist, and if I were just looking at past data I’d conclude that expressing my so-called feminine side in the high-tech business world would put me at a bit of a disadvantage. But that’s kind of like driving while only gazing into the rearview mirror. With almost everyone hating their jobs, increased emphasis on collaboration, and the coming shortfall in skilled workers, I’m thinking that a more nurturing work environment is going to be a competitive advantage.
In fact, I’ve been experimenting with a more nurturing approach in my work in Japan, and it’s yielding excellent results: noticeably improved performance in various individuals, faster response to my requests, and more enjoyable working relationships. It’s working so well that I’m tempted to try it out on this continent. My only concern is whether it’s possible to be both scrappy and nurturing at the same time. Considering the potential 35% higher ROE, I’ll have to give it a go purely for financial reasons.
Nurturingly yours, - Kimberly
P.S. Scrappy Women in Business – Living Proof that Bending the Rules Isn’t Breaking the Law, will be available in July 2010. This book, and the associated website invite women to draw inspiration from each other’s stories. It’s just a small drop in the bucket, but it is one drop.
©2010 Kimberly M. Wiefling. All Rights Reserved. Published on the SD Forum Engineering Leadership Blog by permission of the author.
More...
You see, I was working in high-tech, and for over a decade I’d painstakingly stamped out any semblance of femininity in my work. After earning a masters degree in physics, a field in which women are almost as scarce as on-time schedules, I’d entered the high-tech engineering world, a profession with an equally abysmal track record of attracting women. Why on earth would I want to associate myself - in any way - with anything female in my work? I was sure I would appear weak and ineffective to my colleagues, and quite possibly my salary would decrease.
Maybe I was being a little paranoid, but until recently, I have done my best to ignore the gender issue in my career. I've steered clear of “radical feminism,” and I most certainly didn’t want to be perceived as “nurturing.” However, this past year I’ve been working on a book project, Scrappy Women in Business, which prompted me to reflect on the role of women in the workplace, and my own experience as a female in a predominantly male work environment. As a result of this, and the changing nature of the work environment, I’ve come to value what my wife’s colleague called my "feminine power." But my initial hesitancy wasn't completely unfounded, given the research on women in the workplace.
Even If I’m Not Nurturing, Chances Are People Will Think I Am
It turns out that it might not matter whether I am nurturing or not – being a woman, it’s likely that I will be perceived as nurturing by CEOs and other top executives. Catalyst, the leading global nonprofit dedicated to expanding opportunities for women in business, published a study in 2005 under the intriguing title Women "Take Care," Men "Take Charge:" Stereotyping of U.S. Business Leaders Exposed. Their research demonstrated that, although women and men often lead in similar ways, they are perceived very differently by both male and female senior executives. Regardless of the reality, women are perceived to be better at supporting and rewarding while men are perceived to be better at delegating and influencing upward.
Unfortunately, these unconscious biases impact the perception of competence and fitness for promotion, though with the growing emphasis on teamwork and collaboration these days, I’m not sure in which direction. We can, however, measure the results by observing the difference in participation of women and men at various levels in the professional world, and in the relative compensation of women and men.
Justice is Blind
Back in the 1970’s women represented only 10% of the musicians in an orchestra. That number has risen over the years to over 35%, and a Princeton University study in the year 2000 found that a big chunk of that gain was due to the switch to blind auditions. When the decision-makers can’t see whether the musician is a women or a man, more women are hired. And a study by The Anita Borg Institute on the recruitment, retention, and advancement of technical women found that women are sometimes preferentially eliminated during the resume review process, even if the interview process is unbiased. Another study specifically comparing evaluations of resumes by randomly assigning a woman’s name found that resumes bearing a woman’s name were rated lower by both women and men. (Perhaps women should use initials instead of first names on resumes, or hiring managers should have the names masked before reviewing them.)
Of course we’re all biased in many ways. All human beings are. Our assumptions and beliefs unconsciously influence our decisions, and our brains are clever enough to keep this process hidden from us so that we think we are making rational decisions based on the facts. Don’t think you’re biased? You can find out in about 15 minutes. Harvard University’s “Project Implicit®” provides a test in exchange for using your data in their studies. You will be randomly assigned one of a variety of bias studies, but you can repeat the process to experience them all. Based on experimenting with this several years ago, I found that I have a slight tendency to associate technical topics with women. Go figure!
Just Because You’re Paranoid Doesn’t Mean People Aren't Out to Get You
According to US Department of Labor statistics, only 10% of employed engineers were women at the turn of the century (2001). And while the salary differential in engineering has largely disappeared, the employment differential remains large in all but the life sciences. Even project management remains a profession with some degree of gender disparity—in both employment and pay. The 2010 PMI Salary Survey suggests that only 40% of US project managers are women (based on survey responders), and that the salaries of women project managers are “considerably lower” than that typical for men (about 10%). Karen Klein’s 2005 article “It’s a Women’s World, Too” does make the point that women are entering the project management profession at rates around double that of men, but still acknowledges that female project managers face barriers to success that are peculiar to women, such as excessive humility and a tendency towards self-criticism.
In spite of the possible risk, and because I’m past typical childbearing age (something executives admit is a real barrier for women in hiring and promotion in off-the-record true confessions), I’m less inclined to eschew my feminine qualities in my work these days. I’ve found that these qualities have become increasingly valued for their importance in delivering extraordinary business results. The incredible diversity of teams, increased focus on alliances and partnerships, the growth of open innovation, crowd-sourcing, and collaboration on a massive scale (facilitated by the internet), have all made people keenly aware of the power of group genius and the importance of a more collaborative style of leadership. I’ve noticed that the work I do as a project manager increasingly involves facilitating interaction rather than giving direction; perhaps it was always about that and I just didn’t notice because I was suppressing my nurturing side.
It turns out that female versions of leadership improve bottom line business results. Companies with higher proportion of women on their top management teams enjoyed 35% greater ROE (Return on Equity) than those with the lowest. Although I’m wary of the trap of stereotypes, in the past couple of years I began to wonder if maybe women and men really do lead in some fundamentally different way. And, with more profit at stake, I hope it’s something that can be learned by anyone, even nurturing-averse me.
There are plenty of pop psychology discussions about gender differences, including the somewhat unimaginatively titled “Are Women Better Project Managers Than Men” on the Toolbox for IT Project and Program Management Blog. Puh-LEESE! This kind of conversation is similar to my Japanese friends asking me to describe Americans. “Which one?” I ask. Like all simplistic questions, the answer to whether men or women are better project managers is, “It depends.” It depends on which woman, or which man, and which project, and in which situation. While statistics can help us understand trends in the aggregate, it’s foolish to apply that data to any specific individual or situation. Those who carelessly apply averages to individuals do both parties an injustice. Let’s not deepen the gender divide by participating in these kinds of debates. Instead, let’s look at facts.
The Road to the Top Winds Uphill All the Way
Is there gender bias at work in project management, and the business world in general? In my project leadership role I make it a practice to focus on the results produced, not the intentions of my team. Customers care about results, not intentions. I think the same approach may work well in this situation. I have no real way of knowing whether there is bias in the process, but I do know that there is a difference in the outcome – the participation and compensation of women relative to men. The measurable data from Catalyst certainly demonstrate a disparity:
• Percentage of women in the U.S. labor force: 46.3%
• Percentage of women in management, professional and related occupations: 50.6%
• Percentage of female Fortune 500 corporate officers: 15.4%
• Percentage of female Fortune 500 board seats: 14.8%
• Percentage of female Fortune 500 top earners: 6.7%
• Percentage of female Fortune 500 CEOs: 2.4%
Of course, root cause analysis is important, but the root cause of being overweight has been well known for years and still I can’t lose 5 kilograms. I personally don’t care whether the remaining disparities between women and men in project management—and the business world in general—are a result of accident, unconscious bias, or a devious plot. The causes no longer interest me. Making and measuring progress does. What’s measured tends to get attention, and frequently improves.
Good intentions or accidental bias can no longer be acceptable as a defense for inequitable results. After all, if I accidentally run you over and land you in the hospital, you’re just as injured as if I’d driven purposely in your direction with intent to harm.
The Coming Shortfall in Working Age Population in the Developed World
Based on a report by the Stanford Center on Longevity, (PDF) it looks to me like it’s in all of our best interests to make workplaces more attractive to human beings in general, and—in fields where they are under-represented—to women in particular. In a decade or two, the shortage of working-age people will be an economic crisis in some parts of the world. Japan and Germany in particular will face at least a 20 percent shortage in the coming decades (That’s why I don’t worry about women’s equality in the workplace in Japan – it’s coming!). We'll need everyone's participation if businesses are going to successfully meet the challenges facing humanity.
The Anita Borg Institute found that technical women leave their companies in mid-career at twice the rate of men. (Read more about this and the reasons why if you like.) Companies are losing women, especially at the mid-career stage. Catalyst reported that women cite four major reasons why companies lose female talent: “lack of flexibility (51%); glass ceiling issues (29%); unhappiness with work environment (28%); and feeling unchallenged in their jobs (22%). Only 5% report being downsized and only 3% say they were victims of sexual harassment.”
Of course, the workplace isn’t all that hospitable to men either. A Gallup Institute study on wellbeing concluded that 77% of all workers hate their jobs. HATE! Wow. That’s much worse than being unhappy with the work environment or feeling unchallenged in a job. I’m no expert at organizational development or the link between worker satisfaction and profit, but I’m guessing this is NOT good for project success or bottom line profits. A little more nurturing probably wouldn’t hurt any of us, or our chances for project success either.
If Being More Nurturing Will Increase Project Success, Bring on the Nurturing!
I was educated as a scientist, and if I were just looking at past data I’d conclude that expressing my so-called feminine side in the high-tech business world would put me at a bit of a disadvantage. But that’s kind of like driving while only gazing into the rearview mirror. With almost everyone hating their jobs, increased emphasis on collaboration, and the coming shortfall in skilled workers, I’m thinking that a more nurturing work environment is going to be a competitive advantage.
In fact, I’ve been experimenting with a more nurturing approach in my work in Japan, and it’s yielding excellent results: noticeably improved performance in various individuals, faster response to my requests, and more enjoyable working relationships. It’s working so well that I’m tempted to try it out on this continent. My only concern is whether it’s possible to be both scrappy and nurturing at the same time. Considering the potential 35% higher ROE, I’ll have to give it a go purely for financial reasons.
Nurturingly yours, - Kimberly
P.S. Scrappy Women in Business – Living Proof that Bending the Rules Isn’t Breaking the Law, will be available in July 2010. This book, and the associated website invite women to draw inspiration from each other’s stories. It’s just a small drop in the bucket, but it is one drop.
©2010 Kimberly M. Wiefling. All Rights Reserved. Published on the SD Forum Engineering Leadership Blog by permission of the author.
More...
Monday, July 19, 2010
Guy Kawasaki on Entreprenuership 2.0 [Shriram Natarajan]
Guy Kawasaki speaks about his mind altering experiences; holds forth on entrepreneurship and marketing in the social age.
Guy Kawasaki talked about "Entreprenuership 2.0" at UCSC extension in Santa Clara on Wednesday, July 7th. Guy Kawasaki is a managing director of Garage Technology Ventures, an early-stage venture capital firm and a columnist for Entrepreneur Magazine. Previously, he was an Apple Fellow at Apple Computer, Inc. Guy is the author of nine books including The Art of the Start, Rules for Revolutionaries, , and The Macintosh Way. He has a BA from Stanford University and an MBA from UCLA as well as an honorary doctorate from Babson College.
Alison van Diggelen of Fresh Dialogues collected the questions that the participants had enterred beforehand and asked them of Guy.
It was a wide ranging talk on Guy's opinions on various topics.
Seeing the Mactinosh was one of the three all time (legal) highs he has experienced. Other highs were: meeting his wife and playing hockey (in no particular order).
Microsoft or Nokia could have made the iPhone. They should hire the right people and use their almost infinite cash to build products that people actually want. Microsoft or Nokia could have been the iPad maker -- had they just gotten their act together after seeing the iPhone.
Apple is a company that is dedicated to making the coolest products around. The company culture is decidedly inclined towards creating nifty, awe inspiring industrial designs. HP (to bash another company, he said) was built on two guys building oscilloscopes. They would gravitate towards stodgy businesses with safe markets. Apple's founders on the other hand could barely stay out of jail during their salad days.
The best way to market anything is to make sure that you have a great product. It is easy to market good stuff. It is draining to market "crap". Example: It does not take a genius to market the iPad; on the other hand marketing the "Kin" would be an uphill battle.
For a marketer today, social media awareness and presence is key. If you do not do social media today, you are not marketing. Guy opines that this is a fundamental way to do business today and in the future; to the exclusion of traditional marketing tools of focus groups and user surveys. The people are talking to you and about your company/products in various forums. All a marketer has to do is to plug into them to be successful.
Guy listed his various failures.
His job was to evangelize the Mac way of life to developers and thereby secure the market share for the better product. However Apple lost that battle overwhelmingly to Microsoft.
He does not have a net worth greater than $100 million. He has failed in terms of the movers and shakers of the valley.
He does not own a professional sports team (say the Sharks).
Despite his failure on behalf of Apple, he is best known for his role there. He went on to say that the valley is very forgiving of good faith errors/failures. There are no dynasties (continued success) or pariahs (continued failures). For entrepreneurs, the message is: there will be failures. It will not be the end as long as you learn and stay in the fight.
He would much rather invest in a couple of engineering graduates that build a product that they would like to use instead of a couple of MBAs from an A-list school with a snazzy slide deck.
He would invest in people that are hungry (living on soy sauce and rice) rather than first-25 employee/VP level person of a highly successful company. His thinking is that if you are a senior employee in a highly successful company you are accustomed to certain comforts and a certain size of bank roll. Also if you are said senior employee, you should be able to fund your ideas and not rely on venture capital.
He is living proof that you can fool most people most of the time. He had no formal training in hardware or programming or computers. He was not even the earliest or most passionate Apple fanatics. He mostly got into Apple via nepotism or his familiarity with the original Mac Evangelist. He considers his key to success is his ability to grind it out. Hard work and passion. As an example, he built his twitter fan base from the ground up and by persistently posting good links.
In another context, he facetiously mentioned that the top five criteria for success were: "luck, luck, luck, luck, luck".
Steve is one of a kind person across all time. The combination of perfectionism, sense of style and hunger to change the world is not possible. Guy would have been worth a couple of billion today had he stuck with Apple over the years. He would have to to put up with Steve for 25 years in the bargain.
In response to someone's questions about Steve Jobs' recent emails about the new iPhone's antenna: Guy thinks that this is probably just to indulge in the pleasure of seeing the response that these actions garner.
Twitter occupied a disproportionate amount of time in the chat. He has added a quarter of million subscribers the old fashioned way: one at a time.
The rules of normal interaction seems to apply in twitter (or other social media as well):
- do not take "crap" from anyone (use tweetdeck to filter out and twitter itself to block people you do not like)
- if someone talks to you, talk back
- provide value in your interactions (good links in tweets/updates)
- provide content that is compelling to folks beyond your immediate earshot (measure content quality by the number of retweets)
- if you have provided considerable value over time, it is then kosher to do a little self promotion.
One aspect to his twitter toolkit is taken from the 24 hour news/sports channels: if you watch long enough, you will see the same stories repeat. That is an indication that you are spending too much time on the channel. It also is a tool for Guy to maximise the reach of his message.
Another axiom he has is: if you are not irritating a few people, you are not doing it right.
The only rule on twitter usage is quite simply this: if it works for you, it is right.
Guy's advice to entrepreneurs is:
1) "Ask a woman."
Present your idea to women. They are not predisposed to destruction and could give you constructive ideas on your plan.
2) Build it and you will be funded.
A working prototype is more powerful than any powerpoint slides that you present. Any revenue stream is more powerful than spreadsheets about future monetisation. This goes for securing other funding as well.
3) Market yourself and your ideas
Establish yourself as a goto person in a niche. Build a network of people that look to you for the latest and greatest in a particular area.
4) The time is now:
This is a great time to be an entrepreneur: software is free, marketing is free and limited only by your imagination, labour is cheap, costs are low.
The silicon valley's entrepreneurial spirit is only due to the Stanford engineering department. So if any area that wants to reproduce the SiValley magic, he asks them to focus on their engineering school(s).
You can get more snippets and video at the Fresh dialogues page.
-------------------------------------------------------------------
Shriram Natarajan blogs at http://words.sangram.info/.
More...
Guy Kawasaki talked about "Entreprenuership 2.0" at UCSC extension in Santa Clara on Wednesday, July 7th. Guy Kawasaki is a managing director of Garage Technology Ventures, an early-stage venture capital firm and a columnist for Entrepreneur Magazine. Previously, he was an Apple Fellow at Apple Computer, Inc. Guy is the author of nine books including The Art of the Start, Rules for Revolutionaries, , and The Macintosh Way. He has a BA from Stanford University and an MBA from UCLA as well as an honorary doctorate from Babson College.
Alison van Diggelen of Fresh Dialogues collected the questions that the participants had enterred beforehand and asked them of Guy.
It was a wide ranging talk on Guy's opinions on various topics.
On Apple
Seeing the Mactinosh was one of the three all time (legal) highs he has experienced. Other highs were: meeting his wife and playing hockey (in no particular order).
Microsoft or Nokia could have made the iPhone. They should hire the right people and use their almost infinite cash to build products that people actually want. Microsoft or Nokia could have been the iPad maker -- had they just gotten their act together after seeing the iPhone.
Apple is a company that is dedicated to making the coolest products around. The company culture is decidedly inclined towards creating nifty, awe inspiring industrial designs. HP (to bash another company, he said) was built on two guys building oscilloscopes. They would gravitate towards stodgy businesses with safe markets. Apple's founders on the other hand could barely stay out of jail during their salad days.
On Marketing
The best way to market anything is to make sure that you have a great product. It is easy to market good stuff. It is draining to market "crap". Example: It does not take a genius to market the iPad; on the other hand marketing the "Kin" would be an uphill battle.
For a marketer today, social media awareness and presence is key. If you do not do social media today, you are not marketing. Guy opines that this is a fundamental way to do business today and in the future; to the exclusion of traditional marketing tools of focus groups and user surveys. The people are talking to you and about your company/products in various forums. All a marketer has to do is to plug into them to be successful.
On failure
Guy listed his various failures.
His job was to evangelize the Mac way of life to developers and thereby secure the market share for the better product. However Apple lost that battle overwhelmingly to Microsoft.
He does not have a net worth greater than $100 million. He has failed in terms of the movers and shakers of the valley.
He does not own a professional sports team (say the Sharks).
Despite his failure on behalf of Apple, he is best known for his role there. He went on to say that the valley is very forgiving of good faith errors/failures. There are no dynasties (continued success) or pariahs (continued failures). For entrepreneurs, the message is: there will be failures. It will not be the end as long as you learn and stay in the fight.
On investing
He would much rather invest in a couple of engineering graduates that build a product that they would like to use instead of a couple of MBAs from an A-list school with a snazzy slide deck.
He would invest in people that are hungry (living on soy sauce and rice) rather than first-25 employee/VP level person of a highly successful company. His thinking is that if you are a senior employee in a highly successful company you are accustomed to certain comforts and a certain size of bank roll. Also if you are said senior employee, you should be able to fund your ideas and not rely on venture capital.
On success
He is living proof that you can fool most people most of the time. He had no formal training in hardware or programming or computers. He was not even the earliest or most passionate Apple fanatics. He mostly got into Apple via nepotism or his familiarity with the original Mac Evangelist. He considers his key to success is his ability to grind it out. Hard work and passion. As an example, he built his twitter fan base from the ground up and by persistently posting good links.
In another context, he facetiously mentioned that the top five criteria for success were: "luck, luck, luck, luck, luck".
On Steve Jobs
Steve is one of a kind person across all time. The combination of perfectionism, sense of style and hunger to change the world is not possible. Guy would have been worth a couple of billion today had he stuck with Apple over the years. He would have to to put up with Steve for 25 years in the bargain.
In response to someone's questions about Steve Jobs' recent emails about the new iPhone's antenna: Guy thinks that this is probably just to indulge in the pleasure of seeing the response that these actions garner.
On twitter
Twitter occupied a disproportionate amount of time in the chat. He has added a quarter of million subscribers the old fashioned way: one at a time.
The rules of normal interaction seems to apply in twitter (or other social media as well):
- do not take "crap" from anyone (use tweetdeck to filter out and twitter itself to block people you do not like)
- if someone talks to you, talk back
- provide value in your interactions (good links in tweets/updates)
- provide content that is compelling to folks beyond your immediate earshot (measure content quality by the number of retweets)
- if you have provided considerable value over time, it is then kosher to do a little self promotion.
One aspect to his twitter toolkit is taken from the 24 hour news/sports channels: if you watch long enough, you will see the same stories repeat. That is an indication that you are spending too much time on the channel. It also is a tool for Guy to maximise the reach of his message.
Another axiom he has is: if you are not irritating a few people, you are not doing it right.
The only rule on twitter usage is quite simply this: if it works for you, it is right.
On entrepreneurship
Guy's advice to entrepreneurs is:
1) "Ask a woman."
Present your idea to women. They are not predisposed to destruction and could give you constructive ideas on your plan.
2) Build it and you will be funded.
A working prototype is more powerful than any powerpoint slides that you present. Any revenue stream is more powerful than spreadsheets about future monetisation. This goes for securing other funding as well.
3) Market yourself and your ideas
Establish yourself as a goto person in a niche. Build a network of people that look to you for the latest and greatest in a particular area.
4) The time is now:
This is a great time to be an entrepreneur: software is free, marketing is free and limited only by your imagination, labour is cheap, costs are low.
The silicon valley's entrepreneurial spirit is only due to the Stanford engineering department. So if any area that wants to reproduce the SiValley magic, he asks them to focus on their engineering school(s).
You can get more snippets and video at the Fresh dialogues page.
-------------------------------------------------------------------
Shriram Natarajan blogs at http://words.sangram.info/.
More...
Monday, June 14, 2010
How a Failure in Engineering Leadership Caused the Deep Horizon Oil Spill [Elizabeth J. Agnew]
Mike Williams survived the blowout on The Deepwater Horizon and he shared his story on 60 Minutes in May. What I found fascinating, in addition to how he survived, was his description of a catalyzing moment in the board room, just one of the many leadership mistakes that led to the disaster.
The rig had been working for seven years, and was just finishing up the largest drilling project to have ever been completed. The crew was preparing to close the cap of the oil well. Managers from BP were on site to celebrate a successful completion.
Here’s an excerpt from the 60 Minutes interview explaining what happened the morning of the accident:
Williams says, that during a safety meeting, the manager for the rig owner, Transocean, was explaining how they were going to close the well when the manager from BP interrupted.
"I had the BP company man sitting directly beside me. And he literally perked up and said 'Well my process is different. And I think we're gonna do it this way.' And they kind of lined out how he thought it should go that day. So there was short of a chest-bumping kind of deal. The communication seemed to break down as to who was ultimately in charge," Williams said.
The largest environmental disaster in US history starts because of chest bumping! This may not be surprising, but it certainly is ridiculous, disappointing, and embarrassing.
This highlights the importance of communication in the engineering world. I was told that the technical communications course I took senior year at Cornell would be the most important course I took. And I’ve found that to be true. What if there was a way (and there is) for those two men to have seen themselves on the same team, to have put their different ideas in a pile, then agreed on a way discuss the project that would result in the best all-around process? What if they were trained in how to maintain sight on the bigger picture, on all the forces at play, and not just on being “right”? What if the system was set up so that “being right” was the same thing as “finding the right answer together”?
Later in the segment we learn that if BP hadn’t won the argument, there probably wouldn’t have been a blowout:
In finishing the well, the plan was to … place three concrete plugs, like corks, in the column. The Transocean manager wanted to do this with the column full of heavy drilling fluid - what drillers call "mud" - to keep the pressure down below contained. But the BP manager wanted to begin to remove the "mud" before the last plug was set. That would reduce the pressure controlling the well before the plugs were finished.
"If the 'mud' had been left in the column, would there have been a blowout?" Pelley [the CBS interviewer] asked.
"It doesn't look like it," Bea [the expert; a UC Berkeley engineering professor] replied.
In all the cleanup work and ongoing efforts to stop the leaking, let’s not forget how this clusterf*** started. The way we’re working together IS. NOT. WORKING.
We need to:
- Bring real leadership and communication training to all ruff-n-tuff engineering leaders out there
- Teach leaders how to deepen their identity to Self so they get their egos out of the damn way when solving technical problems that have widespread, multifaceted implications.
- Provide technical tools and processes for the skill of communicating so that when differing ideas are put on the table there is a reliable, impersonal way to choose the best one.
We NEED to change the way we solve problems together if we are ever going to a) avoid the next mega-disaster and b) fix all the mega-disasters that are already ruining our planet.
Source: http://www.cbsnews.com/stories/2010/05/16/60minutes/main6490197.shtml
About: Elizabeth J. "Liz" Agnew works with individuals and teams of technical professionals on leadership development, collaboration, and strategic planning. She offers complimentary consultations with no obligation. Visit www.integrative-leadership.com or email liz@integrative-leadership.com to learn more.
More...
Friday, May 28, 2010
The Strong Boss [Matt Schlegel]
One of my clients is a strong leader. She is a strategic thinker and as smart as they come. She guides herself and her team to deliver consistently great results. Yet, she complains to me that her team fails to think for themselves. As such, she has to maintain a hands-on approach and monitor the team continuously. She finds this tiring and aggravating and wishes she could delegate more. What is happening here?
As I began to interact with my client’s team, I discovered that the team was very good at reacting to direction from the boss. The team understood that the boss highly valued action; therefore, they took direction from the boss and turned that into action as quickly as possible. There was very little need to highlight problems since the boss set the agenda on the important problems to address. Also, the team minimized analysis and planning activities since these activities took time and slowed progress toward action-oriented results.
The figure illustrates the problem-solving dynamics of this organization. The leadership style of the boss created a strong tendency towards action – Git ‘er Done (step 7). The team members attracted to this type of organization are those that respond well to that leadership style. For instance, once the boss set the direction, the team found little need for further conversation about the problem (step 1). By moving directly to step 2, people would organize and figure out how they would respond to the boss’s direction. Ideas would be generated (step 3), but the team would find there was little value in analyzing the ideas (step 4) and building plans (step 5) around those ideas. Rather, the team would present a promising idea (step 6) to the boss for review and approval. The boss, being the smart strategic person that she is, would be able to quickly assess the idea and approve it, modify it or send the team back to the drawing board. In that way, the team would quickly move into the Execution Phase (step 7.)
This action-oriented problem-solving style is very effective in that it produces results quickly. One way to characterize this method is as an iterative method. Another description is “Fail Fast.” This is a great methodology to try different approaches and quickly iterate to a successful solution. And, because the leader in this case was as talented as she is, the probability was high that the ideas she directed the team to pursue would be successful. The cost of this approach is that she had to spend a tremendous amount of energy setting direction, reviewing ideas and monitoring results.
In working with this team, I found that I had to start at the end with the neglected Debrief Step (step 8), reviewing with the team how they solve problems, and determine what was working well and what not so well. Out of this discussion came a list of potential problems (step 1) that the team considered important to address. Reviewing this list with the strong leader, we quickly came into agreement on the important problems. The big difference was that the problems were now the team’s problems, not the boss’s problems – the team was highly vested in solving these problems.
Working with the team, I had them spend more time on analyzing different ideas for solutions and putting together a well-thought-out plan before presenting the plan to the boss. The team put together a terrific proposal in which they genuinely held pride. They presented that to the boss who was equally pleased and gave the team permission to move forward, which the team did with considerable enthusiasm.
The strong boss learned how her personal leadership style was impacting the performance of the team. The problems she experienced with her team were as much the result of her own behavior as that of her team. By allowing the team some say in choosing the problems to solve, the team delivered great results and took far less oversight from the boss, which made the strong boss happy.
-------------------------------------------------------------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
As I began to interact with my client’s team, I discovered that the team was very good at reacting to direction from the boss. The team understood that the boss highly valued action; therefore, they took direction from the boss and turned that into action as quickly as possible. There was very little need to highlight problems since the boss set the agenda on the important problems to address. Also, the team minimized analysis and planning activities since these activities took time and slowed progress toward action-oriented results.
The figure illustrates the problem-solving dynamics of this organization. The leadership style of the boss created a strong tendency towards action – Git ‘er Done (step 7). The team members attracted to this type of organization are those that respond well to that leadership style. For instance, once the boss set the direction, the team found little need for further conversation about the problem (step 1). By moving directly to step 2, people would organize and figure out how they would respond to the boss’s direction. Ideas would be generated (step 3), but the team would find there was little value in analyzing the ideas (step 4) and building plans (step 5) around those ideas. Rather, the team would present a promising idea (step 6) to the boss for review and approval. The boss, being the smart strategic person that she is, would be able to quickly assess the idea and approve it, modify it or send the team back to the drawing board. In that way, the team would quickly move into the Execution Phase (step 7.)
This action-oriented problem-solving style is very effective in that it produces results quickly. One way to characterize this method is as an iterative method. Another description is “Fail Fast.” This is a great methodology to try different approaches and quickly iterate to a successful solution. And, because the leader in this case was as talented as she is, the probability was high that the ideas she directed the team to pursue would be successful. The cost of this approach is that she had to spend a tremendous amount of energy setting direction, reviewing ideas and monitoring results.
In working with this team, I found that I had to start at the end with the neglected Debrief Step (step 8), reviewing with the team how they solve problems, and determine what was working well and what not so well. Out of this discussion came a list of potential problems (step 1) that the team considered important to address. Reviewing this list with the strong leader, we quickly came into agreement on the important problems. The big difference was that the problems were now the team’s problems, not the boss’s problems – the team was highly vested in solving these problems.
Working with the team, I had them spend more time on analyzing different ideas for solutions and putting together a well-thought-out plan before presenting the plan to the boss. The team put together a terrific proposal in which they genuinely held pride. They presented that to the boss who was equally pleased and gave the team permission to move forward, which the team did with considerable enthusiasm.
The strong boss learned how her personal leadership style was impacting the performance of the team. The problems she experienced with her team were as much the result of her own behavior as that of her team. By allowing the team some say in choosing the problems to solve, the team delivered great results and took far less oversight from the boss, which made the strong boss happy.
-------------------------------------------------------------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
Sunday, May 2, 2010
Automate As Much As You Can [Rino Jose]
Automation is the ultimate delegation
One of the classic traits of an effective leader and manager is that they delegate work. They find ways to offload work to others so that they can focus on activities that have higher value to the organization. If the work that's delegated is challenging because it requires intelligence and insight, then this provides junior executives and managers with an opportunity to develop their skills. If, on the other hand, the work is doesn't require insight and thought, it becomes a distraction that prevents people from working on things that matter more. When this happens, the work should be delegated further.
Of course, the ultimate delegation is to simply automate the work. If you can automate any of your work, you should. Having people do work that can be done for them is a waste of time, effort, and money..
Capture what you've learned
Automation enables you to capture and use what you've learned. It's a way of documenting the lessons your team and organization have learned over time. It lets you leverage your project retrospectives, postmortems, and brainstorming meetings. It helps puts into practice what you've decided to do.
People are overloaded today. It's hard to find anyone who has the spare time to shepherd change through an organization. If, however, change can be automated -- at least in part -- the effort of realizing change can be greatly reduced.
Don't keep reinventing the wheel
If you haven't automated how you do typical tasks or how you collect status or how you manage projects, then your organization will reinvent these things differently each time. If you have multiple teams within your organization, each team will develop their own way of doing things. There won't be consistency in how anything is done.
Not only will people be wasting their time reinventing new ways for doing the same thing, but they will multiply the effort it takes you to understand the status of anything. You won't know where your team is at any given time. You won't have a clear view of where projects will land or where the bottlenecks are. Some people will give you spreadsheets. Some people will give you subjective reports with lots of handwaving. You'll have information fragments that don't fit together. When things go wrong, you'll be surprised. When you ask why, people will externalize blame. It might not be anyone's fault -- lacking consistency is really to blame.
Automate to get into a rhythm
Stop doing things differently each time. Use templates for your meetings. Document your workflows (more in an upcoming post). Use tools to automate as much as you can.
Automation helps you get into a rhythm. It provides the infrastructure for your work. It enables you to apply your skills and insight directly to your problems instead of wasting effort on figuring out how to apply them.
When you automate things, people know what to expect. Each time you perform a certain type of work, it becomes easier to do. Every team starts executing consistently. Your teams will find their rhythm and their pace. Your teams will develop organizational momentum.
Keep questioning what you automate
Building organizational momentum is great. Teams are more effective. People have greater impact. Everything runs better. However, don't forget to question what you automate.
When we learn new lessons or when the environment in which we work changes, we need to ask if we're still automating the right things. If something is no longer necessary, we should drop it. If we're missing something, we should add it. If what we're automating isn't working, we need to fix it.
We automate to make ourselves more effective, not to stop thinking. It's ok to create and use cogs to make our jobs easier; it's not ok to become one.
(originally posted on Management Revolution)
_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...
Wednesday, April 28, 2010
All in the Family [Matt Schlegel]
One of my clients is a small-sized, innovative technology company that has been in business for over 20 years. It is a self-funded, privately held company with no venture backing. The company is like a family; it is not uncommon for an employee to say they have been with the company over 15 years. At no other technology company have I felt that the company is as much a family as it is a corporation. Working with such a close-knit group can be a double-edged sword. That is why they asked me to help.
People who work together for many years come to know each other’s strengths and weaknesses very well. They come to accept one another and resolve to work with each other through any situation. This resolution often requires being sensitive to other’s feelings and needs and taking an approach that minimizes conflict and drama in order to keep focused on getting the job done. The downside of this approach is that people will tend to downplay problems for the sake of maintaining group harmony.
My client is a group of some of the kindest, most helpful people I have ever had the pleasure to work with. Some of the adjectives that I would use to describe this group are helpful, creative, analytical, cautious and enthusiastic. Two adjectives that I would not use to describe this group are perfectionist and assertive. Yes, this group appears to have weeded out anyone who would be unwilling to put up with the problems of others and anyone who would be assertive to the point of ruffling feathers. Not that this does not happen from time to time, but this is the exception rather than the rule.
The figure shows the problem-solving dynamic that tends to occur at the company. First, there is a great reluctance to acknowledge that there is a problem in the first place. There are no systems in place to identify and report problems to the group in a systematic way. As such, most problems are raised via the squeaky-wheel method. (Cliché: Squeaky wheel gets the grease.) Once someone has a big enough problem and shares that with the right person at the company, the helpful nature of the team kicks in. They want to solve the problem for that person. The company has great strength in creativity and analysis. They bend over backwards and find a creative solution to solve that particular problem. The team will get the thrill of moving towards solving the problem. If the problem is easy enough, it will get addressed. However, if solving the problem requires any transformative change to the way the team has historically worked, there is no one there assertive enough to move the team through that transformation. The problem is addressed to the point that the squeak stops, and the team moves on to the next squeak.
With this client, my two main jobs have been to fill the role of the perfectionist and the asserter. I have helped the company put in place the tools for collecting data, analyzing the data and reporting problems. As the data reveal the problems, the helpful nature of the team kicks in and moves the team smoothly through the problem-solving process. Then, it is my role to serve as the asserter to nudge the team through any transformative changes that will help them resolve their longer term, systematic problems.
This problem-solving framework gives me the tools to understand both the steps of effective problem solving and the interpersonal dynamics that will influence the team’s progression through those steps. It also gives me the tools to explain to my client what may be missing in their skill set that is impeding them from becoming effective problem solvers.
---------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
People who work together for many years come to know each other’s strengths and weaknesses very well. They come to accept one another and resolve to work with each other through any situation. This resolution often requires being sensitive to other’s feelings and needs and taking an approach that minimizes conflict and drama in order to keep focused on getting the job done. The downside of this approach is that people will tend to downplay problems for the sake of maintaining group harmony.
My client is a group of some of the kindest, most helpful people I have ever had the pleasure to work with. Some of the adjectives that I would use to describe this group are helpful, creative, analytical, cautious and enthusiastic. Two adjectives that I would not use to describe this group are perfectionist and assertive. Yes, this group appears to have weeded out anyone who would be unwilling to put up with the problems of others and anyone who would be assertive to the point of ruffling feathers. Not that this does not happen from time to time, but this is the exception rather than the rule.
The figure shows the problem-solving dynamic that tends to occur at the company. First, there is a great reluctance to acknowledge that there is a problem in the first place. There are no systems in place to identify and report problems to the group in a systematic way. As such, most problems are raised via the squeaky-wheel method. (Cliché: Squeaky wheel gets the grease.) Once someone has a big enough problem and shares that with the right person at the company, the helpful nature of the team kicks in. They want to solve the problem for that person. The company has great strength in creativity and analysis. They bend over backwards and find a creative solution to solve that particular problem. The team will get the thrill of moving towards solving the problem. If the problem is easy enough, it will get addressed. However, if solving the problem requires any transformative change to the way the team has historically worked, there is no one there assertive enough to move the team through that transformation. The problem is addressed to the point that the squeak stops, and the team moves on to the next squeak.
With this client, my two main jobs have been to fill the role of the perfectionist and the asserter. I have helped the company put in place the tools for collecting data, analyzing the data and reporting problems. As the data reveal the problems, the helpful nature of the team kicks in and moves the team smoothly through the problem-solving process. Then, it is my role to serve as the asserter to nudge the team through any transformative changes that will help them resolve their longer term, systematic problems.
This problem-solving framework gives me the tools to understand both the steps of effective problem solving and the interpersonal dynamics that will influence the team’s progression through those steps. It also gives me the tools to explain to my client what may be missing in their skill set that is impeding them from becoming effective problem solvers.
---------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
Saturday, April 24, 2010
Meetings as Performance [Rino Jose]
When you view meetings as a performance, you're practicing something similar to servant-leadership. Instead of demanding people's attention, you earn it. Instead of holding court, you're on stage. It's still your show, but you want people to enjoy it.
When your meeting is a performance, you'll approach it differently. You'll spend time preparing for it. You'll work to make sure everyone's engaged. You'll discuss things that matter. You'll become more animated. You'll think through what you're going to say. Your meetings will have life and energy. Your meetings will have an arc and a story. Your meetings will have a point.
When you play the role of someone on stage, the attendees play the role of the audience. Certain expectations are established naturally. You are there to inspire, entertain, elucidate; they are there to watch, listen, participate -- no cell phones or e-mail during the performance. When you perform well, no one will be bored, and people (including yourself) will look forward to each meeting.
Looking at meetings this way gives you a chance to hone your presentation skills and to practice public speaking. Weekly meetings, in particular, give you a great venue to experiment with different styles and approaches. Vary what you do each week. See what works best for you. Build up your repertoire.
Another benefit to viewing meetings as a performance: it helps you lead change. When you deliver a solid performance, you connect with your audience at an emotional level. You'll find it easier to deliver tough messages and convince people to try something new. When people decide to change, it's usually based on emotion first and then rationalized afterwards. If you can get people to laugh, you can get them to change.
(originally posted on Management Revolution)
_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...
When your meeting is a performance, you'll approach it differently. You'll spend time preparing for it. You'll work to make sure everyone's engaged. You'll discuss things that matter. You'll become more animated. You'll think through what you're going to say. Your meetings will have life and energy. Your meetings will have an arc and a story. Your meetings will have a point.
When you play the role of someone on stage, the attendees play the role of the audience. Certain expectations are established naturally. You are there to inspire, entertain, elucidate; they are there to watch, listen, participate -- no cell phones or e-mail during the performance. When you perform well, no one will be bored, and people (including yourself) will look forward to each meeting.
Looking at meetings this way gives you a chance to hone your presentation skills and to practice public speaking. Weekly meetings, in particular, give you a great venue to experiment with different styles and approaches. Vary what you do each week. See what works best for you. Build up your repertoire.
Another benefit to viewing meetings as a performance: it helps you lead change. When you deliver a solid performance, you connect with your audience at an emotional level. You'll find it easier to deliver tough messages and convince people to try something new. When people decide to change, it's usually based on emotion first and then rationalized afterwards. If you can get people to laugh, you can get them to change.
(originally posted on Management Revolution)
_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...
Thursday, April 15, 2010
Bumps and Dips on the Path to Solving your Problem [Matt Schlegel]
In past blogs I have described a problem-solving process. When I describe it, it is a nice smooth process flowing from one step to the next. Funny thing is, when you use the process in practice, it may not be so smooth. What if we could look down the path to anticipate likely bumps and dips in the process. We may not be able to avoid those obstacles, but we can brace ourselves to move through them. In this blog I will describe a method to let my fellow problem solvers identify in advance those bumps and dips.
People tend to play to their strengths and avoid their weaknesses. Your problem-solving team is comprised of people and their various strengths and weaknesses. Depending on where you are in the problem-solving process, your team members will resonate or not with the phase at hand. If the phase requires a strength that is absent in your team, the team can get stuck and have trouble moving to the next phase. If the team is overrepresented by a particular strength, again the team can get stuck or repeatedly go back to the overrepresented step.
The figure illustrates a team that is generally well represented by team members with various strengths, but has an underrepresentation in the Get It Done Step (step 7) and over representation in the Identify the Problem Step (step 1). What can happen in this case is that team would move around the process to the point of underrepresentation, get stuck, and then move back to the overrepresented step, a discussion about what is wrong, without ever taking the action to solve the problem.
This is just one example. You can see that depending on your team make-up, there can be any number of bumps and dips encountered as you move around the process. It is important for the facilitator of process to understand the team make-up, anticipate the trouble spots, and ensure that the team can move through the obstacle. In the example above, the facilitator needs to clearly identify the Driver role in step 7 and ensure that that role is filled with a willing and able team member. Also, when the team restarts the discussion about the problem, the facilitator needs pull the team back on track by reminding the team that a problem statement already exists.
As I work with teams and see how the strengths and weaknesses influence progress, I realize that there are many well-known clichés that describe these bumps and dips. To name a few: paralysis by analysis, half baked idea, heart in the right place, look before you leap, etc. On your problem-solving teams, what bumps and dips have you encountered and what clichés have come to mind?
_______________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
People tend to play to their strengths and avoid their weaknesses. Your problem-solving team is comprised of people and their various strengths and weaknesses. Depending on where you are in the problem-solving process, your team members will resonate or not with the phase at hand. If the phase requires a strength that is absent in your team, the team can get stuck and have trouble moving to the next phase. If the team is overrepresented by a particular strength, again the team can get stuck or repeatedly go back to the overrepresented step.
The figure illustrates a team that is generally well represented by team members with various strengths, but has an underrepresentation in the Get It Done Step (step 7) and over representation in the Identify the Problem Step (step 1). What can happen in this case is that team would move around the process to the point of underrepresentation, get stuck, and then move back to the overrepresented step, a discussion about what is wrong, without ever taking the action to solve the problem.
This is just one example. You can see that depending on your team make-up, there can be any number of bumps and dips encountered as you move around the process. It is important for the facilitator of process to understand the team make-up, anticipate the trouble spots, and ensure that the team can move through the obstacle. In the example above, the facilitator needs to clearly identify the Driver role in step 7 and ensure that that role is filled with a willing and able team member. Also, when the team restarts the discussion about the problem, the facilitator needs pull the team back on track by reminding the team that a problem statement already exists.
As I work with teams and see how the strengths and weaknesses influence progress, I realize that there are many well-known clichés that describe these bumps and dips. To name a few: paralysis by analysis, half baked idea, heart in the right place, look before you leap, etc. On your problem-solving teams, what bumps and dips have you encountered and what clichés have come to mind?
_______________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...
Wednesday, April 14, 2010
The Knowing-Doing Gap [Kimberly Wiefling]
If knowing “HOW” to do something were enough we’d all be rich and thin. There’s always some reason why well-intentioned, educated, experienced professionals are doing the opposite of what they know makes sense. Frequently it’s because they are really busy, and can’t possibly do what needs to be done until someone ELSE changes first, usually their boss, or someone in a different department. “If only” someone or something else would change then THEY would be able to do what they need to do to accomplish the goals.
A whole book on “The Knowing-Doing Gap” was written on this by two professors of Stanford University when they realized that their colleagues at the Stanford Business School didn’t follow the principles that they taught when they themselves were leading companies. It happens in engineering teams, too. If you want an example of the knowing-doing gap in engineering teams, just consider numerous studies that indicate that the top reason that teams fail is for lack of clear goals. What could possibly be more important for an engineering manager than clarifying goals and communicating them to the team?
Alas, common sense is NOT common practice. What is the source of the Knowing-Doing Gap?
FAIL – The 4 legs on the stool causing the knowing-doing gap and preventing people from crossing it are:
· Fear of Failure – If you’re not allowed to fail you must be careful what you start!
· Aversion to Planning – Studies have proven that, given a choice, people prefer not to plan. At the same time, we also know that planning dramatically improves results.
· Instinct for Competition – The win-lose frame is the first assumption for many people in any situation involving another person. Fear of losing, tied into #1, prevents people from even playing the game.
· Learned Helplessness – “It’s not my fault!”, and “They are doing it to me” thinking. The research on this is absolutely shocking.
The difference between someone occupying an engineering leadership position and a true engineering leader is that the pros do what is required whether they feel like it or not, whether they think they have time or not – no excuses! Winston Churchill is one of my favorite leadership role models and he said “Sometimes doing your best is not enough. Sometimes you must do what is required!” Yeah, that’s right, Winston.
Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.
More...
A whole book on “The Knowing-Doing Gap” was written on this by two professors of Stanford University when they realized that their colleagues at the Stanford Business School didn’t follow the principles that they taught when they themselves were leading companies. It happens in engineering teams, too. If you want an example of the knowing-doing gap in engineering teams, just consider numerous studies that indicate that the top reason that teams fail is for lack of clear goals. What could possibly be more important for an engineering manager than clarifying goals and communicating them to the team?
Alas, common sense is NOT common practice. What is the source of the Knowing-Doing Gap?
FAIL – The 4 legs on the stool causing the knowing-doing gap and preventing people from crossing it are:
· Fear of Failure – If you’re not allowed to fail you must be careful what you start!
· Aversion to Planning – Studies have proven that, given a choice, people prefer not to plan. At the same time, we also know that planning dramatically improves results.
· Instinct for Competition – The win-lose frame is the first assumption for many people in any situation involving another person. Fear of losing, tied into #1, prevents people from even playing the game.
· Learned Helplessness – “It’s not my fault!”, and “They are doing it to me” thinking. The research on this is absolutely shocking.
The difference between someone occupying an engineering leadership position and a true engineering leader is that the pros do what is required whether they feel like it or not, whether they think they have time or not – no excuses! Winston Churchill is one of my favorite leadership role models and he said “Sometimes doing your best is not enough. Sometimes you must do what is required!” Yeah, that’s right, Winston.
Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.
More...
Thursday, April 8, 2010
Getting Really Good at Agile [Ron Lichty]
From the speaker at the next Engineering Leadership SIG event, April 15, 2010:
The first half of Mike Cohn's book, "Succeeding with Agile: Software Development Using Scrum", isn't so much about how to be successful with agile as how to be successful replacing non-agile with agile, selling agile, and transitioning to agile.Mike Cohn is neither a wild-eyed dogmatist professing the one true way nor an ivory-tower philosopher; he's a pragmatist. He devotes entire chapters to helping scrum evangelists decide whether to start with a pilot or go all-in across the organization, whether to pilot publicly or in stealth, what factors might prevent success, how to swing things your way, how to approach a transition in steps, picking the right first project and first team, and how soon to adopt agile technical practices like simple design, pair programming, TDD, continuous builds, refactoring, and automated testing. He notes from the first chapter that agile implementations are hard and don't always "take" - and explains why. He recommends solutions to the many conundrums and traps that agile teams face.
About midway through the book, as you're reading insights into teamwork, you realize that this book is not just about transitioning to agile but about getting really good at agile - and that you're going to need to read it not just once but come back to it for new insights again and again. The fact is it's stuffed with tips, guides, data, approaches, failures, successes, and helpful hints of every kind.
Part of what makes this book important for me is repeatedly reading observations consistent with my own experience, but drawing on so many more experiences with agile that it results in emergent patterns, as well as in truths that are too often left unsaid. Then there are the surprises that come from reading an author who is remarkably well-read across genres. He does us all the favor of reviewing and summarizing scads of studies and surveys that demonstrate why agile is worth the effort, with data on productivity gains, lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality and, importantly, stakeholder satisfaction gains.
What's the role of a manager of a self-organizing team? One of them, agile gurus seem to agree, is exercising subtle control (as opposed to command-and-control) and Mike provides an entire framework for debugging team problems and influencing their success. This will be one of those chapters I know I'll revisit repeatedly.
In another example, Mike remarkably provides what in essence is a crash course in change, and that chapter alone, while loaded with specifics about making a change to agile, could be used by any technical leader making a technology-and-culture change of any kind. Know why shopping carts were introduced and how shoppers were convinced to use them? Mike does, and effectively uses the example to teach change leadership. How does a leader deal with the skeptics and the saboteurs, the diehards and the followers certain to show up on your teams? How do you sway the uncertain to get on board?
Cohn is practical right down to the challenges from facilities and h.r., the likelihood agile transitions will face waterfall-driven expectations, and strategies for coexisting with other approaches, regulatory standards and processes. Importantly, he provides helpful anecdotes and examples from companies large and small. He's familiar enough with other process changes your company may have attempted to be able to compare and contrast and differentiate the substance and style of scrum from everything that came before.
While Cohn is sometimes unsatisfying - drilling down not quite far enough in sharing what's worked - in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.
Finally, I should point out that though it may not be immediately obvious, there's one more group of readers for whom this book has enormous value: Agile wannabes who know their current process isn't working. They frequently have heard of agile but have no idea what it looks like or how to sell it. If you're one of those, you also need to read this book. Mike Cohn over and over offers advice and examples and data that will give you aha after aha as you build a picture of what a truly effective process can look like - and how yours could become functional like his.
If you're interested, there's a longer version of this review at:
http://ronlichty.blogspot.com/2010/04/book-review-succeeding-with-agile.html
_________________________________________
Ron Lichty is a "VPE of Fix-It," providing interim and on-demand VP Engineering services to optimize software organizations and efforts. He specializes in solving problems like painfully slow product development, past-due estimates with no delivery in sight, snafus from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be proactive, and teams unable to break out of research and move on to development and delivery. He also untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Small tweaks, dramatic impacts. He'll be presenting the SDForum's April 15 Engineering Leadership SIG topic on how agile changes the development manager role group in Palo Alto: "If Agile Teams Are Self-Directing, What Do Managers Do?" His book on managing software developers and software development teams, "Managing the Unmanageable: Rules, Tools, and Wisdom for Managing Software People and Projects", is forthcoming.
More...
The first half of Mike Cohn's book, "Succeeding with Agile: Software Development Using Scrum", isn't so much about how to be successful with agile as how to be successful replacing non-agile with agile, selling agile, and transitioning to agile.Mike Cohn is neither a wild-eyed dogmatist professing the one true way nor an ivory-tower philosopher; he's a pragmatist. He devotes entire chapters to helping scrum evangelists decide whether to start with a pilot or go all-in across the organization, whether to pilot publicly or in stealth, what factors might prevent success, how to swing things your way, how to approach a transition in steps, picking the right first project and first team, and how soon to adopt agile technical practices like simple design, pair programming, TDD, continuous builds, refactoring, and automated testing. He notes from the first chapter that agile implementations are hard and don't always "take" - and explains why. He recommends solutions to the many conundrums and traps that agile teams face.
About midway through the book, as you're reading insights into teamwork, you realize that this book is not just about transitioning to agile but about getting really good at agile - and that you're going to need to read it not just once but come back to it for new insights again and again. The fact is it's stuffed with tips, guides, data, approaches, failures, successes, and helpful hints of every kind.
Part of what makes this book important for me is repeatedly reading observations consistent with my own experience, but drawing on so many more experiences with agile that it results in emergent patterns, as well as in truths that are too often left unsaid. Then there are the surprises that come from reading an author who is remarkably well-read across genres. He does us all the favor of reviewing and summarizing scads of studies and surveys that demonstrate why agile is worth the effort, with data on productivity gains, lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality and, importantly, stakeholder satisfaction gains.
What's the role of a manager of a self-organizing team? One of them, agile gurus seem to agree, is exercising subtle control (as opposed to command-and-control) and Mike provides an entire framework for debugging team problems and influencing their success. This will be one of those chapters I know I'll revisit repeatedly.
In another example, Mike remarkably provides what in essence is a crash course in change, and that chapter alone, while loaded with specifics about making a change to agile, could be used by any technical leader making a technology-and-culture change of any kind. Know why shopping carts were introduced and how shoppers were convinced to use them? Mike does, and effectively uses the example to teach change leadership. How does a leader deal with the skeptics and the saboteurs, the diehards and the followers certain to show up on your teams? How do you sway the uncertain to get on board?
Cohn is practical right down to the challenges from facilities and h.r., the likelihood agile transitions will face waterfall-driven expectations, and strategies for coexisting with other approaches, regulatory standards and processes. Importantly, he provides helpful anecdotes and examples from companies large and small. He's familiar enough with other process changes your company may have attempted to be able to compare and contrast and differentiate the substance and style of scrum from everything that came before.
While Cohn is sometimes unsatisfying - drilling down not quite far enough in sharing what's worked - in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.
Finally, I should point out that though it may not be immediately obvious, there's one more group of readers for whom this book has enormous value: Agile wannabes who know their current process isn't working. They frequently have heard of agile but have no idea what it looks like or how to sell it. If you're one of those, you also need to read this book. Mike Cohn over and over offers advice and examples and data that will give you aha after aha as you build a picture of what a truly effective process can look like - and how yours could become functional like his.
If you're interested, there's a longer version of this review at:
http://ronlichty.blogspot.com/2010/04/book-review-succeeding-with-agile.html
_________________________________________
Ron Lichty is a "VPE of Fix-It," providing interim and on-demand VP Engineering services to optimize software organizations and efforts. He specializes in solving problems like painfully slow product development, past-due estimates with no delivery in sight, snafus from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be proactive, and teams unable to break out of research and move on to development and delivery. He also untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Small tweaks, dramatic impacts. He'll be presenting the SDForum's April 15 Engineering Leadership SIG topic on how agile changes the development manager role group in Palo Alto: "If Agile Teams Are Self-Directing, What Do Managers Do?" His book on managing software developers and software development teams, "Managing the Unmanageable: Rules, Tools, and Wisdom for Managing Software People and Projects", is forthcoming.
More...
Subscribe to:
Posts (Atom)
