Building a Culture of Accountability and Curiosity

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I am sitting down with Dan Langevin, CTO of Ideon, to talk about engineering culture of accountability and curiosity, among other things. Dan, welcome. Thanks for taking the time to talk to us today.

Dan Langevin: Thanks for having me.

Shane Hastie: A useful starting point is who's Dan?

Introductions [00:40]

Dan Langevin: I'm co-founder and CTO in Ideon. And Ideon is an API middleware company that connects insurance carriers and benefits administration and broker systems for the purpose of selling health insurance and employee benefits and administering those policies. You can think of us as a Middleware or a Plaid or a Twilio for the insure tech space.

Shane Hastie: What brought you to CTO and co-founder, what's your journey?

Dan Langevin: Prior to this, I was CTO and co-founder at a company in an entirely different space called Lifebooker, which was a marketplace for local services. Small businesses could advertise hours, mostly around some health and beauty services, gyms, that sort of thing. And they could discount their available times based on how desirable those times were. Think of an airline or a hotel kind of pricing model for local industry.

And my co-founder there actually introduced me to my co-founder, Ed Dirker, and Mike, who's our CEO, and we hit it off. He was looking to build something originally around doctor data. And as we built that out, we discovered there was a broader need in the insurance space for connectivity and took what we had already built and applied it in that space.

Shane Hastie: So the build, measure, learn, pivot.

Dan Langevin: Exactly. Yeah.

Shane Hastie: Cool. One of the things that we chatted about before we started was bringing people into a new organization. One of the challenges, we're in the middle of this great resignation and people are moving on and changing. And how do we onboard people well in a technology environment today?

Advice for onboarding people well [02:15]

Dan Langevin: There are two pieces that I think are really important. One is the existing team that you have. I believe strongly that having a committed, experienced and really externally impressive team really helps you to one, recruit and two, to onboard people quickly. We do a lot of pair programming and a lot of collaboration as people are onboarding. That's one really important aspect I think.

The other is having good system documentation, good documentation of your code bases so that the types of people who prefer to read on their own and learn that way, are able to onboard asynchronously on their own time. And that's actually become more important as we shift into more of a remote first where we previously, before COVID, everybody was in the office for the most part. We had some remote people, but it wasn't a huge part of what we did.

And now, our engineering organization is really entirely remote. Almost nobody goes into the office and most of the engineers we have don't live anywhere near an office. And so the documentation aspect has become really important for the asynchronous onboarding.

Shane Hastie: And building and maintaining that culture, the engineering culture of, as you put it, accountability and curiosity. How do you create that and what does it look like?

Building a culture of accountability and curiosity [03:32]

Dan Langevin: I say curiosity first. I think curiosity, the most important thing there is really who you hire. You have to hire people who are naturally curious and you have to have an evaluation process that finds those people and bubbles them to the top.

One of the questions, for example, that we use in our very first screen, it's a really simple prompt. It's just tell me about a system that you designed or helped designed that you're really proud of and why are you proud of it? The curious type of person will know a lot of detail about that. There won't be a part where they're just like, "I didn't do that part. I don't know how it works." They'll have dug into the details to figure that out. That's one thing.

And there's sort of two types of curiosity that we really look for. One is around how code works and domain, and some of the stuff that you typically think about for engineers. But the other is how does the code that we write solve the business problem? I think it's really important for engineers to be familiar with the business problems and the value that we're creating and how users are going to use products we create.

Maybe not quite to the same level that a product manager would, but certainly, to be able to explain it, the value of the thing that they're working on, even to a customer or to a prospect. We don't typically have to do that, but it's something they should be able to do, I think. That's on the curiosity side. That feeds into accountability and then predictability. Accountability is feeling accountable to deliver on the outcomes that we're trying to achieve as an engineering team.

Businesses need predictability in order to function effectively [05:06]

And predictability is the timeline for those outcomes. Business needs predictability in order to function. We can't say, "We're going to build X feature. We don't know what it's going to do. We don't know when it's going to be delivered and now go sell it." This is particularly important to us, we're in an enterprise B2B space, but it's really true for any organization.

Involving engineers in defining the business problem engenders accountability [05:25]

