13 weeks ago marks the beginning of my adventure at Flatiron Health in the data insights (DI) engineering team, facilitating product development through rapid prototyping and iteration. DI engineers at Flatiron use data science and engineering tools to test optimal business strategies, whether it be by taking a current product to the next level or prototyping a new product solution. As a part of the OncoBilling® team, I am currently developing a prototype workflow tool for financial counselors at cancer clinics; the tool is geared at helping them surface, manage and track patients who cannot afford cancer treatment by matching patients with pharmaceutical programs or foundations.
In the weeks preceding my start date, I anticipated the prospect of better understanding our fragmented healthcare system; players were described as having unique incentives, workflows and goals, leading to the conception of a market that's complex and full of "special snowflakes". Once my foot was through the door, I was immediately eager to start developing prototypes of technology tools that providers may find useful in treating cancer patients faster, better and cheaper. My fingers were itching before a pitch-black, bewildering terminal - where should I get started in exploring the code base of a complex SASS(y) company that had developed impressive applications while at the same time integrating multiple external legacy systems and platforms? With X languages and Y frameworks represented, I was relieved to hear incoming engineers would be ushered through the three-week bootcamp process - a series of technical training seminars geared at introducing the novitiate to the intricate system beneath their fingertips.
The first week of bootcamp covered all the environment basics: dev setup, database provisioning and overviews of multiple third-party tools fundamental to the development workflow. That first week is graphed into my working memory as a crowded blur of exhilaration and bemusement, split between general onboarding sessions (e.g.: Flatiron's mission, vision) and bootcamp sessions (e.g.: account provisioning, system operations overview). Weeks two through three were filled with seminars on dev workflow (how to commit and rebase), dev etiquette (if earphones are in, slack first!), and a variety of stack overviews (where does the technology diverge between differing product lines, what services do different processes use, which servers house what).
The current process is strong because it follows a relatively modularized framework; the seminars are valuable stand-alone overviews of the different stacks, processes or behaviors paramount to development. Each bootcamp session has owners and co-owners who pioneer the material and iterate on the content based on feedback from attendees. Every other Wednesday, the company welcomes new members to its ballooning team (new-hires even get welcome balloons tied to their chair). This bootcamping format leads to heightened flexibility in hiring and onboarding: seasoned employees volunteer to give overviews on one of their areas of expertise every two weeks, and due to impressive foot traffic are able to improve on their respective piece of the puzzle with increasing speed. This is crucial to the agile, quickly scaling tech start-up.
On the flipside of the coin, the current iteration of bootcamp hasn't taken full advantage of one of the key benefits of modularization: the ability to split up the pipeline into parallel siloes (empowering the method with flexibility to different learning styles). The current method optimizes for breadth rather than depth, a trade-off that in general is more beneficial for a top-down versus bottom-up learner. A top-down learner is she who prefers to understand the overarching framework that dictates a system before drilling down into practical applications; the bottom-up learner is she who would rather be guided deeply through an intricate example and extrapolate out as she finds systemic patterns.
One hands-on, lab-like aspect of the onboarding process is picking up bootcamp JIRA tickets owned by different initiative teams - usually small, self-contained tasks that may give you a flavor for how a process is executed within a particular stack. The experience gives the new hire a flavor for bits and pieces of different products, data pipelines and processes. Nonetheless, I didn't find the process conducive to a bottom-up learning experience without placing a significant time strain on the seasoned engineer who created the ticket. Deep-dives and code-walkthroughs (which in turn could be an exploration of a single module) should be experimented with in the bootcamp method. Since the current format of the program boasts of a speedy iterable framework, all attendees can proffer ideas to improve seminars, and session owners are held accountable for their implementation and incorporation of feedback.
And this isn't just fluffy idealism, I've seen it happen in my own practice. This recent experience inspired me to develop an additional lab to expose our new employees to our proprietary data pipelining framework: "blocks". In designing this bootcamp workshop, I gathered a list of all the pedagogical tricks I thought I would find useful as a bottom-up learner: some solo work beforehand, a hands-on guided lab exercise and follow-up documentation. So before walking into the workshop, attendees are encouraged to spend 10 minutes exploring a few flagged directories of our codebase and asked to philosophize on a few "guiding questions". I have been encouraged to test out new courses and eagerly incorporated them into the bootcamp process.
I have learned a great deal from my recent onboarding experience at Flatiron about how the company has managed to train, teach and empower a rapidly burgeoning technical team. The process is well orchestrated, offers a comprehensive overview of engineering at Flatiron and boasts of incredible potential while inheriting some growing pains. The question arises: as Flatiron and other technology companies continue to grow and are tasked with scaling their learning and development bandwidth, how can iterable, modularized frameworks be leveraged in fine-tuning pedagogical methods given a variety of learning styles? One promising option is to continue iterating on this flexible framework while developing divergent tracks to be trotted by different style of learners. And we might even coin it the "onboarding special snowflake method".
