Receiving Feedback

My last post on feedback was on giving constructive feedback. Here, I'll focus on receiving feedback.

In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.

If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.

Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn

1. What that person thinks about your behavior - or even you


2. By extension, if that person holds that view, then others may as well


3. Hopefully - examples of the behavior that the reviewer deems in need of improvement


4. Suggestions of how you can improve

First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".

"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.

"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.

Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.

Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).

Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.

Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."

Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.

I'm open to receiving [meta?] feedback on this post.

Giving feedback

Giving and receiving feedback is difficult.

Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.

For now, let’s focus on giving feedback

In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.

Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.

What’s wrong with this dialog - everything?

No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.

There are many things wrong with the dialog. Adrian is making several common mistakes.

Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like

Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.

Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.

It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.

The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.

Here are some attributes of effective feedback:

• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person

There are more, but this is a start.

Next time, I'll address receiving feedback.

Polyglot Programmers

Neal Ford from Thoughtworks has a good blog post on polyglot programmers. His argument is that single-language programmers are becoming a remnant of the past. To thrive in the IT environment of today, we should be open to using the right language for the job.

Attitude, Aptitude and Integrity

This is the tag line for Thoughtworks: Attitude, Aptitude and Integrity. It's printed on the back of all business cards.

As I was saying goodbye to a colleague who is moving on to another position, I told her that I felt that she exhibited these traits. I think that's a high compliment. Good luck Grace.

What's in a blog? Facts? Or Insights?

I recently viewed the blog of a colleague who was detailing a vacation he took. Much of the content was around the facts of the journey - the cab picked me up, the plane was late, etc.

I get more out of blogs that reveal insight rather than sequences of events. We bloggers should seek to convey insights rather than facts... and relegate the details to a journal or something private (still not sure what value such a collection of facts would provide).

I promise to seek to avoid regurgitating facts in favor of sharing insight here.

Stanford Entrepreneurial Thought Leaders

Marcelo Olivas turned me on to these podcasts from Stanford (also available via iTunes). These are regular talks & interactive discussions with entrepreneurs and industry leaders who visit Stanford University. I learn something new from every episode. The lessons are applicable across industries and company maturity.

They also have videos available from their main page.

Highly recommended.

Sausage Making

Otto von Bismarck – the “Iron Chancellor of Germany” in the 1800’s is said to have made this observation:

"Laws are like sausages, it is better not to see them being made."

The comment suggests that the making of sausage is a messy business. It’s better if you just avoid thinking about what goes into making the sausage and simply enjoy the results. Similarly, the making of laws is a messy business that can be unappetizing.

I use this reference quite a bit on projects. The extension to this in the software development world is:

"Software Releases are like sausages; it is better not to see them being made."

Software development sausage making includes our development approach (e.g. points, burnups, self-directedness) and in some cases, our technology choices. I have, at times, made the mistake of opening up the “sausage making” process for stakeholders to assess, critique, and well…watch. Sometimes this is appropriate. For example when getting into detailed conversations about cost/benefit analysis on technology purchases, or to determine whether those choices are in line with the corporate IT strategy, it makes sense to discuss them. Too often, though, I think we make the mistake of getting caught up in discussing the sausage making with stakeholders in many cases where, frankly (sausagely?), they might be better off not knowing how the sausage is made.

This is a classic mistake that technologists make. We get so enamored of our technology and our process, that we think everyone else must be interested in how we do our work.

We should focus stakeholder reviews more on the array of sausages we produce, rather than how they are made. Don't show iteration burnups, or discuss the nature of a "point" in the estimation process. Apply an adapter/interface on the information to convey only that which is appropriate to the audience. Consider this a sausage casing, if you will, that abstracts the detailed content regarding the inside of the sausage. So, rather than discuss with them that

"This sausage is almost done – it needs some fennel, and a little more pork fat, and a touch of lard."

we should be saying something like

"This sausage is almost done; we are 85% confident that it will be available for consumption in the mid-April timeframe and 98% confident that it will be ready in time for the Memorial Day picnic in May. If you want to increase the probability that it is delivered in time for April, we can eliminate one of the ten sausages we have slated for April and refocus on this one."

It is in these conversations that we provide our stakeholders with information that is suited to their digestive profile.

Seeing how others see

I'm taking a Myers Briggs test right now. My whole team is taking the test this week. I learned alot from doing the test in grad school; it helped many of us adapt to our different approaches to working. But that's for another blog entry.

One of the questions: Are you more likely to
a) see how others are useful
b) see how others see

My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus¹ to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.

I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.

¹Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.

Agile versus Discipline (sic)

I recently gave a presentation: "Introduction to Agile" at a .NET CodeCamp in South Florida. One of the attendees commented that Barry Boehm had written a book called something like "Agile vs. Discipline".

