Onboarding with 1:1s, dependencies, and personal workspace 💡
Monday Ideas — Edition #90
This edition is brought to you by Tonic!
The Tonic test data platform provides teams with the tools and integrations they need to transform sensitive production data into realistic test data that’s safe and easy to deploy across pre-prod environments.
From data masking and subsetting that preserve referential integrity, to ephemeral test databases spun up on demand, Tonic enables you to keep your environments fresh and in sync with quality test data to fix staging, catch bugs faster, and shorten your release cycles.
(Oh, and yes, it comes with a full API.)
1) 💬 When you are new, just talk with everyone
One of the most underrated tactics to onboard yourself well in a new company is to have 1:1s with literally everyone who is even remotely related to your job.
Do that in the first 30 days, and don't wait for your manager to take care of this.
How to?
Create a list of all the people in your team and key stakeholders in the company. Don't be afraid to reach out to the manager of your manager, and others that feel "too high". Nobody ever gets pissed off for this.
Prepare some questions to make this both a moment of bonding and learning. Here are a few:
What should I know about the product / company / people?
What is the biggest challenge that you face?
What can I do to make your life easier?
Who else should I talk to?
You will be surprised by how much you can learn from people with casual chats, where there are no expectations whatsoever.
This was one of the best pieces of advice I received from Aadil during our chat last week:
2) ✂️ Prune your dependencies
Most applications today have just too many dependencies. Dependencies spread out for many reasons:
Templates and boilerplates bring in stuff that you don’t use.
Different teams use different libraries for the same purpose (e.g. HTTP calls).
Dependencies from dead or pruned code are never removed (”maybe this is used elsewhere?”)
Keeping a few dependencies is crucial, because dependencies, in turn, bring various problems:
🔒 Security — they increase your application’s attack surface.
🚚 Release — they increase build and deploy times.
🔧 Maintenance — they require constant work to be kept up to date.
The best way to keep your footprint small is prevention:
Create a developer portal to keep consistency across teams (e.g. with Backstage).
Explicitly favor using libraries you already use, instead of new ones (e.g. you can write this down in your design doc template).
Whenever you remove some code, check if you can remove some dependency.
On top of this, you can also do periodic clean-ups — e.g. once a quarter — where the whole team spends a few days squashing unused / redundant dependencies. Or, if you do bug duty, you can make dependency pruning part of the duties.
I listed more techniques (and resolutions) you can adopt for the new year in this recent piece 👇
3) 🌱 The PRT System
In November last year I wrote a piece about Personal Knowledge Management, where I detail the workflows I use to run Refactoring — and my life.
In my workspace, I have three main buckets: 🔨 Projects, 🔄 Responsibilities, and 🏷️ Topics (PRT).
1) Projects 🔨
Projects are things I want to achieve on a defined timeframe. They have a beginning and an end, and are bigger than a single task (I can’t complete them in one sitting).
I create 5-6 projects every quarter, and that includes both Refactoring projects and life projects, e.g. the recent relocation we did, or our honeymoon.
2) 🔄 Responsibilities
Responsibilities are activities that I do on a regular basis, for which I need to maintain a standard. E.g. writing on social media, or running interviews with guests.
The defining feature of a responsibility is that it is recurring: it doesn’t have an end. So, while projects require plans or roadmaps, responsibilities require procedures about how to perform them.
I usually have a recurring task on Todoist for each responsibility, linking back to the procedure on Notion.
3) 🏷️ Topics
Finally, topics are areas of interest. A topic is anything that can be useful in the future. Examples are “frontend”, “no code”, or “sim racing”.
Topics are the least actionable category. It’s stuff that I believe it is worth saving, but I have no expectation of doing anything with it in the near future.
The Projects → Responsibilities → Topics organization kind of goes from the most actionable to the least.
New activities always start as projects, to kick them off. Projects may eventually turn into responsibilities: e.g. I start doing paid ads (project), and eventually I need to manage them weekly (responsibility).
So, when I organize my notes (check the full article for more) I take those that are unassigned — no project, responsibility, or topic is attached — and I assign them to at least one of these buckets. Each note may belong to either a project or a responsibility, rarely both, and can have further topics attached.
For doing this, I use Notion. Notion can model this organization through database relationships, which is flexible and powerful in many ways. Its ability to use views, formulas, and rollups, to me, is simply unmatched.
The main drawback of Notion, if you ask me, is that it is slow, and a bit cumbersome on mobile. This would be an issue if I used it for capturing stuff, but I mostly don’t, so all good!
To me, for organizing, flexibility > speed.
🗳️ The State of Engineering Productivity
Finally, I have a quick ask! 🙏 I am conducting a survey about what makes engineering teams productive: practices, usage of metrics, tools, etc.
If you want to help me out on this, you can fill out the survey below 👇 it takes less than 5 mins.
Thank you, it means a lot!
And that’s it for today! If you are finding this newsletter valuable, consider becoming a paid subscriber — 1500+ engineers and managers have joined already!
Learn more about the benefits of the paid plan here.
I wish you a great week! ☀️
Luca
I like the PRT system.
Currently I have the PARA system (more or less), but I'm not 100% on board with it.
Love the 1:1 onboarding tips! In fact, that is also what I did when I was onboarded remotely during the pandemic. I tried to schedule a 1:1 with all the team members and get to know them. This helps me build the initial trust with the team for my first 30-60-90 day onboarding.