Category: Reflections

The North Star

The North Star

by akc

The North Star

If you find yourself in a situation where you need to lead your team through transformational change, one of the things you’ll need to do is articulate a strategic vision that they can rally around. One way to approach this is by treating it as a mini strategic plan, but depending on the scope this might feel like overkill for a project at a division or department level. And anyway, a strategic plan might not be an easy way into the vision for the folks actually doing the work that will be impacted. (This is especially true if they tend to feel disconnected from your organization’s strategic goals.)

Plus, you might get mired in the “plan” part of strategic planning. You know where you need to get to, but there’s a landscape of unknown unknowns between you and your destination. You may not know the details of how you’ll get there, or what kind of problems you’ll have along the way. How can you plan for all of that if you don’t have the expertise or the time to figure it out? 

This is when you might reframe your strategic vision as your North Star. You can see the North Star, but it’s far away. You can’t really tell how far, or what’s in between it and you. Sometimes it’s occluded by the clouds; at other times you might be distracted by something else in the sky. And you probably have no idea what it’s actually going to be like when you get there. Sounds like transformational change to me.

This worked well for us with customer support. We needed to create significantly more operational efficiency, so we could scale as the business grew. We also needed to improve the customer experience. Ultimately we wanted to set up a customer self-service website where users could find answers to common questions and more straightforward technical issues, and then just as easily submit a support case if needed. 

There was a lot of other work to do before we could build a self-service site, starting with overhauling case handling. I used the self-service website as our North Star throughout the process of building out modern case handling tools and revamping the business processes for support. Having a clear North Star was a helpful way to frame some of the decisions we made. “Will this work for us when…? How do we set this up if we eventually want to…?” 

I find the concept of the North Star also helps when you’re feeling a bit overwhelmed or tired of the initiative. It offers a way to think about your goal that’s less focused on the work, and sets up the destination as something to aspire to reach. Sure, you still have to do all the tasks and actions, but you don’t always need to have them front and center when reminding yourself why you’re doing all this work.

,
The MVP Mindset

The MVP Mindset

by akc

The MVP Mindset

One of the downfalls of leading (or being a member of) a high performing team is that the bars get higher and higher. And I do mean bars, plural — there are two. The one set for you by your organization, and the one you set for yourselves. If you’re a busy team, or if you have lots of competing priorities, keeping your own standards high can sometimes slow you down.

Having high standards for yourself or your team isn’t intrinsically a bad thing. I’d argue that you can’t be truly high performing without high standards. But past a certain point, you should consider whether it’s slowing you down too much. Maybe you have plenty of time and capacity on the team to quickly create something amazing, but it’s more likely you don’t.

This is something my team and I struggled with. As our workload increased, I was trying to get better at noticing when we’d set the bar too high, particularly for training materials and documentation. My framing for this was “done is better than perfect.” That was helping around the edges, because it gave us a way to think about whether something was at the point where tweaks and changes weren’t doing much to improve the end product.

But something was missing. “Done is better than perfect” doesn’t help you think about quality; the focus is on completion. We still have high standards, but we need to adapt them for reality. It also didn’t resonate for me for a project larger than a single handout or blog post.

Then we encountered the Agile concept of the Minimum Viable Product (MVP). This is the simplest product you can get away with — something that will meet the core requirements and be good enough to release. Once it’s in your users’ hands, you can start getting feedback from them and using that to inform your next steps. There are probably some features still on your list, but now you have space to incorporate new ones and do some informed prioritization. Plus, you can more easily make changes to what you’ve just built and validate your assumptions about what your users will and will not actually use earlier in the process.

Eventually we started thinking about our other work in this way. It can feel odd to take this approach with customer-facing stuff, especially when it’s something that you don’t typically see labeled as a beta, like training resources or documentation. One way to think about an MVP in that scenario is by asking a question — is this ready for users? “Ready” can mean a lot of things, but it isn’t as final as “done.” Something can be ready before it’s done. And if you don’t have anything at all, even an imperfect version 1.0 is an improvement to your users.

This approach also supports a mindset shift. Instead of putting your project out there when it’s finished, you go into it knowing you’re going to continue to work on it after you release or distribute. And that you’ll be incorporating user feedback. That could be data from usage patterns, feedback from a few ad hoc conversations, or an analysis developed from a more formal approach.

This can be a great tool for engaging customers. People love to share their opinions, and pulling back the curtain on something like training materials or documentation is a low-stakes way for the organization to give customers an inside look at how things are done. You get the feedback you need, and you’ve helped to build the organization’s relationship with that customer. The customer gets to help you with something that will help other users, and it’ll be a much faster turnaround to when they can see their ideas incorporated. (Because you will follow up and share the next version, right? Right.)

Working to “ready” instead of “done” can feel a little awkward when you’re struggling with some aspect of whatever you’re creating. Take this post. I’ve been working on these last couple of paragraphs for a couple of days now. Is it done? No, I think I need a better conclusion. But is it ready? Absolutely.

,
Do Most of The Things

Do Most of The Things

by akc

Do Most of The Things

