This series highlights the talented Zilliant Engineering team; today’s post features Tony Cardone, technical lead for the “Red Bull” development (dev) team. Prior to joining Zilliant, Tony was a systems developer for BNSF Railway in Fort Worth.
Tell us a little about your background and current role.
I am a technical lead for the Red Bull dev team. In addition to writing code and managing the agile process for the team, I am responsible for working with product management in creating a well-defined backlog of work. Before I came to Zilliant, I was a systems developer for BNSF Railway in Fort Worth.
What inspired you to work in engineering?
I suppose I was kind of destined to be in engineering. Both of my parents were actual engineers (of the structural variety), and being the oldest child, that was passed on to me. I've always enjoyed problem solving as well as being a huge game nerd, so software was a natural fit.
What’s your specialty on the team?
The role of technical lead we have at Zilliant leads to little specialization. We must be well versed in many trades, and a temporary expert in whatever topic our team is currently working on.
If I had to pick one area, I would say being an efficient communicator is a unique specialty that my role requires. Communicating the vision of product management and stakeholders back to the developers is critical to getting the right solution at the lowest cost of implementation. Identifying the potential roadblocks and estimating cost with the stakeholders before bringing work in front of the team is critical to ensuring the product meets the needs of our customers and at a timeline that is reasonable.
What does a day in your life look like?
Every day starts with our team's daily scrum, where we get status on in-progress work and I attempt to identify roadblocks that could slow work for the rest of the team. After that, I have a scrum with all the other team leads and we identify issues across teams, as well as release queue and any support issues that need attention. Once those are over, it's usually dependent on the current stage of our initiative. If we're about to do a new initiative, I'll likely have meetings with the product manager, architect, and stakeholders to write clean stories. If we're in the midst of an initiative, I might be able to write some code, or be prepping stories for the team.
Do you encounter any misconceptions about the role of an engineer at a software company?
I think the classic portrayal of software engineers is a code monkey who sits in a dimly lit command center converting caffeinated beverages into code and rarely interact with other humans is a huge disservice to modern software engineering.
At Zilliant, this is pretty far from the truth. A good portion of any day is spent designing the system and clarifying the requirements from our stakeholders. Also, we sit in a building that is mostly windows, so we actually work in an overly-bright working area.
Have you helped solve an interesting problem or use case for a customer?
We've solved a use case for our biggest customers using the Amazon Web Services Redshift database system. With Redshift, we're able to provide live connections to our customers’ data, with little change to their current visualization access. Visualizations that used to take minutes now take seconds.
How do you work with the science and product teams?
The dev team I'm on works hand-in-hand with our science team quite a lot. The data science in research and development usually ends up being productized by my team. We have two big challenges when it comes to this:
1. Abstraction. When the science team comes up with a new feature, they usually have one customer in mind, with the expectation that all customers will benefit from it. Engineering must then make the product implementation usable by all our customers if they have a similar problem. We must convert their prototypes into working solutions for everyone. As software developers, and not data scientists, we really lean on them to bridge the gap and ensure that the result works with their vision for the science.
2. Scaling. The algorithms and processes they come up with have to be executed in a reasonable time. We have to find the best hardware at a cost that makes sense. One of our big challenges with any new feature is to balance speed and effectiveness when designing a solution, so we frequently work with our data scientists to refine their initial design in a way that can be executed as simply as possible.
What makes Zilliant different from other companies from a technical perspective?
Being first in our market to fully embrace software-as-a-service, we're constantly improving our product for everyone at the same time. That’s a huge competitive advantage from a time and cost-to-serve perspective because all customers are on the same software version and none are on antiquated versions. We're also a small enough company where individuals can bring forth ideas about improving our software process, and, if it makes sense for us, to make a change very quickly.
What do you envision as the future of engineering?
Services are going to be huge, and that's an area we've just started to get into. Many companies these days also have internal developers that make their software, and being able to feed external data directly into their system will create new opportunities for us to provide our expertise without training the workforce on a new tool.
Big data is such a popular buzzword these days, and for good reason. Only now are cloud platforms such as Amazon Web Services and Microsoft Azure becoming accessible enough to provide big data analytics at a reasonable price point. Machine learning and AI-enriched algorithms will be able to solve more problems in more industries than we could have imagined even five years ago.
Stay plugged into expertise in pricing, sales and SaaS in B2B by subscribing to the Zilliant blog.