Q&A with Jason Vella, VP of Engineering @ LawVu
We caught up with Jason Vella, VP of Engineering at LawVu to learn more about his career journey and his approach to leadership at LawVu.
About the Speaker
Jason Vella is the VP of Engineering at LawVu
Transcription of the Q&A with Jason
“...there's this pimply-faced teenager in the middle that we all go through when we have the body of an adult, but the brain of a child...”
For people that might not be acquainted with LawVu Jason, at a top line, what does LawVu actually do?
LawVu's a legal operations platform, which will mean nothing to most people that hear that, but effectively, if you think about what a platform like Xero does for an accounting team, it gives them the opportunity to collaborate, store their documents, have conversations, all in the same place, around the domain of accounting.
LawVu does the same thing for a legal team that works in-house at a large company, like an insurance company or a bank or something like this.
What were you doing leading up to LawVu?
I've been with LawVu for just over 13 months now, I started in March last year. Previous to that, I was a chapter lead at ING, in Amsterdam.
I spent about 13 years in Europe before coming back to New Zealand, working for various companies. But ING was the first step into leadership that I took... well, people leadership, let's say.
I've been a technical leader for quite a while. So there was the first time that I started actually leading teams in terms of their growth and mentoring them and this sort of jazz, and getting into LawVu now I've taken the next step, where I'm running the whole thing, the entire engineering floor, which is quite exciting.
Previous to that, I come from a background in backend engineering. I've been working on quite large high traffic systems in Europe, a couple of financial systems, but I've worked through, I think about 10 different domains, every time I change job it's a different thing.
It's quite an interesting thing because I've had people say, "Once you write a piece of software, then you know how to do it." And it's like, "Well, like building bridges, once you build a bridge, you know how to build a bridge, but there are no two bridges that are the same. Each bridge has different problems around how deep the water is or how high the mountain is, or how much wind there is, or earthquakes".
So, each time we solve a software problem, it's a similar problem to what you've seen before, but in a different context so the problem requires a different solution oftentimes.
“...the possibility of me having an impact, whilst it's still definitely possible, the blast radius of the changes that I can make will be much more limited.”
LawVu has been on a meteoric rise in terms of its growth trajectory and obviously a really exciting time to be a part of that. Could you give us a bit of a snapshot as to where the business is currently at on that journey, so perhaps maybe even comparing it to a human?
Yeah, sure. So I have this analogy that I make with human growth. I think when you're a small child or an infant, you have a child's body and you have a child's brain and you behave like a child, and when you're an adult, you have an adult's body and an adult's brain, and you think like an adult.
But there's this pimply-faced teenager in the middle that we all go through when we have the body of an adult, but the brain of a child, and we still... we go through that identity crisis and we struggle with who we are and what we're doing and this sort of thing.
Startups are very similar. When you have five people in a room, and they're all working towards a fairly common goal, communication is easy. Ownership and engagement is quite easy and decision making is fast because there's only a handful of you and you're all on the same page.
When you start to get into being a large company, then that becomes very different. You've got 100 people, so who has the ownership? Who has the responsibility? Who makes decisions? Who owns a piece of work? So the structure of the team has to change, and this sort of thing.
When you're in the middle of that growth, and you're at that pimply-faced teenager stage, which is absolutely where we're at, the team structure of a large company doesn't make sense, because you're just not big enough to build those roles or those verticals, but you have too many engineers to operate the way that you used to, to get everybody into a room and make the democracy, you just never arrive at a decision.
Nobody really has ownership and this sort of thing.
What we've found is that we end up changing our way of working and our team structure quite frequently. Once every three to six months we look at what we're doing and go, "All right, well we've solved those problems, but here are the new ones. We're now much bigger, and how do we solve these new problems?"
We recently changed the structure of the teams and we know that by the end of the year we're probably going to outgrow that structure because we're looking to double the size of the engineering team.
The structure that we have works today, and we're certainly making decisions based on the information that we're gathering today and where we want to get to, but certainly, we can already see that in six to 12 months' time, the structure is going to start to creak and we're going to have to come up with something new.
It's a really interesting phase of growth for LawVu, because we are doubling in size every year, and you can imagine that the rate of change there, it's quite staggering.
“It's a really interesting phase of growth for LawVu, because we are doubling in size every year...”
I really like that analogy, albeit when I hear a pimply-faced teenager, it reminds me of bad haircuts and probably quite an awkward style. But in terms of the journey of a startup and the opportunity for people that are maybe thinking about getting involved in a business like LawVu, why is this such a cool phase to be a part of?
It's all about impact actually, and it's one of the reasons that I took the role at LawVu.
I've had a number of roles that I could've headed towards. Joining LawVu at this stage is all about how much impact I can have. So this is good and bad. But I can literally think of something this morning, or see if I had to do the incident or something this morning, and just go, "Right. I want to do X about that," and by the afternoon we're actually doing it.
I don't need 20 people to sign off on me buying a pencil. We can move really quickly. So, it means that as the leader of the engineering department, I can come up with ideas. We can change things, we can be really reactive to the things that are happening within the company. Hopefully, we get to a point, or we're not always reacting and we're a bit proactive with the things we do right.
What I hope is that in five years' time I can look back on LawVu being this big successful company and see the results of the decisions that have been made and the processes that I've put in place and this sort of thing.
Whereas if I were to join a much more established company, then I'm just going to be another "has worked there", and the possibility of me having an impact, whilst it's still definitely possible, the blast radius of the changes that I can make will be much more limited.
And there's a lot more, "Ah, we tried that before and it didn't work." Whereas at LawVu we can pretty much try anything because it's all new. So really, this is why I think it's really quite exciting to join us as we are now because there is a lot of change. That volatility is a good thing.
It's, not just me. This is never a one-horse race. We fail as a team, we succeed as a team. As I said, I don't do the typing, so I can say that we need to follow this process or we need to do XYZ, but if I don't get my engineers' buy-in, then it's not going to happen.
The opportunity to have an impact is there, right from the ground up. I'm not the guru, I don't know everything. I'm quite happy to be wrong, and I often am, so we hire really smart people.
It would be doing them a disservice to not let them bring to the table that expertise to say, "Hey, I think we should try this thing." It's not always the right thing to do. Sometimes we'll try something that doesn't work, and that's fine. It's the sort of place where anybody can come up and suggest something and we give it a go.
“Regardless of whether you're sitting in the office or whether you're sitting outside of the office, you have to operate as though you're remote.”
You’re a company that has really embraced remote working, so obviously headquartered down in the Mount Maunganui, however, you have people spread out right across the country. Is that something that has been deliberate from the get-go, or has that been a reaction to finding the right people?
A bit of both. So the deliberate part of it is the necessity for growth. If you look at Sam and Tim, they've got big ambitions.
The team of engineers we had when I started a year ago was much too small to be able to achieve those goals in the timeframes that we wanted to achieve them. So we had to grow very rapidly.
In Tauranga, you have a pool of maybe three or 400 engineers that are permanently based in Tauranga. In Auckland, you have about 10,000.
If we want to grow, we have to spread our wings across the country. I come from a background of working remotely. I've worked remotely for over half of my career, and I know it's absolutely doable. The difficulty is that I've previously, I've worked in companies where we're all in the office. Or I've worked in companies where we're all remote.
But when you have some people in the office and some people remote, that can get quite difficult. It's not nefarious, but people are in the office and they'll have conversations, and then suddenly decisions are being made and it's like, "Oh hang on, what about us remotees? We didn't hear about this."
So there are difficulties with working this way, but we try to use toolings like Slack, the Huddles on Slack, and this sort of thing, to make it feel a bit more like we're all at our desks and we're all approachable, and this sort of thing.
Regardless of whether you're sitting in the office or whether you're sitting outside of the office, you have to operate as though you're remote.
“If you fell out of bed this morning and your pyjamas are really comfortable and you can't be bothered getting out of them, that's a good reason to work from home...”
You mentioned the last time we spoke was around this attitude of making your work fit into how you actually live your life. Can you tell us a little bit about that culture?
It's quite interesting in the sense that I almost didn't introduce this intentionally, but it's really become quite a culture piece of LawVu.
Selfishly, I introduced it because it's the way that I like to work. Effectively, we try to make sure that, like every company in New Zealand and across the world, we champion diversity and inclusion and all this sort of thing, and it occurred to me one day that we have people that have children, we have people that don't. We have older people, younger people, people from different backgrounds, sporty people, lazy people, you name it.
And we expect that all of them are going to do their best work in the office between nine and five. That's just ridiculous. When you actually say it, it's ridiculous. So, what I introduced into LawVu was a policy or a culture that I called the “Live your life” policy.
In most companies, your work is the chunk of the day and you try to fit your life around it. What I've done is flip this around and said, "Well actually, your life is the most important thing and you can fit your work around that."
In practical terms, what that means is that we don't impose that you have to come to the office. We don't impose your work hours and we don't impose that you have to work in any particular way.
I like to go to the gym and I'm not a morning person, I hate mornings. I like my sleep. So I'll start at about nine o'clock in the morning. By 10:30-11:00, I'll go to the gym, I'll come home, I'll have a bit of lunch, I'll work through the afternoon.
Sometimes I just get tired of staring at the screen, and I'll go downstairs and I've got a nice aquarium, I'll stare at that for a half-hour and relax. I'll still be sitting behind the computer at eight o'clock at night, but that's not because I've pulled a 16 hour day, it's just because I've slotted the work in between the things that I want to do as an individual.
There are people at work that like to work from nine to five. They just like that routine, and they like to know that they've done their day of work, they close the laptop and they can go home and have their evening with their families.
Some of them have very young children and they need to pick them up from creche at two o'clock, or they'll get a phone call during the day because the kid's sick. Young children are patient zero, they're sick all the time. So they can just go pick those children up and go and work from home or not. If they need to tend to the kids, that's fine.
We really just say, just live your life and fit your work around it. Nobody needs to ask permission to go to the dentist or take time to go to the doctor.
We did introduce just three rules around this, and it's more about just being courteous to your team than anything. They're not really rules, they're just courtesy.
So the rules are, if you're going to be away from your keyboard for any particular amount of time, just post up and it's saying, "I have to take 20 minutes or half an hour or whatever." Don't tell us why, we don't care, no excuses. We found excuses caused friction, particularly if they're working from home, "Oh, I'm working from home because I'm getting a delivery."
It's like, "Oh, well you could've come in for the morning," or whatever. And it's irrelevant. You're an adult, we trust you to do your job.
If you say you're away from your keyboard, well, we trust that there's a reason for that. And that reason can be, "I'm just going for a run," or "I can't sit here right now, I've got to go sit down for half an hour," or whatever, but the idea is that if I send you a message, I know not to expect an immediate response. You're away from your keyboard, you're doing something, and I'm going to get a delayed reply.
If you want to work from home, that's absolutely fine, again, no excuses are required. This applies to the Tauranga people, of course. In any event, if you want to work from home, just say so.
If you fell out of bed this morning and your pyjamas are really comfortable and you can't be bothered getting out of them, that's a good reason to work from home, just post up, "I'm working from home today," and that's all we need to know. Again, it's so people don't come looking for you at your desk and need to contact you remotely.
The third and final one is that you need to work the hours that give you a good crossover with your team. It is a team sport, we can't have people working from midnight till eight and never coming across their team members, so you just need to be a bit reasonable about it and this has never been a problem.
Most people like working during the day, so it's never really been much of an issue. It's a controversial thing, when I bring it up with other leaders, the question's always, "Ah, but how do you know if people are working? And how do you know?"
I always say, if you're hiring people that you need to watch, you're hiring the wrong people. We've all got our adult pants on, we all should be trusted to do our best work, and if we can't trust that then we've hired the wrong person then, honestly.
We actually find quite the opposite. We find that people work too much because they have the flexibility to go pick their kids up, so now they feel indebted and they want to work into the evening, and you're just like, "Hold up, there's always more work than you can poke a stick at, and it's going to be there for you tomorrow, so unless planes are falling out the sky, shut the laptop, go live your life, and we'll see you tomorrow."
The result is quite the opposite of what people expect. You actually need to tell people to slow down, not to work harder. And when we do our employee satisfaction surveys, it is the most lauded thing. It's the thing that everybody really appreciates, is the flexibility to just be an adult.
“...there has to be a path for an engineer into leadership, where they can go from 100% code to half code, half leadership, to all leadership, no code, or some sort of stepping stone.”
In terms of career progression, you mentioned that you like to mentor younger people or help provide guidance to people that are trying to figure out their own career journeys within an engineering function, and there are many different pathways.
What does that look like at LawVu, and how do you help people navigate all of the various paths that people could go down?
I think there's a number of initiatives we're taking at LawVu, but I think if I had to distil it down to one sentence, it's really the... it's not a ladder. There is no such thing as a career ladder.
Certainly not in engineering and probably not in other roles either, but it's a jungle gym.
In engineering, it's really quite common, and certainly, this has been my story, to go from being an individual contributor and writing code all day, and then thinking, "Well, I want to move up to the next level and become a team lead and having to manage people."
Then you discover that actually, computers are a lot easier than people. You know computers are predictable, people are not. "I just want to go back to code again." And you do, and then you get a bit older and you think, "Oh, I'll give this leadership thing a try again," and you move into a different leadership role, and a chapter leader or a team leader or whatever.
And again you might find that "No, I want to be more technical," and you move across to architecture or... so, it's fine to dip your toes.
I think in any framework like we're building at LawVu, you need to avoid the... particularly for engineering, you need to avoid going from all code to no code in one step.
Because the hardest thing for an engineer is you go to university or however you've learned to code, and you spend all of this time learning this craft, and then you spend the next five or 10 years getting really good at it, and then the next thing you have to do is step away from it.
That's really a hard thing to do. It's a bitter pill to swallow. So there has to be a path for an engineer into leadership, where they can go from 100% code to half code, half leadership, to all leadership, no code, or some sort of stepping stone. So that they can dip their toes and see if they like the people side of things.
At LawVu we're putting in place a career progression framework. Previously we've been a bit ad hoc about it, and we've just done what the rest of the industry does, where you've got junior, intermediate, senior engineers and then you either move into management or principle or architecture roles and that's about it.
But what was really missing was, "How do we pull those engineers along?" We have a saying that nobody's going to retire at LawVu. None of us are going to retire at LawVu, none of us are that old. So the only thing we can do at LawVu, as much as we'd like people to stay, eventually they're going to get bored and they're going to want to move on to something else.
Our goal is to make sure that they leave as a better engineer than when they started, or as a better manager whatever their role is than when they started. If we've done that, then we've achieved.
They've given us two, three, four years of their lives, and their best work, and we've will also invested in them to move them along in their career, and that's a good synergy there.
So, we're putting in a career progression framework to show people how to go from, "I'm a junior engineer. What's next? Is there an intermediate? What's the pathway, and what are the branches of that pathway?"
Because we've had engineers that have decided that actually, they're more interested in the product itself, rather than writing the code. So they've actually branched off and moved into product. And that's a perfectly viable thing to do.
We're defining this framework that basically defines the different roles and the different levels and what's needed to move from one to the other. We're bringing in a thing called the Dreyfus model, which is a competency framework, and it describes the difference between a junior and an expert in terms of competency.
And it's not engineering-focused. It's very generic, so you could apply it equally to administrative roles, engineering, management, whatever. And it gives people a guideline as to the sort of behaviours that we look for in terms of being able to move up a level.
Finally, what we're putting in place is the materials needed to pull people along on their path. So if you're a senior engineer and you want to move into architecture, you're probably going to need to do a bit of training about the different software architectures and where you would use them and why and what they mean and this sort of thing.
If you wanted to move into management, there's probably a bit of psychology stuff you should do, because psychology is all about understanding people. And that's got nothing to do with all the engineering skills you've built up.
As engineers, we get really good at what we do, and then we get moved into management. And the thing that we're good at is suddenly not all we're doing anymore, and we're expected to be good with people, which is probably not the reason we started working with computers in the first.
We need to give people the tools to grow into those roles and that's the final piece of the puzzle. We've only just started on that in the last four months or five months or so, so it's still very much in its early stages.
We hope to release it this quarter, the first draft of it, and we'll continue working on it and we'll come up with the tools and the stuff that we need to help people move along that journey.
“What we look for is people that will collaborate. People that are happy to be wrong. It's about the solution and not about the ego...”
In terms of the other things like attitude and different behaviours, is there anything that sticks out the front of your mind for you when you're assessing people that might fit well into the LawVu environment? Or what type of people would thrive in your environment?
There really is a very marked difference between the things you can teach and the things that are ingrained. The things that we can teach, we're fairly lenient about, and the things that we can teach are things like best practices around code, how do you do code reviews, all of these things are the things that you can simply learn.
Things like being inquisitive, being curious, wanting to understand why something works, rather than... so a good example would be that you come across a bug and you find that actually if you just rerun the process the problem goes away. Some people are happy with that. Those are not the engineers we look for.
We look for the people who say, "Okay, I can see that I can hit these keys and this problem goes away. But why? There's no magic in computers, something has caused this, and I want to see the actual logic and the lines of code that have caused this, and I want to understand why it happens so that I can fix it."
So we really look for people that have that sort of deep curiosity and that passion for computing. But the other thing is that there's this term in computers or in engineering, about the rockstar developer or the 10X developer, and to be honest, these are people that I don't want in the team.
There's a negative connotation around the rockstar developer, and when that term first came out 15 years ago or so, when Silicon Valley was booming and had all these startups kicking off, the idea was that you have this rockstar developer that gets in the zone, put their headphones on, works 20 hours a day and pump this thing out for you and make you rich.
What we've actually found is that that's destructive to a team. No matter how good a single person is, they can only type so fast, and they are human.
You'll always do better with a team of people that work well together, even if individually they're not as smart, talented, capable, whatever you want to call it, as that rockstar engineer.
Worse than that, if you get 20 people that are not as smart or talented as that rockstar engineer and then you drop that rockstar in the middle of them, and they start commanding that team, it's actually really quiet damaging.
What we look for is people that will collaborate. People that are happy to be wrong. It's about the solution and not about the ego, so I am not special in this case, it's not the first time that I walked into the room with the engineers and said, "We have this problem, this is what I think we should do."
One of the engineers will go, "No, that's a terrible idea. Actually, we should do this instead." And they're right, embarrassingly for me, they're right. And that's fine. At the end of the day, the best outcome is that we walk out with the best solution, regardless of whether I thought of it or somebody else thought of it, or we came up with it as a group.
It really doesn't matter. It's about coming up with the best solution to the problem and being able to over forward. So we need people that are going to discuss, put forward their ideas, but equally, be happy to accept that somebody else's idea is better than theirs and to work along with that line and this sort of thing.
So, attitude is really important to us and it drives into that culture piece that we're trying to build with the “Live Your Life” policy and that paradigm. We need people that are going to fit into the culture of LawVu and everything else around the periphery we can teach. That's fine.
“Google's codebase is a bit of a dumping ground as well.”
Why is now such an exciting time for you, to be a part of LawVu? And what gets you excited about the next 12 months?
Again, it's the impact. When I joined LawVu, like every startup, they made a bunch of decisions to get them to market very quickly. And what that meant was that they built things very quickly, they've taken a few shortcuts and we had issues in the codebase, and I'm not ashamed to say it.
Google's codebase is a bit of a dumping ground as well. Everybody's codebase is a mess this is not unusual. So, we had a few issues with PagerDuty going off a bit too often, and alerts and instability and this sort of thing.
We've spent the last 12 months addressing that because as I've said, I love my sleep. Whilst the engineers are on call in a rotating roster, I'm on call all the time. So, if an engineer doesn't answer the phone or can't figure it out, they call me and I get dragged out of bed.
It was just happening all too often. And one of the first things I set out to do, was to make PagerDuty a formality, rather than an actual problem because everybody hates it. I hate it. Everybody hates it.
So, in the last 12 months, we've achieved that. We got through the Christmas period, I had Tim and Sarah coming up to me and saying, we all took holidays over Christmas and the system just ran. Nothing went wrong.
We've gotten to that point now where we've achieved that stability, and now it's onwards and upwards, now we can start really addressing the big chunky things like, I want to take the application, containerize it, we're still moving to .NET 6.
There's a whole bunch of stuff that I want to do in terms of scale and load and improving and automating the quality path of the software, like all testing that we do, we're still quite manual in the way we do our QA, and as we grow that's not going to scale with us, so we need to automate a large part of that.
We've got some long-burning strategic goals to achieve over the next year or two, and the idea behind that is that our sales team is relentless, which is great, and we're starting to sign up some really big customers, and we're growing really, really fast.
I don't want to get to two years' time and then go, "Ah, now that we've got all this load we can't handle it." So preemptively, we're trying to sort out our systems now, so that when the floodgates do open, we're ready for them. I think that's really a really exciting thing to be working towards.
Appreciate you taking the time today Jason, and giving us a quick overview of what's happening there at LawVu. We certainly look forward to following along the journey and checking back in to see how things are getting on in the next 12 months.