Say that you're nobody's boss, you're just a cog in the big machine (so to speak). How do you get anything done? A technique IBM (and others?) terms "collaborative influence."
Collaborative influence is another topic discussed in "IBM's Management Makeover
" (Nov. 2004) in Fast Company
magazine, the same article that discussed how IBM Customers Are Clients
The 33 leaders [who had been identified as outstanding leaders in the new on-demand era] were also adept at a skill IBM calls "collaborative influence." In a highly complex world, where multiple groups might need to unite to solve a client's problems, old-style siloed thinking just won't cut it, and command-and-control leadership doesn't work. "It's really about winning hearts and minds -- and getting people whose pay you don't control to do stuff," says Mary Fontaine, vice president and general manager of Hay's McClelland Center for Research and Innovation.
So collaborative influence is how you work with people you have no direct control over, yet persuade them to do what you'd like, what is hopefully beneficial for the group.
I wasn't familiar with this term, but as a consultant to some of IBM's WebSphere clients
, I often feel like this sort of persuasion is the only real power I have. I can't fire anyone; in fact, if anything, they can "fire" me (from their project, not IBM). Yet I need to convince them to stop doing some of what they're doing, since apparently that's limiting their success with WebSphere products, and start doing things differently, even though they may well not want to.
I'd argue that in our modern workplaces, and in life in general for that matter, the only real power any of us really has is collaborative influence. We all work with lots of people we can't fire, yet whom we need to persuade to take certain actions to help all of our success. Even bosses have pretty limited authority: Yeah, they can fire you; but if you have good skills, you'll just go get another job somewhere else, and now your boss and his/her team are without the benefit of your skills. D'oh!
The best bosses, I find, are those who attract the best people they can find to their teams, encourage everybody to work together, and then get out of the way. That's collaborative influence.
I think collaborative influence is an important component of leadership
, a quality we all need to get better at. Many of the non-programming books I read are on leadership, teamwork, and that sort of thing; I'd suggest you should too.
I'm pleased to find that IBM has an article on collaborative influence called "Changing Minds
You can upgrade your IT. You can rewrite your processes. But you won't change your business if you can't change your people--how they think, how they work together and how they use the resources around them.
Changing the culture of your company isn't easy. It takes time, effort and a very specific kind of leadership. To learn more about it, we spoke to IBM's Senior Vice President Linda Sanford and General Manager Ross Mauri.
It's on a section of our web site called "Boost team performance
," kind of a developerWorks
for workplace skills. It has articles, case studies, and executive guides. (Shockingly enough, we even have some services
we'll sell you to help you achieve this.) The theme of boost team performance:
Bring your people, departments and partners together to boost productivity, streamline the workload and sharpen employee training for a constantly changing world.
So not only is your IT on-demand, your whole company and workplace is an On Demand Business
. Yeah, this gets kind of hypish, but the focus here is on helping people to work together, and I think that's important.
So, do you have collaborative influence? What can you do to get more? How can you use it to do your job better?
Newsweek is running an article, "Google: Ten Golden Rules
." It focuses on the care and feeding of knowledge workers.
Getting the most out of knowledge workers will be the key to business success for the next quarter century. Here's how we do it at Google.
The golden rules are:
- Hire by committee
- Cater to their every need
- Pack them in
- Make coordination easy
- Eat your own dog food
- Encourage creativity
- Strive to reach consensus
- Don't be evil
- Data drive decisions
- Communicate effectively
Check out the article; I think it's real good stuff.
For more Google posts, see Google users wealthier, more Net savvy
, Google Video of the Day
, and especially Google Base
(which links to more posts). For some discussion on IBM's values, see IBM Values
, IBM Customers Are Clients
, and Collaborative Influence
Success as a knowledge worker requires cooperation.
Here's a quote that jumped out at me:
Some analysts even argue that men are less suited than women to the knowledge economy, which rewards supposedly female traits such as sensitivity, intuition, and a willingness to collaborate. "Men have tended to do better in the hierarchies, following orders and relying on positional power," says Andy Hines
It's from the article "The Slump: It's a Guy Thing
" in the May 19 issue of Business Week
. It talks about how the current US recession is concentrated in manufacturing and construction, which is typically staffed by male workers, whereas industries with more female workers like education and health care are still growing.
None of that has much to do with IT, but the quote above sure does. As the quote points out, to be successful as a knowledge worker (which is what most (all?) of us are), you need to be able to work well with others. It's by collaborating with others that we're able to do our jobs successfully. Ironic considering that computer programmers aren't exactly known for being social. Our jobs aren't just about learning the latest technology fad, but about being able to work together; in fact, the latter is actually more important.
Technorati Tags: leadership, knowledge worker, knowledge economy, business week || Digg it | Slashdot it | Post to del.icio.us |
Want your manager to regard you as truly great talent? Try to follow these habits.
I'm interested in what sorts of employees make their companies stronger. I discuss this from time to time under the heading of "leadership" (blog thread
, wiki page
I talk about this particular topic in Habits of Truly Great Talent
(on my wiki).
Technorati Tags: leadership, employee, nanobots, jim collins, wall street journal, fortune || Digg it | Slashdot it | Post to del.icio.us |
The December 12th issue of Fortune magazine
is titled "How to Become a Great Leader."
|The cover article, "The Education of Andy Grove," is excerpts from a forthcoming book. Some of the episodes described are interesting, like deciding not to license the 386 to other chipmakers ("The Reality Shifter") and deciding not to scrap the CICS design for RISC (the first episode in the article); but most of the episodes are a bit tedious and short on insight. I hear Grove's autobiographical books (High Output Management and Only the Paranoid Survive) are really good; the forthcoming The American: The Life and Times of Andy Grove doesn't look nearly as good, judging by the Fortune article. Likewise, "10 Top Leaders Tell Their Secrets" isn't real helpful for us J2EE developer types.|
However, two other articles interview Fred Brooks and discuss insights from Peter Drucker. Those are good (IMHO), so I'll discuss them next.Dec 22 Update
: My colleague Dave Artus has added a good comment (disagreeing with me, no less!), so please click on that link.[Read More
Antipatterns should be ameliorative. For that matter, patterns should be too. For that matter, so should you, at least in the way you do your job.Ameliorate
(verb): to make a situation better or more tolerable
I've been talking about antipatterns
. It's not just enough for an antipattern
to give a common solution, to say "Bet you did this, didn't you? D'oh!" It then needs to offer a preferred solution. This makes the document ameliorative; it helps the reader understand not just why their situation sucks, but also figure out how to make their situation better.
Any pattern should be ameliorative. It tells the reader what to do to make their situation a good one, perhaps better than it was, in any event better than it would be if they applied a less-than-best practice. If a pattern documents an approach which is not ameliorative, whatever it's documenting is not much of a pattern.
When you're doing your job, are you ameliorative? Are you making the situation better? Or worse? Perhaps you're trying to make it better but the situation fights back; that's just a bad (but common) situation. But in a reasonable situation, if you're not helping to make things better, why not? See the importance of leadership
. Leaders ameliorate.
So, be ameliorative. Get out there and ameliorate.
What kind of employees does Wikipedia hire?
I discuss that a little bit in Wikipedia Employee Traits
, including the lessons for all of us. It's part of my Leadership
topic. I hope you find it helpful.
Technorati Tags: leadership, wikipedia, employee, jimmy wales, volunteer, fortune || Digg it | Slashdot it | Post to del.icio.us |
A reader pointed me to his blog, which has a really interesting premise.
The blog is Leadership by Numbers
, authored by Jack Dausman. Thanks to Jack for pointing me/us all to it in his comment on Social Network Analysis
. I don't know Jack and have only looked at his blog a little bit, but I love the premise:
As kids, we made art with paint-by-number kits. Simply matching the outline numbers with an oil paint gave us the illusion of mastery. Today, I'm in IT management in Washington, DC: consulting, systems administration, development & training. And, I still see a lot of paint-by-number projects which try to be the real thing. IT leadership is about reading the numbers, then going outside the lines and taking risks.
Now that is an excellent analogy for how I feel about heavyweight software methodologies! All too often, people are following all the steps but totally missing the point of producing good software. One colleague recently told me, "Sub-average programmers aren't successful with agile methodologies." I responded, "As compared to what? Sub-average programmers certainly aren't successful with heavyweight methodologies! They're not successful with anything; that's what makes them sub-average." Paint-by-numbers doesn't make you an artist, and methodologies by themselves don't make you good at developing software.
For more thoughts along these lines, check out how complicated use cases have gotten
What if everyone graded your boss and everyone knew what grade he got?
"The Employee Is Always Right
" (Business Week) talks about India's HCL Technologies, which pretty much does this. They not only do they have 360-degree reviews, where an employee is evaluated not only by his managers but also his peers and those whom he manages. They also post those results where everyone who evaluated an employee can see his evaluation. The idea is to make the employee responsive to everyone he works with. The CEO, Vineet Nayar, is using this as a technique to attract and retain top talent.
Some quotes I like:
"In our day and age, it's the employee who sucks up to the boss," says Nayar. "We are trying, as much as possible, to get the manager to suck up to the employee."
"We're seeing more innovative methods coming from [emerging markets]...on how to structure and lead organizations," says Linda A. Hill [a Harvard Business School professor]
How likely are you to recommend us to a friend?
This is the question posed to determine your Net Promoter Score
(on my wiki
I also like to look at this as: How likely are you to seek my help again?
So what does this have to do with leadership? Think about who you've worked with today: How would they rate your performance? Would they like to work with you again? If not, how well are you really doing your job?
How would your family rate you? Friends? Neighbors? Local law enforcement officials? Do they like dealing with you? Would they like to again?
If your professional and personal interactions have more detractors than proponents, what can you do about that?[Read More
IBM has published a set of values that help guide the company, namely its employees, and how we work with clients.
As documented in Our Values at Work on being an IBMer
and elaborated on in Corporate profile: Values
, the values are:
- Dedication to every client's success -- IBM's relationships with its clients are no longer based on product sales, but often on deep, long-term partnerships built around our knowledge of each client's business and the market environment.
- Innovation that matters, for our company and for the world -- At their best, IBM's innovations transcend the technology industry, enabling others to innovate as well. We also pursue innovation in education, work/life balance, environmental protection, and all the ways a company organizes and runs itself.
- Trust and personal responsibility in all relationships -- The heart of IBM is the personal commitment each IBMer makes to building and preserving trust even if things don't go smoothly with all the constituencies of our business: clients, partners, communities, investors and fellow IBMers.
Yeah, hoopla, but I can tell you, IBM reminds us employees of this stuff all the time and really expects us to live it. It's the basis of our Business conduct guidelines
. It guides us on making sure to treat our clients
right, work on what's important, and stay out of trouble.
These values are discussed in--you guessed it, my favorite year-old article that I just discovered this week--"IBM's Management Makeover
" (Nov. 2004) in Fast Company
magazine, the article that also discusses how IBM Customers Are Clients
and Collaborative Influence
. The article casts the values as "IBM's New Leadership Traits," which ties in nicely to the leadership stuff I've been thinking about.
These values seem to have spawned imitation, if not word-for-word duplication. A company called BizAtomic
appears to have cribbed our values
. Ditto for the CEMA Territory Champion award
, and for ProGroup
. Two of the three values of JSB Intelligence
seem familiar (guess they don't innovate). But I guess that's the sincerest form of flattery
. Although I might quibble about the irony of apparently plagiarizing the wording of a value espousing trust and personal responsibility. D'oh!
(Disclaimer: I'm not trying to talk trash about any of these companies, and I don't know for sure where they got their wording from. But they
appear to be copying IBM, and not giving IBM credit.
Here's where you can do some more reading about these values:
Three new authors have been added to WebSphere: Author spotlight
: Joey Bernal
, Steph Parkin
, and me
The Author Spotlight highlights people who have published a lot of articles about WebSphere products
. Each author usually has his or her themes, so it's good to find an author whose themes match your interests. For example, Joey writes about Portal, and Steph writes about how to use tooling like RAD 6
The spotlight on an author is useful in two ways. One, it lists in one place all of his/her articles and other publications, so that you can more easily find what all he/she has written. Two, it lists other publications the author finds helpful, which makes a good reading list of other stuff for you to go check out. For example, both Joey and Steph recommend The Soul of a New Machine
, so that sounds like a good book to go check out.
In my recommended reading list, I've listed the books I think any J2EE developer should have on his bookshelf. Need to learn UML? I've listed a book for that. Use cases? A book for that too. Lots of patterns books. And some books on leadership too, because I'm finding that ability to be as important to a project's success as technical ability.
Fortune magazine has published some excerpts from Peter Drucker.
The article is Advice From the Master
. It's listed online as part of Fortune's "How to Become a Great Leader" issue
(but it doesn't seem to be in the printed magazine).
Drucker's take is that executives should look for collegues with specific strengths, not generalists that tend to be mediocare. I think that applys to technical people as well, that good teams tend to have people with different strengths; as long as the people work together well (and that's a big if), the team's total talent is greater than the sum of its member's talent.
I would take this one step further. It's easy to attend a meeting of whatever development team you happen to be part of, look around the table at your teammates and think "He's good. That guy's terrible. She's good. She's not." and so on. It's tempting to look at people that way, but not very helpful. Good managers I've worked for try to figure out what each team member is good at, then see how to apply those abilities to benifit the project. That way, everyone contributes. Given, sometimes you have a team member with little talent or a lousy attitude, who consistantly contributes little to any project. That's a person who needs to re-evaluate their career choice, before their employeer does it for them. But most people have something good to contribiute; good managers look for slots that fit their talents and preferences. This works better than trying to force fit staff members into slots that fit the project better than the people staffing the project.
So look around the table and think about what each team member is good at. And think about what you're good at. Then think about how you can work with them to put what you're good at together with what they're good at. I think you'll find you'll wind up with a team capable of producing much more than you could yourself, even if everybody isn't good at everything.
For a while now, we've had this thing going on inside of IBM. We're not supposed to call the people who buy our stuff "customers" anymore, we're supposed to call them "clients." What's that all about?
It's explained in "IBM's Management Makeover
" (Nov. 2004) in Fast Company
To begin with, the best executives no longer thought of the folks to whom they sold stuff as customers; they saw them as clients. The difference? "A customer is transactional," says Harris Ginsberg, IBM's director of global executive and organization capability. "A client is somebody with whom you have a longstanding relationship and a personal investment." It's no longer enough to sell a customer a server. An IBMer should be so focused on becoming a long-term trusted partner that she might even discourage a client from buying some new piece of hardware if it's in the client's best interest to hold off.
So a customer is a one-time sale. A client is an ongoing relationship, with additional sales from time-to-time as needed. We want a buyer to be customer again and again; that's a client. And check out that last part: We don't want to sell you something if we think you don't need it! Such a sale might be good for a customer, but not a client.
Personally, the term "client" kinda messes me up, because it makes me think of client/server and EJB clients. Then again, maybe IBM is and should act that way to its buyers, acting as a server providing services (hardware, software, knowledge workers). Anyway, I guess I'm just getting too caught up in computer-speak and need to adjust more to business-speak in this case.
Our CEO, Sam Palmisano
, talked out the customer/client difference in this article in Fortune magazine, "Can IBM Get Great Again?
" (but you need a subscription). Here's some guy talking about very much the same thing: What You Call Your Customers Matters.
I've started a thread on my wiki
The first real content so far is a snippit called "Good-Guy Power
." I found it thought provoking; I hope you will too.[Read More