Geek Philosophy

I’ve seen Mary Poppendieck speak several times, and I’ve also read her books. When I saw her name on the program of this year’s Agile Vancouver conference, I expected a presentation on reducing waste in a development organization, promoting flow, or perhaps encouraging set-based development, as would be befitting her reputation as the “Queen of Lean”. Although I’m sure any of the above presentations would have been well worth attending, I was pleasantly surprised to see that Mary was planning to focus on appraisals and compensation, two elephants in the room of almost every organization. I took a few pages of notes from this talk, so I’ll split it into two posts – this one on appraisals, and a followup on compensation.

Mary started by giving a history of performance appraisals, from their first documented use in 3rd century China, to Taylor’s scientific management theories in the early 1900′s, to their near ubiquity we see today. Given their prevalence, and the feeling one gets that nobody outside of the occasional HR organization enjoys either giving or getting performance appraisals, the assumptions behind these reviews merit examination. To help frame the discussion around these assumptions, Mary listed the 4 services that performance appraisals are assumed to provide: a motivation to improve performance, career / professional development guidance, a paper trail for corrective action, and a basis for pay and promotion. I’ll tackle the first three here, and save pay and promotion for the next post, Compensation.

The Bobs enjoy a good appraisal.

As a motivation to improve performance, yearly appraisals are prone to several problems. The value of feedback, either negative or positive, goes down in proportion to the cube of the amount of time between the event generating the feedback and the feedback itself*. If you are trying to effect change in an employee, the best time for feedback is “immediately”, followed by “as soon as you can get that person alone” for items that are better off discussed in a private setting. Additionally, combining positive and negative feedback from a large time frame into one review tends to mute the effect of the positive feedback, since people tend to focus more on the negative. You can think of these ratings as a game without a winner, where the best you can hope is maintain the status quo. If you were to give a high rating to a mediocre performer, it would not give them any motivation to change, so you’d still have a mediocre performer. If you were to give a mediocre rating to a high performer, the high performer (who probably knows she’s a high performer) will be disappointed and probably reconsider how hard she should be working.

To counter the assumption that appraisals are necessary for professional development, Mary touches on the body of research that covers how people across a wide variety of fields learn and master new skills. A concept I first heard about in Malcolm Gladwell’s book Outliers,  the steps to work towards mastery are as follows:

• Identify a specific skill that needs improvement
• Devise or learn from a teacher a focused exercise: designed to improve a skill
• Practice repeatedly
• Obtain immediate feedback, adjust accordingly
• Push the limits: expect repeated failures
• Practice regularly and intensely, maybe 3 hours a day

Now, most of us may find that list a bit daunting, but that is the price of mastery. That said, not everyone expects to master every skill they attempt to use – the closest to 3 hours a day that I spend on any one thing besides sleep is riding the bus, for example. The important thing to note is that in this list of elements of deliberate practice (having a teacher or coach, pushing your limits, obtaining immediate feedback, and dedication), appraisals don’t really cover any of them. How then can they be expected to promote meaningful growth?

The idea of creating an audit trail in case of punitive action or dismissal may appear to make sense in today’s litigious society. Indeed, Mary points out that formal performance reviews gained a lot of popularity following the 1960′s civil rights movement in the US, when such systems were set up to prevent untraceable systematic discriminatory dismissals. However, if this system is meant primarily for underachievers and others needing corrective action, why must all employees go through the process when the vast majority of them are in no danger of being let go?

In my next post I’ll write about the second half of Mary’s presentation, which challenges the use of appraisals as a basis for pay and promotion, and in doing so questions several other common aspects of the dominant compensation model and dives into the complicated area of motivation.

* Simmons’ Law. Yes, I just made that up, and I have no empirical data to prove it, but the disproportionate value of immediate feedback when compared to delayed feedback is a well-known phenomenon. At worst, I’m off by a coefficient.

Further reading:
- Get Rid of the Performance Review, Wall Street Journal
- Bringing Out the Best in People, Aubrey Daniels

