Software Developers Journey Podcast

#126 Ev Haus: animator, programmer, manager


⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Ev Haus 0:00
So I actually built my own fancy spreadsheet and I tracked all the artists across the whole company. And it did it in real time and provided status updates, like it was one of the fanciest spreadsheets you've ever seen in your life. And so I showed it to my manager, and I said, "hey, I've built this thing, a bunch of people have been using it here. I actually think this would be pretty cool. I have some technical knowledge. What do you think about me transitioning over to the technical team? And they were like, an artist doing technical work? Is that a thing? So and we actually, in a way, like spun out a software division specifically to focus on this task management software that I had kind of championed. A few years later after that, we actually shut down the entire visual effects studio and just became a software company building software for for other businesses similar to ours. So I steered the ship not only for my own career, but I think for the entire company.

Tim Bourguignon 0:59
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. My name is Tim Bourguignon, and on this episode 126, I receive Ev House. Ev spent most of his education, pursuing visual arts and trying to escape and in escapable future as a software engineer ever didn't reach escape velocity, he embraced a career in building software. And he's now the head of technology at then hub, but he keeps his artistic craft alive in his spare time door ever. Ev, welcome to DevJourney.

Ev Haus 1:38
Thanks for having me. I'm, I'm excited to be here.

Tim Bourguignon 1:41
So Ev, the show exists to help the listeners understand what your story about, you can imagine how to shape their own future. So let's go back to your beginnings are we where would you place the start of your Developer's Journey?

Ev Haus 1:55
So my journey begins quite a long time ago, in a in a very different country, where from where I live now. So my family, we grew up in Russia, and my father, he was a software engineer for most of his life there. And so I've always kind of been surrounded by you know, technology. And I remember we had this, you know, back in the day, we had this huge old beige box of a computer. And I also have an older brother. And I remember, you know, my dad was teaching him, I believe it was q basic on like MS DOS, or for me, as a six year old, it was very boring, very confusing, but also kind of, kind of, you know, interesting, I always found, I always find something about computers to be very attractive, it's almost like a portal into another world. That being said, most of my time, I spent focused on art, whether it was drawing or painting or graphics of some kind. And all of this computer stuff never really never really drew me in all that much, except maybe others, other than some games and things like that. But then I vividly remember a time when we got internet, there was this dial up thing through a modem. And I think I remember, I think it was Netscape that we used on there. And, and all of a sudden, instead of, you know, all this command line stuff, and just, you know, a blue background with some text, all of a sudden, I got to see graphics on the screen. And that really got me kind of more interested in what what this you know, big old beige box was all about. Now, around around this time when all this was happening, this is when my family also immigrated to Canada. And so the whole immigration process and you know, having to learn a whole new language and go to school, I was pretty distracted. And so I didn't really pay all that much more attention to computers until I was about maybe 13 1415, something like that. And through kind of my, my continual art studies, I somehow got into Photoshop, and don't ask me how I got a license at that age in that time. I don't remember. I would. And, but it was interesting, because most people from what I remember that time in this, this was like 2003 2004. Most people were using Photoshop to make design websites. This was like the time of Internet Explorer five and things like that. And so I kind of got pulled into that whole web design world built, built a website on geo cities. If you remember what that was all about. Of course, I remember there was this community called designs by Mark, which was a I think Mark was a like a Photoshop expert. And so he had like a online forum with other designers and web developers got together. And so I got really involved in all of this and started putting up some of my own designs and like started to get into like even flash and things like that, although I found flash to be kind of too hard. But anyway, I kind of I kind of got into the world of technology through the artistic side, because I really enjoyed playing around with pixels in Photoshop, but in order for me to showcase them, I kind of needed some avenue to put them into. And having a website was the most logical way to do that. And ultimately, that eventually led to me actually starting my own company and building websites and graphics for friends, and even some, some customers. And actually, there was a time I remember when, you know, I was, I guess I was working on some website or something, and I showed it to my dad, and, and he was like, Oh, you know, this is this is nice, but you know, making websites is not a real job. And you know, he should focus back on your studies, and, you know, how's your homework going? And he probably he probably doesn't even remember because saying that, because it was just such an off the cuff kind of thing was very, you know, a mundane type of day. But for some reason that that really stuck with me for for my whole life. Just this idea that, you know, websites isn't it's not a real job. And so I never ended up actually pursuing it much further outside of the being my hobby. And when it comes time, when it came time to like, look for colleges and universities, I ended up pursuing arts again. So I've always done a lot of, you know, drawing in my spare time, I wanted to get into animation. And so I ended up despite, you know, at this point, knowing quite a bit of coding, I just decided to go and become an artist and went to art school,

Tim Bourguignon 6:20
What kind of art did you study there?