Dan Langevin: And you need accountability to have that predictability because the engineering and product teams need to be committed to what they're delivering. And be able to adjust it on the fly in order to hit timelines and create that predictability. That requires problem solving. It requires that curiosity that I was mentioning before, where the engineers really understand the problem. And it also requires you to give enough flexibility to the team in the solutioning.

We don't present engineers with, "This is exactly how this thing is going to work." It's more, "Here's the outcome we're trying to achieve. These are the, it must do this. It can't do this," that sort of thing. Like the guardrails.

Now, take what you know about domain, what you know about how our existing code base works and collaboratively with the product team, come up with a plan that's going to get us there. It's a different way than some organizations where it's really product team or a business analyst comes up with a very specific spec. And then just you do everything in the spec and hopefully, it gets done in the timeline that we agreed to. But I think that having engineering involved early on in the process just naturally creates that accountability because they're committed to it. It's their product that they're trying to launch.

Shane Hastie: That level of ownership, that feeling of it is their product that they're trying to launch, as you put it. How do you make that real for people?

Setting success metrics before starting on an initiative [06:48]

Dan Langevin: One thing that we do that works really well is we set success metrics before we start major projects. Meaning we're going to evaluate, we're building this new API, for example, that is targeted at this new market. Here's how we're going to evaluate whether we were successful in building that.

One way is, did we complete the features that we expected to? That's a small piece. And then the other thing is in year one, we're going to look at the number of users that we get to sign up. In year two, we're going to look at the amount of activity that they do. Maybe it's shorter time periods, but you get the idea. And then being really transparent about, did we hit those goals or not? And what did we learn?

And letting that feedback flow in to whatever we decide to do next. How are we going to iterate on the thing that we have built based on the feedback that we've received from having it in market? I think it's really important to close the loop there. The most demotivating thing as an engineer is to feel like you've worked on something for months and months, and then it never sees the light of day or it's out there and you don't know what's going on with it. You don't know if it was good or wasn't good, or you just never really hear about it again.

And I've had that happen personally in the past, and it is pretty demotivating. It's something that we try to keep a really tight feedback loop and let the team know when we've been successful and when we've had challenges. And how we can overcome them with new, with additional changes in the future.

Shane Hastie: Let's talk about these teams. What makes a great team at Ideon?

Teamwork, ownership and accountability [08:16]

Dan Langevin: I think ownership and accountability are really important. We like teams to be cross-functional and able to execute as independently as possible. Meaning that a team that's working on a problem. Our teams for us, we don't really have a design for most projects because we're an API company. It would be a product manager and then it will be an engineering lead and then some other zero-to-n additional engineers who are going to be on that project.

They'll have access to our implementation team, our ops team, other product and our marketing team. And they really, the engineering lead and the product manager are going out and trying to gather as much information about how are we going to solve this problem upfront? It's something that we think is really important is that the team is the one defining the way that we get to the outcome.

Outcomes typically would come from product leadership or the company leadership of what's our strategy? What are we trying to do? But once it gets down into, "How are we going to get there?" the successful team is owning it from there.

Shane Hastie: Why don't we explore the interpersonal aspects of teamwork? The buzzword at the moment is psychological safety, but how do you create that effective team environment?

Making the environment safe [09:30]

Dan Langevin: I think a lot of that comes from leadership. A lot of company culture, the tone comes from the founding team and the leadership team. I think that if you don't have psychological safety coming from leadership, it's very hard to build it at the team level. But at the team level, there are a number of things that we do through our company values, through the way that we give feedback, the way that our performance reviews are structured, to create an environment where people feel comfortable surfacing ideas.

We have a number of ways they can do that. There's in-person, there's asynchronous, there are anonymous types of forums where people can ask questions or raise issues. We're very focused on retros, either just regular sprint retros or root cause analysis type or any sort of system issues that we've had. Very focused on talking about process, not people when something does go wrong. And creating the types of forums and environment where people know that they can say anything productive and not be made to feel like it was a stupid question or a bad suggestion.

Shane Hastie: Let's talk about career growth for people. One of the things that we see over and over again and sadly, it's still prevalent is we take the best technologists. We decide that because they're the best technologists, they should be promoted. They've earned some advancement and we turn them into the worst people manager. How do we help these people?

