‘Pair Programming, Remote Work & Developer Well-being’ with Eric Heikkila, Technical leader at Ford

This blog was originally published in the Typo blog.

In the latest episode of ‘Beyond the Code: Originals’, host Kovid Batra welcomes Eric Heikkila, Technical Lead at Ford with a rich background in organizations such as Arbor Insight, Gene Codes Corporation, and more. Their conversation revolves around ‘Pair programming, remote work & developer well-being’.

The podcast starts with a fireside chat with Eric, giving us a glimpse into his journey. As the conversation progresses, he delves into the transition from working at a startup to his current leadership-cum-IC role at Ford. Further, he shares effective strategies for remote team management and the pivotal role of pair programming and DORA metrics in ensuring team success and developer well-being.

Eric concludes by offering parting advice to the audience, emphasizing honesty, embracing failure, and learning from mistakes.

Timestamps

• (0:05): Eric’s background
• (0:35): Fireside chat
• (3:38): Challenges faced in transitioning to a leadership-cum-IC role
• (6:03): Daily tasks and challenges as the Head of Software Engineering
• (8:25): Managing remote teams as both a leader and an IC
• (10:40): Remote pair programming vs. working individually
• (13:04): Defining the success of an engineering team
• (14:47): Motivating the team by leveraging metrics for leaders and ICs
• (18:58): How to ensure team well-being and developer motivation?
• (21:18): Parting advice for the audience

Links and mentions

• Eric on Linkedin
• Kovid on Linkedin
• Listen on Spotify, Apple Podcasts, and Amazon Music

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has 30 years of engineering and leadership experience. He has been the founder and ex-CTO of Arbor Insight. Currently, he’s working as a Technical Leader at Ford. He’s also an active Modern Agile community member. Welcome to the show, Eric. Great to have you here.

Eric Heikkila: Thanks. Great to be here.

Kovid Batra: So Eric, thanks a lot for taking out time and coming to the podcast, sharing your thoughts with the community. They’re really looking forward to it. But before we jump into that, we want to have a quick fireside chat with you to know you a little more. Are you comfortable with that?

Eric Heikkila: Absolutely. Yep.

Kovid Batra: All right. All right. So let’s just start with your hobbies maybe, outside of work. What do you love?

Eric Heikkila: Sure. I love building things. We do, you know, all day is mental work. So, doing things like, you know, woodworking or putting up drywall, even painting, love doing all that. Just something tangible that, you know, after all day working on stuff that doesn’t exist.

Kovid Batra: What was the last thing you built?

Eric Heikkila: Recently I took up leatherworking. So I built a prototype really for a dice pouch. My son is an avid Dungeons and Dragons player. He’s at college right now. So building him something to take with him to his gaming sessions.

Kovid Batra: Oh, that’s so cool. Perfect. All right. Tell us more about, something about your life, some life-defining moments.

Eric Heikkila: Yeah. I guess for me it was right after 9/11, I really wanted to just, you know, drop what I was doing and go to New York and help out. But I couldn’t do that. I have a small family, I had a job at a startup as it, as it were. I found out a company in Ann Arbor was working on DNA matching software. So a fellow I used to know, got me an interview there, started working there, and then spent nine years working on software to not just do identification of 9/11 victims, but also to help fight child trafficking using forensic work, used to help, like in the Thailand tsunami. And that’s when I discovered I could use my skills for, you know, it may sound corny, ‘for the greater good’ as it were. And so since then, I’ve always kept an eye out for any of the opportunities that come along to make sure that I was still fulfilling that, that need to, uh, you know, help not just, you know, someone with a counting software, but, you know, somehow contribute to bettering everyone.

Kovid Batra: Oh, that’s so nice. Great. We’ll definitely talk about this more.

Apart from that, like it’s been almost 30 years into engineering. I just want to know, like, how was your first experience with coding or maybe your first experience with your computer? Tell us something about that.