Ev Haus 6:22
So I went to Emily Carr University, and it was a program specifically for 3d animation. So I kind of wanted to work in the visual effects industry went to either be like, you know, work at Pixar, or like a Disney or something like that. So again, like, pretty, pretty closely related to computers, because I really wanted to specialize in the 3d aspects of it, but still very, very focused on the artistic side, this journey of going through art school was quite revolutionary in my life, because it made me realize that I'm actually not that great of an artist. Pretty much all of the people that were my classmates were just phenomenal. Everybody had this incredible talent, when it came to either just hyper realistic drawings, or just really innovative designs. And even like, when it came to to do animation, everybody seemed to be always way ahead of me in terms of their technical and artistic abilities. And it was, to be honest, really quite discouraging at times. And while I'm going through art school, the way I'm paying for this, and the way I'm paying for my school is by getting a job as a web designer. So I end up still writing a bunch of code. And in that case, it was it was PHP, for the most part, I'm like doing some web designs for a local company. By the time I kind of got out of school, I realize, you know, I kinda I kind of like both of these things. And this whole coding thing is actually also kind of fun.

Tim Bourguignon 7:50
So how did you steer the ship in a different direction? How did that decision come to be?

Ev Haus 7:55
So it didn't happen until after I got my first job. So once I kind of got my art degree, I naturally went looking for a job as a 3d animator. I mean, I spent the last, you know, at least four years of my life studying this. So it made sense to go and try and find a way to apply it. And luckily, I found a job pretty quickly as a 3d animator, in a visual effects studio not too far from from where I lived. And I joined that team and I got to work on some crazy big Hollywood movies like Harry Potter and Narnia Spider Man, wow, got my name in the credits, which was very exciting. And, you know, I found it to be incredibly glamorous. But to be honest with you, the work was quite miserable. Because, you know, when you're working in a visual effects industry, these movie projects are so, so large, they're so big in scope that any one single person works on the tiniest of tiniest of parts. There's a story that I always like to tell my friends about about this time. So we were working on a movie, I believe it was a remake of Conan the Barbarian. And there was a scene that I was responsible for. And it's a scene where, you know, this big kind of hunky Conan like, character is in a, sort of like a farm. And he's, you know, with his female counterpart, and they're, you know, spending some quality time together rolling around in the hay. And it was a it was quite a short scene, it was maybe like, gosh, maybe like five to 10 seconds long. But my job at the time, was to trace out every single piece of hay in that scene, which was thousands of them on every single frame. So this was a time when they basically they gave this project to my studio, and there wasn't a lot of animation that was needed in it and they asked, hey, are any of the animators would you volunteer to help us? It was called rotoscoping, which is the act of essentially tracing the items to give them depth. And so I mean, I said, Sure you went out, I'll help out. And I just spent most of my time looking at this, you know, bare naked but tracing, tracing, hey, and then every end, at the end of the day, I would sit down with the director, and he would give me notes about, hey, you didn't trace it very well here, and you missed this spot there. And it's just I remember coming home every day, it's just, what am I doing with my life? It's just absolutely, absolutely miserable.

Tim Bourguignon 10:30
So you obviously chose PHP over raytracing?

Ev Haus 10:36
But, well, it was really interesting, because I think at this point, I think the studio also really kind of probably noticed that I'm running, I'm not really into it. And I think my work was starting to suffer, I'm pretty sure it was on the verge of being fired. I like any day. And I think I also myself instinctively recognize that this is just not where my passion is. And luckily, the studio that I was at, it's actually a pretty new studio. So they didn't have a lot of existing infrastructure, I asked the transition to the technical team at the same company, who were essentially building out a set of tools for the artists in the studio. So because it was a kind of a brand new company that didn't have a lot of existing tools in place, actually, all the project managers, they were just using, like spreadsheets to track work for all the artists. And I was always really fed up with this as an artist. So I actually built my own, like fancy spreadsheet and attract like all the artists across the whole company and do it in real time and provided status updates, like it was one of the fanciest like spreadsheets you've ever seen in your life. And so I showed it to like my, my, my manager, and I said, hey, I've built this thing, like a bunch of people who've been using it here actually think this would be pretty cool. I have some technical knowledge. What do you think about me transitioning over to the technical team? And they were like, an artist doing technical work? Is that a thing? They were they were very skeptical, and rightly so. Right? It's it's not a pretty common career change. But luckily, they gave me a shot. And the one question they asked me was, so if you don't know, in the visual effects industry, pretty much everything uses Python. So all the tools use Python, all of the automation scripts, most of the software is written in Python. And I had zero Python knowledge whatsoever. And so they asked me, hey, how's you know, do you know Python? I didn't want to lie. But I also didn't want to be completely honest. So I said, Oh, Python is no problem. In the sense that, I will learn it, don't worry about it. But I think I gave them the impression that I already knew it. So basically, I ended up having to join the team, they gave me a bunch of automation tools in Python, and I had to learn it basically on the job as quickly as I could.

Tim Bourguignon 12:45
But the white lie wasn't discovered...

