Agile Learning Labs

IEEE Group Answers: "What makes an engineering manager great?"

Last night the San Francisco / Silicon Valley IEEE Technology Management Council met to examine the question: "What makes an engineering manager great?" Nearly 30 people participated. Over 40 good ideas were presented and considered. In the end the group ranked the following skills, attributes, and behaviors most important.

It is interesting to compare these results with those that two other groups generated here. Also interesting is how similar these results are to those generated by a group considering the most important things a technical manager can do to retain key contributors, which can be found here. While there are common themes that run through each group's responses, the results are far from identical. This makes sense to me. Each group is unique, and has different values and needs. There is no 'One True Way' to be a great manager. Certainly there are core skills and knowledge, but to rise to the level of greatness requires really understanding the group to be led, and giving them what they need.

Tier One
Integrity
Enthusiastic & inspiring
Praise & reward
Listen well
Ask questions rather than give orders
Clear communication
Have a vision
Interpersonal skills
Respect staff input

Tier Two
Appreciates the service of others
Team builder
Honesty
Build consensus
Know each staff member's strengths and weaknesses

Tier Three
Recognize individuals, share blame
Big picture knowledge
Focus on fixing, not on blame
Ability to prioritize
Engender ownership
Clear goals

To learn more about the San Francisco / Silicon Valley IEEE Technology Management Council click here.

IEEE Presents: What Makes Engineering Managers Succeed?

Have you worked for a great manager? What were the qualities that made him or her stand out from the rest? Share your experience and tap into the collective wisdom that will be present. We will uncover the most important qualities and skills for a technical manager to posses.

Tonight (Wednesday, January 30), I will be facilitating this workshop for the IEEE San Francisco / Silicon Valley Technology Management Council. The event is open to the public, and will be held at the Ramada Silicon Valley. Details here.

.NOT

I occasionally still get calls to do software development. Recently, a potential client indicated that they would like a Windows shell extension created in C#. I've never built a shell extension, nor done any C#. Before meeting with the client, I decided I should take an hour or two to see how hard it would be for an old-school C++ and COM guy like me to get up to speed.

I downloaded the 'Express' version of C# and started playing with it. Pretty quickly, I had a command line app that worked like Eliza, but got the response text from Google searches. Fun!

Next I searched MSDN for information on using C# to create shell extensions. I found this article, which starts out like this:

This article illustrates the process of creating custom shell namespace extensions using C# and the .NET Framework. The author dispels some myths about the difficulty of writing such extensions, and shows that it is easier than it was before .NET.

Sounds good!

Until you get to here:

Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario.

Doh!

Reading up a bit more it seems that COM, not .NET is really the right technology to use. It's nice to see that my C++ and COM skills aren't obsolete yet.

Retaining Key Contributors - Results

Last night a dozen technical leaders gathered for the Bay Area Engineering Managers Support Group to answer the question:

"What are the most effective steps a manager can take to retain key employees?"

The following guidelines where provided:

• Consider this question from your own personal experience.
• What were the things that kept you?
• What effective measures did you take to retain people?
• What things could have been done to keep you: "If only my manager had...I would have stayed."

We used the Group Wisdom Without Groupthink technique to capture the experience and wisdom of the whole group. More than twenty ideas were generated and discussed. Each idea was given a short name, and posted on the wall. The group then ranked the ideas, based on their own real-world experience. The exercise took an hour.

Here are the results. Some of the names, such as "Giving Credit..." mean pretty much what you would think. Others, "Empowerment" for example, represent the groups best effort at summing up a much more in-depth and detailed idea. The ideas are presented as ranked by the group. I have left out a number of ideas that were considered but ultimately not selected by the group.

Tier One
Empowerment
Giving Credit, Recognition Both Public and Private
Create an Enjoyable Work Environment

Tier Two
Be a Buffer Between Senior Management
Willingness to Actually Lead
Proactive Problem Resolution
Tolerate Failure
Compensation

Tier Three
Clear Shared Vision
Mentoring for Professional Growth
Prioritize to Prevent Waste
Respect

Tier Four
Training
Match Interests to Roles
Be Accessible
Provide Tools for Success
Regular Performance Reviews

Looking at the results, I am struck by how similar they are to the results that have come from workshops that have sought to identify the qualities of a great manager. Results from some of those can be found here. This seems to support the idea that people stay or leave based primarily on their relationship with their manager.

Perhaps now is a good time to mention that I offer one-on-one coaching for engineering managers, as well as several workshops to help engineering managers succeed:
Managing Technical People
Coaching and Mentoring
Delivering Effective Feedback
Makings of a Great Technical Manager
and many more!

Pay for Performance Hard to Get Right

I found this interesting article on the Harvard Business School Working Knowledge site. It examines 13 pay-for-performance programs that various groups in HP tried and dropped. There are lessons to be learned from these experiences.

What gets incented gets done, at the expense of the rest of the stuff. Think about the side effects of any incentive program. Giving extra pay for outstanding individual accomplishments is not going to encourage teamwork, for example.

Manage expectations; better to start with goals that are too high than too low. If management finds that fewer people than expected are able to perform up to the incented level, it is a simple matter to adjust the level down a bit next cycle. If, however, more people than expected make it the first cycle, they are likely to cry 'Foul!' when management adjusts the levels up next time.

Creativity and learning are tough to incent with a pay-for-performance program. Such programs tend to reward 'success' and results, not experimentation, trial and error.

I agree that these programs can be hard to get right, and are costly when they are done wrong. In management, as in engineering, it is often the hardest things that are most valuable. Pay-for-performance is a tool. It is management's job to decide if it is the right tool.

Patterns of Agile Adoption

Mike Cohn has a great article in the Agile Journal in which he describes 'patterns' of agile adoption. The basic premise is that there are 3 choices that an organization needs to make about their agile rollout:

Small vs. All-In

Do we start with a small number of projects or do all our software projects go agile all at once?

Technical Practices First vs. Iterative First

Do we start by adopting things like test driven development and pair programming, or do we start by adopting short development cycles?

Stealth Mode vs. A Public Display of Agility?

Do we keep quiet about it until we figure out how to make it work or do we announce an 'Agile Initiative' with great fanfare?

Each decision should be considered in terms of the people, culture, customers, resources, and risk. The result is 8 possible approaches that an organization might take in adopting agile software development methods.

The model isn't exhaustive or perfect. I'm not sure about the 'All-In' / 'Stealth Mode' combinations, for example. But I think that it is a useful tool for thinking about how best to introduce agile practices into a given organization.

xkcd

"Do you read xkcd?" It seemed like an innocent question when my friend Patti asked me last night. I didn't hear the faint sucking sound. You know the one, the sound of a bunch of time about to go away. I laughed. I cried. I sent links to friends.

IEEE Engineering Management Society Event

I'll be leading a workshop called "What Makes Engineering Managers Succeed?" at the next IEEE Silicon Valley Engineering Management Society event. It's open to the public, and a real bargain. For the cost of dinner, you get a facilitated networking session, dinner, and my workshop.

When:
Wednesday, January 30th, 6:30 PM.

Where:
Ramada Inn
1217 Wildwood Ave, Sunnyvale CA 94089

All the details are here.

Caught on Flickr!

I ran across this on Flickr today.

It made me smile.

Young IT Workers Hard to Hold

Young IT workers disillusioned, hard to hold, survey says

I'm amused that the woman interviewed in this article thinks that the solution to the problem of retaining IT workers is for the workers to change their expectations. I wish her good luck with that. If you would like to find some more realistic ways to improve retention, come out the January Engineering Managers Support Group meeting.