Why Do It?

For the third and final blog post (this week) about the textbook system I'm developing at the day job, I thought it would be interesting to answer a question that some colleagues have asked over the last couple of months. Namely, why am I working on a project that has never been officially requested by management and why do I invest so much personal time into improving the system when there is a very real possibility that it will be axed early next year? The simple answer that I generally lead with is "Because I'm an idiot" but, as with anything in life, the deeper answer is much more nuanced and complex.

In yesterday's post, I referenced Rule 33 from Jordan Peterson's Quora post on the most valuable things everyone should know, which is a concept I've understood for decades but have never been able to adequately articulate. However, of the 40 "rules" that were shared, there are a dozen of them that can be directly pointed to for why I do what I do at the day job and elsewhere.

So let's run through them in a little segment that I'll call:

12 Justifications for Self-Assigning a Project

For the sake of expediency, the justifications will be listed in numeric order rather than by importance.

Rule 2: Do not do things that you hate.

This is a good rule. I hate not solving problems that I am presented with. Colleagues from all over the country provided a list of issues they wanted to see fixed, and I provided a solution that cost the company effectively nothing. Why did I build a custom piece of software rather than aim to improve the existing system? That's part of the next justification.

Rule 4: Pursue what is meaningful, not what is expedient.

Complex problems are generally solved with complex solutions. The existing textbook system at the day job is a mission-critical tool used by instructors and students across the globe. It would make no sense to try and bring about drastic changes to that system without first having some idea of what works and what doesn't. The Mimosa textbook system I developed has been dubbed a "playground" right from the very beginning as it can be broken without consequences.

Rule 5: If you have to choose, be the one who does things, instead of the one who is seen to do things.

Doing things is important. I feel job satisfaction when I stand back and examine something that I did, not something that I participated in. This is certainly a problem of ego, but there is nothing bad or evil about wanting to take the lead on solving a problem, particularly when it's a problem that was handed to me by front-line colleagues.

Rule 6: Pay attention.

This is key. By paying attention I was able to learn about the issues that people were facing despite working from a home office. By paying attention it became possible to identify the people who could most help with the endeavour. By paying attention, the project contained a solution for just about every problem that people reported.

Rule 11: Make at least one thing better every single place you go.

We should all try to do this. I want to help colleagues get more out of our technology by using tools that are pretty much transparent. There should never need to be any need for training on the software I build for the day job. If it's not blindingly obvious what a function is for or how to navigate an application, I've not understood the problem correctly.

Rule 16: Work as hard as you possibly can on at least one thing and see what happens.

This is exactly what I'm doing with the Mimosa textbook system when time permits. If I solve enough problems, will this system be rolled out globally? Will some of the new UI elements I've developed be adopted elsewhere? Will instructors ever "forget" they're using a digital version of a textbook? If I work hard enough and polish the system well enough, at least one of these situations will likely come to pass.

Rule 24: Nothing well done is insignificant.

This builds on Rule 16 above, and I agree. If a solution is done well -- even if it was never "officially" requested -- there will be some significance. There is seldom just one way to reach a goal.

Rule 29: Don't avoid something frightening if it stands in your way -- and don't do unnecessarily dangerous things.

A lot of people I've spoken to over the years who have had ideas worth exploring gave up either out of a fear of failure or a fear of rejection. Nobody likes to appear incompetent in front of their peers and nobody likes to have their idea or opinion dismissed. That said, we don't know what we're capable of until we go for it, and a lot of times people reject ideas not because they're unsolicited, but out of a lack of understanding. Taking on something that is frightening also builds on Rule 28, which became Rule 1 in 12 Rules for Life; Stand up straight with your shoulders back.

If we meet the challenges that life throws our way by presenting our best selves and moving forward, then we will get a lot farther than we thought possible. This does not mean we will always win, but we will inch ever closer to the goal.

Rule 33: Notice that opportunity lurks where responsibility has been abdicated.

This one has been discussed already. Textbook publishers have proven capable of creating very interesting knowledge-based digital educational materials, but skills-based resources are still rather primitive. By paying attention, working hard, and doing the job well, there is a good possibility that my solution will be seen as a viable tool for the global teacher and student base.

Rule 38: Write a letter to the government if you see something that needs fixing -- and propose a solution.

This rule specifically says "the government", but it doesn't necessarily mean the nation's leaders. Instead, we can look at this as "write a letter to a person with authority". This can be a politician, a business owner, a manager, or even a family member. The second half is key, though. Propose a solution. Otherwise the concerns raised, regardless how valid, may come across as just unsolicited complaining. This is generally how I do new things at the day job:

  • devise a solution
  • create the solution and test it, recording data as you go
  • confirm the solution solves the problem well
  • present the solution to an authority in the form of a demo, as pictures say 1,000 words
  • get buy-in

This doesn't always work, of course. When it does, though, problems are solved.

Rule 39: Remember that what you do not yet know is more important than what you already know.

What I don't know can fill a universe. Every day there's something new to learn about the day job, the teachers, and student expectations. I generally try to keep my ear low to the ground so that comments, concerns, and feedback are heard loud and clear. This point also lightly touches on Rule 7: Assume that the person you are listening to might know something you need to know. Listen to them hard enough so that they will share it with you.

We can learn a lot simply by listening.

Rule 40: Be grateful in spite of your suffering.

We mustn't forget to appreciate what we have as we never know when it might be taken away. I'm grateful for the opportunity to build new tools solve complex problems, which are things I might not be able to do if I were working at a typical Japanese company.

A thirteenth rule we might want to remember is this:

Rule 13: Do not allow yourself to become arrogant or resentful.

Arrogance and resentment blind us far faster than we might realise. If the things we create are accepted and welcomed by colleagues, it's important to maintain perspective. The same is said if a project is rejected and countless hours of effort are tossed away. That said, I still have a lot of work to do to keep these two emotions in check.

These rules encapsulate so many of the justifications I have for why I do the things I do and are a far more complete answer than "Because I'm an idiot".