Ev Haus 12:47
Yet, it was painful. At first, I'm not gonna lie. I I remember, messaging my brother a lot, who is a who's a more senior engineer. And he's just kind of gone down the software engineering path. And so I asked him a lot of questions in the middle of the day as I'm trying to solve all these Python automation things. But eventually, I got the hang of it started building some stuff, converted my spreadsheet into something more of like an API. Basically, long story short, Python became really easy. And I started to be able to move quite a lot quicker, I started having time to work on projects that I thought would be interesting, I started building out a whole set of like tasks and project management type of tools for the artists. without actually telling anybody that I was doing this, I just did it because I thought it was fun. And it's what we needed. And luckily, the the company that I was working at, were incredibly supportive of all of this, all of this madness, and this crazy artists building all this stuff in his spare time. And we actually, in a way, like spun out a software division specifically to focus on this task management software that I had kind of championed. A few years later after that, we actually shut down the entire visual effects studio and just became a software company building software for for other businesses similar to ours. So I almost kind of I steered the ship not only for my own career, but I think for the entire company

Tim Bourguignon 14:08
Single handedly changed the company. That that's pretty cool.

Ev Haus 14:14
So that's, that's basically my journey from an artist, and how I ended up in the software world. And I've I've been there ever since. And

Tim Bourguignon 14:23
Before we we move on, what kind of advantage Do you have as an artist working in software for artists?

Ev Haus 14:34
Well, it obviously gave me the knowledge of understanding exactly what the problems are right? Because I am also the end user. So I know exactly what challenges artists face, which is, you know, keeping track of what the your tasks are figuring out Okay, once you're done your piece, who do you hand it off to keeping track of all of the files. So there's a tremendous number of like file management that happens in the visual effects industry. You know, Somebody's creating a 3d model here. Another person is setting up the rigging, somebody is doing textures and other person is like doing like the compositing, and so all of the stuff has to be tracked and versioned. And so there's quite a lot of stuff to build in terms of software. And so as an artist, and as somebody who really cares deeply about design, I spent, honestly, most of my time building out the front end aspects of it, which was challenging, because I also had to build up the back end pieces. And so I ended up building out the Python API that supported all of it. And eventually, the team that came into, you know, run the project afterwards, you know, the back end guys never really said anything, but I'm pretty sure they were completely appalled by the quality of the Python code that I ended up writing there.

Tim Bourguignon 15:46
Hey, it worked!

Ev Haus 15:47
Hey, if it works, you know, it works.

Tim Bourguignon 15:52
Then I'd love to ask the question, to flip the question on its head. Did he happen to face the problem that you were opinionated about one problem as an artist or x artists in this case, and realized your knowledge is not necessarily what your colleagues only need? or want?

Ev Haus 16:11
Yeah, very much. So. And I mean, especially once this project actually kind of gained steam, and we started to build a team around it, and other developers came on board and project managers started helping decide, okay, well, what should this product doing? And what other problems does it solve for other people at this point, like, first of all, I didn't really have a choice. Like my, my personal opinion, is now less less important, but also was a big relief, right? Because I'm no longer the one that has to make all of the difficult decisions. Now there's a group of honestly, much smarter people that can help take this idea and make it into something bigger than it really is.

Tim Bourguignon 16:47
That's cool. Positive twist. Okay, nice. Why did you leave? Why did you change job at some point?

Ev Haus 16:54
So I was actually stayed with that company for a very, very long time. And the the company did go through like a number of pivots. Right. So the first pivot that we talked through was from a visual effects studio into a software company. And so I played a important role there, because I stayed on as one of the lead engineers during that time. But even then, we kind of realized that, you know, this is a pretty niche market, you know, tools for artists, there's, there's not that many other visual effects companies out there. And so we wanted to create a bit more of a generic software solution, solving some of the types of problems that we also encountered, which was around sort of like the data analyst analytics aspects. So we wanted to ask questions of all of the data like, Hey, where are artists spending most of their time? Or how could we move quicker? Or where are the bottlenecks, so typical project management type of questions. And so we actually kind of pivoted the company again. So rather than building software, specifically for the visual effects industry, we decided that we're going to spin off kind of like a skunkworks project, it was a team that would focus on building a brand new platform that would focus on the data analytics side, and potentially even like doing some data science on it. And this was one of the big forks that I had in my career, because I was basically given the choice, you know, do I stay on keep supporting this baby project that I've worked on, you know, this whole time, this visual effects tracking software, something that I that I championed, and I realized, do I do I see it through to the end? Or do I go join this very risky, highly unknown brand new team with a whole new set of team members and build something completely different. And I ultimately made the decision to go and join the new team, which was not an easy decision. At the time. In the long run, I think it ended up being the right decision, because we ended up building a pretty cool new platform quite quickly. It took us a long time before we got any customers. But the the idea was quite quite enticing. And we ended up being building an entire business around this new idea. And I ended up meeting some really talented engineers there, many of whom are still my friends to this day. And so from from there, I think one of the big lessons that I learned was that you control you, yourself, control what will be successful with your own hard work sometimes. Now, you don't always control you know, the timing of the market, or, you know, bad product decisions or lack of funding, there's a lot of things that are outside of your control. But there's also a lot of things that are in your own control. And if you really believe in something, and if you put a lot of work into it, a lot of a lot of that energy kind of feeds back into the success of the product. And you can you can get something to happen purely off of your own artwork.

