The First 90-ish Days at Policygenius
To say that starting at any new job is difficult would be the understatement of the century. So much can go wrong in your first few months: you can get buried under industry-specific acronyms, feel as if you are underperforming due to a lack of support — not to mention it can just be plain exhausting. While my first few months at Policygenius weren’t without their challenges, they were some of the best first ninety days at a job that I’ve ever experienced.
I owe that to not only Policygenius’ incredible culture, but also their on-boarding experience, which revolves around a 90-day plan you construct with your manager to shape your ramp-up experience. Here’s an inside glimpse to the first few months at Pg.
All things Pg
My first day I was led to my desk where I met the home and auto product team. In the few minutes I had to chat, I met my future mentor and did some initial setup for my laptop. Right after that, I headed to a meeting where we would go over basic office-related things, alongside others who started the same day as me. We were given a tour of the office and went over some office policies (or pawlicies if you are referencing the office puppers), and then I got lunch with my group, called a “cohort”. At Pg, there are specific start dates, which allows a group of people to start at the same time.
Starting off with a group of people helped a lot with adjusting to a new company. Even with Pg’s exceptional on-boarding process (I’ll get to that a little later), starting over again is always a little overwhelming, and having a group that was going through the exact same thing was very helpful.
My cohort and I would be together during a series of meetings that went over inter-departmental responsibilities. These meetings were called “cameos”, where someone from each department gives a quick overview of what exactly they do at Pg. I honestly didn’t know anything about insurance before I started, so these meetings were super helpful for getting a bearing on what exactly happens when a customer uses our products. It was also a nice way to get to meet a few faces around the office who you might not interact with every day.
In our first few months, newbies attend multiple on-boarding events, such as Pg 101, where our founders walk us through all of the basics of Policygenius; everything from how insurance works to what our goals are for the next year. These were a more in-depth view of the company as a whole, what makes us different from other insurance aggregators, and why we bring real value to our customers. It also was a presentation on why Policygenius is successful (hint: it’s because we want to help people find the best insurance for their needs, we’re not just salesmen). Pg 101 also showed us what our managers as well as leadership as a whole would be looking for us to bring to the table; they want leaders, go-getters, and compassionate people.
One of the best events I attended was Feedback Training, where newbies work in groups to learn how to provide feedback to fellow co-workers. We went over proper strategies for giving and receiving feedback, things to look for in feedback and when to reach out to a coworker and provide your thoughts. As someone who struggled at her previous job with giving feedback, I learned a ton from this workshop. Since everyone receives this training upon joining Pg, the feedback you have in meetings is never just “great job”. I’m actually learning what exactly a “great job” looks like, and strategies to improve even more so that I can continue to perform at my highest potential.
Mentorship and Planning
In addition to overall company on-boarding, every newbie at Pg gets a mentor to guide them through their first few months. I got to work with John, who has been at Policygenius for two years and has a background in Ruby, which I had no familiarity in. This helped when we were setting up my laptop, as it gave me a chance to walk through parts of the codebase and get a bearing on our backend. All in all, I was able to start working on a ticket in two days, which is the fastest I’ve heard of at any company (and it’s even faster now).
I then met with my manager who informed me of a Pg on-boarding process: the 30–60–90 day plan. Here at Policygenius, the People team as well as our VP of Engineering have come up with a first 90 days structure for personal growth and on-boarding. By the end of your first three months, you should be settled in enough to be working semi-autonomously and have the ability to contribute to the engineering organization as a whole by participating in 20% time. This prepared me for creating my own plan, something that would guide my conversations with my manager as well as my mentor.
I met with John and we discussed my skill-set and my 30–60–90 day plan, which I had drawn up the day before. I, being the way that I am, of course made this plan with ridiculously high expectations for myself.
John asked me what I knew about our backend language, I told him the truth which was: pretty much nothing. In my plan I already had “learn the entire language in a month”, which was very reasonable in my head. He gave me a bunch of resources to start learning, one of which was a textbook: The Ruby Way. John went through it to pick out which chapters would be useful for the work we’d be doing in the coming months. I learn best from taking notes, so I did just that, and we went over these chapters each week during our 1:1.
In the first month, we were able to get a bit of grounding on what skills I could attain at the end of my on-boarding. My 30–60–90 day goals were still a little lofty, but we pared them down to a more reasonable level. Each week in our 1:1 we’d go through these goals and measure my accomplishments against these. It was extremely helpful to have this document to guide our conversations. I thrive on constant feedback and these gave us a way to frame that feedback to result in achievable actions, rather than hand-wavy expectations. If I felt I was falling short on my language knowledge, John would provide tips and guides to learn more. The same went for planning which tickets I’d work on next. If we saw something come up in the backlog that tackled a framework I wanted to learn, I’d pick it up.
Aside from product work, my progression in learning a new language was going decently well, but I was mainly studying outside of work hours. In my bi-weekly meeting with our team’s tech lead, he told me to focus on my studying during work hours. I’ve always been a bit of a workaholic and especially when I start a new job I will spend a lot of time outside of work hours on work-related tasks. Pg doesn’t encourage unhealthy habits, and this mentality pervades throughout the organization. I instead began committing my language learning to each sprint as 20% time, with block of time on my calendar to ensure that I spent time during the sprint on refining my knowledge outside of product work.
By month 3, I was working on (usually) multiple tickets each sprint, and I felt like a real contributor. Outlining consistently and going over each larger ticket with my mentor meant that most tickets went over quite smoothly. If I ever hit road bumps along the way, my team was there to support me. Skills that started off as personally mandated tasks, such as asking for help after a certain amount of time when stuck, started to come naturally. Thinking through a problem thoroughly before diving in just became a part of my workflow. For a more in-depth view on what it’s like to work as an engineer at Pg, check out my co-worker’s article!
Pairing Sessions
Through working with my mentor, I was able to build enough confidence to feel like a contribution to the team and a worthy teammate. When we paired on our first ticket, I’d drive, something that forced me to grow comfortable with the idea of someone watching me as I coded. John also had his own keyboard and mouse, which helped in cases where (specifically) my lack of knowledge of the language or framework made coding difficult for me. I never felt alone in my work during the first month.
One of the greatest parts of my first few weeks was working on a full-stack ticket, touching many of our services, and using technologies with which I had little to no knowledge. As much as that sounds daunting, I was working with someone who had worked on similar problems with most of the services.
I didn’t know the language we were writing in, yet I was given the time to learn while developing, as well as space to study in my time at work. No one chastised me for my slowness or pressured me to be faster, even though what I was working on was holding up a major goal of the team. That isn’t to say that when the ticket drew out longer than anticipated due to unforeseen circumstances, that the team didn’t pick up my ticket and finish it so that we could get the feature out the door. It was a doozy of a ticket, but I learned a ton, which provided understanding for many future tickets, and is work that I’m still proud of today.
Feeling Valued as a New Engineer
When not pairing, I was involved in larger-scale tech discussions from the beginning. Here at Pg, every week we have an Engineering All-Hands meeting where we walk through cross-team risks, shout outs to recognize one another for good work, and a demo of a cool project one of the teams is working on. I also was able to join in on a larger-scale architecture workshop, where teams bring designs to get feedback from the engineering team as a whole.
In my first weeks I met with one of our tech leads on a greenfield mobile project. He wanted my opinions on React Native, which I used for around two years at my previous job. As someone who led the investigation into the use of the framework at my old company, I was happy to be able to share my experience with it and offer suggestions. At the end of the day, he made the decision to write the app in Flutter, which you can read about here. This was important, because not only was I included in architecture design decisions in the company, but my opinion was valued enough at the very beginning of my tenure to weigh in on our future large-scale projects.
We also have skip-levels every quarter, where you have a chance to talk to the VP of engineering about any issues that have arisen, or ideas you have to improve engineering culture as a whole. That isn’t to say that these conversations can’t happen ad-hoc, but having a designated time for these discussions on your calendar means that those who sometimes remain quiet and don’t reach out can be heard. It also makes it clear that your opinion is valued, even as a newer engineer.
Engineering and Product work very closely at Policygenius, which is a dynamic that many companies seem to lack. Weekly, or bi-weekly we have product workshops, where engineering team (and stakeholders) can give feedback on designs and product decisions early on, mitigating risk and also promoting investment in future work. Here at Pg, we (engineers) are involved from the research phase, meaning we can plan our current work according to what we should see next. This allows for proper architecture decisions and minimum throw-away work.
My Product Manager also did a great job of ensuring I understood our roadmap early on. With this in mind, I had context for our sprints. For my first few months, my team would go over the tickets in our backlog before grooming to add some color. We’d discuss why we were working on this ticket next sprint and how it affected our overall goals. My team would also explain at a high-level what codebases the ticket would involve and what types of frameworks or languages with which the contributor would have to work. This process ensured that I wouldn’t feel completely lost in grooming, or have to ask a bunch of questions during grooming. Pre-backlog grooming (as we called it) was just one of many efforts by my team to promote my inclusion in the on-boarding process.
Eight Months Later
It’s now been eight months since I started here, which is insane to me. I feel like it was just yesterday that I was confused by every insurance term-filled sentence during product meetings. With half a year under my belt, I’m now ready to start joining some of our bigger engineering initiatives and contribute to the larger team. I still cringe slightly when pairing, but after a few seconds that feeling fades and leaves room for true problem-solving. I’m planning events every so often for our product team and I’m helping lead our blog initiative (a.k.a. what you’re reading right now). Not only do I love the work I’m doing, I know that our team is helping our customers thanks to the transparency on our product team.
I’m actually proud of the work I’ve accomplished here. I have the incredible culture at Policygenius to thank for that, not to mention my snarky, supportive, and whip-smart team.
Want to join us and have a sick first 90 days? We’re hiring!
