Internal Internships in Adjacent Roles
Here at Panorama Engineering we formally acknowledge that engineers can often grow their impact by better understanding how their coworkers in different roles do their work. From our Engineering career development documentation
Engineers often have passionate interests in the work of different “adjacent” roles to engineering, e.g., technical management is considered to be a separate role which is an “adjacency” to the role of engineer. Other examples include product management, design, support, data science, etc.
These “adjacencies” are alternate career paths outside of core engineering. However, in many cases, developing skills in these adjacencies add to the engineer’s impact within engineering.
From that acknowledgement has grown a program that has allowed members of our engineering department to gain valuable skills and, importantly, perspective as part-time product managers, designers, or data scientists. Once underway, an “ adjacency”, as we call these internal internships, is a chance for an engineer to spend a substantial portion of their time on deliverables for a role other than engineer.
This is likely a very familiar trope to anyone who has been at a small scrappy startup: Everyone does whatever needs to be done, doesn’t matter what your title is and if you haven’t done it before — there’s a first time for everything! As Panorama has grown well past the small scrappy startup stage we’ve aimed to preserve the benefits such role experimentation can bring and not just leave it behind as a relic of the past. Knowing what it feels like to have the rest of the engineer’s team waiting for their wireframes and what kind of questions they get once they have delivered them helps them build empathy and better work with designers back when they’re the one asking the questions.
Within Engineering we get this “for free” by having full-stack engineer as the typical role in the department, without distinction between front-end engineer and back-end engineer. Full-stack engineers at Panorama get experience throughout the technical stack and across the product development cycle. Giving engineers a chance to try their hands at other roles in the company, however, takes additional effort from many parts of the organization. After an engineer expresses interest in gaining some direct experience in one of the other roles at Panorama, there’s a process of involving the department they’re interested in learning about and identifying an opportunity, not to mention figuring out how their team will do without a significant chunk of their developer time for a few months.
To date this process is case-by-case and individually tailored. Sometimes an engineer has deep domain knowledge on a critical path project for their squad and doing without a chunk of their architectural and coding time right then would be painful, and the right thing to do is wait until that project comes to a close. Sometimes there’s a clear project for them to work on in the adjacency and we get them right on it. Often, but not always, the engineer participates in suggesting the project they would like to work on-their interest in learning about the other role already sparked a few ideas.
One engineer I work closely with, Geoffrey, expressed an interest in an adjacency in our Research department. Panorama’s Research department analyzes the copious amounts of data our school partners have provided on school climate, social emotional learning, and more. Geoffrey had a keen interest in learning more about how we identify nuanced patterns in the data and how to use that to provide guidance to the educators we work with about how best to support their students. He started an adjacency with the Research department to dig in.
What happened was a wonderful example of how working closely with another department doesn’t just expand the knowledge of the engineer, but working closely with an engineer helps meet the needs of another department. Geoffrey found that the Research department had not had easy access to all the data they wanted, but he knew exactly what data was available, how it was stored, and how to get improved ETL tools incorporated into our data warehouse. His adjacency illuminated a notable stumbling block in data sharing between departments, and soon not only was he working to address this himself but advocating for more engineers to improve interconnectedness between our repositories. A few months later we had spun up a new squad in part chartered around a closer partnership between the Engineering and Research departments.
Not every adjacency ends up sparking a significant new initiative, and in fact most simply achieve the central aim of growing an engineer’s impact through more direct understanding how their coworkers in different roles do their work. Alongside our desire to help our engineers grow ever more impactful, though, there’s a secret — not every engineer at Panorama is going to be an engineer for the entirety of their careers. (You didn’t hear it from me, though — I don’t want to encourage anyone to leave engineering, we’ve got a lot of amazing things we want to build and need experienced engineers to help do it.) We don’t want to “keep” anyone in the field when they’ve got a yearning for something else. We’ve had a few engineers make their engineering management adjacency here permanent, and doesn’t every engineer suspect that they have a product manager deep down inside, yearning to break free? It’s OK to consider various career paths, even if they don’t match the most common one, and everyone should be able to discuss such thoughts with their manager honestly and openly.
Exploring the places where software engineering brushes up against other fields has been a lifelong interest of mine and I’m extremely pleased to have found a company that is explicit about allowing exploration there. If a company with that kind of openness sounds appealing to you we’re always looking for more engineers to join us!
Originally published at https://engineering.panoramaed.com on October 18, 2019.