Tim Bourguignon 19:32
I observe that so often, that people censor themselves, just thinking it won't work. And if you believe in it, if you try to push further, sometimes it doesn't work, but sometimes you're surprised and it does. And you can you can reach some new heights just by trying to push further, even though you might have some doubts about it. Yeah, that's absolutely right. Yeah. I'd like to come back to this decision of yours. Staying on your old baby. As you called it, or going to this new risky stuff, do you remember how you made this decision?

Ev Haus 20:05
To be honest with you, it was kind of a blur. But I definitely remember, it being a fairly easy decision, because I felt like I had, I had already given this existing project, pretty much everything that I've got. And the team that was built around, it was much more capable than I am. There was some phenomenal engineers working on it, that had on their own a lot of great ideas for what they would want to do with it. And so I felt that most of my time would just be spent, you know, supporting the existing architecture and less around innovation. And the idea of taking all of the skills and all of the lessons that I've learned, and applying that towards something brand new sounded very exciting at the time. And so that that was ultimately I think, what led to my decision.

Tim Bourguignon 20:51
Yeah, that sounds like some kind of fall trust, or, yeah, I can leave this baby it's gonna leave on its own, don't have to worry about that. And then this new and shiny stuff, it's

Ev Haus 21:01
exactly yeah. as engineers, I find a lot of us are very attracted to building something from scratch and working with new technologies and tools. And so just the idea of being able to play with a new sandbox of stuff is quite compelling. Indeed, it

Tim Bourguignon 21:18
was it switching the domain and going away from this artistic endeavor, or an or target, and going into a more generic sense, and maybe not being able to relate that much with the customers anymore.

Ev Haus 21:33
Yeah, that was by far one of the biggest challenges. So from the point of view of the technology stack, everything was great, because we got to start fresh, we had a we had a team of really smart people, we got to build out something that we were really proud of. But from the point of view of understanding our users and knowing what to do with the business itself, we struggled a lot. And it took us quite a long time before we actually had some success in the market. And ultimately, at the at the end of all of it, the company didn't succeed, and it didn't survive in the end. But yeah, I think I think the part that I remember the most is just being very proud of the of the technical work that we've accomplished, because we ended up actually building something that nobody had ever built before in terms of the platform. But jumping into something that not a lot of us had knowledge in in terms of who the users would be how they would use, it was very challenging. And we made a lot of bad decisions. And then we tried to course correct and yeah, it was quite a quite a journey. Could you expand on those bad decisions, or the factors that, in your opinion, in hindsight, led to it not being so successful and failing the end, basically, what we're trying to build is we're trying to build a generic data science and machine learning platform. So imagine you have a business and your business collects a lot of data. So you have probably probably have a bunch of databases that have maybe your customer data, some data base that has maybe your operations data. So you have all of this like info at your disposal. But then you want to ask questions of your data about, hey, how's my business doing? Are we successful? Where are bottlenecks? Where can we gain more efficiency? So questions that are possible to answer with the data, but really difficult, because you don't really have a tool that you could use to facilitate that. So we were trying to build that tool. So you would essentially connect all of these disparate data sources into it, we would try to run some existing machine learning algorithms on top of it to try and like suss out some of the common patterns that we know you might want to ask of it. And then we tried to provide like a really slick UI on top of it, that lets you look at analytics and build reports and dashboards and also, essentially give you all the tools that you need to to gain access to this sort of stuff. So it's, it's a, it's a very big, big problem, because there's a lot of things that are completely outside of our control, starting with the data itself. And then the problems as well are very different. So what we found was that we engaged with different industries, you know, we engaged with the visual effects industry, because we had some experience there. We engaged with the forestry industry, because it just happened to be an industry that, you know, our CEO had some knowledge in and was something that's kind of thriving in the city that we live in, we engaged with the restaurant industry, so very, very different, like different industries. And what we found was they all kind of had the same problems, but also very different problems. And trying to build a solution that helps everyone ended up that we didn't really build a solution that helped anyone.

Tim Bourguignon 24:32
Do you have an idea how you could do it differently nowadays? Well, there's

Ev Haus 24:37
quite a lot of companies that are competing in this space, including some really big players like Google and Amazon that are trying to do this. So I do think it's possible. It's just it's it's a very big investment in terms of what you need to build because you essentially need to build a set of tools that users can play with to get at that. The other thing that was you know, very interesting is that this is also the time when When my own career was also having a bit of a other fork in the road, where, you know, I was, I was the lead engineer on this project for quite some time. And I was kind of getting to the point where I wasn't sure what was next in my career. And a part of it was because my, my physical body was starting to, like, make this decision for me, like I was starting to have back problems and wrist problems. And my eyesight was getting worse because I was staring at the screen all the time. And so I was kind of debating debating what I what I wanted to do as well. And I think a lot of developers kind of get to this point in their career where once you kind of get to a particular seniority, there's a bit of a fork in the road, right? There's like, do you go down the management track? Or do you stay towards the technical track, this was a time when I decided to go down the management track. Because my, my, my idea was that, okay, I would get to work a little bit more with people less sitting in front of the computer screen, I'd get to walk, walk around a little bit more, you know, less sitting. So hopefully, I would be a bit more active in terms of my health. But that also meant learning a whole bunch of other responsibilities, things like around what we just talked about around how do we grow a successful business? And how do we make the right decisions in the market? And there was a lot of things to learn there as well.

