Book review: Slack
Join the DZone community and get the full member experience.Join For Free
I'm glad I started reading book oriented to managers.
Slack, by Tom DeMarco (author of Peopleware) starts with a simple fact: if you're busy in the normal operations of your business (usually development) all the time, you will never have time for learning and change the way you work. In particular, optimizing for efficiency in knowledge work tends to cut away the slack time that programmers have in their work; the very time that would be used for experimentation and innovation.
From that, Slack moves to describing the dysfunctions created by the goal of keeping everyone busy all the time, on the activities they know best. The book is a guide for the middle manager (middle is not an insult: it means still involved in the daily work).
Slack is not only oriented to software developers, but DeMarco has experience in the field and is famous for his other books such as Peopleware. The target is that larger category of knowledge workers, of which I' m sure your organization hires plenty.
This book is for you:
- if you ever wondered why the most innovative things about your projects have been introduced in free time or while there weren't features to implement (e.g. introducing Cucumber; new APIs that make life easier for everyone.)
- If you are looking for a way to define your responsibilities as a manager or a leader, not strictly as a programmer (leading does not need a different formal role).
- If you feel something is wrong with the corporate ways of the Force, but do not know how to respond.
- If you have experienced a process that tries to keep everyone busy instead of focusing on a vision of the final product and on which business goals we want to achieve.
Summary of the views
There are so many takes on management (even just in software development) that I have to "inquadrare" the author before discussing and fully understanding his work.
DeMarco is Waterfall and its Death Marches, but that was an easy thing to do. He's also close to the Agile and Lean movements, given his respect for people as the most important asset of a knowledge organization and seeing turnover as a large capital loss.
In fact, DeMarco recognized the issues with Taylorism and trying to apply an industrial mindset to the software development field, for the known confusion betwee designing and building.
He's not an Agile by-the-book coach however: Servant Leadership advocates may find some issues with some part of the books, such as the 2nd law of bad managers which tells them never to assume the responsibilities of workers and of work beneath their skills.
[This] book shows managers how to make their organizations slightly less efficient but enormously more effective.
An organization that can accelerate but not change direction is like a car that can speed up but not steer.
[...] human workers are not entirely fungible.
The hierarchy lines are paths of authority. They are far too narrowband for all the information that needs to be communicated. Communication in healthy companies takes place in the white space [of the organigram].
Slack is the way you invest in change. Slack represents operational capacity sacrificed in the interests of long-term health.
In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. Aggressive schedule, I've come to suspect, is a kind of code phrase understood implicitly by all involved for a schedule that is absurd [...] Suppose you were to read in the newspaper that your country's brand-new air traffic control system was to be developed on a highly aggressive schedule. What's your response to that? Is there any little voice inside you whispering, "Wait a minute here; let's not hurry those folks along too much"? (If you dont hear such a voice, I guess you dont fly much.)
The notion that impossible schedules don't damage projects strikes me as ludicrous. [...] The sprint-gasp-sprint-gasp marathon would probably take you twice as long to complete as a more normally run twenty-six miles.
I chided one of my clients, an engineering company in the Fortune 500, for all the overtime his people were working. "What would you do, I asked him, if overtime were forbidden and you still had to make the schedule?" "Well, I'll tell you one thing," he answered promptly, "we'd sure have to do something about all these meetings."
If the term "empowerment" is to have any meaning at all, it means putting process ownership largely into the hands of the people doing the work. That doesn't mean there should be no standard, only that whatever standard evolves should happen at the level of the work itself.
When people tell me, "I wish my boss could have been here," I know my message has landed and I've gotten it to exactly the right person. If the message had made no sense to the receiver, he/she would have wandered away without comment; if the message conveyed no call to action to that person, there would have been nothing to resist. The person who is wishing most fervently to thrust the responsibility onto some higher-up is the very person who knows that he or she could make the change happen, but of course it won't be easy. It will involve managing upward and sideways, and perhaps calling in some markers from people all around the organization. An act of leadership is about to happen.
Slack is about management - the realistic kind - of how your organization spends its time and of the control that is given to knowledge workers to empower them. Slack is a resource that allows innovation and change, and an organization that cannot change is stuck in a stasis that the modern business world does not allow. You hear enterprises talking about innovation all the time - yet the investment of slack is the most basic one they are reluctant to apply and that enables what they want.
Opinions expressed by DZone contributors are their own.