Like many of my peers, I started my career during the height of the dot-com boom. And, like many of my peers, establishing a career in technology was more a result of time and place then of deliberate planning. In fact, my degree is in English Literature. Many of the people I have worked with, and especially those I have learned from, came to technology with experience, both real and educational, across a wide spectrum of disciplines. I would say that some of the most interesting, talented, and creative software engineers I have met all had been educated in something other that CS. In this way, the dot-com industry reminded me of the Motion Picture industry (and in 1998 the parallels were plenty), a business that I myself had spent 3 years in, learning to be a Film Editor before returning to my education.
As my career matured and I expanded my skill set, moving from web developer to software architect, I started to find that I was becoming more interested in the process by which Product and Software development teams achieve their goals. As a Software Engineer, most software problems had become routine, but I found that applying an effective process by which teams and companies move forward is a complex and ever-evolving challenge.
Of course, many articles and books have been written on how the software development process should run. Their names, acronyms, and philosophies are diverse and interesting, but not necessary to enumerate here. What I have come to learn, however, is that there is not a one-size-fits all approach to this problem. More often than not, a team develops some form of hybrid process – one that must account for the realities of team size and dynamic, the condition and requirements of the product, and the company’s market position and ambitions. One thread is consistent however: the effectiveness of your process has a demonstrable impact on the success or failure of your product.
When I was promoted to CTO last summer, the issue of our development process was front and center. We had just come out of a difficult period trying to release a new major version of our software. The entire team agreed that we needed to rethink our process; the process we had was simply untenable. Fortunately for me, I have a team of very smart and dedicated individuals, all of whom were ready to take the hard inward look and then execute on the hard decisions. My VP of Engineering, Rick Wolf, was especially instrumental in promoting this change by forcing a move to an Agile Process called Scrum. We haven’t looked back.
During this time, I purchased a small book titled “101 Things I Learned in Architecture School” by Matthew Frederick. It was written as a handbook for architecture students to help them better navigate the “murky and abstruse” landscape of their studies. I am a bit of a architecture nerd (having only later in life realized that I would have enjoyed the study) and will often pick up books on the topic. One page in particular jumped out at me. Lesson # 29 was titled, ” Being process-oriented, not product-driven, is the most important and difficult skill for a designer to develop.” The lesson continues by listing 10 definitions of process-orientation. As this issues is central to my responsibilities, I am going to spend the next few blog entries on sharing some of the definitions that had particular resonance. The first and number one on Mr. Fredricks list is:
“Being process-oriented means seeking to understand a design problem before chasing after solutions.”
In my next entry, I will take a little time to look at how this statement is applied to software and product development, how often you find the inverse applied, and how both impact the quality of your product.