Skip to main content

Giving, Taking, and Being Successful

Giving, Taking, and Being Successful

I’ve been making good use of my commute time recently, catching up on reading, and in particular, the stack of physical books on non-fiction topics that are somewhat relevant to my work. I was making good progress, only to have new, interesting stuff cross my path. One Sunday morning in December I caught part of an interview with Adam Grant on On Being. I wasn’t familiar with Adam Grant before this, but I’m extremely glad that I caught the show. I soon got a copy of Give and Take by Adam Grant, and I read his next book Originals shortly after it came out. In the spirt of giving, and of the serendipity that led me to learn about Adam Grant, I’ll also mention some of the other books Give and Take brought to mind.

I read Give and Take by Adam Grant as last year ended. This is was a great book to end one year and start another with, as it got me thinking about the value of generosity, not just to others, but also to your self.

Grant explains how givers (as opposed to takers and matchers) get ahead in the long run and also help their teams succeed. Teams which have people who have a positive attitude towards helping others in small ways often do better in the end, and in the long run the helpers are more successful too. This goes contrary to the idea that the way that you make progress is to focus on what you need to do. The reality is that for most complex knowledge work, you can’t do it all yourself. As Austin Kleon’s Steal Like an Artist says, the best creativity is inspired by the work of others. Helping others both enables the larger unit to make forward progress, as well as making it easier for you to get help with your work when you need it.

The idea of people who make the team better, even when their short term contributions don’t seem as significant brings to mind "Catalysts" as mentioned by Tom Demarco in Peopleware.( Slack, another book by Demarco, also came to mind because of it’s discussion of the willingness of volunteers to contribute to efforts). This book also brought to mind another recent book, Invisibles, which discusses the “invisible” people who make things happen, and who are happy to be out of the spotlight. I don’t know if I can say that all invisibles are givers but I would not be surprised if that were true.

Giving can have limits. Many people struggle with how to balance the idea that being helpful and generous is good, while not overcommitting themselves. Grant explains how to be a giver and not overextend yourself. Likewise, givers often have a hard time taking care of themselves by leveraging their tendencies to advocate for others. Both approaches involve an an “otherish-strategy,” which is one of the more interesting (of many interesting) concepts in the book.

To those familiar with Jerry Weinberg, this will seem related to the Airplane Mask metaphor in Secrets of Consulting. Grant gives a more detailed model of how to think it through. Weinberg’s metaphor is still good to keep in in front of mind though.

This book resonated with me on many levels. There are lessons here that will help me in my roles an agile software developer, manager, member or my town community, and member of my UU church community. The information here resonates with, and explains, many things I've learned from Gerald Weinberg, about technical leadership (as in the book Becoming a Technical Leader, and Gil Broza about the agile mindset, and many other useful things I've read about how to be an effective team member.

This book will help you to understand why that's true, how you can be a more effective giver, and how to encourage others to give, so that you can be part of a more effective team or community. As Adam Grant says, we need more givers.

update March 28, 2016: Fixed reference to the correct Tom DeMarco book. I mentioned Slack. I meant Peopleware.


_ _

Comments

Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…