My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.

Wow.

Wow.

First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.

That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.

Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?

Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.

Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?

I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.

Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:

• Personnel. Essentially Mr. Boehm says you need smarter people to do agile. This is probably true. I would argue, however, that you’d rather pay one person $90K who can do the work of two people at $60K and that the diminishment of communication costs between people adds to the economies of scale beyond the numbers. This is true in any environment that you wish to consider. The best programmers, it is said, are 10 times more productive than the average. Why not pay twice the going rate for someone who’s only, say, five times as good?
  
• Dynamism. (%Requirements-change/month). If your requirements don’t change as much, agile is not right for you. What a silly statement. They probably meant to say that if your requirements don’t change as much, you can hire cheaper help who can’t adapt to change. Agile works well in dynamic (i.e. most) environments. You might be able to get by in the rare “stable” environment with excessive documentation, and delay between idea and working code.
  
• Culture (%thriving on chaos vs. order). I love this statement: “[disciplined devotee] thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures”. When’s the last time you heard someone say “I am particularly empowered when somebody tells me exactly what to do and when to do it”? I’d much rather have a team of thinking, adaptable, empowered developers than drones who simply follow the process. Am I way out there?
  
• Size. This is the big knock on agile… that it doesn’t scale. I’ve seen it scale… well… fail to scale. I’ve yet to see a successful large-scale agile project up close and in person. But this should not be interpreted to mean that I discount the possibility. I believe it can be done. I just think that it requires enlightened leadership. That’s where the dearth lies.
  
• Criticality. Really, this is plain stupid. Sorry Barry, but this dimension really irks me. When’s the last time you worked as a leaf-node part of a team on a project in either a waterfall… umm, I mean, disciplined… approach or an agile approach. This dimension alone conveys to me that you have lost touch with software development reality. Agile is not the antithesis of discipline. You probably think that agile means “no documentation” – like many ignorant folks out there. Fortunately they’re not writing about it; alas, you are.
  

One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.

Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.

Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.

Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.

In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.

MoSCoW Squared

Agile business analysts are well aware of the MoSCoW framework. That is - the classification of requirements as "Must Have", "Should Have", "Could Have" and "Won't Have". The beauty of this classification is that it clearly defines the stories in understandable terms of importance - rather than 1, 2, 3, 4.

A colleague of mine - David Smith - recently pondered the importance of several stories across two dimensions. There were features that had high importance to one party but not the other, and there were stories that appealed to both constituencies. He plotted the requirements on a two-dimensional grid, assigning their importance across the two dimensions representing those constituencies. It was so informing and illuminating that I thought other agilists would benefit from the idea. Here's an anesthetized version:



Ultimately, the value of the story stems from its radial proximity to the root. In other terms, you could probably draw an arc reflective of the relative importance of each axis (or constituent).

I hope you find it useful. I know that, for us, it provided an "aha" moment.

Laser pointer token

It is sometimes challenging in standups to associate the card to which the speaker is referring to the conversation - particularly for infrequent guests. A low tech solution that I recently implemented for my teams is to use a laser pointer as the token that gets passed around. As the speaker is referring to cards on the wall he/she is expected to point, using the laser, to the cards(s) in question.

An ancillary benefit to this approach is that it can be an early warning sign for scope creep when a team member has no card to reference. It can also be a warning that cards are languishing in the "in-play" section - if nobody is referring to those cards, they may not be getting the attention you desire.

They're pretty cheap too.... you can get a laser pointer for as little as $10.

Growing People

I saw a great quote the other day referenced on a blog. I can't stop thinking about it. It's from the book "Powerful Project Leadership" and the quote is:

"Managers use people to accomplish work; leaders use work to grow people".

This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".

Agile Leadership and Typical Management Titles

I worked at a very big company as a software engineer for 15 years. When I began out of college, my title was "junior programmer". The promotion path was well known. Perform at a level between barely satisfactory and outstanding and get promoted in a year to "associate programmer". Keep doing a satisfactory job, get promoted again two years later to "senior associate programmer". Two more years and it was "staff programmer" (and get your own office). Promotions after that were less structured/timed and based strictly on merit.

Well... OK... not just merit.

Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.

I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.

As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?

Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.

So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):

• Communication/Collaboration skills - "down" - in coaching and developing people within your organization
  
• Communication/Collaboration skills - "across" - in collaborating with folks on peer projects, others within IT
  
• Communication/Collaboration skills - "up" - in managing relationships with higher level IT management/leadership
  
• Communication/Collaboration skills - "Business" - in managing relationships with the business
  
• Technical skills - understanding the technology, architecture
  
• Domain knowledge - understanding the business
  
