Developing Usable Experiences

On Being a Protégé, Looking for Critical Numbers

September 21st, 2011 7:29 am —  39 views

Earlier this year I signed up to be part of program where ambitious developer-types would be paired, through careful review, with others in the organization that had volunteered to be mentors. Both mentors and mentees1 had to go through a review process. After that, selections were made, pairings announced, and mentor and mentee were free to proceed.

I had the privilege of being appointed a particularly special mentor, the Vice President of Sales within our organization. As an engineer deep in the engine room of a large software company, I’m usually focused on developing stuff and hadn’t officially met him. He was hired from outside the organization a few years ago and has proven himself since. His analytical approach leveraging numbers and transparency to focus and inspire his people has shown itself to be an effective motivator that has increased sales.

We’ve met a few times now and I always come away inspired and motivated. I find myself thinking deeply about the things we discuss, the practical lessons and principles he’s learned and applied through the years. Like principles of Open Book Management he practices to educate and motivate his salespeople.

The problem is that developing software is not at all similar to selling it when it comes to motivating those doing the work. As Dan Pink suggests, reward and punishment are not great motivators for creative thinking type people wielding specialized cognitive skills.

As lead software engineer, it is my job to lead other engineers by helping them understand what’s going on, how things fit together, scheduling, the direction management wants us to be headed, and what they can do to help. After thinking about the ideas behind open book management, the importance of transparency, accuracy, and attention to change, I realized there were things I could be doing to better inform and motivate those I lead.

Over the last few months I’ve been experimenting with different data analysis approaches to show what we’ve accomplished, who is working on what, the priority of each association, and an algorithmic approach to calculating percentage completeness. I’ve used this data to encourage focus, discussion, and development. While not perfect, it has done exactly that. Working on it, thinking about the projects and people involved, has really helped me think about and coordinate efforts to get more done in less time.

Since then, I’m exploring the information I can retrieve via RSS feeds against our ticketing system. I loop through the data, adding up code changes and ticket updates per ticket, per release and per team member. Factoring days between releases, changesets, and updates, I can calculate some interesting numbers that are empirical and predictive. I can produce all kinds of statistics, numbers, and trends, but what numbers matter the most?

What are the “critical numbers” that help us do our work more effectively? What numbers can help us understand how we’re doing as team to deliver our product enhancements and fixes on time? What numbers are most interesting to upper management? This idea of critical numbers was brought up at my last mentor meeting. It got me wondering.

It got me wondering; can I use numbers to show that we’re performing better? Or not performing as well? What does ‘better’ mean? How can performance be measured when you’re developing software? What are the benefits of measuring observable actions of engineers? What numbers are most important?

Questions for my next mentor meetings perhaps…

-----------------------------------------------------------------------
  1. The editor in WordPress is telling me ‘mentee’ is not a word. So I researched it briefly at Wikipedia; “The student of a mentor is called a protégé.” [↩]

Related Posts

Comment