Most of my career, I have been a software developer. Occasionally I have tried my hand at managing people. Up until my current job, my attempts at management have met with mixed success. There are a variety of reasons behind this and I want to share one of them. Motivation is important to my success. As a technologist, I had a good grasp on what motivated me and was able to consistently lean into it. In my past attempts at management, I didn't make the connection that those well understood motivations for a technologist didn't apply. Even with this understanding, I struggled.
Writing some code, I feel the most satisfaction when it neatly and clearly solves the problem at hand. Building complete software or even complete features isn't always so cut and dried yet it often can be broken down into smaller and smaller problems, ones that often have one or a few recognizably good solutions. Solving a series of well decomposed problems is immensely gratifying. Stepping back, that accumulates nicely across a larger feature, system or domain. All the incremental wins quickly add up to an even deeper sense of accomplishment. None of this really applies to working with people.
I continued to grapple with this challenge until a couple of years ago when feeling particularly elevated after a routine one on one got me thinking. I reflected on why that was so, especially when I often felt frustrated or exhausted after one on one meetings. What I realized is that when I feel like I have actually helped someone in some way, that often leads to a sense of accomplishment. Helping doesn't always mean solving a problem. What makes me feel good as a manager is helping someone shift some burden enough that they can see their way to a solution or improvement. You can see it in their expression, a visible relaxation that signals some sense of relief.
At the time I had this realization, I was still working mostly as a contributor. I was also coaching a handful of people and back in the role of leading a team. The one on one was in the context of that kind of leadership or as a coach. After my insight, I at first didn't seek out this experience consistently though recognizing when it happened again helped me feel more satisfied as a coach and a leader. Later I would have the opportunity to step more fully into a management role. I didn't immediately realize how connecting more with helping people would help with this next attempt at management. Instead I hesitated, asking what I thought was a more pressing question of myself and my mentors.
What meaningful opportunities to work hands on with the technology would I be leaving behind? I felt more confident in my motivation and engagement as they related to being a contributor.
I was learning that I could find more engagement with being a manager than I had in the past. I was realizing that I would have to lean into that connection with helping others. Thankfully, I could definitely see how doing so would connect well with an opportunity I was already excited about. As a manager I would be able to foster and support the culture of my organization more directly. I was less clear on other aspects of the job, ones I struggled with in the past, especially around bigger picture thinking and strategy.
Despite my questions, especially my reservations about possibly leaving hands on work with the technology behind, I had enough cause to believe I could do the job. I suspected that I would feel rewarded in doing it based on my critical realization and limited experience seeing it in practice. Ultimately accepted the chance to step back into full time manage, feeling vaguely more optimistic about it than I had in the past.
One area where I feel I shine, in writing code and as a leader or manager, is my organizational skills. I can quickly break down a project into a reasonable set of tasks and just as easily leap in to knock each of them down in turn. I know some people struggle to come up with goals and even more to start working on them. Not me, if I am confident about nothing else, it is about being organized and following through.
That wasn't always the case, especially at the start of my career. I loved, and still do, the experience of flow. There was nothing like zooming in completely on the problem in front of me to the exclusion of everything else. What I didn't do so well at was managing interruptions. This weakness held me back from realizing my strengths as an organizer. Interruptions would knock me for a loop. I would drop out of flow and become easily frustrated trying to find it again.
At first, I tried to craft my schedule and my environment to maximize the time I spent in a flow state. I gave in to my curmudgeon nature in order to generate a little hesitation before someone asked me something. I often skipped meals or stayed very late in order to continue coding. Back then, I thought it was easier to stay in flow as long as it took to complete some piece of work. I didn't immediately realize the costs associated with my first attempts to defend my time and attention.
The problems I was tackling grew bigger as did the need to provide input to others. Staying in flow from start to finish became less realistic as my work scaled from hours and days to weeks at a time. Staying in flow wasn't compatible either with highly collaborative tasks or delegation. I was very afraid that being interrupted or even having to take myself out of flow would cause me to forget something crucial. I often used the metaphor of juggling eggs. I felt it was apt, that all the contingent memory and information relied on being in flow and didn't always survive having to step away and resume later.
I was the victim of my own success, excelling at shorter and simpler projects naturally led to more involved and ambitious assignments. Something had to give and minimizing my responsibilities was not an option. I had a deep think and came up with a pretty simple realization.
As you may have guessed, flow itself wasn't the issue. My struggle with larger projects was keeping track of all the bits of a problem and its solution. Getting into and staying in flow hid this complexity or at least allowed me to dominate it through overwhelming attention and will. Flow was still important to my productivity and engagement but it wasn't the whole picture. Originally, I believed flow simply happened, mostly through absorbing all the relevant details and applying jumping into a problem with both feet. Pondering the challenging of resuming flow on some particular project or task, I realized that I was leaning on a limited resource: my own attention and memory. I started my first experiments with journaling and task management. I quickly found that they helped me overcome this limitation.
Since then, I have consistently used some form of note taking. Keeping track of all the fiddly details some place other than my own memory made it so much easier to pause and restart my tasks as needed. Even better, I stopped skipping lunches and while I might still work late on a particular evening, it felt less compulsive. I distinctly remember a feeling of relief once I started using my notes in this way. I welcomed interruptions and the breaks that kept me feeling refreshed and energized, especially during the long stretches bigger projects required. I experimented with different task managers to complement those notes, making the most immediate requests and needs easier to find and resume.
I am currently using Taskwarrior. Taskwarrior is a very powerful and very minimal tool. I had tried to use it a number of times before. I never developed a consistent habit, owing largely to the tool's complexity. With my recent go of it, I seem to be more successful. Reflecting on that success, I realized a couple of things, one related to what helps me find motivation and satisfaction as a leader.
Taskwarrior has robust support for projects, scheduling and tagging. Honestly, the features are a lot to fully take in, let alone figure out how to use. Using Taskwarrior well really takes some investment, there isn't one simple approach to using it you can quickly adopt. Rather you need to map out a little bit of how you think of tasks and then figure out how to model those into the tool's features. You'll know you've accomplished this when your standard view into the tool matches closely to how you think about the work you need to do. The documentation has some suggestions yet there is a lot of room for variation and customization. One example is the support for contexts. The idea of a context is that it is a sort of preset filter, which is helpful as a concept but takes some work to get the full benefit.
For example, the usual examples of a context for work and for home seems like good uses of the feature. After using these simple contexts for a few weeks, I started to see that not all my tasks always stay within these compartments. There are often some time sensitive or priority tasks I worry about forgetting if I focus to closely on the context of work. The naive approach is to have a project for work and either one for home or recognize that no project is a default for home. Contexts, though, can literally be anything. You can create one that has all your work tasks plus time or priority critical tasks from outside of however you model work.
My breakthrough on how best to use contexts put me on a path to solving another problem I hadn't figured out previously: how best to use my phone along with my other devices. The Android app for Taskwarrior is a very, very thin graphical view wrapped around the powerful command line tool. It is less obvious how you craft contexts, reports and tweak the apps configuration on a phone. Thankfully, in overhauling my configs for my laptop and desktop, I realized after a little digging that I could copy and paste my contexts to my phone. More importantly, this encouraged me to create a mobile context.
Just as the examples for work and home were way too simple and required some thinking, so did a mobile context. The common examples, based on a tag like "errand" weren't enough for me. I thought about why I might only have my phone on me and what I would want to see out of my entire set of tasks. The "errand" tag was part of it but I had to combine that with a few others like tags for "convo" or "meeting". The "convo" tag for me means I may complete that task by having a hallway conversation, usually an easily answered question or small piece of information to share.
I gradually added a few other tags based on how I was modeling my thought process on tasks, productivity, especially how they intersect with settings and different kinds of interactions. Seeing how a good set of tags helped with a mobile context, I was inspired to choose a few more for other contexts. I have tags for different media, for example if the details for some task are in an email, I use the "email" tag along with a to do folder in my email client. And so it goes for the tags, "slack", "calendar", etc.
Taskwarrior has another feature that I found deceptively hard to use well, the field for a project to which a task might belong. The examples are again the usual, less than helpful ones, like a literally project, either hobby or work related. Creating a project of "work" for instance, doesn't help me. I have a lot of different areas I focus on within the broader context of work. How I might tackle each of these tasks can vary a good deal. Lumping them all into one project didn't seem to fit how I actually organized myself to do the work. I do have a tag for "work", a way of loosely grouping these tasks together as belonging to my day to day professional pursuits. I do have some specific projects at work that I also model as projects in my list, which combine well with the "work" tag to help me organize them more specifically.
Inspired by some of the tags I mentioned, and in particular how they really helped me think about how I access and prioritize tasks, I had one other insight that relates directly back to how helping specific people yields the most satisfaction for me as a manager. I thought it could be interesting to use the project field for people rather than an actual project.
I don't think people are projects, literally. In my mind, I read a task with a project assigned to a person more as an immediate reminder of who I am helping when I tackle that task. This approach may seem like a small thing. Yet many small things can accumulate to something impactful. Having a constant reminder of who I am helping taps into my core motivation. Honestly, using Taskwarrior itself does as well: I am still a technologist at heart, a deeply technical tool is fun for me to learn and use. That fun is another small thing that encourages me to keep using and evolving my use of my chosen productivity tool.
If you find yourself tackling a responsibilities of leadership or management, for the first time or the nth time, I suggest reflecting a bit on motivation. Broaden how you usually consider the question to include all of your lived experience--surroundings, people, whatever. I would be willing to guess that in doing so, you will likely find surprising, new sources of motivation and engagement that will help you be more successful at all the things these kinds of roles require.