‘From To-dos to Kanbans to Scrums’ with Harijs Deksnis, Director of Engineering at Giraffe360

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a really passionate and a growth-oriented engineering leader as a guest. He has 10+ years of experience in engineering leadership and management. He’s currently serving as a Director of Engineering at Giraffe360, and you can find him next at the DEVWorld Conference on 29th of February in Amsterdam, talking about the team design. 

Pleasure to have you here, Harijs. Welcome to the show. 

Harijs Deksnis: Hi, Kovid! Awesome. Yeah. Thank you for having me. Pleasure to be here. 

Kovid Batra: Great! So, Harijs, before we start and deep dive into your experiences, challenges that you have seen while scaling startups, I think there is something that I want to know more about you. The audience wants to know more about you. 

We have this quick fireside chat where we’ll be asking you some personal questions outside of work so that we know you better. Are you ready for that? 

Harijs Deksnis: Yeah, of course. 

Kovid Batra: All right, let’s get started. My first question. How do you unwind your day? What are your hobbies, passion outside of tech? 

Harijs Deksnis: Yeah, I try to unwind by watching or listening something of my interest, sometimes reading. I do like chess a lot. Sometimes I watch some videos, do certain type of literature, but it can change and, there was a period was very eager into learning different languages, so I used to just listen to audio books in different languages. But yeah, that’s, it goes like in phases, some, some months you have more passion in one direction, and then it changes. 

Kovid Batra: So, what are you reading these days? Like, is there anything going on? 

Harijs Deksnis: Well, at the moment I currently have a phase I’m actually pretty interested in Vedic literature. So, I’ve been looking into Vedas more. Actually just recently read through Rig Veda. So, that’s sort of my current interest. 

Kovid Batra: That’s nice. Being an Indian, I haven’t read that yet. And, I think that’s amazing to know that you are reading it. Any specific things that you came across while reading the Vedas? 

Harijs Deksnis: Well, it’s, it’s, it’s a collection, a huge collection of different hymns and it’s very poetic language. You don’t really read it as a prose, but there’s something behind the words that you just feel it, that it’s quite inspiring. So the very process of reading itself is a very uplifting experience. 

Kovid Batra: That’s nice. Amazing. That’s a very, very different choice, actually. 

Harijs Deksnis: Well, it serves well as unwinding after a long day of work and meetings and a lot of information handling. So, you read it not for the sake of, you know, comprehending information and perceiving every word, but you just read it for the feeling, for the switch of context and, uh, before bed, it’s, yeah, it’s very blissful. 

Kovid Batra: I see. Well, that’s, that’s interesting. 

Moving on to our next question. Well, we all are techies, so I just can’t skip this question. I just want to know, like, how was your first encounter with technology, with computers? 

Harijs Deksnis: Yeah. Well, if we talk about desktop computer, I think my father brought one home in around ’96 from his office, so, I believe, of course, it was Windows 95, and yeah, we just spent the evening playing with Paint and Microsoft Word Clipart and Minesweeper. Uh, so that was the very first computer.

Kovid Batra: So, is that the time when you really fell in love with computers? Or it was just a thing you had at that time? 

Harijs Deksnis: That was an insufficient experience to fall in love with. I was always passionate about technology, you know, playing the NES video game console, that sort of things. But I really, I gravitated towards computers when we got the first computer at home. It  was like a year or two later, and then I just loved going through all the settings in the control panel and just figuring everything out. I’ll start making my first website by saving a word document as HTML files. And, you know, there were links to other pages. So, it’s super static, made in word, but yeah, that was my first attempt to make a website.

And then I thought, “Oh yeah, this is something I really enjoy doing.” Creating these experiences and links, you know, hyperlinks, jumping to one content to another. 

Kovid Batra: Nice, nice. All right. That’s amazing. Moving on to the next thing. I think this is very important for all the audience to know, and I am being very curious here. I asked this to almost all the guests, what’s their success for mantra in life.

Harijs Deksnis: Yeah. Yeah. I resonate with the saying “I didn’t come this far to only come this far.” I really like that one. It’s acknowledging that there’s always a next mountain to be conquered after you’ve done something. And yeah, to never give up, stay persistent, and never settle. 

Kovid Batra: Yeah, I think that that is coming from that growth mindset that you have, like, the challenges that you see. You find climbing mountains and it’s like seeing what’s on top of that. So, it’s always good to be, like exploring things and knowing things and then finding challenges to overcome them. So yeah, perfect. Perfect. 

But still, there is one thing that I would want to know, what do you think that makes you go in this direction? What is that realization that pushes you to be a growth mindset person? Because it definitely takes a toll, right? It’s not like very straightforward that you say that, okay, every time I just want to do something. It has to be some inspiration from within to do this. 

