I’m a little biased, but we have it pretty good here at Sparkbox. In the three short years that I’ve been with this amazing team, we’ve replaced our pattern library infrastructure three times, transitioned from coffeescript to ES6, built amazing applications using Ember, React, Craft, Knockout, Ruby, and Rails. We’ve gone from Capistrano and “QA” servers to continuous deployment with Divshot, followed by Review Apps with Heroku, and now experiments with Platform.sh and Docker.
If you’re waiting for the “Ninja Coders” reference in this recruiting piece, you’ll be sorely disappointed. Along with opportunities to lean on some of the best new tech out there, we’ve been in situations where we’ve felt the need to rely on other’s site templates, used naming structures we now find constraining, and built with Squarespace.
So how do we choose what technologies to adopt and when? I encourage the team at Sparkbox to ask a series of questions that focus on goals and key traits of the technology. There are countless considerations, and these are some of the consistent questions we ask ourselves—those that hit at the traits we want to bring to our technology decision making, especially when it involves our clients’ futures.
Does This Have A Long-Term Impact?
Only a few weeks ago, I sat down with two members of our team discussing a fixture data solution for a little-known ecommerce platform for a startup. The fixture data solution would make development much easier than the “Code—FTP—Refresh” experience we’d been using for a few days. In the end, we chose not to implement anything, deciding we could make the client’s dollars go further by spending them on more important goals. Had we expected to work with this startup intensely over a longer period, or known another team would be coming along to pick up where we left off, the impact of this development experience would have shown its value. However, we hope that by NOT bringing in new technology now, we’ll see this startup able to invest in more critical areas and maybe even have a few more employees this time next year as year-over-year revenue increases.
In contrast to a shorter-term engagement, last year we began a large effort with a client, which set the precedent for many more future applications. This included a design system, CMS, and architecture for one of many applications for years to come. Consistency and structure were very important to this organization. And the long-term nature of their need influenced our approach.
Can We Ease into It?
Frameworks that offer an opportunity to “ease in” allow us to deliver value quickly and remain hyper focused on learning how to architect, write, test, deploy, and design with that technology. Our foray into React began quite small. We knew this was a technology we couldn’t ignore—it had too much promise. The challenge for our team was finding a way to ease into and validate the assumptions while mitigating the risk of a new technology. In this case, we were able to use feature flags to present some users with a React version of a small portion of a Ruby on Rails application. Finding a way to ease into React—and other technologies—lets the team avoid a “big bang” or full commitment that presents lots of risks.
What Are the Industry Considerations?
One of the things that makes Sparkbox so awesome is that we’re often not internally constrained by industry regulations and positions. That’s not always the case for our clients. When I asked one of our energy industry partners what influences their technology choices, I heard: security, security, security. And enterprise ready.
It may be easy to grumble and roll our eyes at the friction these terms suggest, but with great influence comes great responsibility. These organizations have reached a level of success that demands new considerations. Finding proven solutions—especially for highly sensitive clients—is key. Decisions should be influenced by regulation and market factors. No one wants to be on the front page as the latest hacking target.
Can Our Teams Make This Leap?
I have a “technology mind” by most accounts, but even I don’t jump on every technology bandwagon. In many cases, I probably fall into that early or late majority class of the adoption lifecycle. To try every technology is a great way to get burnt out, and knowing what our team and our clients’ teams are ready for is a big factor in whether we should adopt a new technology. It takes a lot of work to be ready to try a new technology, and the skills of everyone involved should be weighed. We want to “level up” our clients in a way that they can sustain.
Stop and Question
It’s important to remember—especially as browsers race to implement new features and major networks become so fast—that there are often gaps in the already elongated adoption tech curve. We take all of this seriously as we present formal technical strategies. This might mean recommending a framework like Ember or Rails in which a “golden path” is clear and documented instead of a malleable toolset like React or Sinatra. It could mean strict adherence to Atomic Design or BEM structures to help our clients reach a mental model quickly where we’ve eschewed the constraints knowing the principles are natural to our way of working. It could also mean heavily prioritizing consistency and structure.
Encouraging Continued Exploration
Internally, we need to offer our super talented team the opportunity to explore their own passions. Our clients are excited for their teams to do the same. By finding ways to explore and learn with minimal risk, we provide those opportunities to both. We recognize the greatest assets we bring to the table aren’t always our design, UX, and development chops. When talking to clients casually, I often hear the most valuable impact is the result of our process, our collaborative and effective decision making, our spirit, and our focus on achieving goals we set out to achieve. Having intentional guides are useful in that effort.
By asking ourselves these questions, we stand a better chance of picking the right technology and mitigating the risks it could present. And should a new technology look good on paper, but not in practice, we have plenty of room to adjust our path, navigating our project toward the best outcome. This is, after all, the agile way: big vision, small changes, learn by shipping.
