Guest Post by Aaron Bach
It all started with an art museum.
About two years ago, our CEO, David Levin, stood at my desk and looked at a custom sign build I had created for the Denver Art Museum (a local client of ours and one that, incidentally, our new building backs up to). The build featured some exciting, compelling functionality: sign-to-sign wayfinding, exhibit promotions, and dynamic pricing. As I demoed it to David, he said something that would fundamentally alter the course of FWI: “We should be promoting this application to every single museum in the country.”
Initially, I didn’t catch the weight of his comment. After all, promoting our best work – meeting room signs, flight boards, virtual concierges, etc. – to entire industries was something we did every day. David wasn’t talking about that. He wasn’t implying that we ought to create a “Custom Museum Application Statement of Work” for every museum in the country. Rather, his vision was something far greater: we ought to sell this exact application (along with a way to customize key aspects) to every museum in the country.
This was a radical notion. It scared me. To date, our software platform had been focused on custom digital signage and content management. We had always done things a certain way, and this wasn’t it. How could we possibly accomplish this? Could the software even do it? What did this mean for FWI long term? Who would manage a program like this?
So, like any careful, measured, responsible technology leader, I thought about all this in the span of three seconds, swallowed my concerns, and boldly proclaimed, “Let’s do it.” At the same time, I remember thinking, “Aaron, don’t you dare regret this.”
Fast forward. After a year of “working group” status, we launched FWI’s Application Development program in January of 2015. And now, as we near the end of our first official year in operation, I want to reflect on some of the big things we, as a team, have learned along the way.
Forming a Development Team
The construction of a competent software team is never easy. In our case, however, we had a unique challenge: for the first 9.5 years of FWI’s history, our Sign Developers had gotten used to building one-off digital signs. SOWs would come in, meetings would be held, and they would begin building. When a particular project was complete, they’d move on. We gave little thought to previous sign builds because there were so many to focus on in front of us.
Task one on our plate was to expand. Principally, this meant that our developers had to change their ways of thinking. It turned out to be a hard transition.
When you begin to build any software for a one-use scenario, you naturally go down the most direct path: you build it to work for that environment and you pay little attention to anything else. That wouldn’t fly with our group. Ours was a harder job: we had to design applications that would work for anyone. They had to configurable; they had to be skinnable; they had to combine our best practices with the flexibility that “app users” came to expect. In short, our developers had to be a lot smarter about how they built things.
To accommodate this change, we decided to pursue a strategy that would allow it to occur. Early on, we adapted Agile Scrum as our development methodology. Although it provided several tactical benefits, one, in particular, stood out to me: it didn’t require that we “get it right” immediately. We could try things; we could iterate quickly; we could collect feedback and rapidly adjust. I believe we flourished more quickly because we didn’t demand that our “end-all-be-all” product be on the shelves on Day 1.
Now, a year later, our team is performing at a level I didn’t imagine was possible. We are operating on all cylinders, so to speak.
The lesson learned? Perfection, although a wonderful thing to strive for, can crush anything that’s trying to change.
My next post will delve into some of the challenges we faced while re-purposing our platform and building an App Store, as well as what the future of AppDev looks like.