Some presentations I’ve attended make me wish my direct reports were there. Others make me wish my boss (or his boss) was in the room taking notes. Dave Sharrock’s presentation at this year’s Agile Vancouver conference, entitled “Leading Agile Change – Walking the Walk”, brought things to a new level. By the end of the talk, I was rueing the fact that my entire peer management group was not there, along with the management of other parts of the organization.

Dave’s dialogue described an experience report where he and other Agile coaches were brought in to a large organization to assist with their Agile transformation, but the goal of the talk was not to educate the audience on how to do huge transitions. Rather, Dave presented a generic planning tool and thought process for leadership teams, called Agile Strategy Mapping, that is applicable for almost any type of strategic planning. Agile Strategy Mapping involves defining high-level strategic objectives in terms of critical success factors, defining necessary conditions for these critical success factors, and then creating a prioritized backlog of tasks required to realize these necessary conditions. Using Agile Strategy Mapping, Dave went on to show how a leadership team can implement organizational change and strategic goals in a focused, incremental way.

A simplified Agile Strategy Map: Goal in cyan, critical success factors in gray, necessary conditions in yellow. The white condition is a nice-to-have.

The term “leadership team” is an important one; Dave spent a healthy portion of the talk describing the fundamental differences between “working teams” and “leadership teams”. Unlike working teams, leadership teams are often not dedicated to a specific problem space. They are ultimately responsible for the work being done, and most of their influence comes through delegation. This is not to say that working teams do not have responsibility or are in any way inferior. The delineation of the two groups is not into a hierarchy of importance (although of course there is some role power involved), but rather is meant to serve as recognition that the two types of teams have different capabilities, requirements, and working styles. Dave’s main push is that, despite these differences, Agile Strategy Maps enable leadership teams to achieve goals in a more Agile fashion.

The concept behind the Agile Strategy Map isn’t rocket science, but the idea of breaking down large, over-arching strategy goals into bite-size pieces is a good one, and one I believe many organizations would benefit from. As is true for working teams, a prioritized backlog fosters collective ownership and shared goals. Even the act of creating the Agile Strategy Map can serve as a valuable focusing tool for leaders, helping turn a group of managers into a team. This team building and collective ownership can then serve to form the basis of a positive feedback loop, on the backbone of small definitive commitments, strong accountability, and a focus on customer value instead of small, local optimization.

Although I really enjoyed Dave’s presentation, and will be using Agile Strategy Mapping as the technique by which I will introduce ideas and recommendations from this conference to my management team, there were some notable shortcomings to the experience. At one point we broke into small groups (6-8 people) to try our own hand at Agile Strategy Mapping. I didn’t really enjoy my small group experience – the ideas generated for critical success factors were too generic and non-actionable (i.e. “mindset change” as a critical success factor), and the concept of necessary conditions seemed lost on most. I may have also been a victim of groupthink, in that the majority of people in my group were from a single company and thus presumably had some shared background and perhaps preconceptions about the planning process. Finally, there appeared to be a large number of individual contributors (as opposed to leaders / managers) in the audience. This is not a problem in and of itself, of course – I was certainly very interested in management and leadership when I was still a junior programmer. However, Dave’s presentation was squarely aimed at those in leadership roles – I feel some of the negative feedback he received may have been due to a disconnect between individuals who were expecting something targeted at grassroots efforts.

Further reading:

• Dave Sharrock’s slides on Leading Agile Change

I’ve recently spent a lot of time thinking about how to grow professionally as a software development manager. Since I was a programmer before becoming a manager, I first thought about how to transfer some of what I learned about professional development as a coder to my role as a manager.

Programmers have it easy

A lot of options

Let’s think about how a programmer progresses. Of course, there’s experience and time, the greatest of teachers. Even if you have a programmer solve a similar class of problems on a regular basis, if she’s keen she’ll come up with new and better ways of doing things. Add a piece of automation here, a new editor trick there, perhaps a refactor or a domain-specific language – there’s always some opportunity to learn something new.

