Team Geek

ISBN: 9781449302443
Available on O'Reilly →

Found in 6 comments
by kashyapc
2018-04-11
This reminds me of the following, from the book Team Geek[1], chapter "Offensive" Versus "Defensive" Work:

[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”

We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.

[1] http://shop.oreilly.com/product/0636920018025.do


Original thread
by foz
2015-06-21
As a manager, 1-1s should not just be considered status reports. They are a way for you to build trust and communication with your staff, and to give them a chance to talk about anything: problems, work on personal development, or feedback about you as their manager.

1-1s are probably your most valuable tool. Often, you will discover problems and info you would have otherwise not known - "our lead developer seems depressed and was talking about quitting", "did you hear about that other project that started? It's in direct conflict with our plans...", "there's a conference coming up, we should present at it", and so forth.

An effective manager should, in my opinion, spend 50% or more of his time with his team. Working on the same topics, talking to them, helping to plan, fixing problems, finding resources, and doing 1-1s. It's no surprise that teams with the most problems often have a manager who is just not around enough.

For new managers, I always suggest the following resources as a great starting point:

- "Team Geek": http://shop.oreilly.com/product/0636920018025.do - "Managing Humans": http://www.amazon.com/Managing-Humans-Humorous-Software-Engi... - Manager Tools podcast: https://www.manager-tools.com


Original thread
by webmaven
2014-06-24
From a technical perspective, I have found 'The Mature Optimization Handbook' invaluable: https://www.facebook.com/notes/facebook-engineering/the-matu... (HN discussion here: https://news.ycombinator.com/item?id=6763683)

'Team Geek' is a great primer on technical leadership: http://shop.oreilly.com/product/0636920018025.do

Another recommended book is 'Shipping Greatness': http://shippinggreatness.com

Assuming you're already familiar with 'The Lean Startup', there has been a series of excellent 'sequels' on many more specific disciplines that you will likely find useful: http://theleanstartup.com/the-lean-series

A recent addition (that I am still digesting) on Agile processes beyond Scrum is 'Unblock!': http://www.continuousagile.com/unblock/ (Posted to HN a few days ago: https://news.ycombinator.com/item?id=7921200)


Original thread
by DavidHogue
2013-09-06
They also have a few other talks on youtube about similar topics and a book now: http://shop.oreilly.com/product/0636920018025.do
Original thread
by harper
2013-07-29
Surprised that this isn't in the thread already.

Brian Fitzpatrick and Ben Collins-Sussman from Google have done a bunch of great talks about exactly this: How Open Source Projects Survive Poisonous People (http://www.youtube.com/watch?v=Q52kFL8zVoM)

They also wrote a book about the topic: http://shop.oreilly.com/product/0636920018025.do

All of their advice comes from their experience running the subversion project. It is also good general advice for dealing with humans/engineers/etc.


Original thread
by radicalbyte
2013-01-17
Replace "geek" with "highly sought after, intelligent and talented employees" and you'll be closer to the truth.

The reason developers are "hard" to manage is that they're in demand, so they don't have to put up with bad or abusive management.

That said.. I'd recommend reading Team Geek (http://shop.oreilly.com/product/0636920018025.do) if you have any ambition to move into a management or leadership role.


Original thread

Looking for a good book? Subscribe to the weekly newsletter.