A Hackathon, A New Office, and Engineering Onboarding
By: Carlos Freire (Senior Software Engineer)
After several years of working as a Software Engineer, I’ve been through various onboarding experiences. And even though I’ve been at Guidewire for three years now, it’s not uncommon for engineers to transfer teams to work on different tech stacks or products in our portfolio. Recently, I did just that. I joined a new team (we call them pods at Guidewire) and I started to reflect on the engineering onboarding process with a new perspective.
During this time, we were also emerging from the lockdowns and our shiny and new EMEA headquarters office opened in Dublin. To celebrate, we did what engineers do. We held a Hackathon!
Dublin PDO Hackathon 2022
The rules were the same as most Hackathons: all development would start when the event began and would be completed during the event. We had free reign to work on whatever we wanted, with no theme restriction. Fourteen different teams were formed, with most engineers attending the event in the office. And we had 3 days to make our visions into reality.
After two years of lockdowns, this hackathon was extra special. It was both the first in-person Hackathon since the start of the pandemic and the first event held at our new office in Dublin.
Drawing from Personal Experience
Most companies have a top-quality onboarding process for their new employees. This is a no-brainer. However, from an engineering perspective, it’s one thing to join a company, and quite another to join a specific engineering team inside that company.
For example, new team members can easily accumulate the basic knowledge they need during their hiring process or during their time in another team. However, it’s not as simple when it comes to each individual engineering team.
When joining a new team, every engineer needs to know the same basic information. Things like:
- Which articles to read
- What access to request
- What environment variables to create
- Which repositories to clone
In modern software development structures, more and more engineering teams are self-organized and given the autonomy to decide and implement their own processes. Unfortunately, this freedom is often where misalignment happens between the company’s carefully defined onboarding process and each individual engineering team’s unique approach to onboarding.
Here are the most common problems I heard from other Software Engineers working for different companies:
No structure
Inside the same company, different engineering teams have different onboarding processes. This is easily spotted by an engineer that has already worked for more than one team inside the same company. Sometimes teams have such stark differences in these processes that an engineer can feel like they changed companies, not just teams.
No documentation
An unstructured onboarding process can seem unsettling until you discover that some engineering teams have no onboarding process at all. In these cases, a new joiner will need several interactions with teammates to gather the required information to complete their onboarding. This lack of documentation directly leads to the next problem.
Hard to find information
For some teams, onboarding depends on how successful the new joiner is in their search for information. Without any guidance or a common starting point, a new joiner can spend considerable time on internal pages and other services to search for and collect all the information they need.
Days, weeks, even months
Everything discussed so far has a cost. The lack of any formal onboarding process or even an unstructured onboarding process both take up valuable time before a new joiner can be fully productive. Sometimes this is a cost measured in days or weeks. But in the worst cases, it can take months.
The same problem awaits the next joiner
Let me share a secret: regardless of all the problems listed above, most new joiners will survive. Some magical day they will be able to finish their quest and will start being productive on their new teams. However, even when that happens, the problem is not over. The company is still hiring, and new engineers are accepting offers. Guess what? They will be joining the same team as our previous warriors, so we already know what challenges await them.
We are engineers. We can also solve the problems we created, right?
Armed with the knowledge that “something is broken,” and with the Hackathon fast approaching, my first decision was to propose a solution to this onboarding problem. My second decision was to build something exclusively for engineers. And of course, using a Terminal was the way to go. After all, only engineers know that Terminals are sexy.
After posting my thoughts on our Hackathon Ideas Wall, I was able to build a team with four of my exceptional colleagues. Armed with the buy-in from three excellent engineers: Sarah Kelso, Nelson Martins, and Vinícius Cantarelli, and one outstanding Technical Writer: Boryana Genova, the “All Aboard!” team was ready to shine.
Our Solution
For any solution to be successful, I believe it needs two things. First, it needs to solve a real problem. And second, it needs to have a name that everyone can remember.
Very quickly, we came up with a great name for our solution! Let me introduce the POD Onboarding Unique Solution Orchestrator!
After our excitement wore off — which didn’t take long — we had the same thought as you. No one can remember that. You probably can’t even remember it even though you read it 10 seconds ago.
Not good.
We went back to the drawing board. What if we cut everything except for the initial letters? P [OD] O [nboarding] U [nique] S [olution] O [rchestrator] (We do love our acronyms at Guidewire.)
Let me now introduce you to Pouso, which means Landing in Portuguese.
❤️ 🇧🇷 🛬
But what exactly is Pouso? Pouso is a CLI application to guide the engineer in their onboarding:
Pouso Architecture
Everything in Pouso starts with defining a JSON file containing the onboarding details for that team. The team lead simply submits their JSON file to the Pouso API.
The Pouso API is a Nova microservice application. Nova is an internal microservice code generation tool from Guidewire, making cloud-native application development easy. It comes with additional capabilities to create CI/CD pipelines, provision applications with authentication, and provide seamless integration for deployment into Guidewire Cloud.
The Pouso CLI is an application built using Go that runs in the terminal of the engineer onboarding with the team. A significant advantage of Go applications is they are fast on every platform and built into a single self-contained binary, so the engineer doesn’t need to install any dependencies or third-party software along with the application.
From a single JSON submission, the team can now onboard all their new engineers in a consistent, repeatable way.
And just like that we’ve standardized the engineering onboarding process with a simple-to-use, easy-to-update solution.
The Results
With Pouso, our “All aboard!” team won second place in the Dublin PDO Hackathon 2022. Who won first? We proudly lost to an AI Self-Driving Lego Truck project. After all, who can beat an AI-driven Lego truck? That’s super cool!
But Pouso wasn’t just a fun project we worked on during a Hackathon and put on a shelf. It’s currently being used by engineering teams to streamline their own onboarding processes. At Guidewire, we are given the freedom to think outside the box, solve real problems, experiment with new ideas, and implement our solutions.
I’m looking forward to the next Hackathon and solving new problems. Maybe you and I will even be on the same team.
If you are interested in working on our Engineering teams building cutting-edge cloud technologies that make Guidewire the cloud leader in P&C insurance, please apply at https://careers.guidewire.com.