Luckily, most programmers aren’t stuck solving the same problems over and over – they’re doing different things. This could mean a new programming language (or new techniques with the one you already use), a new platform, a new module or third-party API, or a new paradigm, such as incorporating more of a functional design style into otherwise object-oriented code. Programmers can also change their focus, for instance from user experience to scalability to embedded systems.

Additionally, professional programmers most often don’t have to do it alone. If you run into a database problem you don’t know how to fix, you can go look over the shoulder of the local SQL guru as they optimize your query. If you’re fortunate enough to be on a team where pair programming is the norm, you’ll be in almost constant learning mode. At a standup meeting, at an architecture design meeting, or at a security review, there’s a group of your peers (or superiors) solving technical problems.

All that said, the title of this section is a bit flippant – to really take advantage of these learning opportunities, a developer would ideally have the will to learn, the drive for self-improvement, and the hacker ethos of experimenting with programmable systems. It’s not that this learning comes for free, it’s just that it can be part of the job (or some on-the-side project, or an open-source effort, etc.).

What exactly would you say you do around here?

The pleasure's all on this side of the table, trust me.

So now, back to the land of management. What does a software development manager do, and how would one go about improving those skills?

Roughly speaking, you can break down what I do into four areas:

• People management. This includes conflict resolution, career development for my direct reports, and managing up.
• Project management. This involves task prioritization, risk assessment, project tracking, and scope management.
• Process / team management. This is broad, but in part consists of promoting technical and team best practices, and focusing on how the team does their work.
• Technical guidance. Although I’m not the most senior technical person on the team, I have substantial product experience and a higher-level context that proves useful during in-depth technical discussions.

Of course there is overlap. What is a team if not a group of people? Choosing continuous deployment could be process or project management, and encouraging pair programming is part team management and part technical guidance. The list goes on and on – I’ll stick with the above demarcations tfor now.

How do you grow?

There are several paths towards professional self-improvement, but I’ll lump them into three broad categories: Experience, Training, and Self-Study.

Experience in this case refers to professional experience, and covers most of what I talked about above with respect to programmer development. This is the knowledge that comes from trying new things, learning from mistakes (both yours and others’), and paying attention to what works in various situations, all as part of your day to day work life. There is always some sort of experiential learning to be had, should you choose to take advantage of it.

Training is another way to learn, and can be helpful in circumstances where there’s a specific skill set to be learned that is too broad to wait for experience to teach, too critical to be learned through trial an error, or too time-sensitive to be learned through self-study. School and certification courses are obvious forms of training, but I also count mentoring (external or within your company) and conferences under this heading.

Self-study is a broad term. and I use it here to refer to everything from reading blog posts and books, to podcasts and forums or user groups, to side projects and open source contributions. Self-study is the most accessible form of learning for most people in this profession, since it is plentiful and often free, but it is often the least taken advantage of.

Naturally, like the overlap in the management responsibilities above, the distinctions between these categories are not hard and fast. Would MIT Open Course Ware count as training, or self-study? Work experience often has aspects of self-study, even though it may not self-directed. A conference may be training, but what about an unconference?

So what are you doing about it?

Aspiring to greatness

Now that I’ve laid out the loose definitions for the types of learning I might undertake, as well as the areas in which this learning could be applied, I’ll get into what and how I’m trying to learn.

People management is an area where I think there is a limitless amount of experiential learning to be had, and it’s one I’ve been focusing on more recently.  Even if I was managing the same people for 10 years, they would change, I would change, and the project would change, so there would be new challenges and opportunities. That said, I have been pursuing self-study in this area (mainly through blogs, books and podcasts), and the upcoming Much Ado About Agile conference has several talks and tutorials on the subject of people.

Project management is something I do as part of my job, but I’m not really a project manager. I have experience working within my company’s project framework, but there’s a lot of inertia to overcome to change anything since it’s a framework the entire company uses. This is an area I’m not putting a lot of effort into improving on my own time, since it’s not a primary interest and there’s relatively little I can do about it in my current position, but I’m always on the lookout for things that I can improve during my day to day tasks.