As a manager, I don’t think it’s unusual to find that you can’t get through all of your actions and to-dos every week. I certainly couldn’t, and this only got worse as the scope of my team’s responsibilities expanded. I also found that there was sometimes a disconnect between my strategic priorities and how I prioritized tasks on a micro level every day.

I tried to just be more mindful of this, but that approach only got me so far. When I transitioned to a new boss, he introduced me to something that turned out to be a great tool to address that disconnect: 30x5s.

Your 30x5s (aka “thirty by fives”) are your five top priorities for the next month. You probably have a few other projects to work on, so this should be the five most important. Your 30x5s should be more specific than “work on the self-service site” but higher level than “write a ticket to have the new fonts added to the self-service site.”

My boss circulated his 30x5s to his team, and had all of us share ours with one another. I also shared mine with my team, who seemed to appreciate having an idea of where I planned to spend my time over the next few weeks.

Once I got into the swing of it, it didn’t take me long to write up my list. First, I’d start with any time-consuming non-negotiables. Things like budget development, performance reviews, or prep for a big cross-functional meeting. The types of things I had to prioritize over other work, or couldn’t realistically assume I could do on top of my typical workload. Likewise, if I was taking a week off I put that on my 30x5s to represent a reduction in my capacity.

Once I’d identified any non-negotiables, I’d think about work that related to my team’s strategic priorities. This stuff was usually crystal clear for me, and I knew exactly what the focus for the month would be. (Our strategic priorities were effectively my performance goals, but if yours aren’t, you’ll want to look at those as well.)

Last, I’d prioritize the list. Sometimes I had more than five, and in those cases I could see which one didn’t make the cut. I might still work on that project, but I wasn’t planning for it to be a major focus. Prioritizing also played into how I’d use the list over the course of the month. Here are a couple of (lightly edited) examples of what my 30x5s would look like:

Month A 30x5s: 

  • Complete all appraisals
  • Prep for, run, & first follow up for fall retrospective
  • Consultant recruitment
  • Prep, run, follow up for Q3 support ops meeting
  • Stakeholder demos for self-service MVP

Month B 30x5s: 

  • Write annual performance goals
  • Consultant decision & contracting
  • Create & finalize next year’s Service Console roadmap
  • Stakeholder review & soft launch of Learning Commons
  • Vacation time! 

After I shared my 30x5s, I’d write a shorthand version on a sticky note that went on my monitor. I used it when I planned for the week ahead, but it was even more helpful throughout the week, as I prioritized on a micro level. If I had some unexpected free time I’d use my 30x5s to decide what to do next. Typically I’d try to work on something related to one of my top two or three. 

Writing up my 30x5s also helped me feel better about the things that didn’t make the list. There was always more work than I could actually do, and having a tangible reminder of the current priorities helped me let go of some of the anxiety around that.

While this worked really well for me at the time, I’m not sure if it’ll feel equally as useful in another role, where I’m (hopefully!) not pulled in as many competing directions. But at the very least it’s a good way to think through the month ahead.

What about you? How do you manage that gap between daily to-dos and strategic priorities?

The Six Things You Do As a Manager

The Six Things You Do As a Manager

by akc

Shortly after I became a manager, I came across a post on Rands in Repose that was new to me: A Disclosure.

Towards the beginning, he briefly talks about the change that happens when you transition to management: You don’t make things anymore. Whatever it was you used to do was probably tangible in a way that your work as a manager isn’t.

Before I became a manager, I was creating and delivering training presentations, writing customer documentation and training materials, and handling support cases. After I was promoted, there was a stretch where I was very much a player/coach. That overlapped somewhat with a period when I was deeply involved in the details of my team’s work because it was clear that we needed to make some significant changes to the way we did the things we did.

As that second period came to a close, I strugged with the loss of tangible output or progress. Especially when I felt defeated by the uphill slog of fighting against organizational inertia, or resource scarcity, or internal indifference. I’d end the day wondering – what did I even DO today? I went to meetings. I sent emails. There’s no real evidence that I’ve done anything substantial.

I was just starting to figure out that there was a little more to it than that, but it all seemed nebulous. Rands explained to me what I was doing, and my role clicked into place. I distilled his writing into a list I tacked up over my desk.

The Six Things You Do As a Manager:

  • You are a communication hub.
    • Abstraction & filtering. Synthesis.
  • You are multilingual / a translator.
    • Help colleagues understand one another. Make connections.
  • The bizarre organizational stuff whizzes by you.
    • Stay composed. Handle it.
  • You are the caretaker of No.
    • Defend your team & your business against organizational insanity.
  • You provide the structure for moving forward.
    • Say yes, but frame it. Start to light a path through the unknown.
  • Trust so you can scale.
    • Teach what you’re good at. Trust the team to do the work.

These were the things I was actually doing. I was producing a constant flow of questions, decisions, actions, and reactions that would eventually add up to something meaningful. My daily output was very different, and sometimes less satisfying than what I was used to. Progress also slowed down and became much more incremental, becuase I’d shifted from working on projects I controlled to initiatives I sometimes didn’t even have influence over.

Once I started to understand my work thorough this perspective, I could see what I’d accomplished each day. The next challenge was coming to terms with the much longer timescale I needed to use to measure my progress.