Harijs Deksnis: Guess curiosity plays a big role. And just yeah, letting go of the past, yeah, shackles of the past, so to say, even though, even though, yeah, it’s maybe past achievements, but you want to sort of step beyond that. You don’t want to stay on that level forever. 

Kovid Batra: Nice. I think that’s a very interesting point. I think curiosity always helps you move in that direction. What I have felt is something which is related to, I should not say survival, but a peaceful survival is what pushes, at least me, even I believe, and I feel that I have that growth mindset that this peaceful survival, if you want to have in this world, you have to be growing all the time. And, it’s not just, like career in all the aspects of life. So, yeah, just sharing my thought here. 

Harijs Deksnis: That’s the way of nature, right? Sometimes you have something to run, stay just where you are. It’s like the Red Queen and Alice in Wonderland. Isn’t it, right? You have to run as fast as you can, just stay where you are. That’s the evolution, pushes us all forward.

Kovid Batra: Perfect. All right. That’s some interesting talk. Well, moving to the main section now where we would love to know how you have progressed through your engineering career, what challenges you have seen. So, starting with the first thing, like, tell us something about your experience where you have seen that scale-up journey, you have seen the transition from a room to a 60-member dev team, moving from to-do lists to Kanbans, to scrums, right? And, this whole thing, what role you played as a tech team member, as a tech leader here? 

Harijs Deksnis: Yeah, well, if we’re talking about experience with Giraffe360, initially I came on board, building upon my front-end developer experience in the past year. So, I joined to start basically a new front end project, a new dashboard. And, started working closely with the team. But, it became quite quickly apparent that you would need a bit of better way of organizing. So, we started scrum in one team, a bit of more structure around planning things. Also started, you know, demos. And then we quickly, got quite productive compared to the rest of the company and the team and, you know, backend became sort of a bottleneck. Then I joined that team and started the process there. Then it went to another team, which was more handling the platform side of things. So, it went a bit of like, yeah, like avalanche ball. So, just get getting momentum and pulling other teams with interest in the same process. And meanwhile, there was the Series A financing round had finished, so there were funds to really grow the team. We also embraced the outsource model with team augmentation. So, just bolstering our capacity with some outsource members in New York, which basically they basically worked as in-house employees, just joining the teams and yeah, that really forced us to grow further, create more structured organization.

That of course, was challenging, put a strain on communication. Some all-time members were struggling, of course, with the change because they get, you know, they were used to certain type of environment, culture. As often in smaller or earlier stage startups, you see ‘hero culture’ forming like a lot of things happen because of some few, but very capable key individuals who do a lot, who can do a lot. But also, as you grow further, as you need to organize better, communicate more scalably and sort of try to get rid of bottlenecks or, you know, ‘bus factors’, that people can just safely leave on vacation and things don’t stop, and delegation can happen. Yeah, those people tend to struggle because, they get used to a certain way of working that also, of course, combines with a bit of feeling of their status or achievement or importance. So yeah, that is an issue that can be challenging. 

Kovid Batra: That you have faced during this journey, yeah. So, let’s say, these kind of people who are there in the team, at times these people, you know, inspire other people to, like come up, step up. But at the same time, as you said that it is a double-edged sword, these people then become an issue in the team also. So, how do you create that balance? How do you handle such people who are actually very good for the team in terms of the efficiency, or if I have to use this word ‘productivity’, but, how do you handle these people? As you said, like you face them as an issue also over a period of time and the teams are scaling. So, how do you handle that? 

Harijs Deksnis: Yeah. Well, I think as you grow, it’s really vital if you haven’t been doing before, start doing regular 1-on-1s. That’s one of the best ways, best windows to actually see the state of your team apart from, yeah, you know, surface metrics, that sort of thing. And, yeah, try to guide them through this transition, explaining what, you know, the phases we’re going in, what kind of role is, and what kind of benefits there are from being able to let go, being able to delegate and being able to instead of being in the center of things, with being the one who documents things well, sets things up for automation, oversees the process that happens well, and yeah, that they can leave on safely on vacation and, and, you know, just turn, turn their phone off for two weeks or whatever. 

Kovid Batra: Yeah. Cool. So, I think most of the people who are in that category, would definitely come on a 1-on-1, listen to you. I feel that maybe 10% or max 20% of those people would actually have that feeling of changing themselves after those discussions. So, these 10-20% people probably who would change after these discussions or 1-on-1s, what do you think really clicked with them that you explain, or the other leaders in the team explain that hit them hard to change their behavior from being that bossy nature to being more cooperative, more understanding and leading with the team, not just leading the team the way they are thinking. So, do you think there is any specific thing that actually click with those people? 

