A Tale of Two Roles - Transitioning from Product to Engineering at Iora Health

bundle update ellie@engineer
If only it were this easy…

Iora Health is transforming health care, starting with primary care. At Iora, we invest in relationships and provide patients with a team that respects and listens to them. So it’s no surprise that this philosophy translates to the way Iora nurtures and develops its own employees. One of the best things about working at Iora is the organization’s support for professional development and investment in its people. Transitioning from Product Management to Engineering, I have benefitted firsthand from this culture. In this post, I share some details and insights from that experience, as an exemplar of how to onboard and support junior engineers from non-traditional backgrounds in ways that benefit the entire team.

Moving forward while staying in place

Just a few months ago, I was a Product Manager with years of experience with online courses and hobbyist work but little formal training in software development. I had developed a passion for coding through resources like FreeCodeCamp and MIT’s open online Computer Science curriculum, but came to realize that it was something I wanted to commit to full-time, not just as a Saturday afternoon hobby. When I decided to make the jump to engineering, I was uncertain of two things: how could I possibly go from self-taught hobbyist to working programmer, and how could I balance my evolving career aspirations with my love for Iora and desire to stay put?

Iora Health is a remarkable place — the kind of organization where our cultural values are not just a footnote on the company wiki, but the cornerstone of every interaction. Iora’s primary care model is truly transformational, and our innovative collaborative care technology platform, Chirp, plays a major role in effecting that transformation. Working for Iora provides that rare glimmer of hope in the world of healthcare technology — the promise that we are actually making a difference in the lives of patients with the software we ship.

the Chirp team
Snapshots of the Chirp team at this year’s annual pool party (ergo all the wet hair!). Image Credit to Chirp Product Owner Divanshu Jain.

Luckily for me, the leadership of Chirp was both fully supportive of my hopes to stay on at Iora in a new capacity, and confident that there was a path forward to develop my after-work hobby into a more serious software skill set. Mere weeks after I first raised the idea, a plan to bring me into the wizarding world of Engineering was in motion.

Early days

“Everything is going to change and nothing is going to change,” commented Will Mernagh, VP of Engineering, leading up to the cutover date. But when I came into the office on April 2 and opened a terminal instead of Gmail, I was pretty sure everything had changed.

GIF: It will change the world as we know it


The first week was focused on easing into the environment: setting up my dev machine and learning our git processes, our application architecture, the ins and outs of HTTP, and so on. From Day One I was paired up full-time with a mentor — one of our Staff Engineers, Gerardo Pis-Lopez — to spend our days alternately discussing high-level context and delving into code.

By Week Two, we had begun to ramp up the actual coding. It was critical to have someone with deep experience there to provide context, guide the conversation in and out of subject areas and code paths, and put blinders on or elaborate where necessary. I had spent months prior reviewing the Chirp pull requests on my own and wondering how it could ever all make sense, but it was an entirely different experience to sit side-by-side with someone who could explain the area of the codebase, highlight what mattered and what didn’t, and answer questions about tools and code design.

pairing workstation whiteboard
The whiteboard at our pairing workstation — keeping the big picture in mind.

Despite the incredible teaching and support I received, the first few weeks were tough. It felt like learning two foreign languages at once (which isn’t far from the truth), and by the end of each day my brain was completely fried. But as the weeks progressed, slowly but surely, things started to click. We shifted from a model where my mentor laid out the process and code to one where we talked through the approach and then ping-ponged between me writing code and pulling up for questions where necessary. Today (towards the end of Month Four) I am working independently on small and medium features and pairing as needed on the larger features or new areas of the app, steadily expanding my role as a team contributor.

GitHub contributions graph
Coding after my April 2 transition date — no longer a weekend activity!

Lessons learned

Bringing on a Junior Engineer without formal training was an excellent learning opportunity for the whole team. Over the course of my first four months there have been things that worked and things that didn’t, and a few things that we are formally codifying into our training process as a result of the experience. A few of those insights include:

People over process

With my background as a process-focused PM, I came to the planning table with a dense Google Doc full of proposed milestones and a list of transition risks, which was met with… a collective shrug. Engineering leadership knew that the key to success was going to be the people, not the plan. One-on-one mentorship with a skilled teacher was the crucial element, but I also benefited from pair programming with a variety of senior engineers on the team. This is a standard for training up junior engineers at Iora that expands the diversity of opinions and styles to which we are exposed. While this approach can seem resource-intensive, we trust that the investment yields dividends by instilling strong habits (of both mind and code design!) early on and enabling valuable independent contribution as quickly as possible.

Responding to Change Over Following a Plan

