Building Software is Amazing
For the past 6 months I’ve had the opportunity to work on one of the best projects of my career. This thing has all the buzzwords: big data, social media monitoring, semantic analysis, kanban, ruby on rails, github, distributed teams, expertsourcing, skype video, lean, pragmatic, platform, you name it. The team is brilliant and highly skilled in their areas of expertise (rails programming, UI/UX development, architecture). Each member cares deeply about their craft and is highly passionate about our project. We argue, we collaborate on great ideas, and all stress the difference between opinions and facts.
This quick reflection just reminds me that building software is amazing. It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product. Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles. I can’t wait to see what shows up in the next “git pull”.
Calendar Retrospective
You feel busy, wish you had more time and work really hard but feel like you are still behind. Sound familiar? It’s time to do a retrospective on your calendar.
I use a program called RescueTime to analyze my productivity in conjunction with BusyCal. I have tuned the software to run from 9a-5p only Mon-Thu. I don’t like to analyze my Morning Think or nightly reading routines and work at home on Friday usually declining meetings. A few weeks ago RescueTime told me that I was averaging 6hrs per day talking, on skype or in meetings. No wonder I was struggling to keep up with my workload.
I decided to try an experiment to see if I could reduce the 15 or so meetings I had on my calendar for the upcoming week. I reached out to Project Managers explaining what I was doing and asking to be removed from the meeting request for a few weeks. I promised to rejoin if my name kept coming up in the meeting. This worked and I have reduced some of my standing meetings freeing up some quality time to be productive.
Our our software development team we are using agile and have a scheduled retrospective at the end of each release (quarter). It is important to physically block time for the team to analyze how they work together, pros and cons and ideas to improve efficiency. I am finding this same concept is important to the quality of your personal productivity. Do yourself a favor and conduct a calendar retrospective.
Looking at my book shelf organized with business books, seeing my iPad filled with iBook samples and seeing the New York Times Sunday edition laying around would make you think I’m a big reader. In fact, I’m a fraud. I’m the person that likes to start lots of books, read for a few minutes at a time and hardly ever finishes a book. I pre-ordered Do More Faster by David Cohen and Brad Feld and read it from start to finish the day it arrived.
Do More Faster is divided into 7 Themes: Idea and Vision, People, Execution, Product, Fundraising, Legal and Structure and Work-Life Balance. Within each Theme are several 1-3 page stories written by Entrepreneurs, VCs and other interesting people in the software, internet, product development, startup realm. It’s a great format for the hyper caffeinated, ADHD, check twitter while your reading type of personality.
This book was fun for me to read because many contributors are familiar faces I either work with in some capacity or have seen around the flourishing Boulder/Denver tech community.
Chapters that blew me away and taught me something brand new:
- To 83(b) or not to 83(b), There is No Question – Matt Galligan
- Usage is like Oxygen for Ideas – Matt Mullenweg
- Karma Matters – Warren Katz
- Don’t Plan, Prototype – Greg Reinacker
Chapters that reinforced some of my favorite work related topics:
- Don’t Suck at E-mail – David Cohen
- Get Out from behind Your Computer – Seth Levine
- Be Specific – Brad Feld
- Get Feedback Early – Nate Abbott and Natty Zola
If you want motivation for anything you are doing I highly recommend Do More Faster.
David Allen’s Getting Things Done (GTD) approach reiterates the challenges of breaking a Project down into Tasks. He focuses on the psychologic barriers people have with the work in front of them. A common example (I’m paraphrasing here) is a person adding “Mom” to their ToDo list. When digging further, David discovers that “Mom” really means “Mom’s birthday is coming up” and there are no Tasks or “Next Actions” defined to move the Project closer to completion. This avoidance is very stressful on the person and a very inefficient way to life a busy life.
We use Rally’s ALM product and the Kanban custom tab to manage our User Story development. I have worked with 2 teams over the past few years and both I consider quite amazing and talented. Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved. Our teams crank out great software, but always within a stressful environment.
As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”. Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?” I realized how similar GTD Projects and Agile User Stories really are.
- A GTD Project clarifies the outcome you want.
- An Agile User Story describes what the User wants to achieve.
Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion. In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource. Also in both, if Tasks can be defined it signals a complete understanding of the work to be done. Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.
My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time. We joke a lot about a common Task name we use in Rally simply titled “do it”. Again, the GTD project similarities are strong here. The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work. Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.
By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!
I was watching This week in Venture Capital #18 with Brad Feld hosted by Mark Suster and was pleasantly surprised to hear “Product Manager” pop up as a topic. At minute 47 of the interview, Mark asks about the “lack of experienced Product Managers”.
Brad says “One of the hardest roles to fill in a startup is that of an experienced Product Manager.” He goes on to say that one can be trained to be a good Product Manager but that person needs to have a certain personality type. Brad cites a quote from Mark Pincus “Be CEO of your job” and goes on to say “If you are a Product Manager for a specific thing, you have to deal with it just like a CEO has to deal with the whole company.”
Some personality traits that do not help the Product Manager are:
- too process driven
- not a good mixture of leadership and management
- not willing to be uncomfortable creatively with it then button down to drive to the goal line
The conversation wraps up with comments on the changing approach to Product Management as the role has become very formalized in big companies. Brad and Mark talk about the older Product Manager/Project Manager setup at Microsoft and the how today’s “Google style” Product Manager is a very different personality type in a very different role. Mark argues this type of personality (product, engineering driven) is not focused enough on the economics of the business and then Brad counters by saying that he would take a call from any Product Manager for a product at Google in a heartbeat. Brad concludes the conversation by reiterating the notion of owning the whole function and knowing how to allocate resources is a powerful skillset and a “very hard role to find”.
