What Software Teams Can Learn From Architects

#PivotalVoices is a series where we talk about how and why people came to technology. This week we feature Judy van Soldt, a product manager in our San Francisco office.

“I was trained as a building architect and I’ve practiced for more than 15 years, including as a project manager on buildings here in San Francisco. As a profession, it is very unpredictable: whenever there is a recession, architects are always the first ones laid off — and the last ones to be rehired after the recovery.

In 2009 I was part of a layoff. Shortly thereafter, I got a phone call from a friend who was building a software team for a project in New York. He said, “We need a project manager… When can you get here?” So in five days I packed up and moved to New York, and I lived there for six months and it was amazing. It was my introduction to agile, introduction to product, introduction to software, introduction to media, introduction to living in New York, all the new things; it was great…

A good architect is very user-focused, and not just on the needs of the person who’s paying for the school, not just the person who’s taking classes or teaching at that school, but also on the neighbor who will walk past every day for the next 50 years and experience that school as an integral part of their city.

After I returned, the Gray Area Foundation for the Arts in San Francisco hosted a themed weekend hackathon about buildings, energy, and transportation — things I know something about. So I thought I would go as a subject matter expert. But when I went to the hackathon, I got on a great team as Product Manager, and we won! We designed an app to help the SFMTA improve transit vehicle reliability and manage their whole system in the field.

Meanwhile, I had been going to meetups of the Bay Area Agile Leadership Network. At one event, before the speaker began her presentation I was waiting in line for pizza and beer, and I met Will Read from Pivotal who said, “We’re looking for PM candidates.” Six weeks later, I had a job.

In a lot of ways, the world of product design is not that different from a building architect’s responsibilities. Think, for a moment, about a new elementary school. A good architect is very user-focused, and not just on the needs of the person who’s paying for the school, not just the person who’s taking classes or teaching at that school, but also on the neighbor who will walk past every day for the next 50 years and experience that school as an integral part of their city.

Of course, construction is a waterfall process. But architecture doesn’t have to be, and I had already started to push that in my practice before I even knew what lean and agile were. What’s the least we can draw or model to communicate the intent? Often, the feedback on drawings from building agencies or from client stakeholders is contradictory, and you have to negotiate that while keeping the integrity of the design. In a lot of ways, these are little feedback loops, but they can have a huge impact.

But the ultimate feedback, even on a smaller project, has to wait until the project’s completely built and occupied. Then — and only then — can you really get the feedback on a design that you did maybe two or three years before. So from that standpoint, software is much more exciting, because the opportunities to self-correct come much faster and more often — before the decisions are set in concrete!

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.