Jeremiah Ivan shows us what it looks like to use the startup mentality to run a larger corporation.
Merrill Corp is a financial data manipulation site used by other companies to help make financially sound decisions. To run successfully, he discusses what it takes to create a desirable team mentality.
In this episode Jeremiah reveals the components of how using a tech road map helps him to accomplish his goals as the VP of engineering at Merrill Corp.
In the words of Jeremiah “Marrying the tech road map, with the product road map, with the personal develop road map” are all equal pieces in the process.
Carlos: Alright, Jeremiah, thank you so much for coming on the show. How are you doing today?
Jeremiah: I’m doing great, so great.
Carlos: Alright, Jeremiah, and the first thing I want to start off with is first of all thanking you for taking the time to join the show. You and I had a quick conversation in the past kind of our pre-interview. Part of our process and I thought you would be a great fit because you have a specific set of experiences that I think other people might find interesting. Just a way to get started, tell me a little bit about yourself and how did you end up in tech?
Jeremiah: Sure. I really started when I went to college interested in doing Java. However, I was 18 and a little crazy so I didn’t went for a lot of work into it so I ended up dropping out of that for a little while. Luckily, I was at Carnegie Mellon I started studying language and really got into Computer Science. So as I settled down and became more mature I end up discovering a good interest in Computer Science really as almost applied language, as applied linguistics if you will of creating something. You know, basically through these words and symbols and I fell in love with this that way that in problem solving. And that was in the 1990’s and I really got too from there. I was an engineer for years working on various projects usually in startups. And then I got involved in leadership only on the last about 7-10 years.
Carlos: Well, 10 years is a long time and that’s what’s interesting because some of the people that might be listening maybe are not there in their career path. It’s interesting to see how one goes from maybe somewhat of a mixed background of in the arts and then you’re part of leadership of a corporation in the tech side so before we get into your specific role what is. I know today you’re working at Merrill Corp, right?
Jeremiah: Yes, I am today. Merrill Corp is an enterprise, this is my first non startup. Merrill Corp is an organization that’s been around for 50 years, more than 50 years, in the financial services area. They got into software about 16/17 years ago into the virtual veteran space doing a lot with secure document collaboration. I came here along with two folks I originally worked with years ago at Snagajob. Really we’ve all been doing startups and the curiosity for us is Merrill offers such a great opportunity in a market space as far as with the investors and where we could go with secure document collaboration. What it’s like to take a startup mentality around technology into an older business. You know, when we got here deployments were happening every 5-6 weeks. And now we’re doing daily deployment. There was no automation to speak of and now we’re in the cloud and we’re doing regular test automation and deploys. That’s the exciting piece how does some of the techniques people used as startups to transform an organization apply or don’t apply to a larger older enterprise.
Carlos: Let me ask you one of the biggest challenges I’ve seen with other leaders that come from this kind of a startup world or used to more nimble and easier to maneuver companies when you come in to the company as a VP of Engineering what’s your biggest, you know, how do you get passed that friction? How are you able to move the organization into the direction that you know I should go but at the same time you know it is way more rigorous than do a startup.
Jeremiah: Definitely, well in any situation of a VP of Engineering whether you’re in a startup or you’re in an enterprise like this you have to be really diligent in your interviewing. At that leadership level you are really interviewing that organization as much as they are interviewing you. Therefore, you really clear that how you handle conflict, the kind of mandates you’re looking to have when you come in. So early on we wanted to make sure what kind of stack we’re looking at building? What kind of budget would we have to make changes? What kind of special dispensation would we have to make changes that would directly impact compliance, that would impact things like… You have to look at those things early as almost part of your requirements, right? Again, I think this is where it’s really important when you’re a VP of Engineering, you know, your role is a product role. Your product is Engineering’s performance. Their ability to do discovery in such a way they could be very clear about the value they are pursuing. Their ability to do delivery wherein, “Hey look we say we’re going to do X we deliver X.” And we’re really clear on how we’ll measure that whether that’s technical performance. If you are proud owner of engineering performance about velocity or quality or stability, so you have to really clear on that. I think it’s even more so important with an enterprise because they just said if they have a built up of all these rules and we’ve always done it this way. So you’re doing requirements discovery during that interview and really during the first period of 60 days you are there.
Carlos: One of the things that come to mind when talking about somebody who had done everything in between and kind of the junior role and the senior role is this transformation and maybe growing into a role. How important is it for you to take this into consideration with new people that you hire. Let’s say you have an open role for an architect. Who fits that role, right? Do you look for somebody who’s got experience as an architect or do you find somebody who you could grow into that job and how do you do it?
Jeremiah: Sure, and I think it’s a combination of say “Why”. You have to look at your team in terms of almost chances of capability and experience, so for example, when you’re working with an enterprise organization that’s a different mindset around developing for it so think of it like this. In enterprise some folks will never allow to look at the staff in production. We’re allowed to look at their code in production and see what the logs are speaking out. Wow! That’s going to mean that there is whole avenues that they aren’t experienced in, operation readiness, monitoring, areas that just they weren’t even allowed to do. So when you think you’re bringing people on. You’re going to be bringing people on who may have strong capability in engineering but not that level of experience. I think you can bring on and we certainly have because we working with folks that are great developers but from an enterprise background, that have capability but not experience. You have to leaven that with folks that are experienced. When you’re thinking about a team, wherever you’re trying to go and every situation that I’ve been in it’s about transformation or moving the needle in an organization to improve performance. You’re going to have a group of people that you find there they are strong and capable and they’re going to need to learn something. That is part of the reason why you’re there is to teach it. Maybe you’re teaching how to do architecture. Maybe how to be operationally ready and aware, and how crap to run both. Maybe you are but chances are you cant’ be the only one doing that teaching so you have to figure out how you build up that other layer. That chance of people who are not only are capable but also experiencing the way you’re going towards. So what we talk about here is we’re looking to build a capacity where we are operationally ready, production ready microservices and we are actually using the book of Susan Fowler, Production Ready Microservices right here at Merrill and really using it as a bible. In addition, we are pulling in folks that had been there and done that so that we can build that so when you say about, “Hey, we’re hiring someone for a senior role do you look for a mix of talent?” Yes, but not in that person, right? You’re looking to build that mix in the team of people who have been there done that and those who are hungry and capable maybe has been there and done that. And then I think you always have to have a lot of really good juniors because these folks are hungry and they haven’t learned maybe anti patterns. They haven’t learned how to do the wrong thing yet. So those three chances I think are what an enterprise is or a startup.
Carlos: One of the things that I’ve seen that are relatively hard. I want to say it’s hard but it’s a less clear path in setting up expectations and accountability, right? The structure for both for accountability and expectations, you know, in different teams I see that work differently. It’s very subjective. It will depend on the leadership style, the person. What’s your take on this because as you’re talking about bringing in or growing somebody into a role or again that mix of skill set. How do you prepare them? How do you guide them through this setting of expectations and goals they need to meet. How do you usually do these?
Jeremiah: Sure, well there is nothing better than pushing your codes frequently. So at a very tactical level when you’re talking about expectations and accountability the first thing you try to do is setup a process where in an environment so we a dev stage in production. I mentioned how we’ve got a team just in a matter of months selling 5-week deploys to daily deploys. Well, the way we’ve done is we started out with automated testing and then we started out with a dev environment that gets built regularly. You know, that’s the part that’s actually continuous integration if you will. There is a PR system that happens and then ultimately it passes some automated checks, it gets merged and it goes out to a dev environment for a larger set of Capybara test run. And you know what it then fails sometimes. And when it fails you got to make a correction so some of the accountability you want to try to learn before the alert goes off in production. So if you’re going out daily in production or if you’re just at a point where you’re going weekly of production, you want to increase that kaitens in dev stage. You want to treat those environments seriously. Have the same kind of monitors and dash board. You think it’s almost like training camp for a sport if you will. You want to sweat and hurt yourself in July so that in the fall, in the winter when it’s the playoffs you’re doing well. That’s been helpful in learning or working muscles where people may not have their accountability and that’s true not just for folks that haven’t had an opportunity to actually support code in production but also, whether they are experiencing that or not, they could be juniors as well. People that are coming in out of code academy or out of college where keeping it built and strong and stable just wasn’t something they had experienced.
Carlos: I think that one of the interesting point that you just mentioned is the whole notion of; I don’t want to call it practice but somewhat of that working the muscle, right, practice and getting better at that because you’re constantly improving. How do you deal though with those folks that are as you said out of code academy and sometimes younger folks that tend to want to deal with? Maybe the word is not younger but maybe more junior folks want to experiment with the new tools, some of these new frameworks as you see we have. We are in the renaissance of frameworks. How do you balance that desire to experiment and production stability.
Jeremiah: Oh yeah. Well, you know, and that happens or just polyglot. What we try to do when people say, “Hey, I have a great idea for a new framework”, or even in the case of microservices, I have a great idea for a new microservice. We want to try expose that to other developers to say, “Hey, look”, in Susan Fowler’s book she talks about almost like an rtnt will for microservice to say, “Hey look, I think this new microservice is necessary here are the things that would do.” In confluence or whatever your wiki is you would have request for comments on that send to people and say, “Hey, you know what actually it looks like you will overlap with this service. Why not just do your work here?” When it comes to new frameworks and new tools I want people I think you need to in your infrastructure and your dev ops to go an opportunity where the UI team can try out a new webpack. They can try out some new modules and some new libraries, so you want to try to build in some separation there. It’s a combination of pushing the notion that if you have an idea you have to open it up for comments and then show how. And this is really good training for juniors, people like say, “You know, why do I have to go through this crap? I really want to use this fun new cool thing.” I really want to get to them at that point to say, “Ok, one day you are going to want to be a senior engineer or maybe an architect or God forbid you’ll follow the dark path and you want to be a manager.” You’re going to need to be able to make a tech roadmap, right? And as much as you, and I will say like I’m pretending I’m talking to seniors, much as you may bitch about, “Hey, product doesn’t give me great requirements and I don’t understand what you want me to do. Well, you can’t give me a Nebula’s tech roadmap or you’re going to this wonderful upgrade to this new library but you can’t tell me when you’re going to be done. Or you can’t tell me why it’s so off other than it looks cool in the blog article.” Look, I want them to do a couple of things. I want them to open up so the greater group why I think it’s a great thing to do and be specific about what engineering performance will it change. Will it change velocity? Well, we can measure that. If it’s going to change performance, we can measure that. We can run some JMeter scripts now and then pick one small area where you put this library in and then run them again. Show me that it’s it, because now you’ve got a case to make more stories to put this library out there. Does this going to improve quality? Maybe you got a better way to do acceptance test or mocking. Great! Let’s pick an area to do that and then two sprints later let’s see that there are left bugs in that area. So you’re still on their side. You’re still saying, “Yes, I want you to go out and find new ways of doing it but we’re going to hold you to the same level of accountability that you want to hold product, the product owners and the UX folks too to prove that what you’re asking us to do is worth it, that it’s going to make an impact.”
Carlos: It makes sense especially because you want them to be cognizant to the process, right? You don’t want them to just say, “Hey, I want this because of that.” It’s good for them to get the big picture, to get the context.
Jeremiah: Definitely. One day they are going to be making a tech roadmap and that’s the questions they have to answer is; you know what it’s either comes down to velocity, quality, stability, performance, speed. Those are the things you are impacting and that’s why we make tech decisions, that’s why we refactor.
Carlos: Tell me a little bit more though about your role of VP of Engineering. It’s somewhat nebulous in the sense, a cool word that you use a second ago and I thought that I think it describes that name because I’ve seen VPs of Engineering do things in different way. Like some completely different roles in one company versus another. Can you give me a little bit of a flavor of the structure? What does a VP of Engineering do versus other roles in leadership?
Jeremiah: Sure, yes, no problem. When I was a VP of Engineering for Camille at Rent The Runway I had an opportunity to be part of a VP of Engineering group and in that city and folks were there from Pandora, and a number of different spots. I Remember people would sit around and go, “What exactly we do?” And part of that was a joke; a part of it is true because it’s a role that can sometimes be in between. For me it is really about being the actual product owner for engineering performance. I think in that role you’re the person that interfaces most of the time with the product organization so you’re about where they want to go, right? And you’re really trying to hire and train up the team to make technical decisions that deliver the quality that we want to see the quality improvement, the velocity improvement, and the performance improvement delivering value cleanly to the clients. So yes, you’re participating in what value may look like. But you’re not the product person. You’re not the person that also makes the decision about what the customer is going to want. But you are the person there to contribute that decision and most importantly to say this is how we will cleanly execute it. And depending on the size of your organization, right? If you are a very very small startup and maybe used to handful of people so you may be making these decisions yourself a lot. In a large organization you’re really trying to scale and you may have couple of directors that are really helping you with that. But a VP of Engineering role is certainly is the role I’m very happy doing. I think doing the C level role is just well it’s a whole other fish. The thing with the C level is like saying you want to be married to who? So like young engineers say, I want to be a CTO one day, and I say that’s great but it’s like saying I want to be married. Who’s this person that you’re marrying? Because this C level you’ve got the board, you’ve got the investors, you’re managing sideways. As a VP of Engineering you would know I think in the best case you’re kind of the XO of the ship. You’re the Executive Officer. You’re making sure, you’re debugging your organization if you will but that’s one of the top things you have to do as a VP of Engineering is you’re there to debug the organization. The organization as a whole, not even just engineering, but as a whole you’re there to figure out what bugs and in the communication of the organization certainly specifically how we communicate as engineers and how we select our tech roadmap items. But you’re debugging the organization so you can get that superior engineering performance, and you’re really trying to marry that tech roadmap. You’re absolute ideal situation and barely ever get to hit it, right? But you elegantly marry the product roadmap to the tech roadmap, ok, and to the personal development roadmap. You are able to find the right thing that product wants to do and you marry that to the areas you need to refactor so almost the new features of the sugar that helps the medicine go down. Along the way you find the right combinations of senior talent, junior talent that want to live on the senior side and learn on the junior side. Then that’s like killing three birds with one stone.
Carlos: “The sugar that helps the medicine go down”, that’s a first one. I love that one. Alright, well, Jeremiah I think this is really great advice for everybody. I have three last questions for you that are a little bit more on the personal side. So what advice would you give let’s say yourself if you’ve ran into yourself 10 years ago or 7 years ago. What’s one thing that you have learned that you didn’t expect to learn but now you know it so you would tell yourself?
Jeremiah: 10 years ago, I would say, “Well, just get out of that relationship.” No, I’m just kidding. Let’s see, so for work right? You know what’s interesting if I look at myself 10 years ago, so 10 years ago I first started experimenting with this dark side of engineering management. I really took it deeply seriously and you should take the course seriously, but in the wrong way. I just stressed myself on it. I’ll tell you, Carlos, my history in the beginning was I was Senior Engineer. I went to engineering manager and I was given the clipboard. My boss at that time was like, “Hey, you know what you’re not ready to be a manager.” He was right, ok, so I went back and I was an engineering lead again. I was a tech lead again. And that was good time holding the clipboard and then I came back I became a manager again and it’s like I became a director. In that case, I remember there were two people. This is back of the shift where people still thought it was ok to play assholes. And thanked God we are past that, we hope we are. It was just not acceptable. And I said, these two individuals had to go but I had an old school manager and that person say, “Hey, no they don’t.” So I took a step back again. I would say during those times I felt bad about it. When I look back at it each of those times whether I was “in the rise” which I was in the second time or hey I certainly did deserve a step back and go back to being a tech lead were some of the best times ever. I would say if I would give myself advice as someone who is just starting to become an engineering leader is you know what, do not think that taking a step backwards for a little while and getting back to the trenches is that at all. Not at all. It could be very valuable especially when you’re starting now. I wish that more people did that.
Carlos: Yeah. There’s somewhat of desire to move fast or move forward too fast and that usually can lead to problems. I think that’s great advice. A little awhile ago you mentioned a book, maybe that would be one of them, but what’s a book your would recommend on some of these subjects we talked today?
Jeremiah: Well, Camille Fournier has just written a great guide to be an engineering manager. And I can say that she’s been one of the best bosses I’ve ever had and I could definitely hardly recommend that book. I would say that again for folks that are working with getting teams ready to work in a modern operational ready way. I would hardly recommend Susan Fowler’s Production Ready Microservices. A lot of teams are exploring microservices. I would add one other book there. This is an older book and this is Michael Fisher and Martin Abbott’s book — The Art of Scalability. And the reason why I add that is this is the third company I’ve been to where they started something with microservices and they go, “Oh no, what we will do?” And it’s usually because you have big old macro services and little baby nano services. Services that do way too much and services that do way too little. I’ll give you an example, here at Merrill when we came in they had tried to get to microservice glory land and one of the issues we do documents, right? So there was a big old honking service that creates all the metadata when you’re going to copy a file so it creates it in Mongo and say here is your file and that was a little teeny tiny baby service that just does the blob copy of the file. And we sat down and we used that as a teaching and I would say, “Hey look. What situation are you in?” That little teeny tiny service failed, that blob, the files isn’t actually copied. But for some reason you want the quiet and still think it was, and that metadata was created incorrectly. Why would you want that? And that’s why I moved to Art of Scalability. Art of Scalability talked a lot about distributed systems and specifically around swim lanes. I really do encourage teams when they start looking at microservices to not just think of it as an extension of object-oriented programming. Not saying it can’t be philosophically but really when you think of breaking down activities into granular services that you can have accountable to a team. It’s so much better if it’s from the customer’s perspective. So if you’re talking about a copy action for the customer that’s all one thing. They don’t care if you’re making a record in Mongo and then copy in the blob, that doesn’t mean anything for them. So if those two things are what it takes to copy those two things should be together. That’s what I love about the Art of Scalability it really centers on swim lanes that covers management and issues of the day.
Carlos: We’ll definitely have those books in the show notes. Curious, which of those is making a bigger impact on the day to day today.
Jeremiah: Well, personally for me and for the manager’s, Camille’s book. I think Camille did a terrific job talking about managing. I would also recommend again, organizational thinking, see Wodtke’s book of Radical Focus. Really great, she covers OKRs but she also covers what it takes to focus an organization. So if you think about the actual human element of managing, again organization and getting people ready, I would say it is Camille’s book to engineering managers, and Christina’s book around Radical Focus, and then I would say the great thing about Susan Fowler’s book about production ready microservices is it’s both the technical and the human parts. She spends a lot of time talking about what it takes to be production ready in terms of like you’re on call. How do you handle on call? How should your alerts be set up? That’s real rubber hits the road stuff and then for the pieces of how do I design these services so maybe not that many alerts will fire then I would go to Art of Scalability. That’s how I order to get ourselves teams, I give out the Radical Focus and Camille’s book on Engineering Management to our leaders, and then we’re actually doing a book club right now with Susan Fowler’s book, and then we would go to Art of Scalability after that.
Carlos: I love that. I mean, it seems just because how passionate you talk about those books I think they’re going to be great. I’m going to check them out myself and hopefully any of the listeners.
Jeremiah: Oh yeah. Susan’s book is just a great one to start with productive microservice as for a team as far as, hey what to worry about. It’s almost a recipe book. If you haven’t read Camille’s book you would love it.
Carlos: I’m going to check it out. So Jeremiah the last question, probably the most important, so first of all I try to use this question as a way to sometimes what happens is that people that are listening in end up saying, “You know what, I want to work with this person. How do I get in touch?” One is are you guys hiring?
Jeremiah: Well, goodness we would love that we are hiring like crazy, ok. We are hiring again, look, we are looking for people who can. Let me tell you this, I’ve got a great group of people right now that are hungry and want to learn. We’ve already got that being dedicated and passionate is a must have so we’re looking for people that can mentor and we’re great with remote by the way. We’ve got some of the best towards… We’ve got several Cloud Foundry, Spring Boot, Java Microservices. We’ve got web applications right now in Angular 2 but with TCF, where you can put tons of different applications on there. We got Elastic, Mongo. We’re going to be getting into AWS with Snowflakes for analytics so we are looking certainly for those who have maybe, when they hear about Susan Fowler book and go, “Wow, that resonates with me,” or Art of Scalability and they’ve done some microservices work or some dev ops work. You reach out to me, jeremiahivan@linkedin. You can see some of my background and we will get chatting. We are good at remote. We’ve got investment and what we really want to do is build a team that you will be proud of and code that you’re proud of.
Carlos: With that, we will also have your link to your LinkedIn so that people can get in touch and hopefully we get some candidates for you.
Jeremiah: I hope so.
Carlos: Well, Jeremiah I really appreciate you coming on the show. It’s been a wonderful interview. One of the key things for me about this interview was seeing how the lessons you’ve learned along the way. Not only the senior level stuff that you’re doing right now but also how you’re able to put together to and to like your previous experience plus the actual senior level work that you’re doing today, and I think that shows. It’s really exciting to have you on the show.
Jeremiah: Well, thank you Carlos. I really appreciate going over with you and I hope everything goes great for you this coming weekend.
Carlos: Alright. Well, thank you so much, Jeremiah. Hopefully I’ll see you soon. Maybe I need to come up and say hi.
Jeremiah: It’s the right weather in Minnesota right now, come on up.
Carlos: Seem like similar to Miami weather so I have to check it out.
Carlos: Alright, Jeremiah. Thank you so much.
Jeremiah: Take care, Carlos. Bye bye.
Carlos: Bye bye.