Staff Quality Deserves the Same Care as Software Quality

The Wikipedia definition of Continuous Integration (aka CI):

Continuous Integration aims to improve the quality of software…by replacing the traditional practice of applying quality control after completing all development.

The CI gurus in the audience will hopefully forgive me for criminally over-simplifying, but the process basically boils down to:

  • Commit early, commit often.
  • Automate tests, build and deployment.
  • You break it? You fix it. RIGHT NOW.

The key motivator in CI is right there in the definition: quality. Rather than waiting for the end of the production cycle to do all of the testing you do it in smaller increments throughout the project. The sooner you locate and correct potential issues the higher the quality of the finished product. This approach is proven for developing software, so why aren’t we also doing it when developing staff?

A typical methodology for managing professional development for a technical staff member is much more old school waterfall in nature:

Yearly review and feedback
  set yearly goals
    procrastination until just before next yearly review
      race to complete goals
        verification of goals in yearly review

OK, perhaps that was a somewhat snarky summary but I think we all recognize it as Standard Operating Procedure. How, really, does this process help anyone? No, don’t answer that; I’ll answer it for you: IT DOESN’T. By the time you get to the annual review, any sort of feedback is so much water under the bridge and far from actionable. Yearly professional development goals are reduced to the effectiveness of an open book midterm: crammed in at the last moment and generating a good grade but with no lasting value, either for employee, team or company.

Instead we should be approaching staff development and management with an approach incorporating the ideas of accepted software development methods like Agile and Continuous Integration:

  • Agile Professional Development:
    • Employee review cycles should be short sprints of a matter of weeks rather than months.
    • Professional development goals should be attainable and meaningful, each subsequent goal building upon the ones which came before.
    • Meetings for checking progress and providing feedback should be frequent, brief and informal. They also should be open, honest and egalitarian (managers need feedback as much as anyone).
  • Continuous Staff Integration:
    • New knowledge and skills gained through professional development should be committed back to the trunk (the team) for integration.
    • Staff development should be automated through empowerment, support, policy and culture rather than dictated by managerial fiat.
    • Notification of potential issues should be immediate and methods of correction should ideally be evident and obvious.

There are, of course, some potential drawbacks in rolling out a staff development process of this sort. The current “waterfall” model has been the standard for a great many years and has become ingrained in the operating manuals for many companies, affecting the ways budgets are written, compensation packages are structured, Human Resources offices are run, etc. It’s difficult to overcome this sort of institutional momentum.

In addition, this process has the potential to impose a hefty burden on tech managerial staff. The impact of yearly reviews for each staff member can be severe enough on a manager’s time. Without proper planning an agile and continuously integrated professional development method could become a fulltime job in its own right.

These drawbacks are not inconsiderable but they’re also solvable and worth the time to do so. It will take a lot of planning to be sure this process is rolled out in a way which makes the most sense for your organization, but as with any worthwhile change (say, to using Agile and a rapid release cycle), if done mindfully the benefits reaped more than repay the effort.

Rant: I Am Not a Cat Herder

Cat Herding image CC-BY courtesy of carterse on Flickr; click to view originalIt’s a no-brainer. It’ll happen. If I were the betting kind I’d lay good money on it. Any time I’m mingling at some social event (cocktail party, BBQ, conference hallway track or pub outing, etc.) there will be at least one conversation which proceeds thusly:

Them: So, what do you do?
Me: Oh, I’m a software engineering manager.
Them: Ah! You herd cats! <insert self-satisfied chuckle at their oh-so-original witticism>

My typical response is to grit my teeth, smile wanly and change the subject. But ya know what? I don’t think I’m going to do that anymore. I’m rather fed up with the all-too-common misconception that managing software engineers is as chaotic and fruitless as wrangling a passel of felines. Seriously, if you’re a dev manager who describes his/her job as “Cat Herder” then just get the hell out of the business now. You don’t respect your staff and you’ve entirely missed the point of your job.

At no point in the management process should there be anything resembling “herding.” If your team requires herding then the problem is not the typically independent and outspoken nature of the software developers that comprise it. The problem is you. You don’t know how to be a manager. Communication, negotiation, mentoring, prioritization, leadership… These are the skills of a successful dev manager. Failure to learn, employ and constantly improve these skills leads to a team full of cats, loose cannons, powder kegs, prima donnas…choose your favorite negative descriptor.

It’s possible to learn these skills but only if you realize that it’s necessary. A good first step toward that is to stop implying your staff are unmanageable by calling them cats. Respect them as the intelligent people that they are, listen to what they have to say and clearly communicate the direction the company needs them to go and why. You’ll find that what you end up with looks a lot more like a functional and efficient team than cantankerous felines.