In the past six months, my job changed from a specialist role to a generalist role, and it is totally different. Context switching has taken on a whole new meaning, and I need a new way to get organized.
In July, I was in marketing, You might call marketing a specialist role. All I did was marketing. While it's true that I worked in content marketing, then social media marketing, then brand marketing, then redesigning the website, each a specialty in-and-off itself, I still specialized in marketing. It was the only thing I really had to think about at work.
At the end of July, my job changed to a general manager of a business unit within ServiceRocket. A general manager is a generalist by definition. Now, I need to think about marketing and sales and customer success and support and product and engineering and budgeting and financial planning and organizational structure and team culture and that’s just getting started.
A general manager is ultimately responsible for running the over all business, very much like the CEO does for the entire company.
Of course, there are team leaders for each of these domains: product managers and customer success managers and engineering managers and support managers, etc. I don’t have to do it all, but I have to help and spend time on each.
If there is one thing I knew, going into this job, is that I needed to stop being a marketing person, and start being a general manager. I could not spend most of my time on marketing, even though that would be my natural tendency.
I needed to get organized and prevent myself from defaulting to marketing, so I:
Here’s how I am doing it.
Naming each domain
The hardest part of any new job is not learning the new skills needed, but forgetting the old habits you are used to, especially when you have been a specialist. I was a specialist. Marketing. So my instinct is to do marketing. Schedule marketing meetings. Solve problems with marketing.
To break this habit, I knew I needed to deliberately spend time on other areas of the business. I sat down to define them, and here is what I came up with.
Assign a domain to a day for focus
I learned (and quickly accepted) that I cannot multitask. I learned that from from John Medina in his book Brain Rules: 12 Principles for Surviving and Thriving and Work, Home, and School. We switch between tasks. We don’t actually multi-task. When we switch, we lose momentum and productivity falls. And looking at the above list of domains, it’s obvious I would be switching.
So I decided to do the same with my domains.
The question of course now is, "How do I put this into practice?”
Most of the things I work on have a Jira issue associated with them. And there are many. I knew I wanted to organize my issues in such a way that I could look at all issues for a domain together and make progress on those issues on that day. As you can related, my issues are across multiple projects and teams, and it's hard to keep them all straight.
Then it hit me.
Swimlanes are my friends
I created a kanban board, which I called uncreatively: Bill’s Master Board. I won’t go into kanban boards or swimlanes more than to say this. I created five swimlanes named for each of my domains, which created a row on my kanban board and displays only the issues for that domain that I want to show up in that swimlane.
Then, I used labels to define which issues go into which swimlane. I chose labels (instead of components) because labels are simpler and more flexible, and since I wanted to start quickly, labels take seconds to implement.
Since I am a generalist, many things I work on are cross-functional and not everything I work on even fits in one of these domains, so labels allow me to “label” any issue I want or not label an issue. I try only to put the big important tasks for each domain on this board.
It’s not perfect, but...
The one thing this helps me with most is reminding me to spend time deliberately on an individual domain for a set period of time. It reminds me that I am not a marketer. I am a general manager. “Today is Thursday. I am working on customer issues and working with our customer teams today.”
This is not to say I only work on customer issues on Thursdays, but I am getting there.
My next move
I am going to start only (well mostly) accepting meetings for domains on days I deal with those domains. Sometimes I still take a product meeting (Tuesday domain) on a Friday (Planning & Finance) because that is the best available time for that meeting. This is a slippery slope into ruining the theme for the day.
I use Calendly to make scheduling meetings simpler. I plan to set up a Calendly event for each domain. If someone wants to schedule a meeting with me about engineering, I will have them book it using the Calendly link for that domain. If the next available time isn’t until the third Tuesday in March, I might have to say, “So be it.”
I am a little nervous about doing that. But this is a real life example of a kink to work out.
Being a generalist is hard.
Jira makes it a little easier.