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.
Bobby Woolf: WebSphere SOA and JEE in Practice
Matching: leadership X
It seems to me that there are two main aspects to doing a good job in a technical role: Technical proficiency and leadership ability. Many of us tend to focus on the first one; we need to focus on the second one as well.
By "leadership," I don't necessarily mean "being in charge," I mean being influential and persuasive. You've probably at some point worked for a manager who was a poor leader but nevertheless was still your boss. Leadership is not a title that can be bestowed upon you by your company or community; it's a quality of how you conduct yourself and work with others. Many development teams have someone who, when he/she speaks up, everyone listens to what they're saying and is inclined to go along because they're usually right; such a person may be "just a programmer" like everyone else, not a project lead or a manager, but they are a leader because they suggest a course of action that the rest of the team tends to follow. That's leadership.
There's a fairly extensive thread on leadership on Ward's wiki. For example, see What is leadership? and Books on leadership. Another Web site, The Art and Science of Leadership, looks pretty good.
In my author spotlight, about half of my recommended reading list is non-technical books, many of them on leadership and related topics: see Becoming a Technical Leader, The Fifth Discipline, and The Servant. Heck, even The Pragmatic Programmer has a lot of leadership aspects to its technical advice; so does Extreme Programming Explained.
So maybe this sounds great but unrealistic. Maybe you feel like just a lowly programmer on a lowly team; what can you do? Here are some concrete suggestions:
It's really just that simple. Think about it: Aren't these the kind of people you'd like to work with? Think about someone you do like to work with: I bet they do these things.
Some organizations may not be very supportive of this. For example, when you report problems like you ought to, the organization may avoid addressing the problem and instead shoot the messenger (which is you). In this case, you have an even more challenging leadership opportunity; as one friend of mine likes to put it, "You can either change your organization, or you can change your organization."
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.
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 magazine.
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.
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.
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?
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:
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:
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:
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.
The December 12th issue of Fortune magazine is titled "How to Become a Great Leader."
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]
Fortune magazine has published an interview with Frederick Brooks.
The interview is "Quoted Often, Followed Rarely" in Fortune's "How to Become a Great Leader" issue.
Fred Brooks is the author of the seminal book The Mythical Man-Month. "The book detailed Brooks' experience managing IBM's bet-the-company System/360 computers and OS/360 software ..." Thirty years later, Brooks discusses the book, whether its advice is being followed, and why the same mistakes keep getting made over again.
Brooks reflects on how some people consider his book the "bible of software engineering." He agrees in this regard: "everybody quotes it, some people read it, and a few people go by it."
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.
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.
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]
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.