Eric Heikkila: Yup. So my dad was an elementary school teacher and when I was seven, he brought home an Apple II, uh, to do grading. They gave him to do grading. And I was just fascinated. And so I bought a book on quick basic and taught myself how to write code. It was really terrible, but, you know, I was able to do, make a character generator for Dungeons and Dragons. Cause you know, that’s where my son gets it from, I’m a big gaming geek. And so, that was, that was my first foray into that, getting the computer to do all the dice rolling and then eventually print out all the character sheets. I wouldn’t have to write them out by hand.

Kovid Batra: Oh, that’s so nice. Perfect. Thanks a lot for sharing all this with us. Now I would like to move to the main section, where I would want to know your journey from a tech founder at Arbor Insight and then moving into a leadership-cum-IC role at Ford. So tell us about this transition, like what you used to do at the startup when you were working there. And then now you have transitioned to this leadership-cum-IC role. How is it different? How is it better? How is it bad? Just tell us about that.

Eric Heikkila: Sure. Yeah, it was definitely a transition. So at the startup, which was a lot of nights and weekends and all the time I wasn’t at my day job and we had a fairly small team, so I wasn’t just setting, like building roadmaps and, and setting technical direction, it was also, I had my hands in the code as well for a lot of it. But then moving from, from that to not just another programmer, but certainly not a, you know, not high up in the executive food chain, say at a large company like Ford. Definitely took a bit of time to get that mindset of, yeah, I’m not setting the direction technically. But their team is really good. Our leadership is very supportive. So I’m still able to bring in ideas and techniques and tools and say, “Hey, we should try this. We should try that.” I’ve got the leeway to experiment with on my team and then bring that to the broader technical leaders. You know, once I’ve kind of vetted it with, you know, on a team, a project and go from there.

So that transition was, you know, interesting in a number of different ways, but while I’m, you know, not at the top of the food chain now, it’s also a lot less stress because I’m not at the top of the food chain. So it was a nice kind of, you know, mental break to get back into more just, you know, more day-to-day coding and still making technical decisions, but, at a smaller scale than at the, uh, like the CTO-level.

Kovid Batra: Makes sense. So basically, all these years where you have worked, you wanted some break from the stressful situation or stressful work that as a CTO you would be doing at a startup. Now you wanted to move to something which was less responsible, right?

Eric Heikkila: Right. Yeah. Yeah. And the, and our, our startup had gotten acquired. So it wasn’t good to stay with that company in particular, but, yeah, I definitely needed something a little more stable for a while anyway.

Kovid Batra: Totally makes sense. Perfect. So tell me more about your role at Gene Codes Corporation, right? You were Head of Software Engineering there. What exactly were your responsibilities in day-to-day and how did you used to execute your routine, the challenges that you faced at that time? Can you tell us more about that?

Eric Heikkila: Sure, sure. And that was the company where I was doing the DNA matching software previously. I had left explored some other, other jobs and then ended up going back to that company after the President reached out to me and said he needed some help. One of the really interesting challenges was only two of us were in the same time zone and the rest of the dev team was 8 time zones away. So there’s a lot of, you know, get up at six in the morning, get into work, have a couple hours of overlap time to go over what the team had done, you know, the previous day. And then I’d spend the rest of my day working on technical feasibility of what they were doing and like how they could move forward to the next step and what the, you know, direction to give them on the stories that they were going to pick up when they came back online. And then at the end of my day, I was offloading that to them and then going home and, you know, coming in the next day and finding out how it went. So that, that lag was definitely interesting to deal with. That was pre-COVID too, so we weren’t used to working remote, but, that certainly helped me anyway, when we transitioned to more of a remote work environment, having that experience with a team, you know, many timezones away.

Kovid Batra: I think still, I mean, a lot of companies were already before COVID were working remotely, and post-COVID it has become even more normal to have a remote team. But I’m sure you have been doing that, now at least at Ford it’s not a remote role, right? Before this, you have been in a remote role, right?

Eric Heikkila: Currently Fort is, is remote.

Kovid Batra: Oh, that’s also a remote role?