Harijs Deksnis: Hmm. That’s a very good question. I think that ties into psychology, and the other can, can be very diverse, depending on the nature of the person. But, the underlying factors are that the company, of course, is evolving and changing and growing, and unless a catastrophe happens, it won’t, you know, go back to earlier stages. And, this is just a new sort of new status quo, and everyone just needs to come to terms with it in a as healthy manner as possible. Acknowledge that, yeah, if some expectations are not being met or somebody is still attached to older ways of working or still have that sense of urgency that used to be there in earlier days that, you know the pivots, pivoting happened more often that every client request was super urgent and important because yeah, there were only a few clients.

But yeah, realization used to come, those days are gone. So, and we are, we need to, operate a bit more at  thinking more about long-term, about just having things operate sustainably and without too much upheavals and chaos, or stress that we need to think about developer burnout. That’s also, of course, a big thing. 

Kovid Batra: So basically, what you’re saying is it’s a collective effect of a lot of factors that could help them change their nature, right? It’s not probably just one thing that pushes them to.. Yeah, I get it.

Harijs Deksnis: It’s not a conversation that convinces them, like you know, solid argumentation because arguments don’t always work, you know, especially in psychology. A lot of things just based are on our feelings and arguments cannot always penetrate that. 

Kovid Batra: Definitely. Makes sense. Makes sense. I think let’s, let’s move on to the next thing that I would love to hear. 

So, when you’re scaling, right? Initial stages, as you said, you have less clients, you have to, like move really, really, really fast, right? You really end up building, some fixes, and ultimately, two years down the line, when probably you have that Series A and you are becoming stable, you realize you have created a lot of technical debt, right? It happens. It happens to everyone, probably. How consciously were you taking those decisions in those first two years or one year of the journey? And then, how in the retrospect, you thought it could have been done even better. Just tell us about that experience of handling the technical debt when you are in the 0 to 1, and the 1 to 10 stage. 

Harijs Deksnis: Yeah. Yeah. That’s, that’s an inevitable consequence. Yeah, technical debt persists throughout our industry, especially when you move fast and in early stages every client request is almost like a, you know, a push for pivot because you’re still finding that product-market fit and every client feedback is vital for you. So, you often, you know find yourself changing slightly or a bit more direction quite, quite often just to cater to that client needs to, you know, so they stay on board and often they are a good signal for other clients, what would make them to join your, you know, client base. So, that Inevitably leads to creating a tech debt. 

In my philosophy, I think ideal way to handle tech debt is to, you know, acknowledge that it exists, and to factor it, factor solving it in future feature development. So, don’t just say, “Okay, we’re going to, you know, take two next sprints, just handling tech debt.” That usually doesn’t sit well with business and product because you know, they always want to see some sort of incremental progress. However, you can sort of balance those both needs by saying, okay, yeah, we’re going to work on this feature, but as we work on this feature, we’re also gonna solve the technical debt that this feature touches, so we can, be in a better state. Yeah, this feature will take more time. Maybe we’ll take, yeah, three sprints instead of one, but doing so, we will both deliver that feature for you, and we’ll have sorted out some X amount of technical debt. That I think is the best way. 

However, in practice, of course, yeah, it doesn’t always go that nice. And sometimes, yeah, we have had that, we operate with set cadence. So, this quarterly cycle of our feature development and then a release event announcing it to the clients and the public, and, you know, then the sales and marketing can build upon that. And, you know, there’s another cycle of three months. So, we also had that some team was very pushing forward just to get some features out. So, you know, we could have some relief on the other parts of the company where, you know, where that feature helped a lot of, you know, automation, and reduced a lot of manual processes internally. 

So, we just, you know, pushed on to get it out of the door. And, the next quarter we said, “Okay. Yeah, this team now has done a lot. They really rushed. Okay, this quarter, they will be more quiet on the new feature development. They will solve the technical debt part, so that in the future they can go faster again.” That has also ended up happening. And, I think it’s fine at the end of the day. 

Kovid Batra: Makes sense. Definitely. 

Harijs Deksnis: The first version of what I explained, I think it’s more wholesome, more healthier, better if it’s possible to pull off. 

Kovid Batra: All right. So, I think it’s more about being conscious to not just completely, you should not just completely ignore that aspect because anyway, you’re going to carry some technical debt. You can’t just solve it and build perfect software at day one, but you can definitely be conscious about it, be considerate of the overall business scenario, situation, and then take a call that “Okay. This is the percentage of technical debt that we are going to cater to.” Of course, you cannot, like quantify it completely, but still there can be some level of focus given to catering to technical debt while building the features also, right? 