Process and team management is where I’ve spent a the most time learning, through experience, training, and self-study. I’ve followed the Kanban community, posting questions and comments, and even helped review a great book on the subject. I’ve read books by Mary Poppendieck, Tom DeMarco, Esther Derby, and more, and my to-read list just keeps growing. I’ve attended and spoken at Agile meetups and conferences. I’ve tried to be an Agile coach for my team (which can sometimes be difficult). Although this is where I’ve focused most of my efforts, I’m starting to back off a bit here in favour of People- and Technical-centric learning, primarily to round out my management style.

Finally, learning about technical management. Although over the years I’ve done some self-study on this, reading books on design patterns, lean and agile development practices, and architecture, I haven’t been as rigorous about this as I could have been. Part of it has been that I haven’t been coding at all (maybe a few lines every few weeks), a situation which I’ve started to correct. Picking up new technologies, even if I’m not using them at work or for any serious projects, helps broaden my perspectives when faced with the challenges I do need to solve at work, providing me with a bigger technical toolkit. I’m also getting more involved in security reviews at work, and have recently had some work-sponsored training by a security expert, and I hope to get some further training on the technical track of the upcoming conference.  While I don’t know if I’ll ever go back to primarily being a developer, I think staying sharp technically is an important part of being a development manager.

Your turn

Thanks for making it this far! Do you agree or disagree with my assessment of the learning opportunities for programmers or managers? Have anything to add? Let me know in the comments.

One of the roles that I see myself growing into as time passes is that of change agent. I don’t mind speaking up when I see problems, I’m dedicated to seeing problems solved even if it won’t happen immediately, and I don’t get discouraged if there is resistance or setbacks when implementing change. I’ve been lucky enough to be leading a team where I can experiment with new ideas and have a lot of control over how my team works.

However, when I look at professionals in my field who are interested in team and organizational improvement, they are almost always consultants. Does it have to be this way? I can see the benefit – moving from company to company, the rate of feedback is much faster, and you can learn what works and what doesn’t work much sooner than you could working within the same system. Also, there’s always this old quote from Deming:

“As a good rule, profound knowledge comes from the outside, and by invitation.  A system can not understand itself.”

Is it that companies refuse to accept major change initiated from within the organization? I’ve heard this repeated many times (though I’ve never seen any studies), so that could account for the lack of “famous” internal change agents. It could also be that people who are genuinely good at turning companies around demand too high a price to be a permanent employee. Alternatively, maybe there’s an inherent bias of contractors and consultants to be more vocal about their methods, previous clients, and successes, as it helps them gain new business.

All that said, I like working in a single company and have always thought that I’d hate being a consultant. That distaste is changing a bit – I think it’s mostly the gathering of clients / insecurity that I’d dislike, as opposed to the nature of the work – but I’m still not very interested in jumping ship and becoming an entrepreneur.  Of course, all of this may be due to inexperience. I’ll be the first to admit I that have relatively little experience in the industry.

For now, I’m still in a good place. I run a small team in a large company, and there seems to be some opportunity for change that I may be able to help out with, so I’m definitely not out of growth options in this area. I try to keep as up to date on modern methods as I can by reading books and forums, talking to other professionals, and airing my ideas publicly so they can either be torn down or validated. Still, it’s interesting to think of the future, and wonder if I’ll ever have the desire (not to mention capability!) to go solo.

After seeing the pile of books I want to read grow and grow, while not actually reading anything due to indecision of what to start next, I’ve decided to implement a reading kanban. I’ve never really used a personal kanban, but I thought that having the titles I want to read laid out in front of me (sorted by category) could spur me to action.

To start out, I think I’ll have allow myself to have three titles in progress – one fiction book, and two books out of the three categories of technical, business, and personal growth. I’m already well into a personal growth book (How to See Yourself As You Really Are), and I’m just starting a business book (The Five Dysfunctions of a Team). I have a raft of technical and business books to choose from, but limiting my WIP will ensure that I actual finish some of them. I only have 2 or 3 fiction books that I’m considering, so I’m less concerned with burning through those.