Eric Heikkila: Yeah, yeah, it’s all remote. We do go into the office on occasion, if we want to do like some whiteboarding in person or get a couple of teams together and, and brainstorm some things. But day-to-day, on the team I’m anchoring, we’ve got people in California and Colorado, New York, you know, kind of spread all over the place.

Kovid Batra: My question was actually that if you are working as a remote leader of a team and you’re working as a remote IC, like these two roles working remotely, there is a whole lot of a difference. As an IC, like you, you just have to do your own work most of the time, right? So it’s okay for you to, like be remote and do it. You are motivated enough and you are so senior that you know what to deliver, when to deliver. You remain committed to that most of the time. But, if you look at it from the leadership perspective, that the role that you are into and handling teams remotely, I’m sure it would have been a little difficult compared to having people in-person, like keeping them motivated, checking on what exactly their enthusiasm is when they’re at work because it changes when it is remote. So, at that time were you using any specific tactics or I should say, strategies to handle your remote teams better and take care of their well-being as well as their overall output of the work?

Eric Heikkila: Yeah, we didn’t get into too much of that with the Software Director position at Gene Codes. Currently at Ford though, in my position, the team around, we set up, our core hours to make sure we had at least six hours of overlap regardless of where we’re located. And then we’re always pairing our ensemble programming.

Kovid Batra: Oh, that’s nice!

Eric Heikkila: And then, so we’ve got, and then we moved stand up, so now we do that just before lunch so that we have some contiguous time in the morning with everybody. And then, just before we’re going to take a break anyway, do a quick stand up and then after lunch, continue bobbing, ensemble programming, pairing. And that seemed to work out pretty well. And then we’ll for like morale building, we’ll do like, you know, once a month or so just to have like a couple hours of, you know, playing some online game together or one time, we did a ‘ask me anything’, but it was around each of the individuals and you could put, like two or three questions that you want to ask the other person. And we did sort of like a lean coffee on that and, and got to know some interesting things about our team members.

Kovid Batra: Cool. So when you are doing it remotely, even right now at Ford, as you said that you have this setup where you try to overlap and do pair programming, this experience of pair programming, how do you find it? Like, is it beneficial in terms of getting more or better code done? I understand the point that if you have an overlap, at least you get to know each other, you stay connected. But if you look at the core work done through pair programming, what’s your thought on that? When you’re working individually, you are more focused and you deliver more quality, how does it work out? I’m interested to know that.

Eric Heikkila: Sure. Yeah, for me, when I’m, when I’m not pairing, I’m way more stressed at the end of the day. Whereas when I’m, if I’m pairing all day, I’ll be mentally tired, but not stressed, because, I’m not alone, right? I’m always working with somebody, you know, sometimes two or three somebodies, at a time. So it’s, we never get into a place where I’m stuck, I can’t move forward because we have, you know, multiple brains all working in the same context and the same goes for either motivation or energy level. If I may be, you know, starting to flag, my partner or the rest of the mob may be, you know, on the upswing. So it’ll balance a lot of that, a lot of that out as well. And then just the knowledge transfer, right? Just being able to, you know, it doesn’t matter if I’m pairing with somebody who’s senior, somebody who’s junior, someone who just came in from college who doesn’t know what they’re doing. I still can learn from them, depending on, you know, what we’re doing, maybe some shortcuts in the idea that I didn’t know about, or maybe some new TDD tool or a different way to look at an algorithm. And so there’s a lot of a lot of give and take, and I find a lot of value in pairing, and, or, ensemble programming, especially for onboarding. Like on any of my teams, day one, you are committing code, right? It’s not, “Oh, welcome to the team. Spend three months reading the manual over there in the corner. And then we’ll get back to you later.” It’s, you know, hands-on right away, get in there and get some work done, which, uh, I think is beneficial. And so far I’ve heard nothing but positive feedback on that from the people coming into that environment too.

Kovid Batra: Yeah, absolutely. I think that really works there also.