Tim Bourguignon 26:13
How did you go about learning that?

Ev Haus 26:15
Well, to be honest with you, I just spent looking around what other managers around me did. So I had zero training, you know, I never took a management course, in my life. I had zero experience, obviously, I've always just been focused on software engineering. But luckily, I had a lot of really amazing mentors around me in the company, people that have grown big businesses and work that large companies. And so I essentially just looked at what they do try to replicate it as much as I can, I made a lot of mistakes along the way, and try to learn from them and take notes and try not to do that again. And honestly, what I found is that, as a manager, you spend more time thinking about the things that are coming up. And like how to make your team successful, and you spend a lot less time in the code editor itself. And that was that was a really big shift for me. And it took a lot of trial and error to get to something that felt comfortable. Did you feel like your mind was fighting against it? Or did you embrace it

Tim Bourguignon 27:13
and go with it?

Ev Haus 27:15
To be honest with you, I still don't know if it was the right decision after, you know, I've been at this for like, what, five, six years now. So, you know, I went from being what I would think is a pretty decent, you know, software engineer to being a really shitty manager, right? Because I had, I had no experience whatsoever. And that was very difficult emotionally, because I know I was, was somebody who felt quite good and capable at their job. And so now coming in every day, and not knowing what the heck I was doing. And in general, I'm also fairly introverted by nature. And so spending most of my day, talking to other people felt quite exhausting, right. And so I would often come home at the end of the day, not really knowing how to be able to measure my own success. So when you're an engineer, it's pretty easy to measure your effectiveness, right? It's like, either the feature was shipped and has no bugs had good performance, it doesn't crash, it gets user adoption, like, all of these things are easy to measure. But being able to measure your effectiveness as a manager is like I would say it's nearly impossible. And if anybody knows any tricks in this area, like please get in touch with me, because I'm still searching for for the right way to measure this

Tim Bourguignon 28:24
searching as well. I'm interested as well. Yeah, indeed, it's one of the biggest problems. And being an engineer and individual computer, you get your your Fix of achievements every day, hike every hour, sometimes, as a manager, if you get this once in a month, that's, that's a good month.

Ev Haus 28:43
Yeah. So what I find is, like, most of my time, I'm spending thinking about, okay, what what can I do to make my team more successful. And, and what that means is, there's a number of crazy factors that are played. And I think if everything is going right, just things feel good, like things are kind of chugging along. But in the real world, I find that like, that almost never happens. Like there's always something going wrong, right. And your job is as a technical manager is not just to fix the problem. In fact, sometimes you fixing the problem leads to more problems. Your job is to anticipate the problem and get ahead of it, like try to identify problems before they come up, and then try to figure out okay, well, how do we how do we make sure that first of all, this sort of thing doesn't happen. And when it does, that the team is prepared for it. So it's a very different type of a challenge. And so like, now, every time I get to code, I always take a big deep breath, and I feel comforted, like coding is now all of a sudden, a relaxing paradise, right? You get to see that, you know, one plus one is always two and it's beautiful. And it's whereas, you know, being a manager is like writing code that you're never able to run, right? It's just like you always shipped direct to production and you hope it works. That's good. I know what it feels like,

Tim Bourguignon 30:01
do you manage or do you manage to, to set up some some time to code and still continue to work on your skills, and maybe get your batteries recharged at the same time?

Ev Haus 30:14
Yeah, that's one of the things that I really believe in like, and I would encourage all like, technical managers to always still be coding some amount of time, like for, for me, first of all, yet, it's just a way to recharge. But it's also really important for you to have an engagement with your team, right? Because it's very hard to get people to respect you as a manager, if they don't trust that you know, your craft. So this is an opportunity for you to really showcase the fact that, Hey, you, you know what you're doing, like, you've done this, before you've solved these problems, you know, how to how to develop quality software. And so, in addition to it being a way for you to hone in your own craft, learn how you know how to how to solve the problems that your team is dealing with, it's also wait for your team to see that, you know, you you also know your stuff, and you know you're doing

Tim Bourguignon 31:03
Do you partake them to writing productive code as much

Ev Haus 31:07
as I can. I mean, every day, I find that I have less and less time for this. And so one of the things that I like to say is, any day where I have the time to write code means it was a good day, it means things have gone really well. Nothing was on fire, and I actually get a chance to contribute back to what my team is working on. That that's a nice metric.

Tim Bourguignon 31:28
I unfortunately, don't come to coding anymore. I to work at home, certainly most of work not not anymore. And for me, the analogy would be if I come back to my my long running to do list with all the crazy ideas I gathered. During the the past weeks and months, that's a good day, because that means all the fires are put out. And I can concentrate on things that are just not coming from everywhere. And lending lending on my desk. I can concentrate on something else. That's usually a good sign. Yeah, that would be the same analogy, I guess.

Ev Haus 32:05
Yeah, I would agree with that.

