I don’t know what I was expecting
I knew that this was going to be different. Unlike traditional companies with whom I’ve onboarded over my (mumble-mumble) years of professional software engineering, Commit is focussed exclusively on building an engineer-first company. The executive team call themselves the “Support Team,” and measure success on the basis of the happiness of the engineers who are called “Engineering Partners.” Because Commit is remote-first, the onboarding process is designed to be completely remote and is largely self-guided.
It’s a simple checklist, a Google doc, outlining tasks to be completed on each of the first seven onboarding days. For example, starting at Day 0 (of course): Get added to the Commitdev org on github, post “Hello World!” to Slack #general channel, attend All-Hands meeting. Standard stuff really.
But as I preview ahead days 1 through 7 I start to get a little bit worried. On Day 7 I’m supposed to do a demo for the team. What am I supposed to demo? Days 4 to 6 I’m scheduled to be working on this project. But what is it? By Day 3 I’m supposed to have a pitch written.
“Anything you like”
This is the answer I get. “It doesn’t have to be of any benefit to Commit.”
Okay, I don’t get it. Now this is officially strange. Commit wants me to spend a week on anything I like? I’m an engineer, I kept thinking to myself. I’m your humble servant. “Simple service simply given,” as Kipling put it. I need direction goddamnit! I don’t know what I like!
What I did know was that I was going to have to come up with something—and fast. I’ve been in this game long enough to know that if I have to demo next Thursday I’d better have something 95 percent finished by Monday. The last five percent of any job takes at least 50 percent of the time. I know that math doesn’t add up, but, dear reader, am I wrong?
Day One
Luckily, I know people. First, we have my onboarding partner Djordje. “DJ” onboarded just a few weeks before I did, so he knows firsthand what to expect. “Do they really want me to work on just anything?” “Yes,” he said. “But take notes. They are going to ask you to write a blog post about it.” I meet with DJ almost every day of my onboarding.
I still have absolutely no idea what I’m going to do. But in the All-Hands meeting is a former colleague I wasn’t expecting to see. Paul is a senior product designer who I worked with at another tech startup in town. What is this designer doing here? Do they know he’s not an engineer? In fact, Paul presented at the All-Hands some conceptual designs for the in-house product, code-named Helix. I knew Paul would have some great ideas for my onboarding project! So I set up a meeting.
Paul had some great ideas all right!
You know what’s funny about software engineering? In my experience (and let me know in the comments if this rings true for you) things take a long time to build. And test. And review. And deploy. A long time. Almost always longer than you’d think. There are fires to put out and traps you can fall in and cascading tangents to follow and get lost in. Nothing ever works the first time, and if it does, you seriously need to look at whether you are testing it properly. Nothing comes for free.
So while hooking up to, for instance, the Linkedin API or the Glassdoor API or the Google Maps API, and then hitting those endpoints, parsing the results and displaying that information in a nicely styled way on Helix, might be easy to say, but I don’t see that it’s feasible to do in, oh, just four days now. (Can’t count demo day itself.) It might take more than a week just to get authenticated to hit those APIs, for one thing.
But Paul was extremely helpful. He shared with me all the latest conceptual designs for Helix on Figma. One of the new designs must have caught my attention, but it took a little while for the lightbulb moment.
He also said something that I hadn’t considered before. “Imagine a world beyond Slack.” I’ll just leave that there. Head asplode.
Day Two
None of my ideas are feasible for my one-week timeframe. (Less than one week now.) I need to come up with a solid idea, today.
I’ve been meeting every day with DJ so far. He’s great. Very helpful and friendly. He likes all my ideas, but I can tell none of these are going to work.
Luckily I know people. A former engineering colleague, Jason, is working with Commit as an EP. In fact, it was Jason who referred me to Commit. I was hoping that Jason could help me decide on something that was a) feasible in the timeframe, and b) going to demo well.
I’m an introvert, but I love giving demos. I think I do a good job engaging with the audience and explaining what we’re looking at. I get passionate about my work and I think that comes through in the demo. But I don’t like to demo garbage—who does?
It was delightful to meet up with Jason. One idea he came up with was a Slack bot to help with onboarding steps. Interesting. But then he said something that hit me. “They really don’t care what you do. Think of it as a hackathon project.”
Of course, this was what everyone had been trying to tell me, but I didn’t get it until then. Oh! It can be anything. It doesn’t need to be useful, or to integrate with their existing product. It’s funny how things go because that freedom to create allowed me to build something useful and integrated with Helix. But I still didn’t have that lightbulb moment yet.
I was thinking about that Slack bot to help with onboarding, and the chat with Paul about how one day there won’t be a Slack (!!) and I was reviewing my checklist and it hit me: I could build an onboarding wizard into Helix, not Slack. I’d seen something like this in Paul’s designs. A day-to-day checklist on what you need to complete as an onboarding EP, built into Helix, not into Slack. This was the lightbulb moment. Plus it was kind of meta. I like that. As part of my onboarding, I’ll build a tool to help with onboarding. That’s perfect.
Days Three to Six
So now, once I had the idea, everything flowed into place. DJ loved the idea. My pitch basically wrote itself. I called it the “Helix Onboarding Wizard.” I included a picture of Ian McKellen as Gandalf ‘cause I figure he’s the best wizard.
I could use Paul’s designs as a guide, but I was not tied to them. This is a hackathon project. I didn’t get it at first, but I do now. The onboarding project is not the point. The journey is the destination.
I’ve already pulled down the source for the Helix project and read through the READMEs and other relevant docs. All the documentation was up to date and everything just worked. I’d decided to use the Material UI Stepper component as the main base class for the wizard UI, and rather than just use a label, have the stepper step through Panels instead. I tried a quick prototype and it worked fine. A couple of browser console warnings that I decided not to worry about. Remember what I said about traps and tangents? Stay focused. On the backend, we’re using a Postgres DB and I remembered enough SQL from (mumble) years ago to punch in the onboarding data from the Google doc. All the routing and everything is already set up. The end-to-end vertical slice was finished by Day 3. I’m delighted.
By Day 5 everything is working great and looks awesome. I can walk through all the onboarding steps in the wizard and check off the ones done, and leave the ones I haven’t. I added features like embedded video and styled links to the documents, and auto-scroll to your current onboarding day. All the styling looks like the Figma designs, but also fits with the Material-UI components. All the data is coming from the database, so the demo was live and not canned, which is always a little more impressive.
Day Seven
I’m nervous before the demo but it’s that good kind of nervous. I have a feeling that the wizard will show well. I’ve prepared a couple of jokes that I’m hoping will sound off-the-cuff. I’ve invited all my friends! In addition to Jason and Paul and DJ, Lillian and Adrian are here from my former company! I’m feeling comfortable because these are my people, even the folks I have not yet met. We’re all Engineering Partners here. We’re working together as a community.
Epilogue
The demo went so well I was asked to do a repeat performance at the following week’s All-Hands meeting for the whole crew. I’m happy to be here. This feels different than anything else before. I’m excited about the future because I’ve joined a community that cares, fundamentally and existentially, about my future and my career as an engineer.
Strange, but true.
Tim Rhodes is a Senior Startup Engineer with over 15 years experience. He has a passion for delivering high-quality software products and solutions that truly meet the needs of clients and functional business teams.