Career progression does not have to mean becoming a people manager [11:00]

Dan Langevin: We have, which is pretty typical. I think a lot of companies do this. We have different tracks for senior individual contributors and managers. And the expectation is as a manager, you will do less coding the more senior you get. As an individual contributor, you will continue to basically do mostly coding, although you're on larger projects, you're leading projects as you get more senior.

That I think is the one really important thing that all companies that have large engineering organizations should do because you don't want the only option for somebody who does want to advance in their career to be becoming a manager. Not all engineers in particular are people managers and want to be people managers. I think that you're taking your best players off the field if you're turning them into people managers who are only writing code 25% of the time, as opposed to letting them go through a more senior IC route.

That's really important. I think that, at least from my experience, it's sometimes hard for people, especially who are fairly early in their career and haven't fully picked a path yet, to know which of those they want to go down. One of the things that we do is we make it really easy, especially early on, to switch back out of the team lead or engineering manager role back to a senior IC role or vice versa.

Make it easy to switch tracks [12:18]

Dan Langevin: It's not a one-way door when you make that decision. And that gives people the confidence to try something new. And then I can think of a bunch of examples where we've had people do that. Or we've had someone who I'm pretty confident is not going to like being a people manager, but really has their heart set on it and wants to try it and does it for six months. And says "This wasn't for me. I want to go back into my IC role." And that's worked out really well.

I think having a culture where people know that that's an option and they know that they will get an opportunity to build the skills that they're good at and the things that they want to be good at, really helps in terms of getting people into the right place in the organization. And also, in keeping people in the organization that we want, who if we didn't have as many options, may have gone somewhere else.

Shane Hastie: For the person who does find that they enjoy this, and they do want to move into that people management track, how do you help them build those competencies?

Building leadership competencies [13:15]

Dan Langevin: There are two pieces, two main components. There are some organizational aspects of people management, of just having a system to stay on top of things. And also, especially when you're let's say an engineering manager level where you're maybe writing code and you have 50% of the time you're doing your own projects and 50% of the time you're helping others.

One thing that we really encourage with people at that stage is just personal organization, keeping blocks of time to do focus work, blocks of time to do one-on-ones. Blocks of time to manage sprint planning and all the other responsibilities that are things that are newly on your plate often as an engineering manager.

And then, the other piece is connecting one-on-one with your direct reports and building rapport with them, understanding what their motivations are and how they need to be guided in their career. And that I think is something that is each person needs to develop their own unique style in doing. There's not really a playbook for it.

My biggest advice here is to just be authentic. People can tell when you're not authentic. And don't tell people what they want to hear, tell them what you believe is the truth and have their best interests at heart, as much as possible. And just really listen to them.

It's like any interpersonal relationship. You just need to be open and direct in your communication. And people don't typically leave jobs, they leave bad bosses is the saying. And I think that having a manager that you feel has your best interests is a really important thing for building a strong culture and keeping the right people on your team.

Shane Hastie: Cycling around a little bit to that culture. How do you retain a great culture as the organization grows?

Retaining culture as the organization grows [14:59]

Dan Langevin: It's hard because you get a lot of new people in. We've gone through a large growth spurt over the last six months or a little bit more than that, more than double the team. You're bringing in a lot of new people, they all have different ideas. We brought in people from a number of different backgrounds as well, not necessarily from the same technology stack that we use. A lot of different ideas about how things work.

I think the things that I have learned through that process are it's important to have an open culture, but also to show some level of direct leadership as the leader of the org. Sometimes you need to put a stake in the ground and make sure that the team knows what the directive is because when you grow really quickly, you can sometimes take in too many ideas and too many conflicting ideas. And they can become at odds and we have to pick a path and go down it.

That's one important thing. And that's going back to your original question. It's really staying true to whatever your organizational values are. Even as there's a lot more noise when you're growing and you're bringing in a lot of new people and ideas.

Shane Hastie: Dan, thanks very much for taking the time to talk to us today. If people want to continue the conversation, where do they find you?

Dan Langevin: I'm on Twitter, @dangevin. And my GitHub is also dangevin. Those are probably the best two places to reach me.

Shane Hastie: Wonderful. Thanks so much.

Mentioned:

• Ideon
• Dan on Twitter