Retrospective: Evolving a healthy engineering culture
This post is part of a series. This week is a retrospective designed to look back at Perforce’s beginnings through the eyes of the company’s guiding architects.
When I accepted the job of Vice President of Engineering at Perforce 11 years ago, it was because I had an opportunity to build an engineering organization from the ground up where everyone was valued for their expertise, regardless of domain. At various points in my career, I have done every job in IT except documentation. For the first time, I had the chance to pull all the disciplines together and get them cross-pollinating. I found it motivating and fascinating.
In many organizations, Support, Quality Assurance, Development, and Documentation are separate entities that don’ t always work in unison. I wanted a group of engineers who respected each other for their specific expertise. Granted, we were small: When I first started, there were three developers, our CEO Christopher Seiwald was still responsible for coding the Server, there were no dedicated QA engineers, and the company had a total of 35 employees. Perforce is now 200+ employees and we have five development teams.
One key thing about our engineering culture was already in place when I joined Perforce: customer focus. This remains true today, as our Development, QA, Performance Lab, Build, Documentation, UX, Program Management and Release teams all revolve around customer support. Having Support be the center of our engineering organization is pretty unique in this business.
We started early on with Product Advocates, who were volunteers who would see a product from inception to general availability. Then we created virtual teams with people from each discipline. That has grown, as we now have a dedicated Program and Release Management team, but we still maintain the concepts that allow for release across the organization.
All of this was long before Agile, though I’ d say what we did would certainly qualify in terms of the emphasis on group ownership of projects, high communication, and building to meet customer needs. In the past two years, we’ve formally adopted Scrum and Kanban. Now, our Technical Directors act as product owners; Project Engineers are certified Scrum Masters; Support Advocates represent the customer; and UX professionals design the user experience. Our sprints are every two to three weeks and Agile allows us to hold regular reviews and get product out the door in a more timely fashion. Overall, our engineers have greater ownership of the development cycle.
The world is increasingly collaborative, with people moving into social networking, and web- and cloud-based applications. If you think about it, Perforce has always been about that way of working. Our productivity and innovation can be traced back to the culture that pervades Perforce. We value each other, we have forged long term relationships and we enjoy working and playing together.
Also, while there’s very little turnover in our Engineering team, I encourage people to switch roles, whether it’s from QA to Development; from Support to Development, QA, or the Performance Lab, or any other role they’re interested in.
What you have at Perforce is a very passionate, smart group of people who are good at what they do. As we grow and launch new products, I’m confident that our consistent rate of change and healthy culture will allow us to continue to provide customers with tools with which they, too, can be passionately innovative.