• Agile Project Management - from estimation and planning to iteration tracking
  
• Ability to inspire
  
• A fundamental philosophy that prefers frequent inspection and adaption to continuously improve
  

The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.

How do these map to more traditional hierarchical positions?

• development/QA/BA manager (managing a group of folks based on functional alignment)
  
• lead developer/QA/BA (individual contributor who is annointed with the "lead" adjective).
  
• architect (might be a member of an architecture team, or may just be a responsibility for someone holding a different title)
  
• director of development (overseeing everything from requirements to release for a project)
  
• C-level leader (person who holds the pursestrings, defines strategy, provides the context & constraints in which the project must operate)
  

Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.

Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.

(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.

Myers-Briggs "Lifestyle" dimension meets Agile & Lean

I was thinking this morning about how Myers Briggs Type Indicators (MBTI) play into our receptiveness and ability to thrive in agile environments and further, into lean approaches to software development.

I think much has been written about the classic programmer profile: INTJ: Introvert, iNtuitive, Thinking, Judging. The poster-child programmer is a loan wolf who uses his analytical skills in a controlled environment to produce excellent software.

From an agile perspective, introverts are, at least in theory, less likely to be amenable to or effective at pairing.I'm not sure this is a particularly apt conclusion, but for now, I'll shelve that thought.

This morning, I turned my thoughts to the last dimension, the so-called "Lifestyle" dimension. That is, Judging vs. Perceiving. From wikipedia:

People with a preference for Judging prefer matters to be decided; to start tasks in good time, well ahead of a deadline; to have clear plans that they prefer not to be distracted from; and they can sometimes seem inflexible in this regard. Those whose preference is Perceiving are happier to leave matters open, for further input; they may want to leave finishing a task until close to the deadline, and be energised by a late rush of information and ideas; and they are readier to change plans if new information comes along. They may sometimes seem
too flexible for their Judging peers.

So: Judging = Waterfall; Perceiving = Agile.

But wait. Isn't Agile just a shorter planning cycle to deal with? "matters to be decided" at the beginning of the iteration; "clear plans", "no distraction". These seem part and parcel of iteration-based development - scrum, for example.

It seems to me that "lean" approaches like not having iterations; just-in-time analysis; polyskilled, adaptable "resources" (aka people) are a "judging" person's worst nightmare. These judgers have already adapted to a shorter planning horizon; now you're asking for a transition from short planning horizon to flexibility - beyond their comfort level.

The challenge is to introduce lean approaches with an understanding of each participant's comfort level.

10 Attributes of Well-Run Meetings

I love well-run meetings. The key here - well-run. What are the qualities of a well-run meeting?

1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.

2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.

3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.

4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.

5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.

6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.

7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.

8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.

9) Don't call all-day meetings unless you have a plan for how to spend the time.

10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.

I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?

Thoughtworks is hiring

I work for Thoughtworks, a global IT consulting firm with offices in six countries (US, Canada, UK, Australia, India, China). We hire very good people to work on interesting/difficult problems.

We're hiring.

Most of our development is in Java, Ruby, and C# (with Ruby becoming more and more a staple of our most interesting gigs). We're looking for developers, testers, project managers, client principals, and probably sales folks.

