Meet Daniel Fang, Kargo’s first backend - and frontend - engineer. We talked to him about the different hats he wears at Kargo, as well as why he decided to join the team last June and what he has learned since then.
I’ve always dreamed of being able to grow into a role where I’m leading the engineering team for a particular area or product. Kargo seemed like a great chance for me to become the primary backend engineer for a new product that pushes the boundaries of logistics software. I saw early on that we aimed to build an extensive data platform to manage shipments and facilities on a global scale. I wanted to have an outsized impact on the technical direction of this platform and grow my technical skills alongside it.
I also really cared about the team culture. I was (and continue to be) impressed with every other member of the team. Everyone has a rock solid understanding of their area and they’re great communicators as well – I never feel scared to ask my team what they’re doing or why they’re doing it. I only want to work at places where I have full confidence in the people around me, and Kargo is definitely one of those.
I wear a lot of hats as part of my role. At the end of the day, my responsibility is to deliver product features for our customers, deliver reliable and scalable infrastructure that is sufficiently error-free, and build tooling to help our internal operations. A really large part of this is defining (or understanding) requirements, defining the scope and effort of a given change, and defining metrics in which we can evaluate success. After this, I will work with the team to understand prioritization. The next step is typically design – for example, data modeling, API design, service design, etc. We usually do team-reviews of large-impacting design changes. The last step is the actual coding and implementation of these changes.
There are a lot of considerations required when building systems at an early stage startup – what languages and protocols should we use? Microservices or monoliths? What tooling should we use? How do we deploy our changes seamlessly? How do we test our changes reliably? What best practices should we follow during development? How do we keep the system flexible, but still maintainable? I spend a lot of my time thinking about these questions.
I also work closely with our product managers and front-end engineers to make sure that everyone’s unblocked.
I’ve learned a lot about how to ask productive clarifying questions. When I get requests to build a system or feature, I try not to take the request too literally, but instead, try to understand what the intended effect is, or what is believed to be the root problem. Oftentimes, the request will be a consequence of a much deeper problem. Understanding what these root problems are allows engineering to come up with more effective or even simpler solutions than what was initially requested.
For example: someone might ask if I could help build them a tool to extract data from one system and input it into another system.
My initial goal is to understand why they would need such a tool and what their core issue is. With enough clarifying questions, I might end up building an automated way for the output system to gather input data, and this automated way could be a very generalized solution for all the tools we build.
I’ve used this approach to great effect when building infrastructure, tooling, and new product features! I think it helps enhance the final deliverable, and helps engineering build only the most critically important things.
I really believe in the value of “Results over effort”. It’s a really liberating value because I no longer feel any pressure to give the impression of spending a lot of effort on tasks. As long as I’m effectively on top of all my responsibilities, I have a ton more flexibility on how I accomplish my work.
For example, I’m not always productive when working normal hours. My productivity comes and goes. I feel like there’s enough trust and accountability at Kargo that I can spend my low-productivity times on recovery and relaxation. I know my team will let me know if I’m lagging on any of my core responsibilities.
This value also pushes me to find more creative, efficient ways to accomplish our tasks. Sometimes it means reducing the scope of a project. Other times it means spending more time building a long-lasting, scalable solution to what might appear to be a common problem.
I play tennis, hike, and love spending time skiing in Tahoe. This might give the impression that I’m physically fit and active, but don’t be deceived.
I’ve spent 12 years playing a real-time strategy game called Starcraft 2. I’ve consistently been a high Master-level player. These days, I enjoy teaching my friends how to play better, watching the competitive scene, and learning new strategies. I follow a lot of competitive games like Smash, and League of Legends as well.
I work on side projects when I can – little pieces of automation or scripting, a website focused on professional video game streamers, and lots of mostly failed product ideas.