Compartmentalization

It’s annual review time for my team. With a pivot to making a conversation out of the review session, some really interesting things happened. I’ve been asking a lot of questions and I’ve been getting a lot of really great answers. The results had me on the edge of my seat.

Did your team have good answers to the questions you had for them at review time? If they had great answers, then you’re doing a great job. If they didn’t, then you’re not.

Rands’ excellent post, ‘No Surprises‘ has been my informal guide for reviews this year. I took his, ‘A Review is a Conversation’ to heart, and debated with my team on where they’re headed, their areas of opportunity and the high leverage projects they should be working on.

Funniest thing is, if you’re making your people great, they should have great answers about their careers. And If you’re not asking questions of them at review time, perhaps you’re afraid the answers will fall short.

This year, my entire team had great answers.

How quick are you from board room to back office?

Through the four stories I shared in my QCon presentation yesterday, the broad accomplishment of Shopzilla’s greenfield site redesign, was incredible business agility. It’s true that we’re very fast from board room to back office.

I’ll extrapolate a little here on how our continued investment in our engineering and deployment infrastructure has been the biggest enabler for our agility.

Archetypes

Perhaps our biggest enabler has been our Maven archetype. In fact, we no longer have only one archetype, but a myriad archetypes for different purposes; web-services, spring-batch, Java-based command-line jobs.

Our archetypes allow our engineering teams to focus more immediately on solving business problems. Engineers of all levels of seniority, focus less on boilerplate, project structure, and deployment concerns. Our Maven archetype encapsulates;

• JMX MBean exposure using Spring
• Metrics exposure, through JMX using JAMon
• Sample Spring configuration and wiring
• Patterns forcing separation of configuration from application binaries

Business Agility, Cross Pollination, DevOps

As a result project structures look mostly the same from team to team, making cross pollination easy. Importantly too, our applications are homogeneous from a deployment / DevOps perspective. Distilled, performance of applications deployed to our any environment, can be visualized on our internal dashboards (permanently) in a matter of minutes.

I’ve written about this topic previously on the Shopzilla Tech Blog. The hindsight here is particularly interesting, in seeing how much the archetype approach has allowed agility from a business perspective. The proof: beso.com and more recently, tada.com.

Information from my QCon presentation, “Hot Swapping your Engines at 30,000 Feet – War Stories from Shopzilla’s Site Redesign”

War Stories from Shopzilla’s Site Redesign

Twitter post from @uclajug inquiring about the yield of the Fire Chief role

It’s been some months since the inception of the Fire Chief role, and I’d like to share further information about how the Fire Chief has helped the Inventory Engineering team realize their maximum potential. The Fire Chief role has proven that where legacy systems cause distractions, removing a single person’s capacity from the team’s total can actual increase the team’s velocity: team members are more focused, and have fewer distractions.

Before the Fire Chief

As I joined the Inventory Team, I was amazed to learn that the daily stand-up was more than 50% focused on discussion about fires. Any net-new user stories included in our iterations saw the attention equivalent to a second class citizen. Fires: important. New, strategic, foundational engineering projects: unimportant.

The Inventory Engineering Team's languishing velocity prior to the Fire Chief

After the Fire Chief

I still remember the day when the Fire Chief hat arrived in a wrinkled brown envelope at the office. I must admit to being pretty excited as I sat down with the team to unveil our brand new, bright red, Fire Chief hat. For a brief second there, the perspective that legacy systems and fires make for less glamorous work melted away.

If I had to point to the coolest part of the Fire Chief role? Overhearing people around the office, “Have you seen the Fire Chief?”. It’s so true that our Fire Chief is incredibly popular. What else is cool? Our burndown…

The Inventory Engineering Team's improved velocity with the Fire Chief

It’s also worth noting, that in a team where legacy systems meant distracted engineers, and bred more legacy systems, the Fire Chief role has bred focus, a passionate (popular?) team, and excellence. I’m pretty confident when I describe the Inventory Engineering team as “high performing”. Our stand-up meetings (which the Fire Chief still attends) are focused around new projects, with approximately 1 minute of the 15 minute stand-up dedicated to the Fire Chief’s daily report.

Proof in the Pudding

Our strategic, foundational engineering project, “Inventory LIVE!” is currently being launched by the team. Inventory LIVE! is focused squarely the incredibly challenging problem of scale; 200 million domain objects in an Oracle Coherence data-grid, 90 JVMs, 12 Tomcats, and RESTful web-services, using FastInfoset and JAXB, streaming over HTTP.

I should mention that Inventory LIVE! is a net-new engineering project, owned solely by the Inventory Engineering team. I’m confident that such an undertaking would not have succeeded without our Fire Chief concept.