It's a beautiful cloudless day, especially here at 36,000 feet. I'm on a flight headed for San Francisco and my brand new position as Director of Engineering for the Mobile division within Walmart Labs.
When I'm not on the job one of my passions is skydiving. As you might imagine, there isn't a lot of room for reflection when you're free falling at 125 miles per hour, but since I've chosen to stay with the plane for my full flight today it seems to be a perfect moment for a retrospective on the last segment of my career with my previous employer, Amirsys Inc.
I joined Amirsys 6 years ago, initially as the Technology Manager, then to Director of Technology and finally Chief of Technology. Amirsys was more than a job for me – it was a home, one that gave me a golden opportunity to test out a number of theories on making software development better. Thanks to my close association with Dr. Alistair Cockburn and the Salt Lake Agile Roundtable discussion group, I had no lack of theories, practices and experiences to draw from.
One of the techniques learned from the SL Agile group that I introduced to Amirsys was a retrospective format that focuses on three key questions:
- What worked? (Things that we did that worked well)
- What didn't? (Things that didn't work out well)
- Try? (What are we going to do differently)
This format worked very well for our teams at Amirsys, so I don't see any reason why I shouldn't apply it to my own career to see if I might actually learn something.
Agile Sadism. Creating and/or raising visibility on organizational “pain” was an effective tool in inducing cultural change within Amirsys, especially in the early days of adoption. Ultimately we created a team culture that was focused on rapid and repeatable delivery of value, value being defined primarily as revenue generating software.
Note to self: It's probably best not to actually tell your peers and your direct report that you are actively engaging in benign corporate sadism.
“Special Operations” team model. Amirsys as a company had a clearly stated goal, namely to reach a specific company valuation by creating a number of complementary revenue generating “fronts”. What we didn't know early on was exactly what these fronts were going to be. Forming the development teams around a "special operations" military model of small, cross-trained teams allowed us to repurpose our output at any time based on business priorities by shifting teams and team members members to where they were needed.
Just In Time team growth. Over time it was clear that our products would grow in revenue to the point where they would justify the services of dedicated team roles. Our “multiple front” business strategy made it difficult to determine when any one product would require a specific dedicated team role, rather than hire for the role on an individual product basis I introduced a “Just In Time” role growth plan across all products. When we reached a point where the lack of a dedicated role was slowing the progress of all teams we hired people capable of performing that role across multiple products. Once a role was established we would hire additional resources for that role based on overall workload.
Protecting the team. I believe it was Kay Johansen that drew a picture once that has stuck with me for many years. Essentially the picture was a team surrounded by a wall called "management". The purpose of that wall was to allow in positive elements - resources, praise, etc. and block the negative elements - decision thrashing, micromanagement, unnecessary process. The not-so politically correct term for the role of a manager in this context was a "shit shield". I took that picture to heart in working with my team at Amirsys and felt I did well - our annual team member turnover was less than 10% for the 6 years I was with the company.
What didn't work well:
4 Dimensional Trick Shot. Alistair Cockburn gets the credit for this term. Remember the old Disney "Flatland" cartoon that showed the peculiarities of living with different numbers of dimensions? Good. Now picture Goofy, standing in front of a four dimensional pool table. After carefully lining up his shot, he fires the cue ball right off into the middle of nothing. Three days later, when everyone has gotten bored and gone home, every ball on the table neatly drops into a pocket save one, which ends up landing directly on top of his head. Yes, that was me. Goofy, I mean - not the ball.
Knowing that we had multiple product fronts to generate revenue on and not enough time or resources to have a dedicated platform team, I opted to have the teams build the platform as they were delivering individual products. Imagine my dismay when the CEO and my peers became frustrated with my tendency to call shots like "Enterprise wide authentication and subscription management off the side rail and into the "project that seems to be getting no resources right now" pocket Tuesday afternoon, two months from now". Lesson learned for me: No more trick shots into dimensions that the rest of the business can't see.
"Racking up Technical Debt". Early in my tenure at Amirsys the leadership of the business indicated that we had a specific time frame to increase revenue in advance of a financial event. Believing this to be the case, I decided to bias the efforts of the development team towards delivering revenue-generating products and features as opposed to clearing known technical debt. Of course what ended up happening is that factors converged to perpetually keep the date of that event 18 months or so into the future. It tok me a good three years to really recognize the situation we were in and put more effort into selling the rest of the business on clearing technical debt, by which time our technical debt had accumulated to the point where significant effort was required to clear the most pressing issues. Lesson learned: Don't trade consistent effort on clearing technical debt for squeezing out a few more features. If a specific goal requires pausing on clearing technical debt, time-box it.
What do you mean, "I don't know when we'll be done?. When we finally got serious about clearing technical debt, the number one target was a nine year old application that had grown so fragile that any work within the application was at least 4X beyond when it was new. By this time we could either refactor the existing application in place, or to end all non critical support of the legacy application and kick off a brand new effort.Even though refactor in place is much more difficult than a ground-up rebuild, I chose that option to allow the business to continue to add features to the product as it was being refactored. Although I warned the business about the tradeoff between predictability in completion for ongoing feature development, when the effort spanned into several months the business became frustrated with my inability to give a hard completion date. Lesson learned for me: Tolerance for uncertainty on the part of the business as a whole is a critical part of the "Refactor or Replace" decision.
Relationships. It seems strange to be discussing relationships in the context of running a software team, but ultimately I believe that this is one of my greatest failures. The key relationships that I failed to properly manage were the ones with my peers and with the CEO and President of the company, who I reported to. At the heart of my relationship failures was a lack of effective communication - about status, about progress, about challenges. I believe that this lack of transparency and collaboration on my part ultimately led to a shifting of my responsibilities that took me out of the day-to-day operations. Lesson learned for me: The team is not just my direct reports. It is also my peers and who I report to.
Sunshine, sunshine, sunshine. Given that every single one of my "Didn't work" points had some element of communication and visibility involved, it is clear that I need to put more emphasis on "Sunshine" (one of the 8 principles of Crystal that discusses transparency and visibility). More specifically it is my intent to:
1) Define clear metrics that best report progress and status to the whole team, from leadership on down
2) Create and maintain ambient data collection mechanisms that gather metrics data organically from the working teams that feed into highly visible info radiators
3) Commit to interacting with the whole team on an ongoing basis to insure clarity of meaning from the metric data
Mentoring. It probably comes as no surprise that I consider myself an advanced practitioner of Agile. That being the case it is rather ironic that I haven't put much effort into encouraging the growth of others on my teams in the same subject. By putting more emphasis on mentoring in all directions (direct reports, peers, my superiors) I should be a able to multiply my effectiveness without increasing the amount of actual work I am required to do. Of course this also requires me to let go to the point where others are able to try different things, make mistakes and learn.
KISS, YAGNI, etc. From an internal dialog with my ego: "Yes, I do think I am a talented software architect, and yes, I definitely want the world to know this. But do I have to prove it by setting up those 4-dimensional bank shots just to show that my secret master plan is a work of genius? Can't I just be happy with putting more emphasis on clear metrics for success and let the team decide for themselves how best to deliver based on those metrics?"
Simply put, less focus on delivering expected value six months from now out of work being done now, and more emphasis on delivering actual value now. By setting up clear metrics for success around the work product of the teams I believe we will deliver more value now while maintaining clarity for the whole team on what we are building and how well we are performing at delivering it.