Canvassing as a Software Engineer

Earlier this year I finished the book Tools of Titans by Tim Ferriss. I could say a lot about this book (and Tim) in general, but I’m going to focus on one of the sections that was valuable to me: The Canvas Strategy (AKA Canvassing).

I don’t recall the name’s meaning but the strategy goes like this: Do stuff that nobody else wants to do to make yourself valuable. My favorite example that Tim gives is that of Patriots’ head coach Bill Belichick. Belichick volunteered to watch film for hours on end to prepare for upcoming games. He did this extraordinarily well and shared his learnings during team meetings. His expertise eventually made him useful in increasingly important decisions which led to promotions and ultimately the head coach position. He has won more super bowls than any other head coach in NFL history.

This strategy is especially effective for newer, entry-level employees (a la Belichick) looking to move to a more senior role but can also be extremely valuable for senior developers as well. I go into a bit more detail about this later on.

Reading this section of Tim’s book made me think of when I first started working remotely for my company, nearly 3 years ago. I was unknowingly using the canvassing strategy to improve my career prospects as well as prove to my company that they made a good decision to keep me on board as a remote employee. Here are a few things I did.

Release Management

Releasing on Android is relatively simple- all you need to do is upload a file to the play store and you’re live. For a business, however, there is much more overhead to a simple release. Wrangling translations, handling staged rollouts, working with QA to fix any blocking issues, as well as monitoring crashes are standard for every release. All this can add up to a full work day, distributed across 2-3 business days. I handled every release (which we did every 2 weeks) for over a year during this time. It’s easy work, aside from slightly high-pressure debugging/bug fixing, but nobody wants to do it.

Once I was no longer the release conductor for every release I would still monitor crashes. My work schedule starts and ends 2 hours before the rest of my team. When crashes come up on a new release I can have it fixed before anybody else logs in.

Code Review

Very rarely does code review lead to a promotion and it is not easy to quantify on, say, yearly reviews. I personally do not hate code review as much as some of my fellow Android comrades, but code review is generally seen as a chore. It takes time that does not directly move the product forward and which is seen more as an expense in software engineering.

I was the beneficiary of excellent code reviewers when I was first getting started in Android. To this day, I believe code review to be one of, if not the, most important way to learn. I reviewed probably 75% of pull requests made into our repo over the course of a year.

Ad-Hoc Requests

My team gets pinged with various requests and questions a couple times a week. Being the go-to person for these can be time consuming and will interrupt your workflow. For these reasons, nobody wants to do it. Answering and following through with these questions and requests is the best opportunity to apply the canvas strategy. These requests also let you meet people across the company which is rewarding in itself.

Conclusion

The premise of canvassing is to do things that others don’t want to do in order to create value. By definition, utilizing this strategy will come with a bunch of miscellaneous work such as extra bug fixes, working on team processes, mastering Jira, taking meeting notes and so on and so forth.

A big word of caution here: make sure that you’re doing things that help progress your career. Canvassing does not mean to do things outside of your role. If you’re a software engineer it isn’t up to you to make a pot of coffee for the office every half hour. Do things others don’t want to do inside the bounds of your role and career goals.

Finally, start small. If you’re first getting started as a software engineer it is going to be very difficult to take on a lot of these tasks. When you see a request come through that you have some context on, take it. When you see a release crash that looks familiar, take it. Volunteer for things very slowly at first. Gradually you will get a better handle on things, your debugging skills will improve, and you be able to take on more and more.