Tim Bourguignon 32:07
Okay, um, but this company, wasn't Zen up, was it?

Ev Haus 32:11
No. So this was a company called accumulate. Yeah. And so I was there for a good period of time. And you know, about five years into building this data analytics platform, we essentially ran out of money. And so we had to shut down the whole studio, which is a very, very sad time in my life, obviously, because now literally all the hard work that I've put into being there, disappeared, literally that day. And, and literally all the code was gone. Like I didn't have access to the code anymore. And for me, that was a really important lesson, because it told me that the code that you write actually doesn't matter. What matters is the knowledge and the experience that you gain from writing that code, because those are the things that you could take with you. And you can apply them anywhere. And, you know, this was this was a, this was a failure that actually didn't see coming. This was a situation where I actually even though I was, you know, a technical manager at the time, I was a technical director, actually, I didn't really ask a lot of questions about where our money was coming from. And our CEO, always had the good intentions of kind of shielding us from some of the money challenges. He didn't want to burden us on the team, he wanted us to focus on the technology, which is what we did. But what that meant is that we didn't really ask the questions around how the business was doing. Or at least we didn't ask enough questions. And there was a period where I knew we were kind of close to the edge and things were kind of a little rocky. But had I really known the severity of the situation, I would have probably spent a lot less time on you know, frivolous things like fixing linter errors in my code. Versus you know, really like bunkering down and going Hey, guys, we got a we got to ship something that, you know, gets us some users. And that entire experience was was another really big lessons for me, which is the sense that transparency is one of the core values of any company, you know, anytime you hide data or info from your team. It's almost as bad as lying, I would say, right? Because oftentimes, you don't know what questions to ask. So like, had I had I known that we were financially struggling, I would have asked a lot of questions, but I didn't even know that that was the case. And so, now my big lesson is that I value transparency quite highly. And I share everything with my team, you know, any question that they have, and in fact, I often overshare I tell them things that maybe they wouldn't have even thought to ask because I want to make sure that everybody's aware of what challenges we face what what struggles might be coming up what, what things that I'm scared about. I think those are all really important. And they show they show your team that you care and you're genuine and you're honest, but it also lets your team have an opportunity to help you. When things do go

Tim Bourguignon 34:56
kind of South. What would you say to Someone's saying, well, but if I do this, if then you the state, the company or the project is in, they will probably leave. And we don't want that to happen. So we'll let's, let's hide some some stuff until it gets better. How would you answer to this?

Ev Haus 35:17
I mean, it's a reasonable position to take, right? Because it's true, people might not react to the news very favorably. But I think it's kind of your responsibility as a manager to be upfront with everybody. Because for every person that decides to, you know, jump ship, because they're scared of the news, I guarantee you, somebody else will step up and use this as an opportunity to really show off just how incredible they are. Every single time, I have presented challenges to my team, it's always created an opportunity for somebody to really show a lot of initiative Help Help us get through this pain. And it really allows people to get to become leaders right in the space, you need to create those opportunities for people on your team. If everything is just always kind of humming along, and things are going, Okay, people get bored and leave anyway. So by having a little bit of almost chaos in the in the, in your company, maybe chaos is the wrong word. But having a little bit of you know, opportunity to challenge your team is actually quite important.

Tim Bourguignon 36:21
It is a neat, that's a very nice way to frame it. Thank you. So take us to two then hub, what's the what's your story getting there? And and what are you doing there?

Ev Haus 36:30
Right, yeah, so we finally we finally come to, to the present. So after my time accumulate ended, I was looking for for my next chapter. And, you know, I really enjoyed what I was doing accumulate, I enjoyed my position, I enjoyed the type of role that I was in. And so I look for a company that was of a similar size, similar challenge, maybe maybe a little bit bigger, maybe some different types of challenges, maybe again, something where I get to use my own skills a little bit more. And I found Zen hub, which is just a phenomenal, phenomenal product. So if you don't know what that hub is, is it's a task and project management suite that's built right into GitHub. And, you know, most developers have a GitHub account, that's pretty much where all open source projects lives. So most people are aware of what GitHub is. But if you try to run a business in only from from GitHub, it could be quite challenging, because they don't quite have enough tooling around it. And then hub provides that tooling. And for me, this was very exciting as an opportunity. Because again, I could come back to where I started, which is building tools for people just like me. So now I get to work on a product where the end user is the developer. And guess what, I'm a developer at heart. And so I get to understand exactly what the pain points are, I know the market really, really well. And the super amazing thing is that we get to use Zen hub, to build Zen hub, right? Every day, I am using my own product. So if if something is in there that I don't like, guess what I just go in, and I fix it. And having that power is just so valuable. And it's just so rewarding, to be able to build something that you are a consumer of fitting is awesome.

Tim Bourguignon 38:15
And that is really cool. So how long have you been there?

Ev Haus 38:19
So I've been with design hubs for just a bit over a year at this point. And I'm so excited for the next year, because we've got some some amazing things coming up.

Tim Bourguignon 38:28
But just about a year, that means the end of 2019 at the beginning of 2020. We're hit with this new pandemic. So how did that go? Being a new hire is very high position in any company and going fully remote. At that point, how

