- Tell us a bit more about the business you represent?
- Being the CTO, what do your day-to-day responsibilities look like?
- What frameworks do you use for managing technical debt?
- How do you decide whether something is so painful that it merits a full rewrite?
- How does your technical organization work with the other operational components of the company?
- What do you see as the hottest trends within your industry today?
- Do your technical teams or do you use log analysis as part of your role? If you do, how do you find this helps day-to-day operations?
- What can we hope to see from your business in the future?
For the next interview in our series speaking to technical leads from around the world, we’ve welcomed experienced CTO at Zynq, David Cottrell.
David has worked on building various enterprise products at Google and Microsoft. At Zynq, he helps Fortune 50 companies transition to hybrid work and effective office space management.
Zynq is an all-in-one office management platform that makes the management of people, space and time easy & efficient.
We help companies worldwide optimize their spaces, embrace hybrid work, boost collaboration, and keep employees & visitors safe. Our notable customers include Albertsons, H&M, Armani and many more.
My days typically include regular syncs with engineering, design reviews, prioritization meetings, and security-related reviews. Of these, my favourite part is definitely diving deep into our product and working with an amazing bunch of engineers. We are very much a product-first company and hence my intimate involvement is essential – and I love it!
I also have direct calls with key customers & prospects about integrations, security, and how we can best configure them in Zynq. As an enterprise software, our customers play a key role in pushing us forward. I also make sure to have time in the code itself!
We use type systems to help us keep technical debt under control (Typescript with React & Nodejs), which enables sharing of type-safe code between our front & backend. This makes large refactors much easier, and safer, and allows us to detect dead code. Sharing code between the front and backend also reduces the surface area technical debt can spring from.
That’s a tough question! I make that decision based on whether the underlying framework the code is built on is fundamentally the wrong tool for the job, and this is resulting in sufficient bugs and painful development.
We, in fact, started Zynq with a framework in a language without types (Python) and felt both these pains acutely, resulting in a re-write to Nodejs in Typescript. As an enterprise product, where bugs needed to be minimized at all costs, this re-write was totally worth it, although it was a real pain.
We work extremely closely with support and sales. Every engineer is exposed to customer support requests on rotation so they have the necessary visibility into how customers are interacting with the product.
As well: sales team members are encouraged to reach out to the engineering team where necessary. The engineers will often hop on calls where a technical stakeholder is expected to be present.
These practices have ensured that engineering is intimately in touch with other aspects of the business, keeping them attuned to the needs of customers and ultimately has led to many amazing features!
I see more and more external tools in the engineer's toolbelt than ever before. Whether we like it or not, a big part of modern Software Development is becoming, having the skills to find the right libraries and possibly paid SaaS services that are right for the job.
The ecosystem is moving away from large opinionated all-in-one frameworks, but rather libraries and SaaS tools that specialize in solving one problem, and doing it well. These smaller tools are easier to swap out between each other and actively compete, so the cream rises to the top! This is unlocking smaller teams to focus on what matters for them rather than getting caught in the weeds reinventing the wheel.
More than ever before, I think a good engineer needs to know when to pull in an external dependency (paid or not) and how to choose it well. For everyone but a few behemoths like Google, gone are the days of building everything in-house (and even Google engineers are feeling left out).
Do your technical teams or do you use log analysis as part of your role? If you do, how do you find this helps day-to-day operations?
The engineering team monitors Mixpanel user action logs & error logs on rotation, including myself. This helps us keep a pulse on how our application is doing and has helped us catch issues early.
Growth and some amazing, industry-changing features. Zynq's on a mission to make physically coming in to work a thing everyone wants to do (at a time and place that works for them!). With the pandemic apparently behind us, the office is making a big return. We want to remove all friction on getting people back and enjoying their work lives side-by-side with their colleagues once again.