By Dave Gullo, Co-Founder and CTO at VideoAmp
“Play drums, go snowboarding, hack amazing code, and be with family”… do one or more of these EVERY day.
One of my favorite things is playing the drums. I learned to play on my Dad’s kit. In High School I was the drumline captain and played big-band and small group jazz. Leading the drumline meant that I could make a Freshman run a lap with a huge bass drum if they were being an ass.
I gave back by donating my Wed nights for “Elementary Honor Band”, teaching the basic rudiments and protocol for corps-style drumming to 4th to 6th graders from feeder schools. At first they were unwieldy and hard to handle, but eventually they began to focus and give respect. Year-over-year, I saw a few stand-out students. Witnessing this growth gave me great satisfaction.
Many years later, I returned to LHHS to visit my music director; most closely related to the teacher in “Mr Holland’s Opus”. While I was there, the drumline was busy rehearsing on the field. By this time the band had much greater funding and booster support, and was 5x better than when I was there.
As I focused into the snare line, I recognized my best student from honor band as the lead snare and drumline captain. This gave me indescribable great joy.
Nowadays the goal is the same, but the venue is different. As Fire Chief of Technology (and Lead Arsonist) at VideoAmp, my primary goal is to transform engineers during their time with the Company. One of our core values is that underscores this is that every engineer at VideoAmp should be worth more in the marketplace due to their time with the company.
Every engineer at VideoAmp believes in the concept of continuous improvement and career cultivation.
We achieve Transformation through Continuous Improvement Strategies:
We follow the philosophy of “OKRs” or Objectives and Key Results as implemented by Jack Doer at early Google and many successful startups since. The idea is that each person setup quarterly stretch goals which are aligned with the company’s goals. An example of this is a node.js engineer who wants to learn Scala, or an API engineer wanting to learn frontend better. Non-examples are brushing those back molars a bit more, or learning Chinese.
Validation is an important aspect of growth and is jet fuel to the fire for an engineer’s self-actualization. We use peer reviews to encourage and set a high bar and to make sure the final work product is consistent with our development principles. While some companies do full-time peer-programming – where two people share a single computer – we achieve this by doing peer-reviewed pull requests in Git. Additionally I have a frequent 1:1 schedule with engineers to promote an open dialog.
Lunch and Learns
My favorite activity is hacking. Not “WarGames” hacking, but building/coding hacking. Many of our most efficient tools in-house started as hack sessions, which evolved into purpose-built tooling. Lunch-and-Learns are the way we turn one person’s idea into an open-source effort. Besides hack projects, we also use this time to learn about new open-source technologies we are assessing, or for our internal cross-pollination efforts, how engineers learn about new languages and systems.
Nothing brings together a company more than to spend a few days together building new products and ideas. Beer and pizza helps too of course. But we have no shortage of huge and robust datasets at VideoAmp, so we get together from time-to-time and build amazing data visualizations and product ideas on top of our large data warehouse. The outcomes of these hackathons vary anywhere from amazing charts for the monitors in our office or stunning graphics for slide decks to internal administrative views of our data or sometimes even new graph or view of a product in production.
When I have asked engineers
“….what does your career look like in …. say… 10 years from now?”
The common responses are “um I’m not sure”, or “a manager”.
Provided they don’t respond “still doing this?”, you should have no cause for concern.
A few common paths are the “Pathway to Engineering Fellow”, “Pathway to Manager”, and a third category which is the quantum superposition of the two (where I sometimes find myself in the quest for both).
I recall so many geeks in the past saying “Manager.” When you scratch the surface a bit, it seems that responses are sometimes misguided based on the person’s true strengths. Often times, someone’s true calling is engineering excellence. With others, they are natural leaders, and jump quickly to the whiteboard, organize the thoughts of many in a room, divide up the responsibilities, and are the defacto Captains of the “Get Shit Done” team.
We encourage setting a course for one of these two main pathways.
In our organization, we don’t require as many managers, just GSD hackers. It’s my goal for every engineer to possess a sense of self-management, and at the team-level self-organization, and at the organizational level innate understanding of our company’s current quarterly goals and broader strategy.
Whether or not an individual knows their exact pathing, these skills reinforce either path, including the “quantum superposition of both path.”
Our org is primarily a scala shop. We’ve interviewed a pretty sizable cohort of the local area’s scala talent, and they didn’t make the cut. What we found was that translating a node.js engineer (that already has the domain knowledge in video ad-tech) into a scala engineer was easier to do than to find top notch scala talent (let alone with the video ad-tech domain experience).
Therefore as a part of our path to Fellow, we allow for lateraling teams. This is not limited from node to scala, but is also present in our full-stack team. We decided to tear down the walls between frontend and our api teams, and require each to do both, with specialists at each end. The result is an ongoing path for noders to know frontend better, and vice versa.
Again, as with setting OKRs, we found this aligns with the engineer and the company and provides a win-win.
Recognizing the Intermediate Steps in Timeless Works
On great works (such as a Roman aqueduct, or the Eiffel tower), what we often forget about is all the scaffolding and shims which were vital intermediate steps, which are gone in the finished product. An experienced engineer knows how to build these intermediate steps to achieve great things. Furthermore in software engineering, some of these intermediate steps persist as unit and functional tests.
These intermediate steps also apply to transforming individuals; to challenge them, take them out of their comfort zone, to go through steps not seen in the path, and to instill a sense of these as part of growth.
What’s the “Key Result” for this Transformation Objective?
The goal is to build talent in 10 years which meets or exceeds their goals as realized today. If these individuals are able to recognize ANd apply the intermediate steps to future peers, and transform their game, then this initiative will be successful.
P.S. Ask me in 2026 how it went!