it's a long one. So I've been Ah, I started, actually. Is, ah, hardware engineer at Apple back in 88. So I've been doing this for a really long time, and, ah, it's probably a longer journey. Then we can fit in this video, but I'd say probably early in about four years into my career, I realized that I was far more interested in the technology from a software perspective, and all the chaos and trouble seemed to be happening where the humans and the computers were intersecting and not so much about moving zeros and ones across motherboards and whatnot. So that was really when I began my software career, which is the one that I'm still in to this day. Since then, I've been started company since about 94 founded Cem. Some open source projects June was probably one of them, or notable ones was an early adopter for mongo DB. Even among the master one or two, Um

so morning console. So the role that I'm playing it morning Consulate VP of engineering is it's a multifaceted role, which is good. You will see that VP roles in technology org's can be very vertical. That could be their specific. And so sometimes you'll you'll take a VP role, and you're just so boxed in and focused on an area that it's just a very specific, limited set of skills that you bring at morning console is definitely more of a generalised role. So I would say in the two years that I've been in morning consult, 2018 was primarily about, um, strategy. You know, where is winning? Where is the end zone? And what do we have to do to get there? And 2019 was mawr about laying the infrastructure and, you know, building that that DNA often engineering organization so they were ready to scale because you can't have one person leading an entire army of engineers, right? That doesn't that ends very quickly in a in a successful way, so you have to make sure a delegate and grow. So that was pretty much the focus of 2019 2020 has been all about growing these teams and launching MAWR and more parallel teams to get more work done as quickly and efficiently as possible. And that brings in a different, different, uh, set of muscles to bear because you're your number. One goal at that point is to try to make sure your team's air coordinated so you don't have what I like to call the ready Fire aim experience, where Team one is building something in. Team three has already been building it for two months. So there's that aspect of things on the technology specific side of things. The skills that I'm bringing to bear when it counseled are are mawr again. It's at the VP level. It's more strategic, less necessarily hands on keyboard. It's more about. For example, we're all pollock lots being that we all program in many languages until tool kits and, ah, with a younger organization. That tends to be a challenge because startups will become, you know, hello world good at 10,000 things and aren't really good at any one particular thing. And so my message early on was, Let's pick a couple technologies and get good and once once we were productive with those technologies, we could then grow to play with the more abstract stuff. And for us it was kind of a practical choice of full stack JavaScript and go for backend like shared services, heavy lifting, data transformation and so on. And on the JavaScript side, we needed to pick up front and framework, for example. And although I've been playing around with view, I kind of taken fond of you. It seemed practical to us that all of the engineers that we were interviewing had react experience. And so we made a very pragmatic choice. Ah, and not necessarily a dogmatic one and just said, Let's let's standardize on react because that seems to be where all the talent is. We don't want to lose a month of productivity for every engineer that comes in to learn some new special framework that only morning consulate uses, for instance. So, um, the strategy there was to be as practical as possible with our tech stacks. Also, I'm responsible for building out the operations side of engineering at morning, consult. So talking about how we build all of this infrastructure, for example, in Public Cloud on AWS, for instance, where you know, you automate the experience that that the developers right there code, they get push and that's it. They're done. From that point forward, everything should be automated so that no humans air accessing anything on cloud infrastructure. That gives you a very repeatable, scalable production environment. It means you can automate your testing and then going further up that stack, make sure that the developers are living in an environment that as closely as possible mirrors what production and test looks like. Um, let's see, Work hours. We have really good work life balance that morning console. I actually typically stick to me on 50 hours. Sometimes I'll burst. I might have work to do over the weekend, you know, Might be lousy weather and no, no domestic duty. So I'm gonna hide in the basement, right? A bunch of documentation or do bunch of testing. Generally speaking, we we keep pretty good hours. That said, I've been in start ups and VP rules where I was easily doing more than 100 hours a week and, uh, not recommended. I guess early on in your career, it's great because you learn a lot and you move fast but yeah, always always have a work life balance. There was burned out engineers of reproductive engineers either, And, uh, regarding toe time spent during travel and work from home. You know, with quarantine. It kind of puts a ranch in. All of those plans were fully remote, just like everybody else at this point. Um, normally, I don't do a lot of travel. We kept most of our engineers in our D C office, our headquarters. We have a very collaborative, chatty culture at morning console. So it's It was common to find engineers huddled in the corner over whiteboard, drawing diagrams, trolling each other about who had the better idea. Uh, and it's hard to do that via remote. That's something that we've had to learn in previous org's. Sometimes the VP role will include. You know, evangelism means speaking at conferences, going to attending, to meet ups, doing recruiting type functions. So sometimes you'll see some travel there. But right now it is definitely not a whole lot

Let's see. So one of probably the best learning experiences that morning council has gone through, which I signaled as soon as I got there. Waas the need to have, ah, a product driven engineering organization. And it's something that probably doesn't get enough. Uh uh, enough conversation about and I think it it does definitely deserve it because you will see startups where engineers are building things and they launch it and no one wants it or they launch it and everyone wants it. But no one wants to pay. And that's because the engineers weren't being driven by a pure business side stretch strategic view of what this startup was needing to build. So when I got to morning Council, it was immediately apparent to me, Hey, we need to grow the product organization as fast as we can. Uh, engineers warning console are are committing code and doing code reviews within 48 72 hours after they start a product person. It takes 30 60 days toe on board because they need to learn the you know, the politics, the stakeholders, the business, everything else, and it's it's a lot more to digest. So getting the product teams to grow first before you bring in all of the engineers is always a more productive experience. Plus it make sure that your engineers air Onley building things that are relevant to the business, and that's a really important skill. Whenever you set out to build something, you have to let that inter entrepreneur and you ask that question. Do I need to build this? And ah, and that also reaches out to another thing that I see is is build vs by you know, you need to be practical about what you're putting together. If there are 10 open source projects out there that do exactly what you want to build, and you should ask yourself if you really need to build it right, the joke I've always made was, you know, we created computers to do all of all the dumb stuff so we could do the fun stuff. Don't flip that upside down, right, and, ah, and as engineers attack techies, we have that habit, right? Were wired to solve problems, to look for trouble because that's what we want to solve. Want to fix things? Sometimes we just look for problems that don't need to be solved