Ev Haus 38:44
did that go off really challenging. So one thing that really helped us is even before I joined Cena, but already did a phenomenal job of embracing a remote working environment. You know, we have an office, but every single meeting room in the office was already equipped for remote work. Our CEO is actually fully remote, he works out of San Francisco. So we had a number of people that were already fully remote, but the vast majority of people were working out of the office in Vancouver. And so when the pandemic hit, we we obviously jumped, you know, we took that very seriously. And we asked everybody to work from home, which for a lot of people was Yay, we get to work from home, um, and for a lot of people was quite challenging because, you know, they didn't have the equipment, they didn't have the space, maybe they were living with roommates, or maybe they had children at home. It could be it could be a very difficult transition when it happens so suddenly. So it It took quite a long time for us to find a balance that that worked. But I think it was an important change for us because it made us really iron out some of those some of those challenges that we have, both in terms of communication process, how we work, how we communicate, you know, time zones and when we set up meetings, like we we were kind of Forced to iron out a lot of these a lot of these problems, and I'm not gonna lie, I don't think it's perfect today, we still struggle in many aspects of remote work, I think the biggest thing that we struggle with is just the the lack of social interaction, I think is quite undervalued for remote companies, because being able to get to know your teammates, being able to hang out with them, Go grab beer, you know, talk next to a water cooler, whatever it is, those moments seem very mundane. But they they're actually quite valuable. They they let you connect with your team, they get you to realize that people that you work with also have challenges and struggles and gives you an opportunity to to help them or assist or ask questions. And all of these things do contribute quite quite heavily to building a culture where people love coming into work every day,

Tim Bourguignon 40:51
I guess we're fighting with the same thing with Bo, because some of them we're working with the they are slowly starting to realize that there's a problem there. But I guess it's been it's been a lot of rainbows and unicorns so far and saying, well, everything's doing fine. And look at that the velocities not going down. We're still producing coal, and everything's fine. But they guess slowly, we're starting to realize where where the things are falling between the cracks, and to guess we're not at the end of the hall surprises in this in this regard.

Ev Haus 41:21
Yeah. And I think it's very interesting. Like, I've talked to multiple different companies, and I've heard it on both sides of the spectrum. Like I've heard some companies go, Oh, my God, how have we not done this before? This is remote thing is amazing. People don't have an excuse to not show up to meetings anymore. Like, it's great. We're getting through all this stuff. everybody's like, everybody's got energy because they don't have to commute. And I've heard the exact opposite, where it's like, I don't know what I'm gonna do. My business is crumbling. I can't trust my employees anymore. Because I don't know where everybody's at. Like, things fall through the cracks communications suffered. So it could be really challenging for some people.

Tim Bourguignon 41:59
Yeah. I wonder how long it's gonna continue with this pandemic? And probably we have to, to buckle up and, and continue in this direction. We don't have one of a choice.

Ev Haus 42:10
Yeah, but I do think overall, it was probably a good thing for the industry, to, you know, as much chaos as it is. And as painful as the situation in the real world is with the pandemic. I think people being forced to embrace remote culture probably was for the betterment of the entire industry as a whole. It I think it unlocked a lot of opportunity. Like for example, right now we're we're hiring a bunch of individuals on the floor for our engineering team. And whereas before, I would almost always emphasize people that would be able to come into the office, no, no, I don't even care like a for as long as you're like anywhere within relatively similar timezone, I'm happy to have you come join the team. And in a way that's very refreshing. And it eases a lot of burden for me as a hiring manager. And it opens up a tremendous amount of opportunity for the engineers who might want to work at a company that isn't in their city. So I think overall, there's quite a lot of benefits to it,

Tim Bourguignon 43:07
I have Oh, I have a toddler at home and being able to, to walk up the stairs and see her be really happy to hear her dad, two or three times in the morning. And then same in the afternoon. That's that's really something I sometimes I wonder, how did I do leaving at seven in the morning, before and coming back at 17 in the evening, and not seeing my kids at all. And it's just, I just cannot cannot remember how that worked.

Ev Haus 43:35
out. I don't even remember anything about you know, everything seems like a blur, though.

Tim Bourguignon 43:44
And one other thing I I find really, really interesting is the that we were forced to start thinking and outcome and not in seed button in seats anymore. And really saying, well, you're not seeing your your employees. So where are you actually expecting from them? What do you What is it? What is a good employee? What, what is or what is he? Or is she? Or are they doing at work, when you cannot see them? And how can you measure that? their outcome is right, without looking at their timesheet? And without looking at all the working now? What What do you expect them to produce in one week? What kind of communication do you expect? If things are going right? What kind of communication Do you expect if things have gone wrong? and stuff like that? This is really a really healthy discussion, I think.

