There was a time when driving Formula 1 cars too harshly would cause them to break down a lot more. A driver with a feel for their equipment - applying subtle movements of the feet and hands at the right times - could not only preserve their vehicle, but also achieve a more elegantly controlled, efficient and faster ride. Some say, however, that nowadays computer technology replaces the need for this. Cars have become unbreakable and drivers desensitized. There is no longer any "mechanical sympathy".
In the tech industry, steady improvements in processing power over the years has allowed software developers to become similarly desensitized. Martin Thompson - co-founder of LMAX Exchange and expert in high-performance software - borrowed the notion of mechanical sympathy from motor sport and applied it to high-performance software applications. Good performance in software is the result of code written to utilize a computer's resources efficiently and “sympathetically”. After all, what use is there in optimizing an algorithm if three out of four CPU cores sit idle as the program executes?
But this is about another mechanical sympathy parallel - that which exists between leaders and their software development teams. If teams are the race cars - fast and maneuverable but also complex and brittle - then team leaders are the drivers. Only with mechanical sympathy can sustainable performance be achieved.
Mechanically unsympathetic
The trouble is today’s leader constantly faces the temptation to abstract, detach and desensitize. Management tools - software applications, processes, frameworks, metrics - seduce us into thinking that teams can be operated at arm’s length. Developers become avatars. Progress is a line on a chart or a sticky note on a whiteboard hopping from left to right. Creativity is coerced into weekly schedules as though it were linear and predictable. Verbal communication - what remains of it: ritualized and time-boxed. There is a subtle art to leading software teams that processes and tooling cannot replace. When they do, sympathy, along with the ability to lead, is lost.
Still, tools and process are not the root of the problem; they can only make an existing one worse. The real problem comes from failing to understand the challenges software developers face to begin with. There are subtleties and intricacies that give computer programming a depth few will comprehend. In The Art of Computer Programming the influential Donald Knuth calls it: “an aesthetic experience much like composing poetry or painting.” Fifty years of programming have passed since publishing this opinion but few would disagree with it were it uttered today. And this is to say nothing about the added complexity that comes when developing software collaboratively.
It goes to show that computer programming, despite attempts to be more, remains something of an esoteric art form - part engineering, part invention. It’s difficult for the uninitiated to control (though they try) a process they misconceive.
The pitfalls one encounters trying to run a software development team are numerous and the unsympathetic leader falls into every one of them. The over-reliance on tools and processes is one example but there are many more: measuring productivity in lines of code, adding developers late on to hit a deadline, valuing and expecting linear deliveries of work, obsessive focus on features to the detriment of quality, overspecifying, underspecifying, and so on.
A little more understanding would surely see some of these pitfalls avoided.
While developers neither expect nor require their leaders to be technical experts, one that shows no grasp of the challenge - and no interest in becoming more informed - quickly loses respect. The “us” (technical people) and “them” (management) division that results is as unfortunate as it is devastating to the ability to lead. Unfortunate, because the contrary is also true. A leader that demonstrates interest in technical problems - putting time and effort into becoming more knowledgeable - will in turn be treated sympathetically. In essence, this is what mechanical sympathy is all about.
Beware the unsympathetic leader and the adequately performing team
Unsympathetic leadership does not automatically result in dysfunctional teams destined for failure. Often a team’s natural impulse to go forward can be sufficient to make some measure of progress. In fact, some capable and resilient teams make relatively good progress regardless of leadership shortcomings.
The combination of a resilient team and a management process that gives the appearance of organization can look quite convincing, especially to the unsympathetic leader. But a Formula 1 car driven around in first gear is no achievement. Teams in this situation may go on indefinitely at the same sluggish pace, never getting close to performing like they should. How many expensively assembled teams are being driven in this manner by leaders that barely know it?
Recognizing when a team is underperforming is the challenge leaders face on a daily basis and where mechanical sympathy can make the difference.
The sympathetic leader
The sympathetic leader understands the following:
Software development is a creative process - innovation comes in waves - so progress will not be linear. Prioritizing a steady stream of deliverables over solving problems properly will result in poorer solutions and frustrated engineers.
No significant development work is predictable or repetitive - otherwise it would have been automated already - so why request accurate estimates or forecasts.
If a quality product is desired, time spent on the part you can’t see - good architecture, eliminating technical debt, refactoring code, etc. - is as important as the features and functionality that you can see.
Developer ‘flow’ is a precious thing. An ill-timed meeting or disruption can mean the loss of a morning’s work.
A failure to procure paid software, extra screen real estate and a comfortable chair for developers is far costlier than the expense of purchasing those items.
It takes time and effort to transform a group of developers into a team that performs.
Verbal communication outside the confines of structured meetings is likely to result in a more fluid, open conversation; this is how a leader keeps a finger on the pulse of the team.
Performance impediments come frequently and in many forms. Eliminating them is an ongoing pursuit.
Interest and education in technical topics makes for better and more sympathetic leaders.
It is the leader’s responsibility to be sympathetic to all of this and more. Development teams cannot reach their performance potential if awareness is lost in abstractions or leaders are otherwise desensitized or unsympathetic.
A little understanding
In the pursuit of high performance a leader must be sympathetic. Like race car drivers of old, it comes down to subtle actions - imperceptible to onlookers and only possible when completely in tune with the needs and struggles of the team. It takes time, effort and experience to develop this kind of sensitivity.
The effort doesn’t stop once you have performance where it needs to be either. The best leaders never take their eyes off the road. They know when to drive hard and when to ease off the throttle. They know how to recognize outstanding performance and how to ensure a team is able and willing produce it when needed.
A team steered sympathetically will respond favorably.
Mechanical sympathy benefits not only leaders of software development teams but all leaders of teams engaged in complex work.
In short, a little understanding goes a long way.
