I’ve often said at performance reviews and job interviews that I enjoy being the least knowledgeable person in the room I’m working in. It's not that I take pride in not knowing things, but rather that I feel I can get into "the zone" much more consistently if I’m surrounded by more experienced peers. I’m very curious by nature, and part of what I love most about the IT industry is that I frequently have opportunities to learn new and interesting things from different people.

Shorter projects come and go rather quickly, and they have you focused on a different framework, process, or technology for a brief time, before moving on to your next adventure. What about long commitments to massive projects though, like enterprise software solutions, which are typically built and maintained across years or decades?

After 8 years of working on three projects for three different clients, all of which were high complexity, massive enterprise software ecosystems, I found myself wondering how I can avoid getting overwhelmed by monotony, without sacrificing loyalty to a client or moving away from a team of people who, after enough time, feel more like war buddies than simply colleagues. It never occurred to me that shifting positions within the same project is much of an option. After all, I’m an engineer, so that’s the role I limited my solution space to.

The plot twist came about three years after I started work as a developer on my current project. Shifts in personnel started to affect team morale and keeping everything well organized was putting way too much pressure on the small PM team. I’ve always openly opposed the prospect of moving into management (though the opportunity came up as early as my first job), but I did, however, love frontend development and visual design ever since I first saw how newspaper editors created page layouts on paper, way back in the mid-to-late nineties. I was also always active in helping customers refine and improve their requirements as a developer, partly because it helped me be more confident in what I needed to deliver, but also because it’s a fun challenge to figure out how to cover all the corner cases in a spec and try to better understand underlying problems before investing in solutions.

It so happens that the product team on this particular project did a bit of everything besides literal project management: they were product designers, and worked closely with the people in touch with the end-users, helping shape the product. They were UI and UX designers, working on improving the design system and trying to deliver better artifacts to the front-end engineers. They were developing specs and helping validate quality assurance, having built up an intimate understanding of the product and the industry it served. All of this sounded very exciting, even if it came at the cost of having to fiddle with roadmaps and estimates, sprint plannings, and retrospectives. So when I felt frustrated as an engineer because the PM team didn’t have enough staff to support the rest of us, I jokingly said I’d try my hand at helping them out, even if it means putting development aside for a while (which was a very difficult choice to make, since I was always passionate about writing code).

Be careful what you wish for, they say, and soon enough I found myself in my first day at the office, working with the same people, for the same customer, at the same desk, without an engineering task waiting for me in the morning. This was almost two years ago, and now I feel like a career path in product design is just as good an option for me as development ever was, and I feel confident that I can alternate or divide myself between the two in the future. Let me tell you what I’ve learned from this experience.

Pay attention to what you enjoy helping your colleagues with. We often dive so deep into our specific tasks that whenever we're pulled into something else, we consider it solely as a distraction. If I’d have realized sooner that many of the things my workmates from other teams have involved me in were not just obstacles to overcome so I can get back to my keyboard, I wouldn’t have been as reluctant to look at coding as just a part of what I can do to bring value in an IT company.

Play to your strengths globally, not just locally. I’ve heard ‘play to your strengths’ many times, but I didn’t ever consider my strengths in the context of other positions on a team. I was always told that I’m a good communicator and teacher, so as a developer, to me that meant I could try to focus more on mentoring younger colleagues or presenting tech talks, and doing knowledge sharing. It’s worth thinking about your key skills as tools that can help you fill more than one shoe on a project.

Never say never. Even though I’ve never been attracted to project management, I like keeping things tidy and well organized, it’s just that I always limited this endeavor to my own tasks and goals. Turns out, trying to organize a project is a very interesting challenge, and a humbling one as well - it helped me get out of my head and acknowledge that there are many ways of skinning a cat, and a team works best if everyone gets to do things their way, provided that everyone understands they’re in it together and stick to decisions made as a team.

Tribalism is real, so try to mingle a little with everyone Even if you’re the most open-minded of people, working closely with a group makes all of you develop a sense of belonging. This helps any shared opinion within the group become axiomatic because it tends to live inside an echo chamber. A developer voiced their grievance about how a particular process on the QA team is affecting the project in a bad way? A visual designer got mad at the developers for not respecting some aspect of his mockup? By the time these opinions get out into the wild and reach the other teams involved, they are very difficult to change, even if they are incorrect or based on incomplete information. The QA process might make perfect sense in the long run because they need to trim down the time spent running cumbersome test suites before each release. The developers might have ignored the responsive designs for tablets only momentarily because there’s no plan in sight for users in production to adopt such screen sizes. The more teams you have regular contact with during your day, and the more you listen to and acknowledge their problems, the more you’ll find that it’s rarely the case that any single team has the perfect perspective to find the best solutions.

I’ll close by circling back to the idea I started with. There’s no shame in trying something new, even though you’ll be far worse at it than at your current role. I know that comfort zone is a highly debated term, and I know that it’s an individual choice how much one likes to respect or ignore its boundaries. My advice to those who want to jump out of theirs is this: never let the prospect of losing your hard-earned status keep you from trying something new. Your status doesn’t go away, you’ll still have all the skills and experience you’ve gathered along the way. You can always go back and continue where you left off. The way I see it, much of your previous experience is going to help you, no matter what new role you take on. The work ethic, the ability to organize yourself, the communication skills, all of the non-specific strengths that you’ve honed in your previous roles are coming along with you, and they’ll make sure that you learn faster and better than before. With each new thing you learn, the next one becomes easier in one way or another. So don’t be afraid to put aside something you’ve spent much time and effort on, just for the sake of being called ‘senior’ or ‘chief’ or whatever pompous title. You’ll never know how much further you might travel on a new path unless you take the first step.

Being the least experienced person in a room means one thing: there's no room to get worse, only better.