TimeSaved is thrilled to announce the arrival of our new Director of Engineering, Nathan Young. Nathan comes to us with over a decade of experience in management at Cisco and site reliability engineering at Nike. He is excited to take up the mantle of scaling the engineering process and team at one of Canada’s fasting growing technology companies.
He shares his thoughts on deployment processes, building for scale, and the importance of actioning on customer feedback. Also – why you shouldn’t try to build your own app.
Tell me a bit about your background and how it paved the way to your role at TimeSaved.
I started out in consulting before moving over to Cisco as a developer and then a tech lead. Throughout my time at Cisco I did a great deal of hiring because my group grew constantly, so I was always focused on how to scale quickly and properly. I got the answer to “how do you refine the software development discipline”, and how does that interface with the business needs. I had a lot of challenges there that developed my product ownership and technical leadership.
At Nike I was in the SRE org doing site reliability and prod ops for SNKRS Launch and global commerce. Nike runs launches several times a week and when they are hot, they are some of the biggest network events out there, with a scale 100 or 1000 times the normal load. There are caching challenges, bot mitigation, tons of publicity and it’s this huge machine that’s a core part of their business and it’s a little different every single time. And it has to work right every single time.
So that was just a beautiful place to be and I was so happy to work in that part of the company. Nike really pushed my understanding of the cloud based microservices, really pushed my understanding of network infrastructure and the caching layers and bot mitigation and authentication forward a lot.
You’ve been with TimeSaved for a few weeks now. What has it been like so far?
I love being at a company that’s got such involved customers, where we can build relationships and get our product in people’s hands for direct feedback. And I like the aggressive software development and iteration style, and that the company has the bandwidth to do software development right. It’s our job to do continuous integration and to take advantage of all of the new ways that technology can be done. Because we’re building a product for other people, it’s our job to get technology right. And as a software engineer that’s exactly where my passion lies.
What have you noticed so far in those conversations with our staffing partners?
I’ve been having some technical conversations directly with agencies recently, and one thing I’ve noticed is that some people are trying or have tried to tackle technology builds themselves. That’s not an easy thing to do, especially if your business is focused entirely on something else. And it’s not cheap. That’s part of why specialized startups are flourishing right now. It’s because each of these verticals have specific technology needs. And as a technology startup you get to look directly at that industry and focus entirely on building the technology to meet those needs.
We’ve heard about people who have built their own app, and then abandoned it in favour of buying a solution. Why do you think that happens?
There’s more that goes into maintaining it than you might first consider. Building it is really just the first step – but it’s not a one-time expenditure. The world is changing all the time. Your business is changing all the time. The data that other people can offer you, the way that people want to work with their phones (browsers, iOS versions, you name it) it’s just a moving target. It’s never going to be one and done.
And integrations are a whole other target as well, because with an integration your partner is going to change over time. So you have to have an interface layer that allows them to change and helps your integration be resilient over time.
Lots of things change over time, including very basic things about software development. What are the biggest things you’ve noticed?
Cycle times. Even on a pretty complex product, with the right team in place you can come with a minor feature change, and have it live within a few days. The situation used to be that you come with a change, the same amount of effort, and you have the overhead of a release cycle and a testing cycle and a QA cycle and a 37-step deploy process that you have to do at 3am on a Saturday night. And it takes until dawn. That’s gone.
But it takes discipline in how you use the platforms together, how you structure your development process, and a certain focus on test automation to maintain that velocity to keep the overhead from growing as you go along.
This has a profound impact on customer velocity. If you want to act on a piece of customer feedback, you get that thing done. If you want to move things around your roadmap, you move them around, and you don’t slow down.
There’s also a very different approach to using infrastructure. Rather than having this enormous hardware spend, and a bunch of system administrators and database administrators and database server admins, that’s also all just gone. Your infrastructure is part of your codebase effectively, and it makes changing in response to scale easier.
A big thing on our minds given what’s happening in the industry right now is that we are prepared to scale our technology, and our team, fast. Any advice?
When it comes to scaling the team, our culture is a precious thing to foster and protect as you grow. We need to be explicit about preserving what we have as we hire, and making sure we construct a day to day process that helps developers stay friends with each other. It’s a very different mindset to be tactically focused on getting your deliverable out the door, to having that focus and keeping it but knowing that everything that you’re doing, you’re doing on a codebase you co-own with your team.
And right now we have developers who are also DevOps experts, and that’s an excellent way to go. We’ll always want developers to have those skills going forward. But as we continue to scale there will be room for a Reliability Engineering practice, with some people focused purely on DevOps and production ops because when you really dig into that infrastructure, it’s too much to do and write feature code at the same time.
How about on the technology side?
With technology, test automation and test-driven development demands some attention because there are still times we’re writing tests retroactively and there are still some parts of our systems we have to sanity check by hand. In every other respect, we’re doing great with continuous delivery so it’s worth getting testing right.
As our system gets more complex, we have some work to do on authorization and in the API layer that will give us a lot more flexibility to change the underlying systems. We’ll also need to adjust as we scale traffic on our apps, and it’s worth laying the groundwork in cloud technologies so that scaling is easy when we need it.
What are you most excited about for the future?
Now that I’m at TimeSaved I see it as a huge opportunity. There’s a great product, not just beautiful but a joy to use. There’s a great team and an incredible market fit and I’m ready to take the technology to the next level. Scale and reliability are super fun challenges for me, growing a team and working in such a great culture is great. I’m just really looking forward to it