“Getting things done through others” is a common, one-line definition of management. While it accurately reflects the fact that there is separation between those who perform the work and those who don’t, this definition needs to change.
A major reason for this is historical. 20th century management techniques involved rigidly defining, organizing, and controlling the work. Work where the actual steps that produce output are very specific, concrete, and not subject change. Where the design of the work can be performed once and applied repeatedly; like the manufacturing processes where decisions flowed down from a hierarchy and the assumption was that those at the top knew more about the nature and needs of efficient, productive work than those executing the work.
This is why simple measurements work well in manufacturing settings. Measuring an input – like hours worked – provides a metric that correlates to the output. All other things being equal, the more hours worked, the more output produced. Likewise, outputs themselves are tangible and easy to measure because the same output is always being produced. The more widgets produced, the more productive the operation. The effectiveness of an optimization in one area of the process can be readily measured in the increase in output.
With software projects, design is a big part of the entire development process. There needs to be an overall, architectural design. Class hierarchies and methods to implement the business logic need to be designed. The choice of algorithms, data structures and control logic are uniquely combined in every program. Test plans and automated test routines need to be designed. There is always uniqueness involved, and design is a constant activity in each and every project.
Software projects can’t use simple metrics. You can try, like measuring lines of code, but using a simple metric doesn’t provide any value and it can even work against you. Over-emphasize simple measures and they will be gamed. You want lines of code? You’ll get them. But extraneous lines of code are counter-productive, making the code harder to understand and more difficult to maintain. Conversely, what incentive will people have to simplify code, reducing the number of lines and making that code more understandable and maintainable?
Using measures like overtime to keep yourself satisfied that people are putting forth their best efforts and that they are being more productive can backfire on you as well. Tired workers make mistakes. They cut corners that they know they shouldn’t, but when faced with getting home to their families, getting a workout in, or engaging in a hobby, they do. And cutting corners will haunt you later, when problems surface in spades.
The nature of knowledge work like software development is very different from factory work. Knowledge workers understand a lot more about the nature of their work. Between this and the continual design nature of the work itself, the hierarchal dynamic is inverted. And just as a designer of a manufacturing process examines his or her impact based on the outcome – the efficiency and profitability of the manufacturing process – we are better off being concerned with the outcomes of a software project and the care and feeding of those who produce those outcomes.
We're also better off when we aren't micromanaging competent professionals. They don't need to be told how to perform every step, they need room to work. Professionals need support from their organization along with a little assistance every now and then to get across the finish line.
Getting things done through others must change to enabling others to achieve results.
Enablement is about helping others to succeed. To provide the means and opportunity that makes success possible. It means supporting and guiding versus directing and controlling. It is about real-time decision-making and participation in making things happen versus delegating and judging after the fact.