The outline of my learning roadmap was developed with Engineering leadership, and expanded upon by our VP of Technology John Norman in a blog post, which makes an excellent resource for anyone considering a similar career switch. Initially the plan was to have me focus solely on Ruby/Rails for the first three months, so that I could develop mastery over one language/framework and keep a narrow area of focus. But it quickly became apparent that full stack development on a mature app is heavily skewed towards frontend work (surprise!), so after two weeks of dredging the backlog for Rails cards, we were forced to make a quick pivot to JavaScript.

GitHub Linguist repo classification
According to the Linguist library, our primary application repo is indeed written in JavaScript!

While the high-level roadmap remains extremely useful to me as I progress, staying flexible and focusing on becoming a productive contributor to the Chirp product as opposed to a master Rubyist early on allowed me to quickly add value across a wide range of features.

Finding Mental Models That Work

Learning programming can be daunting, especially without formal training, but I found that certain metaphors and models helped me grasp some of the concepts at play and boost my confidence that this was a skill at which I could eventually excel. For example, some of my mentor’s most effective (and personally resonant) explanations were those packaged in literary metaphors, such as his description of the craft of coding as “half detective novel, half science fiction,” or one memorable explainer of the call stack likening it to Scheherazade’s role in One Thousand and One Nights — perfect analogies for someone who can’t write a technical blog post without a Dickens reference.

I also felt a confidence boost after speaking to acquaintances in engineering from nontraditional backgrounds, who emphasized that the skill set needed for programming is often more akin to learning a foreign language than to pure math (not that I don’t love a good stats problem, mind you, but I’ll always prefer verb conjugation). I have an shelf of books at home dedicated to Spanish language classics, so when viewed in that light JavaScript seems a bit less intimidating.

Slack in the System Accelerates Growth

GIF: Must go faster


It’s tempting to keep engineers working at 100% capacity in the hopes of maximizing productivity, but here at Iora we’re big fans of the Lean principle of slack in the system. We build in our own form of slack called Engineer’s Time for engineers to focus on whatever they choose for 30% of their total capacity. This allows us to keep technical debt down, make open source contributions, deliver experimental features, and most important for junior engineers, reflect and study outside of the standard feature work.

In my first few months as an engineer I used my Engineer’s Time to take Mike North’s EmberJS trainings, read Sandi Metz’s books on object-oriented design, and build upon my basic understanding of Ruby and JavaScript syntax. This not only provided me with the breathing room to process concepts I was learning on the job, but also took some burden off of senior engineers to explain concepts that are covered well in other resources so that we could spend our pairing time on meaningful, domain-specific topics (like how RabbitMQ enables us to seamlessly sync data across a variety of microservice-style apps, or how we manage to transform rigid HL7 laboratory results into the user-friendly labs view in Chirp!).

Trello card for blog post draft
I even wrote this blog post using my 30% time!

Keep Calm and Code On

Despite the incredible support and encouragement I received, the first few weeks were inevitably overwhelming. Shifting my perspective away from thinking catastrophically about all the technical knowledge I don’t (and may never) have, and instead focusing my attention on the progress I was making, allowed me to defuse the stress and become more productive in the day-to-day. Pulling up for weekly one-on-ones with my mentor and new manager was also key to obtaining objective feedback and ensuring that things were right on track.

I also continue to try to emphasize the qualities I do bring to the table, like being a female engineer with years of product experience and a degree in Psychology (you’d be surprised how often it comes in handy!). The world of technology is far too vast for any of us to master it all, so emphasizing your strengths and learning to be comfortable with where you are goes a long way.

It Takes a Village (or at least some seriously awesome coworkers)

After years of tinkering with code in isolation, the progress I was able to make with so much support was staggering. At one point or another I have received help and guidance from every single member of our 13-person engineering team, whether it be troubleshooting an environment issue, Socratic-style pairing sessions, or approving pull requests before I even knew I was finished with them. The Product and Design teams with whom we work side by side have been equally supportive, staying flexible with the user stories I first pulled and offering encouragement throughout the process. It makes all the difference not just to have people let you do something, but for them to be excited about it and invested in having you thrive.

Take, for example, the responses I received on my first pull request.

team comments on first pull request

Nothing engenders confidence and self-esteem in a new programmer like having the support and enthusiasm of a team like that.

In conclusion

Becoming a software engineer is a lengthy process, one that might even last the rest of my career. But with focused mentorship, continuous feedback, and a supportive team environment, it has gone from being a pipe dream to my daily reality. Iora’s dedication to its employees and commitment to their personal growth makes it the best place in the world (in my admittedly biased opinion) to be a junior developer — and to continue to grow into whatever comes after that.

GIF: Well there it is


Thanks to Max Fierke, Katie Grundl, Dan Ritzenthaler, Alex Rothenberg, David Garrett, Will Mernagh, and Megan Prock McGrath for feedback and edits.