Ask the impossible….

I was recently approached by a previous employer to go back to them. All very flattering, though I’m not sure that it’s for me. But it got me thinking about why I left. Like most job changes I suspect, in loose (or polite) terms this one was driven by “philosophical differences with management”.

What that came down to in this instance was goal setting. Goals at this company were set very aggressively – during the time I was there I don’t think we ever hit all the goals of a project, and reading between the lines of annual reports since I’ve left, it looks like that record has been maintained. There are a lot of reasons why that might happen, but in the case of this company I think it’s because the CEO is a believer in the maxim “ask the impossible to achieve the best possible”.

That’s not something I buy into. To me, overly aggressive goal-setting is counterproductive.  It leads to rushed work, poor decision-making, and an inevitable descent into firefighting and resource shortages.  Products get launched half developed, which leads to poor sales growth, reputation damage, and still more rework. If developers don’t buy in to the possibility of management’s goals, they ignore them and start to set their own, which makes it that much harder for management to maintain staff morale (and to maintain their own credibility:  from personal experience, trying to persuade people that something that both you and they know is a dumb idea is actually a good one is no fun) .  Stress and the repeated sense of failure when goals aren’t met (even if the project turns out to be a success from a long-term business perspective) kill motivation, and lead to burnout and staff turnover, thus exacerbating the resource shortage problem.  Resource shortages lead to the low-priority infrastructure and forward research jobs never getting done, which in time reduces the organization’s innovative capacity enough that even just keeping up with the competition is a  stretch, never mind getting ahead.

You can get away with setting big hairy audacious goals every so often (though it’s worth noting that the original BHAG was supposed to be a vision statement – something so long term that the question of actually achieving it never really arises), and goal setting needs to be aggressive enough to avoid gold-plating and the student syndrome, but going for the big win as a matter of routine doesn’t work.

Engineers’ personality types

For purposes of motivation and task assignment I’ve tended to think of design engineers as being somewhere on a spectrum between two extreme types I term “creator” and “builder”.

Creator types are in it for the challenge of coming up with something new, and are happiest when on the very edge of being out of their depth. Their biggest buzz comes when they’ve been beating their head on something they thought was impossible for weeks and have just seen the fist glimmer of a solution. Although the best of them recognise and enjoy the synergy that good teams bring, being part of a team per se doesn’t do it for them. They perform well under extreme pressure but can’t sustain high stress levels indefinitely – a “sprint and glide” environment works best for them. They respond well to an “only you can save mankind” approach.

Builder types like the feeling of being a cog in a well-oiled machine. They like well-defined tasks which are challenging but clearly possible, and enjoy the steady flow of task in, task done, task out. They don’t respond well to the extreme pressure you can apply to a creator type, but will hold up at their pressure limit for much longer. They need to see that the rest of the machine is holding up its end, but given that respond well to a “don’t let the team down” approach.

Most of us sit on a spectrum somewhere in between the two, and understanding where someone fits (which may move around depending on circumstances) is an important line management skill.

I’m reading Boehm & Turner’s “Balancing Agility & Discipline” [47] at the moment, and I’m interested to see that this stacks up pretty well with the “Agile” and “plan-driven” workspace cultures they refer to (p49) . I hadn’t thought of it in the context of matching the project approach to the people you have, but – yes.