The North Star

The North Star

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

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.