Engineer or engineering leader? What’s the difference and where do you fit? with Corey Nichols of SonoSim

Transcript

Ledge: Corey, thanks for joining us today. Good to have you.

Corey: Good to be here.

Ledge: Can you give a two to three minute intro of yourself and your work for the listeners?

Corey: Yeah. I’ve been working with SonoSim for probably about five years now. We focus on ultrasound training and simulation software. Really focusing on getting med schools and individuals the best edge ultrasound education that they can have.

My time at this company, and I’ve been there since before there were 20 people in the company, that kind of spread out in multiple rooms of the company, and I’ve watched it grow to what it is now. It’s over 50 people now over a larger space. Working to really grow the team over the next year.

I started out as a software engineer, learning all the different aspects of the product. Helping design and build out a lot of the web services that we have as well.

I’ve seen all the sides of it. I worked in helping out with the support and all of that. Now I’ve moved into the Director of Engineering role, helping grow the team and coach others and help them understand all the different aspects of the product.

Ledge: Off-mike, before we started recording, you were talking about how there’s a big difference or lots of differences between being on the software engineer side and then being in the leadership of engineering.

You actually particularly resonated with that, but a lot of people go through that career juxtaposition where they say, do I want to keep writing code or do I want to get up a little more in the management realm?

How did you make that distinction and choice? What appeals to you on one side versus the other?

Corey: That is a very difficult choice. For me, going through school and then into my career, I always thought that I’d really be working just hands-on, very technical. But I found, as I started working with the teams – we went about a year without a Director of Engineering, a VP of Engineering role – I as gravitating to helping coordinate the different scrum teams and trying to motivate people to continuously improve. Focusing on getting them involved in various types of education and improving the quality of code and all of that stuff.

It ended up being kind of a natural fit. It wasn’t just overnight decision too, it was gradual. Gradually, I started taking on this responsibility and seeing that there’s a lot of challenges in coordinating and working with the people side of software.

Ledge: You said the team is obviously growing and you have multiple scrum teams. How do you divide labor across? It’s a product that serves a very important informational purpose. That this training is really important for all kinds of people in the field.

How are you arranging your product and engineering teams to address the different aspects of making sure that it has high availability and that it serves the needs of the customer?

Corey: It’s pretty hard to coordinate the different teams because we’re a fairly small… The engineering team itself is about 14 people, but that includes researcher & development, admins and internal infrastructure. Then there are engineering teams as well.

We have desktop applications, so that’s a little bit easier to carve out and get a group that’s focused on just supporting that application. Then we have a series of microservices on AWS. That one’s a little bit more cross-team. There’s system admin and some others that are helping build up that infrastructure and maintain a continuous integration and deployments.

Then we have another scrum team that’s set up to focus on all of the microservices and web applications that we offer.

I think the hardest part right now is, we don’t really have a team large enough to tackle everything at once. They’re really working closely with the product team to come up with those priorities, and just pull off the top priorities and those are the applications that are going to be focused on at any given point in time.

Ledge: I get asked a lot by engineering leaders how other engineering leaders are addressing the balance between ‘new feature, new feature, new feature, new feature’ and remediation and technical debt, in addition to QA, which is really staying ahead of the curve.

How do you build all those things in, and how do you allocate scrum time for technical debt remediation, because it’s not going to be in your backlog. How are you dealing with that issue?

Corey: I think that was a big struggle through 2018. Initially, it was just feature after feature after feature, and that’s what the product team wants to see. But then you start to notice this feature goes out but then you have issues starting to crop up. As that happens, it really becomes apparent that you need to take a step back. Focus on quality, building in the right processes.

Right now, what I’m trying to do with the different teams is build in downtime, so to speak. So I’m not planning from Day 1 on the sprint – although at the end of the day I’m working with them to just take in enough work, making leaving that extra day at the end to go through and make sure all of the right tests are in place, all the continuous integration system needs to be updated in order to support adding in new tests. That kind of stuff.

We can really take a minute to focus on those improvements rather than just cram in as much work as possible.

Ledge: Does the product team and the leadership have to be in the loop on how you allocate time in order to…

There’s budget implications. Obviously everybody wants 50 more features than you could ever fit in a given sprint. Yet, by not building the infrastructure properly, and by not doing QA properly, and even just looking back at technical debt, things you want to improve in the system at large, you can’t build that foundation after the fact.

How do you deal with that conversation in the board room, so to speak?

Corey: That was, I think at the beginning of the year, a lot harder for our team. It really took having a few things start to not necessarily fall apart, but you have a couple of issues that really impact customers. That allows us to actually point and say, look, there is a foundation that needs to be in place in order for us to really continue to deliver these features.

The more we build that up and the more testing that we can automate and build in, the faster we can deliver those products.

At first it might be a little bit slower, but once we actually get going with building in this actual continuous integration pipeline and focusing on quality upfront, in the long run you’ll be able to deliver a little bit faster and have an improved product on the other side, with a little bit more of attention to what’s going to impact our end customer.

Ledge: Yeah. Speed to market, everybody says that’s the number one thing. But speed to market with something that customers want and that actually works is the implicit understanding.

Corey: Yeah. That works. That’s the difficult part. You can deliver something, but if you don’t deliver something that works the way the customer is expecting it, then people will stop using the product.

Ledge: Absolutely. One question I ask all the engineering leaders is, we’re in the business of evaluating and sourcing and vetting just the very best software engineers in the world. That’s what we do.

We have a pretty strong heuristic for doing that. A big process. Many steps and our own way of thinking about that. But I like to gather best practices from the field as well.

So, I’m curious, as you’re building the engineering teams at your business, what are your heuristics for identifying the absolute best engineers that you want to bring on board?

Corey: For me, I think it’s really focusing on trying to find somebody who’s going to be adaptable and be able to really learn.

It’s a little bit harder to identify those things, because you can do lots of whiteboard problems and people we can sometimes solve difficult algorithms and be able to implement something really quickly on the board, but it doesn’t necessarily show that they’re going to be a team player really, working with others, wanting to collaborate and really focusing on getting the testing done upfront.

It’s trying to tease that information out during an interview process. When talking with engineers, I really want to see that they’re interested in learning new subjects and exchanging knowledge with the rest of the team. Being open minded to new practices and different practices. Not necessarily just rinse and repeat everything that they’ve done in the past.

Ledge: Which doesn’t necessarily match everything that everybody else has done in the past. So obviously that collaboration is going to be huge there. How about problem solving abilities? That comes up a lot. I wonder how you think about that.

Corey: Yeah. I try and come up with some questions that are not specifically programming questions, but try and think of something… There’s no way this person could have found and researched this or anything else . It’s some thought-provoking questions that are open-ended. Not necessarily a right answer, but just want to see how analytical can somebody be. How do they break down a problem into smaller pieces that are more tangible, more solvable?

It’s more trying to figure out how they work through the process as opposed to just getting to the answer.

Ledge: Agreed. That comes up a lot.

Well, Corey, thanks so much for coming on. Really appreciate the insights today. Thanks for sharing those.

Corey: Thank you.