For the final spotlight interview before our Delivery Conference commencing 23 March 2021, we meet Matias Woloski, CTO and Co-founder of the authentication and authorisation platform, Auth0. Hear how the company has successfully navigated remote working and delivery and why he believes mistakes aren’t mistakes – they’re just a part of the building process.
Welcome Matias, thank you for joining me today in the CTO Craft hot seat! What’s keeping you busy at the moment?
Right now, we have a bit of news relating to the acquisition, so that’s been at the front of my mind lately. Other than that, I’m focusing on the long-term innovation aspect of the business and the explorations we’re doing in different areas of the market i.e. on the privacy side we’re doing a lot of interesting things and on authorisation to see where we can innovate there as well.
Across the world, COVID-19 has affected people and countries in different ways, how has your leadership had to change from 2020 being the year of recovery, to moving things forward again in 2021?
In our case, we’re lucky we’ve been a remote organisation since 2013, which meant that the transition during COVID wasn’t that big of a deal because we were already working in a distributed fashion. But with employees being at home more than usual, we’ve had to do a lot of things to improve that. Like meetings that were fun rather than typical work meetings; last year we had a summit for the purpose of learning but we also did things like cooking lessons for people to spend time together outside of work. But still, we were mindful of the fact that people are tired of being in front of the computer, so some of our activities were offline, without meeting each other, to make sure that we were supporting people having downtime too.
Did you notice an impact on delivery?
Not really, although in some cases, there may have been some short-term impact, it wasn’t the case that it was like ‘okay now we’re shipping half of when we were shipping before. In fact I would say some people worked even more; it was a mix. Those who had children were understandably more impacted, but we have a quite diverse mix of people because we started as a remote organisation. We hired from every country so we had access to different profiles of people, but overall, we didn’t see a negative change in delivery.
Given that your company has been remote for the past eight years, how do you maintain alignment between teams?
We have a good framework for product strategy, a quarterly cadence roadmap and OKRs as well for non-roadmap work in terms of important things we want to focus on that go outside of what we deliver on the product side.
All in all, we have a good framework for alignment because we’ve been honing that over the years since we had to build the company like that from day one. Communication is an exceptionally solid and developed practice at Auth0. You will find a lot of stuff written down in conference or an internal knowledge system. The use of Slack has also always been very natural so people collaborate a lot there actually, email is almost not used.
We have a few other things like, which may not be directly related to alignment but it’s more about coping with Zoom fatigue, i.e. we remove all meetings on Friday. It’s a day where no one is allowed to schedule any meetings and so it sends the message that you should try to avoid meeting as much as possible and instead write things down more and align in that way. That still allows for ad hoc meetings if needed, but it ensures that we are removing all the recurring things that don’t add value.
When it comes to roadmapping, what would you say are the biggest mistakes that some engineering teams make building it out and estimating?
It’s hard to get estimation right and that’s a well-known thing. I think one of the mistakes is trying to think about or engineer everything. From the beginning we’ve had a principle to prototype first and build after- it leads to more understanding of the space and the problems that you’re solving. In a way, you’re constraining the solution space quite a lot so it’s very different when you say: ‘Okay, we need to build this feature and we have this quarter to do it’ and you start thinking about all the ways that you’re going to work on it including the design and over engineer everything. When you start off with a few prototypes that help you shape the problem and you also constrain the time that you have, things are much more fluid. They flow much better because you are constraining the options you can think of and while it might be easy to talk about, it’s less so when you have to write code, and that’s where reality hits right. I think that’s a very common mistake so try not to do that!
Great. So when you’re taking on a new project, what is the first action you take to make sure that you get team buy-in?
Similarly to our process for roadmapping, we have product managers and a product strategy and our vectors are clearly communicated so our teams already know what they will be working on in a year’s time. Yes, the specificities of that work of course get clearer as time goes by, but the buy-in aspect is already there. We have a product that is already at scale so all the things related to our organic roadmap like teams being independent and autonomous and them working with product managers in a kind of bottom up/top down process of product strategy to ensure product execution, that defines the year and so invites organic buy-in.
In the longer-term, that’s my area of focus and it’s more experimental. We have much more freedom of exploration from that point of view and as part of that, we try to involve the team in that process, by getting them to go and explore those areas, like privacy and authorisation, and so you also get the buy-in on that through inclusion.
When it comes to delivery or indeed, exploration of new ideas, and mistakes are made, how do you ensure that these failures are small or that they’re learned from quickly enough to ensure they’re not fatal to the end product?
All the teams do retrospectives and after we ship something big, we look at what went wrong. What you find, when you are regularly looking at the structure of how you are shipping, it means you’re constantly looking at the output. You know what things are working and what things are not; it’s a continuous process.
In a company that is growing like we are, you have to constantly tweak the way you do things across the organisation. Of course it’s not easy – there is no silver bullet for anything – but I think we focus a lot on the understanding first before looking at the things we can do to improve. Right now we are thinking about reorganising the way one of the domains works and merging some of the teams together in subdomains. We had noticed that the dependencies across things were too much and if we can remove them, things could go faster.
If you try to align things and the structure itself doesn’t allow for quick delivery and agile-like movement, you need to change it; so that’s what we try to do. So I would say, yes we engineers make ‘mistakes’, but I wouldn’t even call them mistakes, this is just the nature of building things; it’s a messy process so it’s about how to manage that messy process and improve things as you go.
Yes, that’s a really good way to look at it! And my last question is, do you have any book recommendations that you think engineering and delivery managers should add to their reading list?
I have a copy of Will Larson’s An Elegant Puzzle: Systems of Engineering Management, which is a very good book. He also has some good stuff on his website where he interviews staff engineers, which I liked a lot because they are a critical piece in an organisation, especially at scale.
There is some good stuff in Team Topologies, [also recommended by James Shore] which talks about the cognitive load that is created by the structures you put in place, and how you can remove that, in the context of scale-up organisations i.e. with microservices and different teams owning different things. Those are the two that come to mind right now.
Thank you, Matias!
***
Catch Matias and some incredible other speakers at our forthcoming CTO Craft Con 2021: The Delivery One on 23 – 25 March.
Find out more and get your tickets here!
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.