Cool. So now, coming to this point where we are looking at pair programming, helping teams become more productive, in general, in so many years, you would have worked with different teams, build different teams, right? But the most important question always comes, as a leader at least, how much effort the team is putting in? How much effort is aligned to the business goals? How would you define the success of your engineering team, right? And as a leader, you have to take accountability and responsibility for that, right? So, tell us about different experiences with different companies, of course, the way you have defined success for your engineering teams and how do you go about it?

Eric Heikkila: Right. So I guess it depends. Like at the startups, it was very much, “Are we getting the features out that our customers want?” Because they’re waiting for it, right? They said, “Here’s what we need.” We don’t have any time, get it out the door so we can get it in their hands. And a lot of that ties into the metrics that, you know, DORA, tracks and, you know, supervises. And then, for me, the time between when we, you know, put pen to paper and say, “Here’s an idea.” to when that gets, you know, not just deployed, but released out to the customer. That’s really, one of the main metrics I look at. And then also, you know, number of defects that get released and, and things of that nature. So I’m not, not so worried about lines of code, not so worried about, you know, effort or how long does the story take, but really, are we, are we generating value for our customers? And, that may not be writing code necessarily, depending on what the feature is.

Kovid Batra: Cool. So even now, when you are part of such a big organization, right, we see a lot of frameworks, a lot of engineering metrics coming into the picture. So for smaller teams, when you have almost complete visibility, like what people are doing, what is getting delivered. I personally feel that this approach of setting the fundamentals of delivering value as a success for the engineering team is perfect, right? But, when the size becomes bigger, like you have so many people working along with you, having clarity for yourself as a leader and for the person who is working as an IC, as a developer, on a day-to-day basis, it’s very difficult to keep them motivated just with this long term vision of delivering value, right? On a daily basis you’re writing code, you really need to have a push where you know, “Okay, I need to do this today” and you have to win every day, right? Not every day at least, but you have to put in that effort. So a lot of companies we see putting metrics in place, right? Putting certain KPIs in place. What’s your thought on that, or for that matter, how do you do it right now with Ford? Are you guys implementing something? If you’re comfortable sharing, please do.

Eric Heikkila: Sure, sure. Yeah, we’re, yeah, it’s, it’s interesting because we’re kind of going through that phase of, yeah, “What should we be measuring? And how do we communicate that to the teams? And how do we break it down at an executive level and at the next level and get on down to the developers?” So what we’ve been trying to do is create, you know, objectives at a, like a division level, you know? And then, and then at a more like a product line level. And then from there having each of the teams in that product line look at those, OKRs and then say, “Okay, is that something we impact?” You know, is it? Then, “How do we impact that?” And then, you know, generating their objectives and, and the metrics for success based on how they think they measure up to the, the overall objectives that the, you know, the company has set. So, doing a little bit of top-down and then a little bit of bottom-up. Hopefully, they’re kind of meeting in the middle and making sense.

Kovid Batra: Making sense. Yeah. Yeah, absolutely. Is it okay for you to share any of the examples that you have recently seen getting implemented at your organization or somewhere else where you can actually tell us with clarity which metrics would be suitable for what kind of measurement? Do you have an example in your mind?

Eric Heikkila: Oh, yeah, part of the problem, especially at Ford, it’s kind of a moving target because they’re, you know, changing technologies, you know, partnered with Google now and, you know, things are kind of moving at a, at a fast pace for the, the development teams. So we’ve been looking into automating more of the DORA metrics, but like actually tying that into, to get for, so we can track commits and tie that to stories and then track that, you know, through its life cycle, it’s a bit of a challenge due to the different technologies in play right now. So hopefully, they’ll settle down and then we can get some of that automated. Right now there are some dashboards in place, using a tool like Datadog to be able to generate metrics and then post them someplace that’s, that’s visible. So we can track, yeah, a lot of the not necessarily velocity, but you know…

Kovid Batra: Production failure, basically the observability there, right?

Eric Heikkila: Right. Right. Yeah.

Kovid Batra: Makes sense. Makes sense. So I think this is also a very important metric to, I think one of the most important metric to track because ultimately it links to customer satisfaction also, wherein if there are more bugs, more failures on the production, then the customers would be dissatisfied. So cool. I think, yeah, that’s a very relevant example.

