
Recalibrate Your Productivity Sensors - nkzednan
http://www.tombartel.de//2016/07/05/recalibrate-your-productivity-sensors/
======
vegabook
Excellent article, well thought out, a parsimonious distillation of the
essence of day-to-day management. However it ignores a crucial issue in all
management jobs, and that is credibility erosion. "Boss doesn't have a clue
about the code". Which leads to "I'm cleverer than the boss" and creates a big
management problem. So once in a while the boss has to _show_ why he's boss,
that he's amongst the best at the line-functions of the job. Nothing worse for
team morale and productivity, than professional managers who do everything Tom
Bartel has said here perfectly, but have no operational competence or
credibility in the actual domain that the the team operates in.

~~~
anaolykarpov
I'm a Perl dev and at my previous job my PM was an ex java dev, while the
department manager didn't even had technical background (he was an economist).
This meant that the management had to completely trust us regarding the tech
part of the project (estimations, technical solutions, overcoming obstacles,
etc) while we trusted them with regards to the non technical issues of the
project - mainly the non tech interactions with the customer. The relationship
between developers and managers was one of collegiality instead of a boss-
subalterns one where everybody knew their role. They were our facilitators and
enablers, not our bosses, while we were doing our best to put them in the best
position possible to the client.

~~~
tushar-r
What you said about the PM and Dept. Manager, reminded me of this article by
Rands:

[http://randsinrepose.com/archives/entropy-
crushers/](http://randsinrepose.com/archives/entropy-crushers/)

== A good project manager is one who elegantly and deftly handles information.
They know what structured meetings need to exist to gather information; they
artfully understand how to gather additional essential information in the
hallways; and they instinctively manage to move that gathered information to
the right people and the right teams at the right time.

There are humans who are really good at this. They thrive on it. Engineers
have difficulty believing this – it’s the same issue they have with managers.
They see these strange humans focusing furiously and scurrying hither and yon
and they wonder, “What are they actually building?” They’re right. Project
managers don’t write code, they don’t test the use cases, and they’re not
designing the interface. You know what a good project manager does? They are
chaos destroying machines, and each new person you bring onto your team, each
dependency you create, adds hard to measure entropy to your team. A good
project manager thrives on measuring, controlling, and crushing entropy. ==

------
jonathanfoster
There's only one measure of management productivity and that's the output of
their teams. The go-to book on this subject is High Output Management by Andy
Grove [1]. It is hands down the best book on management. I highly recommend
this book to anyone who is transitioning into a role where you'll be leading
people.

[1] [https://www.amazon.com/High-Output-Management-Andrew-
Grove/d...](https://www.amazon.com/High-Output-Management-Andrew-
Grove/dp/0679762884)

------
lugus35
> "Do pair programming with an employee"

If you are a 100% manager, then you will not be able to pair program for a
long time as your programming/technologies competences will fade away quite
rapidely.

~~~
golergka
Competence required in pair programming may be very different, though. A lot
of times, a co-pilot who understands the fundamentals well, but doesn't know
particular framework/library would still be a great service, just for asking
the right questions.

------
gfody
_If you spend a lot of your time coding, you are preferring an activity that
also others can do to something that only you can do._

For some reason this sentence took a while to make sense

~~~
jaredsohn
I experienced the same thing. I think moving 'also' like this makes it more
clear:

 _If you spend a lot of your time coding, you are preferring an activity that
others _also_ can do to something that only you can do._

~~~
dasil003
Even better if you move it one word further?

 _If you spend a lot of your time coding, you are preferring an activity that
others can _also_ do to something that only you can do._

Or maybe just change the whole phrasing:

 _If you spend a lot of your time coding, you are preferring an activity that
someone else could do to one which only you can do._

~~~
tbartel
Thank you for your suggestions. I actually adopted your last one, see
[http://tombartel.de/2016/07/05/recalibrate-your-
productivity...](http://tombartel.de/2016/07/05/recalibrate-your-productivity-
sensors/)

