Re: Should I Bill for Time Reading?

["Steven J. Owens" <puff -at- NETCOM -dot- COM>]

Anonymous asks:
> I recently started working for a small software company as manager
> of their Publications group. [...] like to spend some time reading
> two or three good books on the subject of management.
> [...] 6-month contract-to-hire position at a reasonable hourly rate.
> [...] president of the company) talks and behaves as though I'm here
> permanently [...]
>
> My question is: Is it ethical to bill the company for time I spend reading
> these books on management? In most contracting situations, I would think
> not. But in this situation, it seems like it might be legitimate.

Tom Johnson suggests:
> Ask your manager if he is willing to pay you for improving your skills. If
> you think he wouldn't approve your request, you shouldn't bill for it. If
> you think he will approve it, then ask him.

     Well, I'd say it couldn't hurt to ask, but in general I'd suggest
just billing for a straight 40-hours-a-week and don't stress about it
either way.  In other words, don't be afraid to spend an hour reading
while at the office, but likewise don't be anal-retentive about
tracking and billing for all of your time.  As long as you're appearing
at the office for at least 8 hours a day and you're averaging out to be
productive, just roll with it.

     If it comes naturally to you, go ahead and track all your hours
and what you're spending your time on, in the office and out of
it. This can be an excellent way to learn about your work habits and
improve them (or learn to take advantage of them - are you best at
creative problem solving in the morning, and routine detail work in
the afternoon, or vice-versa?).

     The consensus I've read and heard about in the contracting and
consulting field is, if you're reading something specifically to solve
a problem for the client, and it isn't something you're supposed to
already be a master of, go ahead and bill for it.  If it's generally
useful stuff you'd like to learn about anyway, or an area related to
your expertise but not directly in it, you might bill at a partial
rate.

     However, in general my feeling is that the best approach is:

     First, make sure you're not making people uncomfortable - usually
to do this you have to put in 8 hours a day and five days a week,
regardless of how many extra hours you spend on a given day or how
productive you are in those hours.  People are funny this way.

     Second, assume that you're putting an investment of time and
energy into your own skillset and reputation, so you don't need to
specifically bill for that time.  I generally try to build all the
overhead into my rate, so ultimately I get paid - and I demonstrate my
worth.

     Third, but on the other hand, be equally unafraid to do some
reading at the office, if it's appropriate - something you need to
check up on right now, or a good way to fill some "dead air time", or
a good way to revitalize yourself or adopt the proper mindset.

     For example, I'm currently working on a very java-intensive
project, so I try to spend the bus ride in, in the morning, reading a
java book, ideally a topic in the book relevant to the day's project.
It gets me in the mood, puts me in a programming frame of mind, and
starts me thinking about what I'm going to be doing.


     Since you're working for a software company, I strongly encourage
you to bone up on software project management, so you know how best to
fit your work into the overall context.  Also, a lot of general
project management material comes from software project management
research.  Much of the theory in Hackos' book, for example, is cited
from the Software Engineering Institute's research - specifically the
Capability Maturity Model comes to mind, but other topics as well.

     Start with Fred Brooks's classic _The Mythical Man Month_.  It's
slim, fairly readable, and will give you some sense of the legacy of
project management in this field.  Plus, having it on your shelf
should convince most programmers that you have something of a clue, or
are at least seriously interested in obtaining one, about what they do
and how they do it (We don't want to *be* them, but we do want to
*understand* them; after all, we are supposed to be the expert
communicators :-).

     Brook's central premise is a "surgical team" approach, with one
"master surgeon" architecting the project and providing conceptual
unity (a very handy concept), and other specialists tackling specific
areas.  The state of the art has gone a long way since then, but this
is a good starting point.  Brooks also has some excellent things to
say about internal project documentation - you might want to select a
few pages, highlight the specific phrases, and have them printed up
poster size :-).

     Start there, but don't stop there.  Steve McConnell's _Rapid
Development_ is a good next book, a voluminous tome but well worth the
reading.  Read the first chapter, then just browse it, you'll almost
always come away with something worthwhile.  _Rapid Development_
(which is *not* about a software development methodology called "Rapid
Application Devleopment", AKA "RAD") is more directed at managers and
addresses the broader aspects of software project management.

     If you want more of the rank & file, in the trenches point of
view, with lots of theory to back it up, check out _Code Complete_.  I
had to learn a lot (of what little I know) the hard way, and I kept
wishing I had a good anthology of the various excellent articles and
papers I dug up on the topic.  McConnell's book answers that wish
quite nicely.  He also has a third book meant to be very concise and
practical, for programmers in the trenches who don't have time to read
a 1000-page tome and ponder the theories.

     In addition, I'd suggest you subscribe to the CACM and several of
IEEE's publications (_IEEE Software_ to start, they have a bunch - I
think there's one related to project management specifically, but I
found a lot of good stuff in _IEEE Software back when I had regular
access to it).

     Both the ACM (Association for Computing Machinery) and IEEE
(Institute of Electrical and Electronics Engineers) are professional
organizations. You should have a decent shot at getting your employer
to pay for the memberships and subscriptions (I think _Communications
of the ACM_ comes with the membership).  Some companies routinely do
so for their software engineers.  While you're at it, try to get them
to pay for your STC membership as well.  You may want to wait until
you become a permanent employee, or maybe bring it up with your boss
and if he's reluctant to do so immediately, ask him to commit to
reimbursing you for the ACM, IEEE, STC, and various books once you
become a permanent employee.


Steven J. Owens
puff -at- netcom -dot- com
puff -at- guild -dot- net

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=