00:00:10.400
Well, first I want to thank Ruby Central and the RubyConf organizers for having me. Hello! I'm Mina, and my pronouns are she and her. I'm a software engineer at a consulting agency called Tandem, where I've been for roughly four years. If you want to get in touch with me, I'm over at the RubyConf Discord server and on Twitter.
00:00:21.279
Recently, I came to the startling realization that I no longer fall into the category of early career engineers, which led to quite the existential crisis; an experience that sparked this presentation. The talk is titled 'Managing Out: Strategies for Leveling Up.' I'm here to share my experiences leveling up, both practically and psychologically, and how I gained the skills and mental readiness to progress as a mid-level engineer and beyond.
00:00:49.680
In January of 2020, the project I had been assigned to for over a year received a contract extension. This extension significantly expanded the team; we more than doubled the number of engineers, bringing on individuals with varying skill levels, including new project leads. This change in team composition affected how I fit in practically overnight. I found myself in a unique position: I was not in an official leadership role, having completed my apprenticeship just before joining this project a year prior, yet I was also the longest-tenured engineer on this team at just over a year. This tenure was considerable compared to other Tandem projects.
00:01:19.600
Consequently, I had more familiarity with the codebase and our client than many of my teammates. Less than two years into my career as a software engineer, I became a person that my team counted on to be self-sufficient and to provide support and guidance to my new teammates. I felt uneasy being thrust into this pseudo-leadership position where I had opinions but no real seat at the decision-making table. At that stage of my career, I still had much to learn, yet I possessed enough project experience to support my team. Thus, I struggled with what I should focus on next.
00:02:06.960
I wanted to continue growing as an engineer, both technically and as a team player. I aimed to support my new teammates to the best of my ability and to continue providing value to this project. Being the overachiever that I am, I wanted to accomplish all of these tasks simultaneously. Through trial and error, I eventually devised ways to thrive in this position. They fell into three general categories: set good examples for the team and model collaborative behaviors; be creative in the ways I share knowledge and utilize existing tools to achieve new goals; and embrace my role by taking ownership and initiative.
00:03:00.000
By focusing on these strategies, I managed to emerge from this phase as a more confident engineer and a more empathetic teammate, all while contributing to successfully taking this product into nationwide production.
00:04:08.319
Every team has a set of processes that make it most productive. When new members join a project team, they must learn how the team works. There are various ways to share this information, such as through documentation or verbal explanations. I remember in school, whenever we had a writing assignment, my teachers would always tell us to 'show, don't tell.' Therefore, I opted to demonstrate our existing processes through my actions rather than using directives.
00:04:27.600
I was concerned about coming off as condescending, and leading by example felt more appropriate for my role within the team. Actions leave a deeper impression because the impact of behavior is more evident. Instead of discussing the theoretical benefits of doing things a certain way, we could find opportunities for pair programming or collaboration to show that we are a team that works together. We can also be open about asking for help early and often, which conveys that expectation and empowers others to do the same.
00:05:04.800
After spending considerable time on this project, I realized I held significant historical information and context about past decisions. This surprised me, as I was used to being one of several individuals who possessed this knowledge; most had moved on to other projects. Suddenly, I looked around and found I was the only one left. I have worked with team members who hoard information and resist sharing it, and I knew I did not want to become that type of leader.
00:06:02.720
I consistently reminded my teammates that I was always available to answer their questions, to pair with them, or simply to be a sounding board. I also listened closely during daily team syncs to understand what my teammates were working on and how it was going, trying to identify any uncertainties or blockers they might face. I emphasized that while I didn't always have the answers, I was willing to collaborate to solve any issues together.
00:06:40.799
This was also an opportunity to find out if any context or prior decisions needed to be communicated. Our project had a rich history, and many implementation ideas had previously been explored. For example, a new engineer might not know we had already done a spike to determine whether to raise errors using the GraphQL gem or let ActiveRecord handle it. We ultimately decided that ActiveRecord was better suited to our use cases, so their time might be better spent solving new problems.
00:07:32.959
Taking the initiative to suggest pairing together opened doors for collaboration with my team. As an early-career engineer, I often needed help when tackling a task but was too afraid to ask my team for it out of concern that I would bother them. I always felt relieved when those offers were made. So, once I stepped into a more experienced role, I ensured to be the one to advocate for pairing without requiring my teammates to ask me first.
00:08:12.400
Pairing with the team was beneficial not only for them but also for me. I'm a strong proponent of pair programming as one of the best ways to learn, enabling me to practice various technical concepts and be exposed to different coding styles, ultimately improving my skills. For instance, a couple of new engineers picked up a ticket that would greatly benefit from being remodeled using single table inheritance.
00:08:57.920
I had been introduced to this concept on a previous project, but hadn't really utilized it, while they had never encountered it before. So, we spent time working together and improved the extensibility of the code. When introducing the two to single table inheritance, I gained better practical knowledge about it. Explaining concepts like this to my new teammates solidified my understanding, and I was surprised by how much I knew about Ruby and Rails.
00:09:45.280
Another opportunity to flex our technical muscles and gain confidence is through participating in code reviews. Some of my new teammates joined our project without knowing Ruby. Although I wouldn't classify myself as an expert, I could still offer insights about the language, such as implicitly returned values. As a reviewer, I approach pull request reviews as another chance to collaborate with my teammates.
00:10:24.720
I strive to be thorough, carefully reading code changes and testing the functionality. I provide both compliments and critiques with empathy, utilizing the feedback framework 'ASK' which stands for Actionable, Specific, and Kind. Furthermore, I often offer to pair after making complex suggestions to eliminate any potential for miscommunication. If you're interested in hearing more about giving and receiving code reviews, I delivered a talk on this topic at PNW Cascades last year.
00:11:01.680
By setting good examples for my team and using my actions to model collaborative behaviors, I grew as an engineer and deepened my understanding of Ruby by teaching those who were new to it. I supported my teammates by providing technical guidance through pairing and code reviews while ensuring we maintained a consistent process.
00:11:53.040
With clear expectations and everyone up to speed, we worked more efficiently and delivered better quality code. As part of our onboarding process, new engineers received a brief demo of the application and a high-level walkthrough of the codebase. While these sessions were valuable for grasping the bigger picture, to implement a new feature or improve functionality, we needed to dig deeper for specific details.
00:12:41.760
Instead of saying 'everything you need to know is in the code,' I utilized tools embedded in our workflow to share information about the codebase and help my teammates become more productive. For instance, I contributed to implementation discussions by enhancing ticket descriptions on our Jira board. Our leads and product manager created tickets and filled in business requirements, but it was our responsibility as engineers to translate those into implementation details.
00:13:57.440
Our goal as a team was to ensure common knowledge and shared resources and provide enough information in the descriptions for anyone to pick up tickets confidently. Although every team member was capable of finding their way in the codebase, being new to a project or coding in general might lead to some additional detours along the way.
00:14:41.840
The information I added to ticket descriptions served as the beginnings of a roadmap, indicating the general direction toward implementation. It was never detailed enough to dictate how they should implement it; suggestions were framed as helpful insights, such as 'take a look at this model—it might relate to this task,' or 'we have an established pattern here that could be beneficial, and here’s where you can find the examples.'
00:15:27.720
At the end of every sprint, we would come together as an engineering team to review the planned work for the next sprint. In these meetings, we discussed the details of each ticket, deciding if any needed to be broken down into multiple smaller tasks for simpler implementation and code reviews. I always made sure to ask questions, raising any red flags or potential edge cases.
00:16:29.440
As someone starting out, I kept quiet in these meetings because I didn't process the new information about code or our client’s business as quickly as needed. By the time I formulated a question, the conversation had already moved on. However, I observed more experienced engineers ask thoughtful questions and comment until I learned to think like an engineer and understand what is important in these discussions.
00:17:32.880
I sought to empower the team by exposing my knowledge gaps—setting an example for my newer teammates by demonstrating how to contribute in these discussions, as my previous teammates had done for me. When early career engineers see an experienced individual admit not knowing the answer, it sets a standard. As this tweet says, it normalizes acknowledging knowledge gaps and illustrates how to respond.
00:18:16.160
By employing creative means to disseminate knowledge throughout the team, I grew as an engineer because sharing my understanding allowed others to challenge any incorrect assumptions. Incorrect assumptions do not survive long in the open. I supported my teammates by helping them progress from square one when facing new tasks and ensured our requirements met client needs by considering edge cases and associated risks.
00:19:06.080
At the beginning of this presentation, I mentioned my struggle to reconcile my project experience with my actual role on the team. Although I held the most context, I wasn't officially in a leadership position. Eventually, after much introspection and mentorship, I decided to embrace my position. Someone wise once told me that we do not always lead from official positions; many opportunities exist for learning and practicing leadership skills, regardless of our titles.
00:20:02.240
I began to take initiative, serving almost as a second-in-command for my leads, who were quite spread thin. The time and experience I gained on this project propelled me from early career into a mid-level engineer. In this new, somewhat intimidating position, I recognized that when I had an idea or identified a specific task needing attention, I should take action.
00:21:15.040
As I became more seasoned as a software engineer, fewer people would intervene to tell me what I should be doing. My leads began to expect me to be self-sufficient and to facilitate the team toward productivity. I realized that no one was going to dictate what the project needed because I was becoming that individual.
00:22:02.560
Thus, I started implementing measures like writing documentation that others had generally overlooked or volunteering for small process-related tasks. When boarding new engineers to the project, I recognized that we had failed to document clear processes for introducing someone to the project.
00:22:43.440
As we fumbled through the onboarding process initially, I began creating documentation for the next time we welcomed new team members. My goal was to develop a one-stop shop for everything new engineers needed to ramp up, as well as clear instructions so that anyone could lead the onboarding process.
00:23:23.360
Now, writing documentation may not be an engineering team's favorite job, but I volunteered for these tasks intending to prevent the team from facing similar situations in the future. This was the turning point that allowed me to settle fully into this new stage of my career. Rather than waiting for someone else to take care of the necessary tasks, I took responsibility.
00:23:55.840
I also volunteered for various small tasks, such as managing pair rotations. We were a pairing-by-default team, which meant that a ticket on the board would be addressed by two engineers to distribute knowledge and ensure fair pairing. We established a bi-weekly rotation that was maintained in a spreadsheet. Although this may seem straightforward, many factors required thoughtful consideration, such as managing vacations and pairing engineers who might already have knowledge related to the planned work.
00:24:49.679
Managing the spreadsheet was a task that didn't require a lead's expertise and skills. By taking this off their plate, they could focus on more critical tasks like managing the roadmap, prioritizing client requests, and coordinating with designers and product managers.
00:25:28.559
In essence, I positioned myself as the Commander Riker to my lead, Captain Picard, delegating smaller tasks for them. As a result, my leads no longer had to handle these responsibilities nor worry about them, allowing me to alleviate some of the load from their plates.
00:26:24.399
By truly taking ownership and embracing my role, I practiced leadership skills from a less demanding position while laying the groundwork to one day take on an official leadership role. I became an alternative point of contact for leadership, providing the team with more accessible support than our leads could offer.
00:27:11.360
I recognized my privilege in being in that unique position, where I had the knowledge and experience to step up without the burdens associated with being a project lead. I set a positive example for my team so they could understand processes and expectations.
00:27:30.640
Ultimately, I shared project knowledge with my new teammates using tools integrated into our development workflow, making the process more organic and less condescending. I embraced my position and practiced leadership skills in preparation for the next stage of my career.
00:28:23.680
My initial confusion about where I fit into this new project dynamic motivated me to find or create opportunities to maximize my contributions. I worked diligently with these strategies to build trust with the client, stakeholders, and my teammates.
00:29:10.560
Currently, I'm preparing to take on the official role of project lead for a new client, and I have never felt more prepared.
00:29:41.440
You might already be engaging in some or all of the approaches we've discussed today without realizing the impacts you're providing to others or receiving yourself. By acting with greater intention, we can grow tremendously from even the simplest day-to-day interactions.
00:30:27.999
Thank you so much for choosing this talk. I would like to take a moment to plug a couple of my good friends who are also speaking at this conference. Be sure to check out Mercedes Bernard's talk on minimizing your circus factor and building resilient teams, as well as Stephanie Men's talk, 'The Intro to Abstraction I Wish I’d Received.'
00:30:56.560
And if you liked what you heard and want to join us at Tandem, we are hiring senior and principal engineers, as well as an engineering manager. Additionally, we have an apprenticeship program that I would love to discuss with you. Enjoy the rest of your RubyConf!