You are viewing an old revision of this post, from February 4, 2018 @ 17:02:32. See below for differences between this version and the current revision.
Recently, a colleague of mine recommended the book Slack to me.
I’m only part way through, but I have to say I like it a lot — mostly because it help to post hoc justify my own decisions.
I recall when I was first placed into a management role. I’d interviewed for a web developer role; gotten it; and then a couple of days before discovered that I’d have a designer reporting to me (who had started one week before me).
As this was my first “corporate” job, I was at a bit of a loss. Two things I did was to read a lot of management books, and listen to the backlog of Manager Tools.
The second was to struggle with “how much” work to assign to people (first; the designer; somewhat later, a statistician).
On the one hand, you want people to be as productive as possible. On the other, people that spend all of them time doing their “work” would never get better at it. That seems less than ideal.
Also, I ran into a few occasions where I’d assigned some work, and then during that week some needed change occurred — in a couple of cases, a client pitch. In some others, I’d just read something and wanted to bring it into the workplace.
In those two situations I’d get the question “Well, when am I meant to work on that?”
Gosh, I don’t know, I thought. During the workday?
I ended up making up a rule of thumb, and then centering our weekly one on ones on that rule. The rule was:
- 60% of your time on day to day.
- 20% of your time on learning to do your job better.
- 20% of your time on “process improvement”, to make your job faster/easier.
If I “assigned” (or they had scheduled) more than 60% of their “weekly hours” to their day job, I regarded them as overcommitted and tried to shift deadlines around or reprioritize.
I can’t say I was fantastic about it — you’d have to ask them — but reading Slack reminds me very strongly of doing that.
In brief, the argument (which occurs in other books, e.g. The Goal) is that people that are always busy impede the flow of work through the organization. The busier your are, the higher the latency for any additional work. If you have high latency, then efficiency in work further on through the organization is very low and total task latency is high.
Or: if you want an organization that is flexible, then you need to build in flex time.
Post Revisions:
- February 4, 2018 @ 17:02:32 [Current Revision] by Michael Griffiths
- February 4, 2018 @ 17:02:32 by Michael Griffiths
Changes:
There are no differences between the February 4, 2018 @ 17:02:32 revision and the current revision. (Maybe only post meta information was changed.)