Start Side-Hustling
Back in university I worked in a media office, and it seemed like all the creatives had two jobs in their life: their real job, and the thing they did on the side. Our graphic designers would run a consultancy, our photographers would put together a magazine, and our videographers would were constantly shooting for events or contests.
I once asked the head of our office about this, and he sagely responded “everybody has to have a side hustle”. Although I didn’t understand it at the time, years later I’ve come to realize that he’s right: whether you’re a videographer or a software engineer, having a side-hustle at work can be a valuable way to grow your skills and impact.
Side hustling, what’s that?
A side hustle is pretty much anything you do which is not part of your specific job responsibilities. If you’re a software engineer, you could have a side hustle where you help define and maintain your team’s code review practices. Alternatively, you could spend time writing blog posts, or leading brainstorming sessions about team direction. You can even side-hustle outside of your day job (we call those hobbies), but for this purpose we’ll just focus on side hustles during your day job.
Now you may be thinking to yourself “Why bother with side hustles? Why not just keep doing and let someone else take care of that messy, non-coding, work?” The simple reason is because side hustles represent a huge opportunity for you and your team.
Side hustle opportunities exist because there’s a problem that needs to be solved and no ones currently solving it. Chances are there’s a problem brewing under the surface, but everyone else has been too busy to deal with it; this is good news for you! It means there's an opportunity for you to step up, fill that gap, and learn something new in the process.
Take the above example of a team that doesn’t have clear code review guidelines. On a team of three people, it’s probably not such a big deal: everyone has a social agreement about how code review should operate. However, as you onboard a couple of more engineers you notice that code reviews begin to slow down, and maybe start to focus more on nitpicking than important questions.
At this point, the problem is probably not the most urgent one for the team, so no manager or CEO is going to say “time to roll up my sleeves and fix this team’s code review disagreements”. However, the lack of code review standards is a very real problem, and one which left unchecked will lead to slow code reviews and a lot of grief for the team. If no one does anything and you onboard four more engineers, your code reviews may descend into slow, grinding, arguments. Fortunately, if someone steps up and solves the problem now, before it’s too late, the whole team will avoid this fate.
Side Hustles: Good For You Too
Side hustles don’t just help your team, they help you broaden your own impact. There’s always a limited number of technical problems to be solved, so you may not always be able to lead a shiny new engineering project. Side hustles allow you to find a new challenge even when the rest of your job isn’t pushing you to solve new challenges.
Once you start taking on side hustles you’ll also find that they bring you into contact with people you would have never otherwise met. These connections are rarely immediately valuable, but they can be immensely useful as you look for new opportunities, or even just a new way to solve problems in the future.
Okay, so how do I side hustle?
Great! You’re now on-board with the idea of a side-hustle and you’re keen to start your own, but you don’t know where to start. How can you get started side hustling?
Define The Problem You Want To Solve and Solve it Locally
First, you need to figure out what it is you want to solve and how to solve it. For me, this always starts with a problem that I’m experiencing for myself. Coming back to the example at hand I may say “I’ve been running into a lot of disagreements on code review lately. How can I fix that”.
With that problem in hand, I next try to figure out how to solve it locally. So, I may sit down and say “why do we do code review?” and “how can I make sure we avoid bikeshedding in code reviews?”. With those answers in hand, I’d try to build a set of personal code review guidelines and see how they work.
Look to see how the problem and solution generalize
Once you’ve gotten a local solution to the problem, the next step is to figure out how others view the same problem. The best way to make this happen is shockingly easy: talk to people and ask them how they feel about the same problem.
For me, this often consists of setting up coffee meetings three groups: peers with context on the problem, peers who are totally unfamiliar with the problem, and a brief discussion with The Decider(s), people who could block or empower any solution I come up with.1
Generally these meetings consist of me saying “Hey, I’ve been thinking about
- Is the problem a real problem, and is my solution on the right track? If I casually mention this problem to two or three people and no one says “yes, we should totally do that”. Chances are I’m looking at the problem the wrong way and need to go back to the drawing board.
- Is there additional nuance on the problem? Frequently when I float ideas past people they’ll ask something I hadn’t considered. They’ll say something like “yes, I totally agree that we should have code review guidelines. How would we have those work across teams which have different codebases and release schedules?” I generally file these pieces of feedback away and see how I can incorporate them into the project.
- Possible allies or co-side-hustlers Ideally, whenever I’m taking on a new side-hustle, I want to have once person working on it with me. This not only forces me to be accountable to someone, but also it provides a layer of redundancy and emotional support. Finding someone who is excited enough about your solution to join forces isn’t necessary, but it is helpful.
Define a project plan and an MVP
Once you've had your brief conversations and have gotten positive signals about your direction, the next step is to actually define what you’re going to do to scale up your idea. You wouldn’t launch a big feature without first writing up a design document; similarly, wouldn’t want to implement company-wide code review guidelines without having a plan for how to draft, review, pilot, and finalize them. So write down a plan for your project and make sure it includes a set of small milestones which allow you to start small, validate your idea, and then grow from there. Taking our example of code review guidelines, that plan would look something like this:
- Draft key themes of code review and get them reviewed by senior engineers in 3 disparate areas
- Take feedback create a first draft of code review guidelines, present to decider and previous engineers for feedback.
- Create a second draft of guidelines, work through second draft until all parties are satisfied.
- Create a final draft of guidelines, present it to other key technical stakeholders (maybe all principal engineers + managers-of-managers) and get approval
- Circulate final draft to see if anyone has any blocking feedback
- Share new guidelines with the org and put a plan in place to monitor their adoption.
Notice how this plan doesn't try to solve the whole problem at once. It breaks the problem down into discrete steps and then layers on complexity only once the foundations are solid. Whatever your goal is, you want to define a similar set of clear steps which provide lots of check-in points for others.
Plan in hand, it’s time to get empowered to start
side-hustling. Generally doing this consists of a meeting with The Deciders, who you
should have already identified and talked to. If not, here's a quick rule of
thumb: if it’s a team-level change, that’s probably your manager; if it’s larger, it’s probably a
manager-of-managers. Find your decider and tell them “So I’ve been thinking
about
For some people, this may seem weird. “I’m telling my boss what we should be doing? Don’t they know what’s going on?” Well, maybe, but it’s much more likely that they have 25 other things which demand there attention, so if you stroll into their office and say “hi, I’d like to solve one of those problems for you”, their first thought will not be “get out of my office plebe”, it will be “oh thank god someone is solving this problem for me.” Remember, the time between something becoming a problem and the time when it becomes a fire can be long, and filled with lots of pain.
Of course, they won’t always say “yes” immediately, but they may push you to revise/clarify a couple of plans. However, so long as you vet your idea up-front, chances are you should be able to move forward with your plan.
They said yes! Now what?
Great! You’ve gotten the okay for your plan. Now what?? How can you do your new project along with your “normal work”? The secret here is running your side-hustle just like another project.
Work in Small Chunks
You wouldn’t run a big engineering project by just trying to accomplish the whole thing all at once, and you don’t want to do that with your side hustle either. You should have defined an MVP, milestones, and a scaling plan as part of the proposal you showed to The Decider. Now’s the time to use that. If you haven't, then go make one.
Start by working on the first milestone on your project. In our case, this would mean just writing down some rough high-level principles and getting feedback on those. Execute on that piece effectively, document your learnings, and then come back to subsequent milestones based on what you’ve learned. Trying to do the whole thing at once is a recipe for getting overwhelmed, so keep your focus small.
Find the time
Once you have that plan, it’s time to start working towards your first milestone. Again, you should be treating this like just another engineering project. Start by breaking down your first milestone into a set of individual tasks, and begin working through them. You can even have bi-weekly planning meetings where you establish a goal for the week and then myopically execute on that.
I also like to block off 30-60 minute sections at the end of a day as “side-hustling time”. During this time I put down my normal work and only work on side-hustles. This calendar time is important for me, as it serves as a reminder to put down the urgent work I’ve been focused on, and refocus on making forward progress on this important task. It’s okay if I miss a couple of these, but I try to make sure to have at least one or two a week so that the project never slips into “neutral”.
You may also find that as you work through these milestones you’re stuck and don’t know where to go next. That’s when it’s a great time to shoot an email to The Decider and get some feedback from them. Chances are they can unblock you by pointing you towards a resource who can help you. Don’t expect The Decider to solve your problems, but they are useful if you’re at wit’s end and don’t know where to turn.
Get regular feedback
As you start to accomplish, you want to make sure to check back with the original person who you worked with to get sign-off. As you hit each milestone, report back to them with what you tried, what you learned, and where you are thinking of going next. They may not be able to jump in and directly lend a hand (remember, they’ve probably got other priorities), however, they will be able to serve as a good sounding board for possible landmines on your way forward.
You’ll often find that this project feels a bit slow and plodding. That’s okay! Your side-projects are never going to move as fast as the things you spend the other 36 hours a week working on. What’s important is that you keep moving forward and showing progress. If you do that, and you keep trucking through obstacles, you’ll find that over time your pilot becomes a full-blown solution. It won’t be fast, but you’ll find that the people you meet and the things you learn will make it worth the while.
1The concept of deciders is universal, but I stole this particular version of the idea from Jake Knapp's excellent Sprint book.
A big thank you goes out to Michael Stephens, who reviewed early drafts of this post.
Discussion, links, and tweets
Hey! Thanks for reading! If you like what you read and want more, you can follow me on Twitter.
Tweet Follow @maltzj