I’ll try to write up my thoughts on any books I find particularly interesting, and will also try to report back in a few months to see how the book kanban is going.

If you’re getting sick of my many reviews of Much Ado About Agile presentations, you’re in luck – not only is this my last review, but it covers two sessions (albeit on the same topic, by the same speaker). I’ll likely do a conference summary post after that, and then I’m on the hook for coming up with 19 more posts this month to keep up with NaBloPoMo.

On the morning of the second day of the conference, I listened to Christopher Avery speak about responsibility. I really didn’t know what to expect from this talk, and I hadn’t heard of Christopher, but the summary appealed to me – leadership is an area that I’m increasingly interested in developing. I spent all of Thursday in a tutorial with Christopher on the same subject – this post will cover both segments.

Christopher’s talk was centered around The Responsibility Process, which is a framework that describes how people react to adversity. Here are the five main states that someone’s mind can be in when approaching a problem:

* Responsibility

* Obligation

* Shame

* Justify

* Lay Blame

The idea is that when something bad happens, people’s minds land in one of the states above, almost always at the bottom. Often you’ll work your way up through the other states, stopping somewhere before responsibility.

As an example, let’s say that my team has accidentally shipped a critical defect to production. What immediately springs to my mind? “Whose fault is this?” This isn’t a particularly useful state of mind – blame doesn’t get you anywhere, and besides, most problems are system problems, not people problems. So, I say “well, this got out because we didn’t have time to test, and we have no budget for more testers, so I guess we’re stuck.” This is justification – I’ve explained away the problem, and now don’t have to worry about it any more. Unfortunately, the problem (or at least, the root cause of the problem) is still there!

Let’s say I realize that we don’t have the budget for testers, but I also realize that, as the manager, I’m ultimately responsible for the quality of the code. This realization could move me into Shame – “how could I have let this happen? I’m such a bad manager”. Many people stop here, and often shame is rewarded and treated as “responsibility” – if I asked my team who coded the bug, and someone put up their hand and admitted it, saying “thanks for owning up to it” would be rewarding shame.

Obligation is another state that’s mistaken as responsibility. Obligation is when you are trying to solve the problem, but only really expending energy and effort to be barely adequate to pass. Showing up to that meeting that you don’t want to go to, because you have to? Obligation. Almost everytime you use the phrase “I have to”, you’re talking about obligation. It’s important to remember here that the Responsibility Process is a framework for addressing your state of mind when faced with a problem or upset – in-depth analysis is not required when you say “I have to go catch my bus” or “I have to go to the bathroom”.

Spending too much time in Shame or Obligation can lead to a psuedo-state called Quit. This doesn’t mean you’ve actually quit the company, it just means that you’ve mentally checked out. The person who “has to” go to a meeting, then comes along and opens their laptop to read email, surf the web, or do anything else but be present in that meeting – they’ve quit. Christopher says that Shame, Obligation, and Quitting are the trillion dollar problem in information work today. By focusing your work hours on things where you’re truly excelling (instead of being barely adequate), the company will benefit and you will have higher job satisfaction.

How do you move from Obligation to Responsibility? This is the tricky part – it’s the idea of moving from “have to” to “want to”. You have to want to be responsible. That meeting that you don’t want to go to but you “have to”? If it’s truly a waste of your time, and you’re not getting anything out of it, talk to your boss and convince him that it’s not a good use of your time.  Now, if there’s really nothing that can be done about going to the meeting (for instance, if your boss convinces you that it *is* necessary), you need to re-evaluate and see if you actually have a problem.

This kind of thing is hard to explain, especially with contrived examples. Furthermore, as Christopher says, you can’t apply this stuff to someone – you need to teach it so that people can self-apply. The class on Wednesday focused on the concept, and the the tutorial on Thursday focused on how to teach it. This included hands-on group work (trying to convince others of the concept in face of resistance), and an in-depth look at the “Keys To Responsibility” – Intention, Awareness, and Confront. I found the tutorial quite helpful, and it was useful to work with others to find examples, counter-examples, and issues that would come up when trying to teach the Responsibility Process to others.