Pluses of Thoughtworks:
- You'll probably not find a more competent/smart group of people in any other consulting company.
- We deliver working software using Agile software development approaches (pairing, TDD, etc.)
- Lots of travel (if you're single and want to see the world, we encourage travel to different countries)
- Amazing level of transparency in corporate activities and a flat organization.

Minuses:
- Lots of travel

If you would like more information, see www.thoughtworks.com, or respond in this blog with your email address and I will be happy to provide more insight.

For Dummies

I've always despised the "For Dummies" book series. It's not the idea... the few I've browsed in the bookstore (with suitable disguise in place) seem to be well-written and humorous. It's the damn title. If I buy the "Sewing for Dummies" book, and interpret language literally, the purchase has nothing to do with my novice status as a seamstress (seamster?) but conveys that I'm actually a dummy.

I must admit I bought one once - but it was appropriate: "Golf for Dummies". My golf game is worthy of the term (nothwithstanding my strict grammatical interpretation argument above).

Saw an interesting title on the shelf at the library today: "Beginning Java for Dummies". This begged the question: where is the "Advanced Java for Dummies" book? And does one exist? Can you get to the advanced tier of "Java developer" and be a dummy? Perhaps the library just doesn't carry it. It was, however, a college library (OK, not exactly a top-tier university).

I checked Amazon. No, there's no "Advanaced Java for Dummies". But there is a POJFD book (OK... take off on POJO.... plain old "Java for Dummies"). There's also "Java Programming for Dummies". Not sure what the difference is. If you're not programming with Java, what exactly are you doing with it? Hmmm.... Perhaps the "Java for Dummies" book describes how to order at Starbucks.

Aside=> My favorite Starbucks order: Alok's: "double tall, two splenda, breve cappacino".... I used to pick up coffee for him and the barista would always eye me and say... "Ah, for Alok?". As if to make sure that I wasn't actually ordering Alok's "usual" for myself. Fortunately, at the time, I had no clue what I was ordering.... it could have come with pork rinds as a garnish for all I knew.

A search for the terms java and dummies on Amazon yielded 412 results. There were only 14 results for ruby and dummies. Hmmm.... guess I figured out where the smart people are hangin' out. To be fair though, not all responses were relevant to the specific technology. The Ruby results included a few "dummies" books whose authors included someone with the name "Ruby". And I'm pretty sure "Ballet for Dummies" has nothing to do with Ruby. Not quite sure how that got into the mix. Didn't have the time to peruse the 412 Java results to weed out the chafe.

Found "Management for Dummies"... hmmm, maybe there is an argument for the validity of this series. (Thinking about managers from previous companies of course.... really.... wonder if any of them are still on my Christmas list?)

Shoemaker's shoemaker

Sometimes I feel like a shoemaker who walks around life in bare feet. I'm a software development professional... consultant even. I help companies create advanced software.

My colleagues are hot on IPods, Macs, PS2, XBox, fancy cell phones.

What's wrong with CD's? I've got a CD player... a bunch of CD's and I can cycle through them. I know, the IPod and other MP3 players allow you to consolidate. OK, good. I have sparse financial resources (4 kids!) and have to wisely allocate those resources. Do I need an IPod? Focus on the word "need". Do I really NEED it? Yes... I'd like one. (feel free to post a response and I'll give you my mailing address for your to send me a check.... or maybe I'll even figure out how to do PayPal, or whatever the cool version of it is now)

Macs.... I really don't understand this one. OK, it makes some cool things easier.... like creating movies, music, art, etc. I'm a left-brained guy. This is not as important to me. If you're a computer guy complaining to your management/IT department that you can't be effective with a PC.... but if they were to get you a MAC, boy, you'd be smokin'.... check your motivation. I mean, really... as an IT professional.... you can't figure out how to make your Windows experience efficient? Be honest with yourself.... you're after the cool factor. You couldn't get the chearleader in school, so now you're trying to be the "football player" of cool technology. Give it a rest. If you want a Mac, buy one yourself. And stop your bitchin.

Gaming machines.... really. Sounds cool. Why don't you try LIVING life instead of experiencing it vicariously through the imagination of some geeks who create virtual worlds? Reminds me of a guy ... good friend actually.... who claimed he couldn't make our volleyball match because he had to sit at home and watch a Giants game. What's with that. Do you live life, or are you a spectator?

Do you really need to check your email via the phone? Really? Are you that important? Ask yourself ... as you thumb through your emails in mid-conversation with a colleague or employee of yours.... is this more important than human contact? I had a manager once who thumbed through his blackberry as we had a "one-on-one" at a Taco Bell of all places. As I was conveying my career goals and such, he was thumbing through the blackberry and mumbling... "uh huh". Please.

Lastly... this "connectedness technology" does not exist for you ... it's for me. If you expect me to answer my cell phone when you call, you have severely mistaken my motivation for obtaining said cell phone. You see... I bought it to make it easier for ME to connect to others.... not for YOU to find me at all hours of the day and night.

Dope a rope

So you're on a team using all of the agile techniques (please don't say methodology). You're pairing, using TDD, daily standups, etc. You have the maturity to understand (or you've been on the other end too many times) that micromanaging doesn't work, but you want to keep a close eye on one of your team members; the code she writes often ends up being less than healthy. In fact, it sometimes is beyond refactoring and needs to be rewritten. You'd rather she not spend a great deal of time going down ratholes. What do you do?

Rotate pairs often. This is a stealthy/healthy way to keep fresh eyes on the problem. It's the classic agile way of spreading the perspective around.

Dope a rope. This is a technique I use sometimes to be welcomed into another developer's sandbox. "Dope"... means I express ignorance (maybe too strong a word) about what he's doing and ask 3rd grader type questions. (Easy for me now - as I have no developer credentials on my current project and am acting as a project manager). I ask for explanations that lead the developer to "throw me a rope" and pull me into the code to show me.

What is the result? The developer sees that what he's doing matters (because I'm paying attention) and feels confidence (after all - he knows more than me). I get an opening to subtley convey suggestions for improvement. And I usually learn something.

Cram First

CRAM First

CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?

The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.

To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).



Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.

When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.

Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.

I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.

Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.

Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.

Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.