Covid19 is a unique situation that gives opportunity to embrace successful distributed work. With over eight plus months of resounding success to distributed work for the company with expectations meant and exceeding even the optimistic forecasts, I would like to propose a further open program to be created and offered to associates at <Company>.
Proposal: Engineer Exchange
- What is it?
Engineer Exchange is where an engineer or technical associate can volunteer to be nominated and approved to "join" a different development group within <Company> for a limited time (1 - 2 weeks), think of it as Visiting Scholar Program for <Company>. What brought this idea to the forefront of my thought is how distributed work can allow us to make powerful changes over vast distances that would not be possible in a physical office focused workplace. Now is the perfect time to take advantage of the freedom from those constraints to bring associates together, sharing and achieving goals that would not have been possible prior to this transition.
Further a somewhat analogous situation is the case of a junior executive expected to be familiar with divisions outside of their direct sub organization to be promoted to senior executive overseeing multiple divisions the junior executive would be expected to rotate into the role for hands on knowledge. The benefits of this are to increase their engagement, enrichment, and experience with the company. I am proposing to extend this program to all associates however I am outlining the details at the engineer position as I am most familiar with it and that technical skills are more context neutral in short bursts and transfer is possible within the time constraints of the exchange in my opinion whereas other business focused positions I foresee a larger context buildup and adaptations would be needed for other positions that I do not feel as confident in presenting at this time.
How is this possible?
With almost all teams working remotely the movement of an engineer from one team to another on a temporary basis is as easy as signing into a different remote access portal or machine. The constraints of the physical world have been removed and as information and capital freely moves around the world the inverse is also true that an engineer can move to a different working group by the click of link or button and work from a variety of locations in our now fully distributed workplace.·
- What are the immediate benefits of doing this internally?
All workers eligible for the program are already vetted and successful members of their own teams. Associates that emphasize the best qualities of <Company> can broaden their knowledge while at the same time sharing and bringing back valuable information to their original teams.
- Diversity and opportunity can be internally distributed amongst associates
Associates that are in completely different states/countries/time zones can now work with others they would have to schedule or physically visit in person to do the same quality of experience. Associates that are wanting to show and prove that their skills and contributions and abilities are available to use and learn new ideas, approaches, and technologies can use this time as a trial period to showcase themselves, for example a Quality Assurance Automation engineer writing integration test code could ask to exchange into a full time development group to do this without fear of failure or desire to look for opportunities in another company willing to hire them as a full time developer.
What would this program look like?
I have a clear sense of how this program would work for an engineer and process flow.
- The engineer in question applying for inclusion in the project should have been in their current position for at least 6 months to qualify
- The engineer must be nominated by their peers after approval in the exchange group for the program
- The engineer should be aware and capable of filling the position they are moving to exchange in. For example if the position requires knowledge of certain programming languages, they should have to complete qualifying work prior to accepting the exchange. For example to join Project Rise from another group means some familiarity with Amazon Web Services and Azure cloud capabilities, for other divisions this may mean Golang, Java, Docker, etc. The technology qualifications should be minimal as if you can work with a statically typed language then almost all of them will have the same common patterns, practices, and topics.
- The engineer agrees to nominate someone from their original team when they return to pass on the opportunity (again nominee pool comes from the volunteers in the approved available engineers that are interested in doing this activity). This would be sharing the opportunity for others so that rotation occurs and not the same engineer is sent over and over as part of the exchange process.
- The engineer agrees to be the primary contact/host when returning to their original group for an incoming exchanged engineer from another group at a future time. This is to keep continuity and pay back their time to their original team for giving them the chance to participate in this exchange and have a responsible party for any production code written by the exchanged engineer during their time spent with the group.
What would the visiting engineer be expected to do?
The visiting engineer would be expected to be treated as a new hire during this time, the level of their position depends on their familiarity with the underlying systems prior to exchange. An example would be that an engineer that currently works in C# within their group that is visiting another group that uses C# would be able to contribute at a higher level than an engineer that writes C# that is has volunteered to work in Golang projects. Although I would think that the ability to learn and explore the second option of moving to a different language/development mindset would provide a larger information exchange than the prior.
Responsibilities and benefits for the hosting group:
- The visiting engineer would go through the onboarding process from a technical standpoint, therefore validating and updating how a new hire would expect to perform in an ideal situation. A true new hire would not have the familiarity with company policies that an exchanged engineer is expected to have.
- There will be a designated host engineer to assist with issues and team practices. This goes beyond simply granting access or debugging a setup issue. A host engineer would inform the exchanged engineer with how code is released, what development practices are used, how communication is done (core hours, do you do standups), also this engineer would work with the exchanged engineer to target and deliver working code to production during this exchange time. Two reasons for doing this is to show impediments and the host engineer will be able to support any contributions the visiting engineer does in their stay long term. Many of these points could be communicated over documentation prior to the arrival of the visiting engineer, but this may not always be possible or the desired case for validation of the arrival of a new engineer (I anticipate some groups may want to test their onboarding steps from scratch for a full appreciation of a different more independent perspective without going through the process of interviews, audits, etc.)
- The hosting group will treat the visiting engineer as a new valued member and can ask for one or more technical, development, organizational presentations from them about their current group to share with their hosting group. Some topics that come to mind that I can foresee would be like Microservices, Docker, Database management, Code Reviews, Functional Programming, Redis, AWS, and many more.
Responsibilities and benefits for the participating engineer:
First this is not a sabbatical for the participating engineer like the programs offered at the Recurse Center for example. This participant is intended to focus on learning new ideas, topics, and approaches while bringing an awareness of impartial auditing questioning on practices (Why are some things done differently at the host organization and for what reasons), and sharing their own teams successful approaches to common problems.
- Further breakdown like so:
Knowledge exchange to host group and current group. As horizontal gene transfer can allow for rapid advantageous changes to be incorporated from disparate species. The core idea here is the same that each engineer exchange potentially could inject rapid beneficial improvements.- The engineer should be prepared to record their experience for two reports or presentations: - An experience as an outsider to validate the onboarding process to the group and their opinions as a third party (like audits are performed in other code and business areas) - Information on how the host group is achieving their goals and their process and tools
Engineer from <My Current WorkingGroup> applies after completion of the minimal ramp up time in their current position (the 6 months I mentioned before) applies to be in the Engineer Exchange Group for <Hosting WorkingGroup>. As part of the application process they list other groups that they are looking to learn from in a ranked list order as the group must be willing to host the exchange engineer (not all groups may have this ability is a known consideration)This engineer is accepted and is now a candidate on the list for nomination by a peer and is approved by their peer group to participate. The engineer now contacts their first ranked choice option to schedule a time that they can spend 1 week with and works through the required details for it.
- Who is their host contact?
- What setup will be required to join that week(s)?
- Prepare one or more presentations on the current technology process for the hosts to review and question - Inform current working group of their unavailability during that week(s). In this case it would be considered that the employee is unavailable during this time as if they were in training for that week and are expected to have emergency availability, but no normal availability. Their responsibilities will be with the host group during that time.
Example Case (Me):
I would apply to be a participant in the Engineer Exchange Group for <WorkingGroup>. My peers would approve the exchange. I would pick in this case for brevity two groups <Application Group 1> and <Application Group 2> as groups I would like to be exchanged to. I would then spend 1 week going through the onboarding process and work on code with my designated host engineer (responsible party for code I write after exchange is over) and I would hope to be able to get code written that hopefully is deployed to production during this time would be my primary goal with secondary goals of asking why am I doing certain things and presenting the <WorkingGroup> approach to applicable problems that the hosting group is working through. After the week I would then prepare two reports. One report for my host team on my experience performing the onboarding and topics I think <WorkingGroup> would be interested in learning more about for further collaboration. The second report would be for <WorkingGroup> and would detail the topics that the other team is working on and how they work together along with any points of interest on working together seamlessly in the future.