Harijs Deksnis: Yeah. 

Kovid Batra: Makes sense. Perfect. I think with all this going on, I think what becomes most important is that there should be alignment in the team. Like, without the team alignment, having that hyper growth in the 0 to 1 phase, or 1 to 10 phase is very difficult. So, when you lead teams, you have to have the same success criteria for them, or maybe some specific success criteria for them to align with the business goal so that the business is achieving what it wants to.

But, when it comes to engineering teams, I would like to know it from you. How do you define engineering success? How do you measure it? And, while all this is going on, I feel that a very important part which you just mentioned that we should take care of the developer burnout with the factor of taking care of the developer well-being also comes in. So defining success for engineering team, measuring it and looking after the developer experience, developer well-being, how do you do that in a startup in this stage where you need hyper growth? 

Harijs Deksnis: Yeah. We actually are still finding our way with the, when it comes to, like metrics and that sort of thing, because it of course, it takes also a bit of time to collect them and to, you know, to make sure they’re consistent across time so that they can actually be based upon to, to make some decisions. So, we still operate often more of a sense or common sense when it comes down to that. But, yeah, I think I’m also converging on the opinion as I think the most of the industry, the DORA metrics at the team level are quite reliable signals of how well the team is doing. So, you know, the four metrics in there, to deal with them with stability, and deal with velocity. So velocity, I believe, is the ‘lead time for changes’, and the ‘deployment frequency’. That is how fast you’re going. So, the faster you’re going probably is better, it means you can, you can react faster.

And, another two, what was this? ‘Change failure rate’ and ‘recovery time’ is stability. So, how stable you are, how often you are introducing a change that needs to be rolled back. Or if you do that, how long it takes for you to recover. And, if those are low, it means you’re quite, quite stable. And if you’re going fast, if those all four metrics are good, it means you’re going as fast as you can and you’re still doing it in a stable and reliable manner. I mean, then you’re doing great. 

Kovid Batra: Yeah. 

Harijs Deksnis: And when it comes to yeah, developers, well, of course, a big red flag is if you, if you happen to have too high employee turnover, or you see burnouts happening too often. That is a big, big thing. 

Kovid Batra: How do you identify a burnout? Like, if somebody is in that zone, how do you do that? 

Harijs Deksnis: Yeah, I think 1-on-1s, both with your team lead and then sort of the team leads with their team members. I think that is very, very important to catch these signals early. I know when it happens first time in career, when you encounter a burnout, it’s actually a lot of people don’t notice that it sneaks up. Also when I, in the past I had my first one, yeah, it just snuck up on me and then it was too late.

Kovid Batra: Sorry to interrupt you here, but, I would love the audience who might be feeling the same, should know that it’s okay to feel that way. And, it’s okay to come up and talk to your managers or leaders to actually resolve this problem. Because I think in that situation, I personally have been in that zone. So, I would love to know, like, what does it feel like and what did you do about it when you went into that burnout zone? 

Harijs Deksnis: Yeah. It’s a difficult state because once you’re in it, you cannot reason out of it. And it’s not like a weekend recovery to get out of it. It usually takes months. So it, it’s a serious state. I still see it as a long-term accumulation of stress that was not properly dealt with. 

I think a long time ago, I, I saw some psychology lecture. Well, I’m gonna use, well, a glass, if you hold a glass like this, it’s, it’s pretty lightweight. You can hold it like this. But, if you hold it like this for, I don’t know, two minutes, it gets a bit heavy. Hold it for five minutes, it’s quite heavy. So, I don’t know, maybe you can make it to 10 minutes or even 25 if you’re resistant, but at some point you’ll, even though it’s super light, it’s going to hurt a lot in your arm. It’s going to be a lot of pain. And yeah, you won’t be able to do much with that arm for a long time. Well, not long, but you know, significant time enough. And, that just shows that even a small amount of load, if carried for too long time without letting go, you know, for, you know, having rest moments in between can result in a huge strain, and, basically loss of capacity for a while. So yeah, that’s the analogy there. And first time, yeah, it just sneaks up on you because, I just have been doing a lot and not letting go, often thinking about problems, you know, in evenings and weekends, maybe there’s some sort of personal trouble as well at home, family relationship, that adds to the load. And yeah, one day you realize, wow, you don’t have energy to be creative, to want something, to think something you just want to, yeah, you just want to, I don’t know, you don’t want anything. And that’s a very sad situation. 