Eric Heikkila: Yep. So we’re going and we’re taking not just that, but looking at, okay, how can we make that predictive? So, you know, starting with, you know, measuring uptime, downtime, but then, working on instrumenting it so that we can tell, okay, it’s about to fail.

Kovid Batra: Yeah.

Eric Heikkila: We need to intervene before it impacts our SLAs.

Kovid Batra: Perfect. Perfect. Absolutely. Apart from looking at the efficiency, I think one more important thing which has recently become very important is looking at the well-being of your team members, right, their experience. So how do you guys do it at Ford or how you have been doing it at other companies where you have worked? Can you just give us a few examples, like how you executed developer well-being, probably if there were some metrics you were looking at to ensure that people are feeling happy, motivated?

Eric Heikkila: Sure. I mean, one of the big things is, we do a retrospective. It’s about once a month now. We did it for every two weeks. That was a little much for the current team size. So we pushed it out a little bit longer. But on that, we have a, a wheel that has all kinds of emotions around those around the side. And we’ll, you know, put a dot vote those.

Kovid Batra: Okay.

Eric Heikkila: And then we’ll just go through it and say, “Okay, I’m feeling excited because we’re working on this project. I’m feeling worried because we said we’ll get this done by the end of the quarter. And, you know, maybe I’m tired because we’ve been, you know, working extra hard because of the worry around what we promised.

Kovid Batra: Makes sense.

Eric Heikkila: So a lot of that, and then spending more time on the retrospective on the, more like emotional or personal side, rather than the technical side. We’ll save, you know, the technical stuff for the day-to-day standups and interactions. But, really for the retrospect, we try to focus on, you know, like you’re saying, well-being, how are people feeling, you know, what should we try changing to, you know, maybe reduce some of the stress or, you know, at least spread it evenly across the team.

Kovid Batra: No, at least the important point is that the teams, the organizations should have a focus here. There could be multiple ways to do it, but at the end of the day, if you have an intent to actually take care of your teams, they would reciprocate back in terms of the output that they’re bringing in the value they’re creating. So it is cool. Like, everywhere I see these kinds of things happening where there could be pulse check-ins, there could be things like what you said, that there is this dart you put on, different emotions and try to understand. So that makes it more gamified and interesting for people to express themselves and come up with things that they are feeling. So, really cool for sharing that with us. I think we’ll try that in our company too.

Eric Heikkila: Cool.

Kovid Batra: Cool. Eric, I think, more or less, these are the questions that I had, but before we let you go, I would like you to share some advice from your 30 years of experience that you would like to give probably to your younger self or the audience who is coming into this role. Any parting advice from you would be welcome.

Eric Heikkila: Really the, some of the things that have, that helped me out, also got me in trouble is being honest, just be completely open and honest and, you know, and say, here’s, here’s exactly what’s going on, right? Good or bad. You know, I just need to have that honesty and the other, the big thing I’ve seen too, especially from people new to the industry, they’re so afraid to be wrong. It’s like, go ahead and be wrong. It’s okay to be wrong. We’re wrong all the time. We don’t know what we’re doing. Welcome to the club. Be wrong, fail fast, but be able to recover from that. So do, you know, make small mistakes. You know, go ahead and make mistakes. Just make them small and then learn from them.

Kovid Batra: No, that’s a very apt, perfect advice. I think someone who comes in to the system and this is what the first time they’re working in a particular role, they are too conscious to fail. They’re too conscious to express themselves as being wrong. So people get into that different direction if they’re trying to defend themselves. So, it’s a very good advice. And honesty is definitely something I personally appreciate. When you are transparent, when you are telling what the exact situation is, people around you feel more comfortable, take better decisions and it becomes easy for you and the other people around you to operate in a better way. So, great piece of advice, Eric.

Thank you so much for taking out this time and sharing your experience with us once again. Looking forward to having more discussions with you in the coming time.

Eric Heikkila: Sounds good. Thank you very much.

Kovid Batra: Thank you, Eric. Thank you so much.