Ev Haus 44:37
Yeah, and you're absolutely right. That this is something this is another one of those in addition to transparency. This is another one of those values that I really firmly believe in, which is trusting your your team, right? I very rarely come to anybody on my team and tell them hey, here's a task I need you to do. Like just almost never happens. Usually what I do is I come in and say hey, here's a problem. I have. Can you To help me solve this, and you you, you have to give your team an opportunity to impress you, you have to, you have to trust that people that you've hired are going to be successful. And it also gives you feedback, right? Because if they're not, then maybe they're not the right people for that role. As with everything in software development, it's a game of trade offs, right? So you can, you can tell somebody exactly what they need to do. But then you're, you're doing all the hard work of figuring figuring that out, right. And on the other side, is you could put a lot of trust and faith in your team and the folks that you've hired, but then they have to have a lot of initiative, right, they have to go out and ask the questions and understand the challenge and talk to the right people and research what needs to happen and tell you when you're wrong about something. And not everybody is capable of that, too. So it really does change your attitude, and in terms of who you hire, and the skills and qualities that you look for.

Tim Bourguignon 46:03
And then the qualities and skills that you teach, preach or guide people forward?

Ev Haus 46:10
Yeah, exactly. Yeah,

Tim Bourguignon 46:11
I want to underline it again, give your team an opportunity to impress you. I love I love the attendance. That's, that really resonates with me. Thank Thank you. Do we have any advice for people transitioning right now from this individual contributor role to maybe something more managerial? Like you did you have any advice for, for people in this in this phase of their career?

Ev Haus 46:36
Yeah, for sure. I think I think my advice is, don't be afraid to get it wrong. I've I've talked to quite a lot of engineers that have made this transition. And pretty much everyone other than crazy, few exceptions have gotten that wrong. Like they'll they'll choose the management role, and then realize it was a horrible mistake, they hate talking to people, they just want to write code, and then they've gone the other way. And just as many people who have had the exact opposite experience where they've No, no, like, they really want to stay technical, they want to like really dig into the architectural problems. And then they realize that you know what, I'm actually not enjoying this all that much. And it's very isolating. And I would really love to opportunity to lead a team. And they go the other way, I would say most people get this decision wrong. And, and I would even also say, You yourself might get it wrong multiple times, you might want to transition a few times. So the only way you're going to be able to figure out if it's right for you is by trying it. So if you are in a position where you're ready to make that jump, and your company is giving you an opportunity to do this, just take it take it, give it a go give it a try, the only way you're going to know if it's a good fit for you is by going through it yourself. And just you know, be ready for the fact that it's going to be hard, right? It's it's a very different set of challenges. It's a very different type of problem solving. There's very few situations where there's a right and a wrong every day, you're just dealing with a bunch of gray area. And your job is to figure out which direction to go in at any given time, one of one of the best pieces of advice one of my mentors gave me was that, you know, let's say you are, you're faced with a difficult decision at work, and you have to decide between A or B. And so you review the kind of the data that's presented to you, you look at the evidence and you know, you ultimately decide, you know what, let's let's go with decision A is the right decision based on what we know now. And then you make that decision. And then later, you know, new evidence comes in, and you realize it was the wrong decision. And you've made a horrible mistake, a bad manager will look at this circumstance and see that, hey, I've made a really terrible decision. A good manager will look at it and say, hey, I've made two very good decisions. First, I made a good decision, because I looked at the evidence and made the right choice. And then when new information came in, of course corrected and reversed it, both of those situations where the right decision with the information that I had at the time. And so basically the lesson here is to make the best decision with the data that you have at that time. And don't be afraid to make a mistake and course correct. If it later turns out that you did something wrong.

Tim Bourguignon 49:21
That's music to my ears. Thank you very much. Where would be the best place to continue this discussion with you.

Ev Haus 49:28
So I'm probably easiest to get ahold of on Twitter. It's just at of house. I'm also on Facebook and LinkedIn if you want to look for me there. But if you want to jump in and challenge me on anything I've talked about today or tell me you know, how do we measure a good manager? please reach out to me on Twitter and I'd love to chat with you.

Tim Bourguignon 49:49
You've heard it. Do you have anything to plug anything on your plate anything we don't want to advertise?

Ev Haus 49:55
Absolutely. I would encourage all the listeners to come check out Zen hub. I'm obviously very biased in my, in my opinion, but I think it's a phenomenal tool. And if you're if you're a GitHub user, and you've never heard of us at least jump on the website and learn what it's all about.

Tim Bourguignon 50:10
Awesome, and we'll link to the show notes. Thank you very much. It's been a blast listening to your story, that was really cool.

Ev Haus 50:17
Thank you so much for having me.

Tim Bourguignon 50:18
And this has been another episode of developer's journey. We will see each other next week, bye. All right, this is Tim from a different time and space with a few comments to make. First, get the most of these developer's journey by subscribing to the podcast with the app of your choice, and get the new episodes automagically, right when the air. The podcast is available on all major platforms. Then, visit our website to find the show notes with all the links mentioned by our guests, the advices they gave us, their book, references and so on. And while you're there, use the comments to continue the discussion with our guests or with me, or reach out on Twitter or LinkedIn. Then a big big THANK YOU to the generous Patreon donors that help me pay the hosting bills. If you have a few coins to spare, please consider a small monthly donation. Every pledge, however small counts. Finally, please do someone a favor, tell them about the show today and help them on their journey.