Kovid Batra: Right, exactly. I mean, there have been scenarios. I think, this is from my personal experience, where personally, everything was fine. I’m happy home, having a good time with my wife, my parents, but when it comes to particularly work, it seemed like the way it is there always, right? So, I mean, as you said, like it could be something going on personally, and then at work-wise, and then you’re overloaded. I mean, I have felt that I was happy at home, but not feeling the same when it came to work. And, of course, reasons are different for everyone. But, burnout could be just related to your work where you are not getting what you need from that environment. So yeah, I think good we touched on this point. I think the audience would be becoming more aware of this situation, scenario and probably have more courage to deal with these kinds of situations. 

All right, coming back, uh, like to the engineering metrics and the success of an engineering team. So, you mentioned about the DORA metrics, right? Right now in your team, you said you don’t go by the metrics or you don’t go by these things. You just go by your gut feeling and the overall.. 

Harijs Deksnis: We pay attention to those, but yeah, we don’t have actually, like system set up, that, you know, that measures and tracks across time. We sort of look at it back and look up data when we need it and sort of have a good sense where we are, but we have some way to go there to have it more, you know, reliable and consistent. 

Kovid Batra: That’s absolutely fine. Yeah, I think it’s not, like very common yet that everyone is using those metrics or tools around those to actually understand what’s going on in the teams, but they do have this sense of what’s going on in the team.

So, my interest is to know, like if you don’t have these proper frameworks in place, let’s say, what exactly on day-to-day basis or weekly or monthly basis you look at to ensure, “Okay, things are going fine.” Like, I would just want you to, like reflect on that one month of maybe two sprints or one sprint, however you follow it. How does it look like? How do you ensure that things are going fine? 

Harijs Deksnis: Yeah, well, there are a couple of signals. I think it tells, everyone, even laymen, that things are doing well. So, your team is energetic, right? They feel they’re winning. They like the challenge they’re solving and they’re solving it in a reliable time. We are building features or product, that our clients like and they use, and of course there’s feedback. And, if there is negative feedback, we react to it fast and we don’t introduce too many bugs. That, you know, that keep us bug fixing for, you know, a disproportionate amount of time. And, there’s a lack of frequent incidents. Of course, you know, incidents can happen, that’s normal. But yeah, if you, if they end up happening weekly, depending on the system, of course, then something is wrong. 

Kovid Batra: Yeah. Makes sense. I think, even if you’re not following certain framework, I think the signals that you’re looking at ultimately point towards the important things that you should be looking at. I think that really helps you going. Probably when the teams are really big, you would have to have a proper process, a framework in place when you have objectivity on what’s going on each metric. But right now, probably with a 50-60 team size also, you’re able to manage seeing what’s going on. If the bugs are increasing, is the team motivated or not? And then this is really amazing point that the first point you said, “Is the team energetic and motivated or not?” I think that covers the 80% of what is actually expected to be there, as a developer experience, as a team experience that everyone should be motivated and energetic. Taking feedback, doing less number of bugs, doing more, delivering fast, I think always happens on top of it if the core is aligned and motivated.

So yeah, I think that’s perfect, Harijs. It’s really nice, knowing that you are taking care of your team, not just work-wise, but in general, how they are feeling. So that’s, that’s really nice. 

So, I think, this was my last question that I just wanted to ask in the interest of time. I’ll just ask one more question. I mean, you told about how these metrics work out for you and how do you handle that. One thing that I want to understand from you is when you set goals for your team, particularly, right? How do you exactly do that? Is it just some engineering achievements that you have to have at the end of the month or at the end of the sprint, or are you linking it to some product or business metrics also? 

Harijs Deksnis: We are mostly guided by product features or quarterly goals the business and product wants to see. And then it comes in a form of a new feature, new functionality being delivered to the customers. We track it at the quarterly level. At the sprint level, we do have a lot of freedom for the team leads to decide on the pace or the priorities. They sometimes can and do decide they have to tackle a bit of technical debt, so they can move faster to the goal in the next sprint.

Yeah. The quarter and product feature delivery is just sort of our milestone cadence. 

Kovid Batra: It makes sense. I think just keeping things tied to the engineering achievements would not be appropriate because at the end of the day, product and engineering works together to deliver the features, to deliver the product. So ultimately, the goal is to make the customer happy and deliver as much as possible for the customer. So, aligning that, the engineering team with that is really, really important. 

Perfect. All right, Harijs. I think it was a really nice conversation. It was a pleasure having you. Thanks a lot. 

Harijs Deksnis: Likewise. Yeah. Thank you for having me. It was a great conversation. Have a great day. 

Kovid Batra: You too, Harijs.