Christopher is a great speaker with a smooth presentation – think motivational speaker, not time share salesman, but without any sort of evangelical zeal. You can tell that he really believes what he’s saying, which I suppose is only right since he’s been researching this approach for 20 years. For me, this smooth presentation simply meant that I enjoyed a nice delivery of content that I could relate to, but I know of at least one other person that attended the first day’s presentation was turned off by it. This surprised me – a coworker suggested that this was a consequence of (over-generalization alert!) people in the software world not being used to dealing with talented professional communicators. There was also a definite “self-help” bent to the presentation, which I know I find more appealing that some others. Overall, I feel that it was definitely worth my time, and I’ll be trying to apply what I learned to help myself and my team.

More than any other conference I’ve been to, this year’s Much Ado About Agile conference has left me with a pile of books that I want to read. I’ve actually put off reading a few career-related books recently because I’ve felt that the information isn’t sticking, but I’m going to try out the SQR3 method (as mentioned in Declan Whelan’s presentation) to see if I can up the retention level.

Here’s the list of books that I wrote down as “must-haves” – if you were a presenter at the conference and don’t see your book here, it’s probably because I didn’t attend your session!

• Certain to Win: The Strategy of John Boyd, Applied to Business (Chet Richards)
• Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility (Christopher Avery)
• Behind Closed Doors: Secrets of Great Management (Esther Derby, Johanna Rothman)
• Agile Retrospectives: Making Good Teams Great (Esther Derby, Diana Larsen, Ken Schwaber)
• Fearless Change: Patterns for Introducing New Ideas (Mary Lynn Mans, Linda Rising)
• The Fifth Discipline:The Art and Practice of the Learning Organization (Peter Senge)

The Fifth Discipline wasn’t written by a presenter, but was mentioned by several. It’s been on my “to-read” list for a while, but being called out as a wonderful reference on both systems thinking and organizational learning means that I’m going to actually suck it up and get a copy.

I’ve spoken briefly about Esther Derby’s talk on “Becoming an Agile Manager” – it turns out all of the slides are online, and much of the content is discussed on her blog. For instance, here’s a post on expanding knowledge overlap.

It’s nearing the end of day one of the yearly Agile Vancouver conference, Much Ado About Agile. I’ve enjoyed the talks I’ve seen so far, and I’ve been taking extensive notes, but I thought I would try to quickly summarize some of the talks.

The first talk I saw was the keynote, delivered by Chet Richards (author of Certain to Win). The talk was titled “The Fundamental Secret of the Universe” – that secret being that if do the unexpected, and react faster than your opponent / enemy / competitor, you are certain to win. The talk focused on the findings of John Boyd, the OODA process (Observe, Orient, Decide, Act), and how in a variety of situations across human history the ability to react to happenings quickly has overcome superior technology, numbers, and head starts. I’d heard of OODA before, but outside of describing the acronym I’d never seen it described. The talk was quite good, and everyone really seemed to enjoy it. The mindset approach involved – get a few core concepts, and learn them very deeply – is something I would like to work on more, as I often worry (for lack of a better word) that my understanding of fundamental Agile and Lean principles is somehow “superficial”.

The second talk I attended at the conference was presented by Esther Derby and entitled “From Big Boss to Steward Leader – Becoming an Agile Manager”. This talk focused on how managers need to shift their thinking on a few fundamentals, such as decision boundaries and intervention strategies, in order to adapt to the way that teams work under the agile mindset. This was thought-provoking session, and I especially liked the idea of increasing “information overlap” (that is, making sure that developers know how the business makes money, and that higher-ups know the way the work is done). I was fortunate enough to snag a half-hour private meeting with Esther afterwards, where I got to ask some questions specific to my situation, and about topics that were complimentary to her talk. I’d been meaning to pick up her most recent book, Behind Closed Doors, and now I definitely will.

Tomorrow’s post – Linda Rising’s excellent talk on Caffeine, and possible other tidbits from Agile Vancouver!