Reflections on joining Lendable in the middle of the pandemic
James Mannion
James Mannion
I'm writing the last bits of this article from our lively office after having a nice cup of coffee with my workmates. But that's not how I started at Lendable... I joined the company in March 2021, during the global pandemic. As someone who has always preferred to work from an office alongside a team, I very rarely chose to work remotely prior to the pandemic.
The pandemic has transformed the way we work, and it is my opinion that some of these changes are here to stay.
I read somewhere that we weren't working from home, we were all just doing what we could during a global pandemic. Initially, for me, this was certainly true. I had to adjust quickly to working remotely in a role I had previously enjoyed doing from an office amongst a team for a number of years.
I then decided to move into a new engineering role at Lendable and the experience of joining a team remotely felt like a challenge in itself.
I felt that building social relationships with colleagues, having lunch together and the normal daily interactions of the office had helped me quickly acclimatise and integrate when joining previous companies would be missing, and I was apprehensive about starting a new role with none of those comforts.
It ultimately worked out great, I have been on the team for almost five months and in that time I have been content and productive despite having worked exclusively remotely the entire time.
What follows is a list of things I tried to do from the start which I feel make my on-boarding experience successful and enjoyable:
At Lendable, it is standard for a new joiner to aim to complete a ticket within the first week of joining. This incentivises rapid onboarding and provides an important early sense of achievement and ownership of something with the team.
Whilst the first contribution is likely going to be small (mine was to add an index to a database table), getting to the point you have added something to the codebase and shipped it to production is quite an achievement:
you will have been given a tour of the product and the codebase
your development environment will be configured and functional
you will have made use of the task tracking system, the code repository, and any other resources used by the engineers to prioritise and manage daily work
you will have understood and practised the standard flow of making a contribution to the project
you will likely have interacted with your team regarding the piece of work - the daily standup, code review process, potentially pair or ensemble programming
you will have moved a change through the entire delivery pipeline to production and seen some value delivered to the business
As you join an established team, naturally there is a significant amount of information to absorb. In addition to new frameworks, patterns, conventions the team has established and developed over time there is a rich and complex problem space to understand.
As a Domain Driven Design advocate, I recommend forming a written glossary of terms to document the ubiquitous language as you interact with the various domain experts and discuss important concepts and topics.
The development of a glossary can lead conversations to insightful and interesting places and surface a wealth of information very quickly, accelerating your learning and improving the quality of your contributions.
If a glossary doesn't already exist it is likely to become a valued resource and source of truth for the team when discussing and modeling new and existing features.
As a new joiner at Lendable I actively looked for opportunities to add documentation. I wrote a number of guides documenting the tasks and processes of my onboarding with a view to making the process for the next joiner even more pleasant.
Better still, I have been able to introduce the team to the practice of Event Storming, bringing together experts from every corner of the business to produce documentation collaboratively which has proven tremendously valuable and quickly been adopted as common practice across teams. We are iterating on the format and learning to Event Storm effectively as a remote team.
The most significant difference when joining a team remotely is that you won't physically meet the team you will be working with. Despite this, becoming acquainted with the team is important.
At Lendable, it is standard for new joiners to be introduced to individuals from each department of the company within the first weeks. In addition to being a personal introduction to the wider team, these sessions provide an insight into the structure of the company, the daily work, and responsibilities of your colleagues, their areas of specialisation and expertise, interests, and history with the company.
Making the effort to chat to your new colleagues is an excellent ice-breaker, it will help ease new starter nerves and serve you well as you grow into the company.
I have found collaborative programming to be an excellent tool in becoming acclimatised within the team as I joined Lendable.
Within the first couple of weeks at Lendable I was able to pair program with the majority of the team at one time or another. Pair programming proved an excellent means to get to better know each individual personally, their roles, and responsibilities within the team.
It is also a great opportunity for the team to learn about you in the same ways.
I have also found it particularly valuable to see how others work, and I accredit a lot of my own best practices to things I learned pair programming with great engineers over the years.
As you join a new team it is a fantastic opportunity to knowledge share with your new colleagues.
As you join a new team you are likely the person with the least knowledge and context as you explore the codebase. This can be used to your advantage and help you make valuable contributions very early on.
I make a point of looking for ways I could refactor code that would have enabled me to understand it more quickly.
If you have read Martin Fowler's Refactoring book you will know opportunities to refactor can range from simple things such as identifying an opportunity to extract a well-named variable (maybe from the glossary you are developing) to moving behavior closer to data to create more intuitive and testable class structures.
Start small and keep refactoring, and you will achieve a great sense of achievement and learn a lot about the existing codebase and decisions made.
Peer reviewing the work of your new colleagues is a great way to become productive within your new team even before you are in a position to make your own contributions.
You'll also see the working practices of the team:
What workflow does the team use?
Are there code owners/specialists for any parts of the codebase?
What does a typical interaction between engineers look like as code is reviewed?
Are there hotspots within the codebase that seem to be changed frequently? (is there an indication of a particular area that would benefit from refactoring to make it more extensible without constant modification?)
What does the commit history look like for WIP branches? Does the team practice TDD?
Are there standards and conventions to cohere to when opening a pull request, or submitting a review for an existing one
At Lendable, I learned that the conventions for opening a pull request include writing a commit message in a defined format and the inclusion of an animated GIF:
Even in a remote-first role, there are likely to be opportunities to interact socially with your colleagues and as a new joiner. Doing so will alleviate your new starter nerves and enable you to identify members in your new team that has interests and hobbies that overlap with your own.
At Lendable, there are a number of non-work-related Slack channels which are a great place to find colleagues who share your interests. I was thrilled to find lots of colleagues shared my interest in the Simpsons, computer games, board games, music, and discussing those interests in the dedicated Slack channels enabled me to get to know the wider team within the first few days.
This proved a fantastic ice-breaker.
The shift to remote working has proved stressful and challenging for us all. It is crucial for morale and well-being to recognise and commend the efforts and value each member of a team brings.
The support and acknowledgement from my new Team at Lendable have been fantastic and this has been absolutely key to managing my impostor syndrome and building confidence to be more forthcoming with my suggestions and ideas from my previous experience.
Making an effort to show empathy and appreciation for the hard work and achievements of your teammates is a hugely rewarding thing to do and may just give someone working in isolation a boost to continue to do their best work.
I hope this collection of thoughts and suggestions is useful to someone as we continue to do our best work in the rapidly changing world of tech. If you are interested in taking the next step in your career with Lendable, we are hiring for multiple exciting roles with the option of being fully-remote or hybrid!