Driving Adoption

Getting a new system or process setup is a challenging process. You need to build buy-in for the idea, convince folks to spend money and time acquiring it, and then actually go and get it. Getting to this stage is a big accomplishment… but the work is only just beginning.

Once you’ve got a new system or process, you need to convince the broader audience of your organization to adopt and use it. Many teams will spend a lot of time and resources on implementing the system, on to run into challenges with adoption as they don’t give it the same focus.

The acquisition phase of a project typically involves a smaller, more focused group, the adoption phase expands the focus to a much broader audience (sometimes the entire org!). This means that while the general form of securing adoption is similar, you’ll have to use different tactics and strategies to communicate with them.

Identifying Users

Adoption begins with identifying who should be using the platform. For example a new legal system might impact all of Legal, but also other users who would submit requests. A new ticketing system would impact support, but may also need to include folks from IT to help administer it. A new knowledge base may impact the entire company, but have a deeper impact on some specific individuals as well.

Many times these folks may seem self-evident, but making time to dig in and understand who will be expected to use the platform is still important. Not only will it validate your assumptions (something that in itself should be done more) it will also help uncover other groups who may not be as obvious. Identifying who will be impacted is also critical to the next step - understanding what they’ll be doing with it.

Understanding Needs

Once you’ve identified who will be expected to adopt the new platform, you’ll need to determine what they’ll be doing with it. For example knowing that HR will be expected to use a knowledge base is one thing, understanding how they’ll be using it to craft and share their policies is something else entirely.

Depending on what resources you have available this may also be done in conjunction with outside help (e.g. whomever helped implement your system). That said, this step should always include some representation from the impacted teams - after all, they know their processes and needs the best! Work with those groups to identify champions - individuals who are engaged and motivated to help out. Champions will help you not only uncover use cases and processes, but also help in future steps - building documentation, evangelizing and more.

Training Development

Once you understand what the target groups will be using the tool for, you’ll need to get detailed training and enablement information together. This could take the form of vendor-provided recordings or other off-the-shelf information, but it should be supplemented with tailored training for your team. (I find that off-the-shelf information is great for more generic processes, e.g. “how to enter XYZ record”, but specifics vary wildly between groups, so having details unique to your org is critical).

This is also a great place to involve your champions, or other individuals from the impacted group, as they can help build, or at least review, the training material. This will both help catch weak-spots, but also make buy-in a bit easier as you can have those individuals help train others.

Your training should also consider different methods - written, recorded and live - to help capture the broadest possible audience. This does take some more effort, however, having different mediums available helps ensure more folks actually take the training.

Communicate

Communicating typically happens at all stages of this process, however, now it is beginning in earnest. Not only will you be communicating status updates to stakeholders, here you’ll be sending targeted information to groups that will be expected to use the platform. These could take the form of detailed schedules explaining when things change, index of training, invites to live training and more.

The goal is to ensure no one is surprised by the change, as well as that everyone understands the impact of changing to a new system…. After all, it will require everyone to change their habits and how they work, so they should clearly understand what is happening.

Communication shouldn’t only come from you, however… work with executives and leaderships to help spread the message (one trick I like is to get a short video of execs endorsing the platform.. It’s a very low lift that can have a huge impact). Working with individuals who are well-known in the target group and having them send comms is also a great way to help increase the impact of your communication.

Followup

Once the system is live your job isn’t over - it just changes shape a bit. You’ll still need to focus on communicating updates, expectations, stats and more to help support the team. Follow-on training is also always a good idea, as are showcases drawing attention to ways the tool is being used (e.g. “look at the amazing work HR is doing - you can do it too!).

Many teams find it helpful to schedule regular reviews of their adoption - quartlerly or twice yearly. This gives them a set time to sit down and review how things have been going, determine next steps and improve offerings. This step is commonly missed, however, regular reviews give you a great opportunity to improve adoption over time.

Conclusion

Adoption is one area that many groups struggle with - but it doesn’t have to be a challenge! Taking time to pull together a team and supporting the impacted groups is always worth the time spent.

The Importance of Ticket Deflection

Any given support team will collect a large amount of tickets. These can range in complexity from simple to complex, and require a wide range of skill sets to manage, track and resolve.

The first step in handling those tickets is to gather them all in one spot with a tool like Zendesk, Jira, Asana or something else. This allows groups to track their status, report on them and manage the workload. Generally a small group (sometimes just one person!) handles all the tickets.

Eventually, however, the number of tickets and the types of tickets that come  in begins to grow. That small team will find itself buried under a landslide of requests, and will be rapidly shifting from one type of ticket to another. This constant pressure, and need to context switch takes its toll.

Tiered Approach

To help address the wide range of tickets that come in, companies tend to evolve a multi-tiered approach for their support teams to handle the influx:

• Tier 1 - This is the front line and is equipped with stock responses to as many tickets as possible. They’re typically trained how to triage any given ticket, and if they have a response to provide it. Examples of tickets this group can handle are things like password resets, simple Q&A and general feedback.

• Tier 2 - This is a more specialized group that takes over any ticket that Tier 1 isn’t equipped to handle. They may have some stock responses, but generally this tier has either access or training that the Tier 1 group lacks. There are, however, some things Tier 2 can’t handle.

• Tier 3 - These are your super-experts and they handle the most complex or challenging topics. Ideally only a small percentage of tickets end up in this group as there tend to not be many of them, and the requests can take a while to respond.

This structure allows the team to specialize. Some agents tackle the large numbers of “simple” tickets, while a smaller number focus on the “complex” ones. This increases response times, as well as satisfaction, as the simple ones are knocked out more quickly, while a more knowledgeable agent handles the harder ones.

This approach, however, requires humans - someone who is trained in how to respond to, and resolve, issues. In many cases a human is required to help out, however, employing someone to answer tickets can be expensive, and it can result in it taking longer to get an answer.

The 0-eth Tier

This is where ticket deflection, or Tier 0, comes in. This tier is everything the customer can do BEFORE asking for help. It could involve reading a wiki page, asking a chatbot something, or trying it themselves. There’s a wide range of things this COULD be, but they all result in the customer getting an answer/help without having to interact with someone on a support team. 

Examples include:

1. A knowledge base - Having robust, customer-facing documentation is a great way to empower customers to answer their own questions. These do take time to setup and maintain, however, directing customers to them is significantly cheaper than having a human answer at ticket. Many customers also want the ability to lookup information on their own, so having a knowledge base available also helps fill that need.

1. In addition to questions and answers, knowledge bases can also contain step-by-step guides customers can try on their own to resolve their issues. This subset of information gives customers one more thing they can do before having to interact with your support team. This allows customers to get help 24/7, and further reduces the demands on your support desk.

2. Chat bots - Chat bots are getting a LOT smarter and a lot more helpful. While there are certainly some gaps and features that aren’t quite there yet, these interactive tools make accessing information and guiding customers to responses a bit quicker than search. Some of the newer tools are even able to take action on behalf of a customer - for example resetting their password. This reduces the number of things your TIer 1 team is responsible for, both simplifying their workload but also reducing it.

3. Automated Tools - This one can be a bit trickier to setup, but having a tool the customer can use, without having to access a support team, is another way to deflect tickets. Resetting a password is a common example - customers click a button and go to their email to get back in. This shortens the distance between the customer having an issue and getting it solved.

Typically Tier 0 starts out as a small help-center, however, it should be constantly evaluated, expanded and updated as time goes on. Not only will older content need to be refreshed, but new pages, tools and guides can be added. 

Tier 0 Improvements

Agents should be constantly on the lookout for opportunities to improve Tier 0. Not only do they see all the incoming requests, but they have solutions for them. There’s several ways this can be done:

1. Writing (or rewriting) articles - Agents are typically closest to the problems, and solutions, so they should either have the ability to directly edit or update articles, or have a process to suggest changes. 

2. Product improvements - Agents should have a pathway to suggest product changes to avoid the need for a ticket. These suggestions should be reviewed by product, marketing, or other teams, to see what can be incorporated to help alleviate the need for a ticket.

3. Training materials - Agents should suggest ways to train customers or users on how to use systems. This can directly reduce the number of “how do I do X” tickets.

Deflection can be a bit tricky to quantify, after all you’re stopping them from having to do something (put in a ticket), so you may never know how much it’s REALLY impacting. There are a few ways to keep an eye on it.

1. Knowledge base utilization - Tracking which pages are used can give you insight into how much pressure it’s taking off your ticketing system. For example if you add a new article on password resets and that ticket type drops, you can infer the article had some impact.

2. Automated actions - The number of times your chatbot (or other tool) takes actions is another way to see how effective it is. Each password reset done automatically is essentially a ticket that wasn’t submitted.

Ticket deflection is incredibly important to a successful ticketing system. Not only does it reduce pressure on your support teams by both reducing volume and the number of things they have to handle, it empowers customers to take action… and is faster than putting in a ticket. There is a bit of legwork needed to determine what can be done, but it’s more than worth it.

Are system evaluations important? (Yes, definitely!)

I worked at a company once where we used a particular software tool to manage our projects. It wasn’t a bad tool….  But it didn’t quite fit our needs. My team spent a LOT of time figuring out how to make it work, which not only distracted us from work it made us more than a bit frustrated. We didn’t have a choice though, so we suffered through using it, and finally, after about a year of pounding a square peg into a round hole we asked why we used that particular piece of software.

The answer… was a bit shocking.

Basically an executive was asked what we should use, and they pointed at the one we had and said “that one”. That was it. No further discussion. No questions asked. No requirements gathered. Nothing.

I had a feeling back then, and have since learned, that that is NOT a good way to pick a system!

Positives and Negatives

The positive aspects of randomly picking an option is it’s quick. You’ll get to the end of your “selection” process faster than you could otherwise. This can be an attractive prospect as system evaluations can take a lengthy amount of time and resources to complete.

In some extreme situations there can be an argument for speed, but I have never encountered one where every other aspect of the evaluation was thrown out the window. Needing to move quickly isn’t an excuse to not conduct due-diligence.

That positive aside, there’s a TON of negatives… things like:

1. Price - other options may do the same things (or do them “well enough”) more cheaply, or can be implemented more quickly. If you don’t evaluate those systems you won’t even realize you’re paying more for something.

2. Features - The one you pick may not do what you need, or may do it in a way that makes it challenging or onerous for your teams to adopt. Critical features can fall into this bucket, making a quick selection incredibly painful for teams when they realize their new system doesn’t do something they need to be successful.

3. Compatibility - The one you pick may not integrate or be compatible with other systems or processes you have. This can result in your teams having to do additional manual work to transfer information or get what they need. At best you may need to build custom integrations between systems, which introduces greater cost and risk, and in some cases may not even be possible if you don’t have the resources to integrate (either money or people).

4. Duplicative systems - You may already have a system that meets your team’s needs. Failing to recognize this could result in you ending up with two, VERY similar systems. This increases the administrative and budget overhead and adds unnecessary complexity to your tech stack.

Any one of these on its own should be enough to not randomly pick an option… all of them together make it a painful, and costly experience.

Doing it right

Instead of pointing randomly, groups should go through a more formal evaluation of their requirements and their options. This doesn’t have to be a months long, in depth endeavor, but it should at least involve some thought about what is needed, and how the options meet those needs.

Typically this process includes things like:

1. Identifying stakeholders - who will be using the system, or be impacted by it? Depending on their level of involvement stakeholders should be involved in the selection process to help ensure their needs are met. This list should include direct users, but also teams who would have to support or build the system (e.g. IT, engineering, etc).

2. Determine requirements - what challenge or issue needs to be solved and how should the system do that?  The stakeholders identified in #1 can help pull this list together, but this is a critical step (one that the company I worked at definitely skipped!). By the end you’ll have a list of things you need to be successful, and while you may not get all of them, understanding what is needed will help you make a better choice.

3. Get options - After you know what’s needed, go and find potential options. This could be as simple as some quick googling, or an in-depth examination of what’s out there. Personally I find this to be an interesting step as I get to learn about what’s available.

4. Eliminate some - Compare your options against the requirements. Do any clearly NOT meet your needs? Sometimes you can figure this out just by looking at their website, other times you may need to send an email and ask for more info. Doing this helps weed out options that are clearly not a good fit, and saves time later.

5. Get more information - Once you’ve got a shorter list, dig in and really compare the rest to your requirements. Get a formal demo. Talk to other customers. Figure out how it really works. While it’s uncommon to find a system that really does everything you need, this will help you find the best possible fit. Have a core group of your stakeholders (especially from the group who will use the platform) get involved in this step as they’re the ones who will be stuck with the final outcome!

6. User Acceptance - If you decide to go forward with a new system make sure your stakeholders have a formal acceptance. Let them use the system and determine if it meets your needs… if not, work with the vendor to update or change things, but don’t just blindly accept that it works as expected!

All of this does take time and effort… however, it’s always cheaper to go through this process than to end up with a system that doesn’t meet your needs. Not only will you have to replace it, you’ll have to retrain everyone, find a new system, and rebuild credibility.

A great side effect of this process is it also gives you a great opportunity to build buy-in for the new system, to update processes and policies, and further enhance how your team operates.

Does it take time and effort? Yes.

Is it worth it? Definitely.

Learn by Teaching

I read somewhere that one of the best ways to learn and remember a skill is to teach it. On the surface this doesn’t make much sense… if you’re teaching something, you should already know it, right?

Dig a bit deeper though, and you’ll realize that teaching something not only requires you to understand the skill or concept - it requires you to rethink how you understand it in a way that helps someone else understand it. That sounds a bit odd, but hear me out. 

When I teach someone something, it doesn’t help them if I explain it in a way that makes sense to me (ok, well maybe it helps them a little).  This is due to a few reasons, but mainly - they don’t think the same way I do, and they have a different background and set of experiences. These differences blunt the impact of any explanation I provide that is entirely tuned to my background and my thinking. It also forces them to spend time and energy trying to relate to my explanation - time and energy better spent learning.

The challenge in teaching, then, is reshaping how something is explained to best match the learners background and understanding. This requires a great amount of mental gymnastics on the part of the instructor, as not only do they have to hold the idea or concept, they have to understand their student pretty well too.

This is what makes teaching a great way to improve your own skills. It essentially forces you to relearn something from a different perspective, which helps solidify concepts, challenge assumptions and bring up new ideas.

Working with one student, or a group, over time makes this easy.  The longer an instructor and student have together, the better in tune they’ll become. This is what makes long-term relationships with a teacher so powerful - they get to know you, but more importantly they know how you think and learn.

I find it odd that more people don’t teach skills - it’s an amazing way to solidify a skillset.  I definitely understand that some folks don’t want to, and that’s totally OK… but for the rest of us teaching a skill is an incredible way to get better.

How to start

Teaching something doesn’t require us to be college professors in a classroom with dozens of students. You can teach something to an individual on a coffee break. It doesn’t even have to be a complex skills - a simple introduction to a concept or idea helps both the student and the instructor get better. 

The size of the group does change how someone should approach teaching, as does the medium…. Teaching one person over Zoom is a LOT different than teaching 20 people in person, which is different from teaching 1000 over a recording, which is different then a 1 on 1. And while the instructor will learn different things from different groups and sizes, teaching someone you’re comfortable with, in a setting that works for you is still really beneficial.

Go teach!

So, my challenge to everyone is to teach someone… something. Pick a thing you understand well and find someone who wants to learn it. Take some time to get to know them and what they want to learn, and then expand your own thinking and teach them that thing. Pay attention to how you have to challenge your own ideas about the topic. What do you have to rephrase? What new analogies did you come up with?  How did YOU grow and learn from teaching that person?

How to get into Project Management

A common question I hear frequently is “How do I get into project management?”.  Typically it comes from individuals who are new to their career and are interested in becoming a project manager (PM), but folks looking to make a career change also consider it.  After answering this question several times I figured I’d collect my thoughts on the answer and share them below.  Hopefully they’re helpful!

Why are you interested?

The first thing I ask someone who expresses interest in becoming a PM (or anything else really) is why are you interested? There isn’t really a wrong answer to this, but understanding why someone wants to become a PM helps them figure out how to get there, or maybe helps them figure out it’s not for them. For example, wanting to become a PM to help improve the lives of under-priviledged people is different from wanting to be part of building something big.

Understanding their “Why” not only helps guide them in terms of where to apply their time and energy, but may also help determine which type of project management they should look into. For example if they want to be part of construction projects then Waterfall projects are likely a better fit.  If they want to build the next Big App, Agile is likely a better fit.

One important thing to note is that while you contemplate your Why, you may determine Project Management isn’t for you - and that is OK! Discovering that about yourself is a very important thing, as it will let you focus on something else that you’ll get more excited about.

What project experience do you have already?

This question is a good way to baseline where someone is, and also helps figure out next steps. It’s also a bit misleading, as almost everyone has SOME kind of project experience.

• Just out of university? I’m betting you’ve been part of a class or group project and had to navigate stakeholder management (e.g. your project team).

• Ever done a home project? Many things we do at home are projects.  Do you have a garden? Build Lego? Install your own gutters? All projects. 

• Never been part of an official project? I’d bet the team you were on had some projects going that you were aware of.

• Been part of a project team, but not the PM? You’ve definitely picked up some bits and pieces of how projects work.

Knowing what experience you have is important as it helps you figure out where your knowledge gaps are. Personally I learned many of my PM skills by doing… which isn’t necessarily the best way. This gave me a deeper understanding of some of them (e.g. communication), but I was totally lacking in others (resource management). This required me to improve my general knowledge to first understand what I was missing, then targeted learning in those areas.

What options are available to you?

I’m still working on a way to instantly become a PM, so the next question I ask is what options are there? Some individuals are in a position where they can take extensive training courses at work to learn the skills, others have an intense job that limits their time, and others are between jobs for various reasons and have other restrictions.

There are certainly a LOT of different ways to learn PM skills, including, but not limited to:

1. School - Many universities / colleges offer certificates, or even degrees, in PM. I took a great community college course on PM, and it was also part of the masters program I was part of.

2. Paid online learning - There are a ton of online learning options for PM (instructing.com is a great one, and I have several Udemy courses on the topic). These can offer intensive courses, or packages to help improve skills. Some will also prepare you for certifications (more on those below).

3. Free online learning - There’s also a ton of free online learning (check out my youtube channel).

4. Books - Personally I learned a ton from various PM books (like this oneLINK NEEDED).  For a relatively small investment (in dollars) and larger investment (in time) I picked up a lot of the basics.

5. Mentorship - Some company’s offer formal mentorship programs, and informal mentors are almost always available if you look around. I find these tend to be better if you’ve got a starting point, but can also help someone get into being a PM.

There may be more options out there, but taking time to understand what is available is crucial as it helps guide learning.

Entry level roles

Finding an entry-level job in Project management can be challenging, but there are a few titles or roles to look out for:

1. Project Coordinator - Coordinators tend to assist project managers by helping manage things like scheduling, documentation and more. This is a great way to get exposure to project management without being responsible for running the project.

2. Project Analyst- Analysts typically focus on specific areas, e.g. risk management, contracts, etc. This type of role may be easier to get into if you already have experience in that area, but it will expose you to project management in general.

One thing to keep in mind is that every company may call the job something different, so it’s important to read the job description.

Closing Thoughts

I thoroughly enjoy my time in project management. It’s helped me learn a ton of great skills, exposed me to some really interesting people and helped me grow as a person. It does, however, take some internal work to get into and to thrive in. That said, the time you spend considering this is more than worth it.

Many ways to solve a problem

On a recent 5+ hour flight I noticed something. It wasn’t that the snacks were terrible and the drinks were slow. It was that many, many people had run into the same problem… and came up with different ways to solve it.

The problem wasn’t anything really major - they weren’t fighting with their neighbor over their armrest or realizing they lost their luggage, instead, the problem they had was “How do I prop my phone up so I can watch video on it?”.

Flashback

Growing up I remember flights having an inflight movie. The movie was projected on a single screen at the front row, and repeated on small TV’s down the aisle… and if you didn’t like the movie, tough luck.  As technology progressed this eventually turned into seats having their own TVs (which was an insanely amazing upgrade!).

Now, we’ve come full circle… planes don’t have screens any more… but everyone has their phone! Unfortunately the nice people at the phone company’s don’t make it easy to watch something on your phone for a long time.. No one wants to hold it up for hours on end, leaving us with a communal problem - how do I watch something on my phone?

Many Ways

On the flight I was on I observed at least a half dozen ways to get around this issue. 

1. A phone case with a kick-stand

2. Propped up against the seat in front of you (not a good idea if they decide to recline!)

3. In a ziplock bag hanging from the closed tray-table (I really liked that one)

4. Propped up against a sock (hopefully a clean one?....)

5. Hanging from the closed tray table by the back of a case

6. Wedged into the magazine holder above the tray-table

What interested me about this wasn’t what people were watching (mostly sports-ball), but rather how many solutions to the same problem I saw. Each individual approached the issue of not being able to watch their phone in a different way, and based their approach and solution on what they had available. Even though each person had a different method, each one still solved their problem.

This got me thinking about problem-solving in general. Every day we address, and overcome, challenges… and rarely is there a single way to do that. Instead, we solve problems in different ways based on our skills, knowledge, what we have available and more. There isn’t a single right answer, but instead many answers that get the job done.

This also challenged my own bias to my own solutions.. Sure, I think they’re good / correct / etc., but they’re rarely (ok, basically never!) the best possible way to do something. That doesn’t mean they’re bad since they get the job done. The danger is thinking they’re the only answer.

The path of “there’s only one answer” gives us a number of extra hurdles we have to overcome, including:

1. We may not have the most effective answer - Sure, using a specific tool was really useful at some other company or situation, but it may not be the best option here.

2. We cheat ourselves out of growth - Sticking only to what we know robs us of learning. We won’t learn how to use a new tool, or how to approach a problem in a new way.  Instead, we just do what we know, which doesn’t lead to growth.

3. It may be more expensive in time or money - Sticking with the single answer we find may not be the fastest or cheapest way to get something done. Other tools may still get the job done while being faster, or cheaper.

How to find new answers

When I can’t come up with a solution to my problem, or if I find myself assuming whatever I come up with as being the best solution, I consciously try to break out of that thinking. This can take several forms:

1. Forcing myself to use a different approach

2. Researching other ways to solve the challenge

3. Talking to others about how they do it

While each of those steps comes up with (hopefully) new answers, what it’s really doing is helping me think differently, and to challenge my internal assumption that my answer is the best. I find this makes problem solving more interesting since I get to learn more ways to solve things, and many times helps me find a better answer than I could on my own.

On the excitement of maintenance

If there's one thing I know everyone loves, it's maintenance. Ok, well, maybe not for most of us… but it is a very important activity, both in our daily lives and at work.

I’m sure you can imagine dozens of maintenance examples. I find the easiest ones to pull out are home-related - like laundry. I like having clean clothes to wear, which means I have to make time during my week to wash and fold laundry so it’s ready for next time (quadruply so with a few kids!). I am incredibly thankful that washing machines exist (I cannot imagine how long it took before these wonders), but I’m still required to take an hour or two out of my week to do it.

This is time I would much rather spend doing almost anything else. In the case of this particular type of maintenance, it’s also time I know will be quickly “used up” since those same clothes will appear in the laundry in the next week or two.

There are, however, many, many work-related examples of maintenance. When I manage projects I find myself having to organize notes, collect and scrub tickets, and remind folks for the ump-teenth time that something is needed. I certainly don’t wake up excited to perform these tasks, but they are 

There’s a quote from a TV show called Ricky and Morty about personal maintenance that resonated with me - “Because the thing about repairing, maintaining, and cleaning is it's not an adventure. There's no way to do it so wrong you might die. It's just work”. In the context of the show this speaks to a character’s need for constant life-or-death situations.  (Hopefully) most of use will never be in one of those, but maintenance is still just work.  There’s rarely anything exciting about folding a shirt, or reviewing meeting notes, or reading server logs to find a bug.

Sooo why do it?

It’s boring and repetitive, so you may be thinking why would we choose to do maintenance?  Well, it’s worth it. If I don’t clean my laundry I won’t have clothes to wear (I’m told this is something to avoid). If we don’t change the oil in our car the engine will wear down and break. If we don’t restart our computers for new updates we’ll get hacked.

In short - we tolerate it’s annoyance to avoid worse consequences later.

So what do we do about it

Personally I’ve found that maintenance itself really can’t be made to be fun.  We can outsource some/most of it, however, there will always be SOME maintenance-related tasks we have to do personally.  We can, however, do some things to make it more bearable, or at least slightly enjoyable:

1. Make it a game - I find this works well with a group (or with a few kids…), but set each person against each other to see who can do the most maintenance, accurately, the quickest.

2. Get a reward - As a kid my reward for doing chores was an allowance… As an adult my reward for doing chores can go beyond completing the task.

3. Do it as a team - These boring tasks can go a lot quicker (but subjectively and objectively) when done as a group. Put on some music and get your team together and knock out that boring data entry. Get a friend to help with that thing you’ve been putting off.  Maintenance goes faster, together.

Conclusion

At the end of the day maintenance isn’t going anywhere. Machines still need an oil change. Clothes still need to be folded. Meeting notes need to be archived and never read. All that said, it serves an important function in keeping things running smoothly - and if no one ever complains about an issue because I performed boring maintenance, I’ll call that a win.

Becoming a “jira guy” - or how I started using Jira

One of my favorite sayings is ‘use it up, wear it out, make it do, or do without’ - and it's served me very well with my tools.

Over time I’ve found out different ways to solve challenges with tools like Atlassian’s Jira. but the reason WHY I use Jira, or any tool, really, may surprise you.

I’m frequently known as “a jira guy” (I can’t say “The Jira Guy - that’s already taken!). This name came around since I”m generally the person on my team trying to figure out how to use Jira to solve a problem.  Building a new piece of software? Jira can help with that. Have a help desk to manage? Jira does that. Have complex Sarbanes-Oxley (SOX) compliance to track? Jira can do that.

For the Jira example it’s not because I think Jira is the best possible tool, or because I’ve spent years analyzing all the options and picking Jira… it’s because I tend to get stuck with it. It happens to be the tool my employer has available, so I use it.

The same is true for Confluence - it happens to be the knowledge base my employers uses.

I didn't start with Jira or Confluence, instead it was Sharepoint (a Microsoft product).  I don't have any particular love for it, however I was tasked with setting up a knowledge base to support 5000+ workers, so I got to work figuring it out.

While I did learn some of the specifics of SharePoint, I've realized the skill I really learned was how to figure out a system, and then map it to my needs.  This could involve changing how our processes operate to work within a limitation, using parts of the system in ways other than intended, or even building custom extensions (as was the case once with Google sheets.)

I've found being able to adapt to new systems makes it much easier to get started at a new role.  Here's a few tips on how to do it:

1. Be curious - Don't just accept how something is done, or wait for someone to show you how to do something.  Take time to poke around, challenge yourself to figure out how a system works or make it do something you need. This both teaches you the system but also makes you a bit better at problem solving.

2. Do your homework - Read the instruction manual, go on YouTube, ask around, but don't just sit there.  This will not only expose you to different ways to use the system, but also give you ideas on other ways things can work, or even other tools you could use. 

To be honest, ‘Because that's all I have’ isn't really the best reason to use any tool - ideally there's a formalized process to identify needs and then find the best fit. Personally it drives me nuts when a group makes a decision without going through that needs-analysis, but I do also understand that many times we’re just stuck with something, so we make do with what we’ve got.

Check out this video on how I got into systems, and maybe a better way to do it…

What do you mean by "Integration"?....

One of my favorite terms in tech is “integration”. It’s not my favorite because I build them, or because of what they can do, or because of the technical complexity.  It’s my favorite because everyone uses it to mean something different, and like many terms, the range of differences can be immense.

Further, the cost of misunderstanding the intended use can result in turning down projects, to complete failures, to incredible amounts of overengineering. It’s a loaded term - and one that I have a lot of fun unpacking.

Wait, what’s an integration?

We live in a world with lots of computers and different systems (citation needed). Many times, any given system can house all the information or processing it needs - but in many other cases they have to talk to other systems.

To me an integration is anything that allows two systems to pass or share data. An API is an integration. A CSV being emailed is an integration. An XML file being passed to an AWS bucket is an integration. A human typing information from one computer into another is a (bad) integration.

In an ideal state we never know there’s an integration - the system just works. If we’re aware of them it’s likely through some kind of login (e.g. having to log into your bank account to pay a bill), but after that we never think about it.

Here’s an example - in order to get your paycheck, your company must have a system that integrates with their bank. This integration tells their bank to send your pay to your bank.Those banks are integrated to share information, and your bank has an integration with your mobile app so you can view your balance. This represents AT LEAST 3 integrations, although many more are likely involved.

OK so what does that mean

Since this term means so many things to so many people, one of the first things I do when I hear someone use that word is to ask them to describe what they mean. This generally isn’t the first thing they think I’ll ask, so it can take a moment, but it’s one of the most important questions for me to clarify.

This is important as the answer can have wildly different impacts on a project. For example I was once asked to integrate an HR system with a third party’s Learning Management System (LMS). They asked our team to “provide an integration passing employee data” - to which our team said “sure, that will take 3-4 months to develop and test.

This timeline didn’t work for the third party and risked losing a contract.  So, I asked a few questions, and after about 5 minutes of talking learned that all they needed was a CSV file with 5 specific columns of data.  I asked our team if this was possible and they said yes - and a week later we were up and running.

This is what makes talking about tech, and integrations so challenging - the slightest misunderstanding or misconception about what is meant can result in massive impacts to a group or project.

Over the years I’ve started to pull together a list of different types of integrations to help me understand what is needed.  Check it out below, and let me know what you think!

Are skills like JQL and SQL still needed?

Magic?

I know it’s not, but some of the recent advances in AI tools are basically magic. They can take a question I type in and translate into something the computer easily understands. While there are certainly other query languages out there, the ones that I’ve used the most are JQL (Jira Query Language) and SQL (Structured Query Language)(I”ll leave it to the comments to argue on how to pronounce it!).

I began using both only after my job demanded I needed those specific tools.  SQL came around when I was asked to help build out reports, and JQL was forced upon me when I was expected to lead a team’s Jira initiatives. Both required me to beat my head into the keyboard repeatedly, until, finally, I got the answers I needed.

At first blush AI would seem to reduce, or eliminate the need to learn how to write queries in those languages. It’s easy enough to just type in a question and have the computer do it for me, so why bother learning how to do it myself? Looking back on my career this could have saved me a TON of effort, energy and time by giving me a way to just type in a question and get an answer.

If you don’t know…

This technology will help a LOT of people get information they need more quickly. Many folks don’t have the time (or the ability to replace keyboards broken out of frustration) to learn a query language.  This means that without this type of tool, they’re stuck with basically three options:

1. Not get any data -  Not knowing how to write queries, or not having someone who can, means you won’t be able to get information. This will result in poor decision making and a general blindness to what’s going on.  Certainly not a good option given the amount of data our systems generate these days!

2. Learn how to query - Personally I’m a fan of this option as it helps expand skillsets and ways of thinking.  It does, however, require time, effort and energy… and not everyone has those. It’s also a skill that you’ll lose without practice… I’ve learned SQL at least 5 times, and every time I have to use it I find myself further back on the learning curve that I used to be.

3. Have someone else do it - Many, many people do this today. They have, or find, an analyst who knows how to talk to computers, and have that human translate their needs. This, however, requires budget and/or headcount, and is not a luxury everyone has when they need it. (Note that analysts do MUCH more than just translate English in a query - they work with you to understand your needs, ask better questions, provide insight into the data and more. Query translation is only a small part of their role!).

Having an AI tool that can create queries for you removes options #1 and #2 as the computer can do it… and that’s something they’re really good at. They won’t forget how subqueries work.  They won’t fat finger a project name in JQL. They won’t be missing a critical piece of info on how the language works. Those AI tools will take over a small part of what #3 can do - create queries. (I find there’s a mis-conception that analysts just write queries all day - they do a lot more!).

AI Advantages

That AI tool also has some advantages a human doesn’t.  It’s likely closer to the data, and related data, than any human could be. It likely doesn’t only understand YOUR data and YOUR question, but the similar questions of dozens, or hundreds, of others. It likely has access to millions of additional (anonymized) data points that it can use to make better queries.  A human doesn’t stand a chance at having all of that, making these tools incredibly powerful in some ways.

These tools eliminate two of the options we have (don’t get answers and learn it yourself) and also and offer some advantages that humans can’t possibly replicate (more data, faster responses, etc). This means that “just ask the computer” will make many, many, people much, much faster at accessing data more quickly.  This will (hopefully) lead to better, faster, decision making.

But wait, there’s more

While I feel these tools will help by eliminating the need to learn a query language, I still feel there is value in learning one. 

For me it’s similar to learning math even though we have calculators, or learning a bit about how a car works when we learn to drive - that underlying information teaches us concepts about how it works, allowing us to better use it and understand the answer that the magic box gives us.

I see several reasons learning queries is valuable:

1. Skill augmentation - For those of us who know query languages, these tools will help us augment our skills. This is similar to how a writer may use a tool like ChatGPT to draft a document, then edit it to their liking. AI can give you a starting point for a complex query that you can then expand on, or write more simple queries faster, saving you time. Eliminating the need to write simple queries frees up time to focus on more complex ones, allowing us to further improve our skills (I read somewhere that tools like this will turn a good engineer into a great one, and a great one into a fantastic one).

2. You’ll know what the machine is doing - Understanding how something works is incredibly important to understanding why it’s doing what it’s doing, and being able to explain it.  Knowing what a “Select” statement is in SQL, or how the “IN” operator works in JQL will mean you can read the machine’s output. At the very least this gives you more confidence in what it has churned out, but will also help you defend its results if anyone asks. I can easily imagine scenarios where someone is challenged on the data they present and only being able to offer “well, the computer told me” as a defense… (this would not be good!).

3. You’ll get smarter - Similar to augmenting your own skills, you’ll be able to expand how you think. The tool will have a different approach than the one you use in some cases, exposing you to new use cases or features you haven’t used yet. I find I tend to only have narrow use-cases for tools, resulting in me missing concepts or features outside that focus. Using AI tools will help break me out of that narrow window by showing me other ways.

Parting Thoughts

AI tools are here to stay.  They’ll continue to augment and improve our skills, and will continue to become more and more powerful as we understand them more. They are, and will continue to be incredibly useful in helping humans do more faster.  That said, if we’ve learned anything from comics books with that great power comes a great responsibility - not only to use it responsibly, but to understand how it does what it does.

AI For All! (Well, all Atlassian Cloud customers...)

What happened now?

Back in April Atlassian announced that they would begin to deploy AI in their products to help empower users… and now they’re fulfilling that promise. What began as a beta deployment of AI for ~10% of their customers is now becoming available to anyone who wants it (well, and uses Atlassian products!).  There’s several features that will be made available now to Premium and Enterprise Cloud subscribers (admins can turn them on here), with others coming up soon:

Item	Notes	Area
Generative AI Editor	Think ChatGPT but tailor towards creating User Stories, or product updates, or empathetic responses in Jira or Confluence pages.	Productivity
AI Summaries	Summarize long Confluence pages to quickly understand what they’re about.	Productivity
Natural Language Automation	Automate actions, like creating a table with information, directly in Confluence. Available in Jira soon.	Productivity
AI Definitions	Still in beta, but will allow users to define company-specific terms easily in Confluence… no more wondering what a TPS report is! Available in Confluence now as beta, Jira soon.	Productivity
Natural Language -> JQL	Translate natural language questions to JQL… hopefully folks will still need my JQL Udemy course! .	Data
Natural Language -> SQL	Translate natural language questions to SQL… I love this one since I’ve learned, and forgotten, SQL multiple times.	Data
Confluence Search	Ask Confluence for information on specific projects, policies, etc. One of my favorites since it helps users find things quickly.	Data
Compass Search	Natural language questions for Compass - similar to the Confluence update, this reduces the distance to finding things.	Data
Request Type Suggestions	Agent helps users put in the right type of ticket based on Q&A. Helps folks file tickets correctly, reducing time to resolution (and frustration!	Driving Action
Bitbucket Code Review	Coming soon, but automatically will leave comments in pull requests to speed up reviewing. Available soon.	Driving Action

My Take

There’s several different areas that I think would benefit from this type of AI. All of them impact end users on a regular basis, and having any of them would help reduce friction, and frustration, with the people I work with (links to YouTube shorts with more thoughts):

1. Knowledge discovery - whether its natural language search in Confluence or a Virtual Agent guiding someone to a knowledge base article shortening the gap between “I need something” and “here it is” is always helpful. For me this is especially true in systems, as many times you need some special knowledge (looking at you JQL) to extract it.  I’ve also found that even if you take the time to set up Confluence as “perfectly” as possible, things can still slip through the cracks in search.

2. Productivity Assistance - I’ve used tools like ChatGPT for a while and found them incredibly helpful in augmenting my productivity and creativity. Atlassian intelligence now provides similar support in Jira and Confluence and allows users to draft Pages and Blogs, but also to fill out tickets for user stories, requirements and more.

3. Guided support - Virtual support agents are another area I’m interested in exploring with Jira. Many times the support process involves soliciting information, then moving down a decision tree to get to an answer. That answer could be “restart your computer”, “do XYZ” or even “I’ll need to escalate this”, but offloading that work onto a machine allows the human agents to focus on other tasks, like managing escalations, improving process and more.

4. Query Translation - Lets face it, most folks won’t learn JQL, SQL, CQL or any of the “QL”’s. Or, if they do, they’ll learn juuuust enough to get by. Those are incredibly useful tools in finding things, but they’re usually too technical for the majority of uses. Using tools like AI to help bridge that gap, and allow individuals to write natural language statements that get converted into something Jira understands is a great move.

Personally Speaking

Personally I’ve been able to use a bit of this set of tools and I’ve found it very helpful… in particular the ability to search Confluence with natural language. I put a LOT of time into crafting structured pages that are as user-friendly as possible… and even then folks still have trouble finding them. While this feature is still in beta, it gives my team the ability to search MUCH more effectively than using the general confluence search.  Or, what honestly happens, having folks open one big FAQ page and using CMD+F to look for keywords. To me, this is basically magic and would reduce the need for me to act as a human router by quite a bit. 

One particular use case that caught my eye was allowing the agent to take some action. For example, in this gif it appears the agent is able to grant Jane access to Figma. This is a great use of automation to help reduce workloads (I imagine before a human would have to perform this), however, I can see some hurdles… especially if the system that is being requested is restricted or requires additional approval.

Take on AI

Any of the things these tools can do can be done by a human - but they take time. Time to learn the basics, and then time to create something new every time it’s needed. Personally I’ve learned, and forgotten, SQL or JQL more times than I can count, and while it’s not too hard to remember or relearn, it does take time and effort. I can easily see having an AI Assistant augment those skills be a huge time saver.

Confluence, for example, can now help setup pages or draft articles.  This doesn’t take away from my ability to add new policies or other content, but instead reduces my workload by adding formatting, suggesting things to include and prompting responses.  This allows me to focus on the more interesting, and important, parts of adding the actual content.

Summarizing pages is another great use case - not everyone has the time to read a 10 page blog post about a great new update. Having an AT tool read through and summarize it into a single paragraph is immensely useful.

I can easily see this type of feature making Confluence or Jira much more approachable to folks as it removes some of the objections related to “how do I use the system”, “I don’t know where to start” and the like. This in itself is a win as it reduces the distance from “I don’t know what to do” to “I’ve created something”.

Next Steps?

The next thing I’d love to see is if these tools can also reach out to the right team or person to gain approval to add Jane…. although then I wonder how the agent would handle someone ignoring it’s request (maybe shutting off access until there’s a response?….).

Or, for example, having the system realize I’m writing an article on HR policies, and either suggest other folks who should chime in (either by knowing what they’ve written, their status in the organization or other data), or proactively reach out to let those individuals know my article is there.  A similar feature could apply to tickets - pulling in resources who can help unblock or progress an issue without me having to ask. A feature like this would help shorten the time it takes to get something approved, and make sure the folks who need to know about the change, or chime in, are looped in.

Overall I feel that tools like these will augment and improve the humans that use them, and I’m excited to see how Atlassian is combining their current tools with these new ones. I’m looking forward to seeing what everyone does with them!

Additional Resources:

Atlassian’s official blog post

Testing Anxiety (Grade school, college, certification etc)

This won’t surprise folks who knew me back then, but I wasn’t a good test taker in school.  I didn’t get nervous or freak out about them - I usually just didn’t care… Fortunately (maybe the wrong word choice…), this changed after I left college and had to sit examinations for various certifications, such as the PMP, or ACP-620. I found they made me nervous… I was taking MONTHS to prepare for them, writing out dozens, no, hundreds, of flash cards and drilling them until I saw them in my sleep.

On the day of the exam I would be anxious… extra energy making me jittery and hard to focus.  The 2-4 hours stuck in a booth clicking answers felt like forever, and waiting for confirmation of a pass took longer.

Sidebar:

For those of you who haven’t had the pleasure of taking one of these exams you used to have to go to a testing center, sign in, hand over all your stuff and then sit in a booth with a computer.  You’d answer all the questions over 2-4 hours, then click “done”.  You wouldn’t know your results until you went to the front and the proctor gave you a printout with “pass” or “fail”. The time between clicking “done” and seeing that paper was pure agony.

You can now take these exams at home, which requires you to show videos of your space to prove you aren’t cheating (finding a clean spot is hard!). Once you click “Done”, however, you’ll get results VERY quickly.  But that gap still feels like forever.

Additionally, I earned my Masters in IT Management several years after earning my BS while working full time… and pulled almost straight A+’s the entire time.

For years I’ve been trying to figure out the difference… and I think I finally have it figured out - I care now.  For me the exams in school were compulsory, something I had to do… so I did, just… poorly. Now, however, they’re optional, something I am opting into.  I’m choosing to subject myself to hours of lectures, reading assignments and practice environments. I’m choosing to memorize how workflows or automations or queries work.  I”m choosing to do all that instead of relaxing, or playing video games, or doing anything else.

And because I’m choosing to do all this, I’m nervous. Nervous that I’ve wasted my time, or won’t do well, or won’t have learned what I wanted to.  I think it’s that personal buy-in that’s made the biggest difference.  Once I decided to become invested in something, it had value to me.

Current Me wishes that past Me had figured that out… but I don’t think I would have. I didn’t have the desire to do well on the test or in (most of) my classes. While I do suffer from a bad case of “what if” when I think about it, honestly I’m just glad I’ve figured it out now.

Understanding why I care makes it easier for me to flip a switch and make something important. For example, while I may not REALLY care about that certification, I do care about what the process of earning it teaches me.  While I may not REALLY care about most of the content, I do care about the portions I know I’ll apply.

It’s been an interesting revelation, and one that I’m glad I finally made.

Boolean Basics - Parenthesis

Does anyone out there remember PEMDAS? I remember learning it back in grade school as a way to remember order of operations… but I never thought it would be helpful as an adult!

If I’m being honest I never thought it would be useful, ever, since I wasn’t into math… that said - I do NOW find it helpful!

Specifically the “P”, which stands for Parenthesis, is the part we’ll dig into today.

As a quick reminder, PEMDAS details the order in which specific mathamatical operations occur in an equation or statement. The letters stand for :

• P - Parenthesis

• E - Exponents

• M - Multiplication

• D - Divison

• A - Addition

• S - Subtraction

So if I remember 5th grade math correctly, any time I see multiplication in a math problem, I do that BEFORE I do any addition. Any time I see exponents, I should figure those out BEFORE I multiply anything… and so on.

Parenthesis, being the first letter, are done before annnnything else. In practice this means you take anything found inside a parenthesis and do it ALL before anything else. For example if we have

3 * ( 5 + 2 )

Then we first do the bit in the parenthesis like this:

3 * ( 5 +2) → 3 * 7

Then the rest

3 * 7 → 21

That’s a simple one… it gets gnarlier if the parenthesis are nested - that is parenthesis inside parenthesis… for example:

(3 * (5 + 2) ) * 3 + ( 2 + 1)

First we would find the “inner most” parenthesis -

(3 * (5 + 2) ) * 3 + ( 2 + 1) → (3 * 7 ) * 3 + ( 2 + 1)

And then the next layer

(3 * 7 ) * 3 + ( 2 + 1) → 21 * 3 + 3

And then the next operation (multiplication)

21 * 3 +3 → 63 + 3

And then addition

63 + 3 → 66

This means we need to be REALLY careful when parenthesis are involved, since if we don’t do those things FIRST, we’ll get a different answer. For most queries this isn’t too complex, as MOST queries only have none, or one, layer of parenthesis.

For the more complex ones, however, it can be beneficial to break them down (similarly to what I did above) to understand how they work.

A general rule I follow is that if I see ANY parenthesis, I take a moment to understand what they’re doing, even if things seem simple. Taking just a moment to unpack what they’re doing will save you a LOT of headache later!

Service Level Agreements

Expectations are a tricky thing. Everyone’s got one, and they don’t always align with what other people think. This is especially true working on a help desk or providing customer support. A customer calls in expecting an answer or a resolution in a specific timeframe… and many times the agent answering the call or ticket is stuck having to reset that expectation.

Folks get expectations from a LOT of place - but there’s one that can help make everyone’s life a bit easier and set those expectations out of the gate - the Service Level Agreement, or SLA). An SLA is basically an agreement between the service provider and the customer on how long something will take or how something will be done.

Essentially it’s a promise by the customer to have a specific expectation and in return the provider will meet that pre-set expectation.

Having worked on a help desk and helped agents working on them I find them to be both really great and a bit not so great.

Why they’re great!

SLA’s are great because they set a clear expectation that everyone can see. Generally they’re posted on a website and shared with customer groups so everyone has visibility into what they are. Customers go into a call knowing what to expect in terms of service. and agents know how long they have to complete any given request.

Why they’re not so great…

SLA’s aren’t so great for much the same reasons. Customer can now see how long something should take, meaning they can end up watching the clock and getting more anxious as it gets close to ticking down. They can also cause stress for agents since watching multiple tickets near their SLA is a bit stressful.

Some Terms

1. Breaching - When an SLA is exceeded. For example if you have 1 hour to do something and you take 2 hours, you’ve breached that SLA.

2. Paused - SLAs can be paused under certain conditions. This can be done when the agent is waiting for information from a customer or something is blocking the ticket. Generally this is utilized to ensure agents aren’t penalized for things they can’t control.

3. Active - SLA’s are active when their clock is ticket. Generally open tickets have an active SLA.

How to manage them

Folks who have SLAs setup should be on the lookout for the following:

1. Tickets nearing the SLA - Tickets within an hour or two of exceeding (breaching) their SLA should be closely monitored, and if needed additional resources should be added.

2. Tickets breaching SLA - These ticket should be examined to determine WHY the SLA was breached. This information is helpful to improve your processes and prevent it from happening again.

3. Tickets with a paused SLA - Tickets that have a paused SLA should be monitored to ensure they’re paused legitimately. It’s not uncommon for tickets to be paused and then forgotten about.

SLA’s in Jira Service Management

If you’re using Jira Service Management you can easily setup and track SLAs. Be default, you’ll have two

1. Time to first response (TTFR) - This begins ticking when a ticket is opened and stops once an agent responds. This helps ensure tickets get a quick response indicating they’ve been received.

2. Time to resolving (TTR) - Begins ticking when a ticket is opened and stops once a tickets is resolved. This is what most people think of when they think of SLA’s as it enforces a timeline to solve an issue.

You should consider when SLA’s are paused, commonly done when:

1. Tickets are waiting for customer - If a ticket is pending the customer to respond to take some action pausing the SLA lets the agent work on other issues.

2. Pending - If a ticket is stuck due to a third party it frequently pauses the SLA.

Function Help

I’ve been using Google Sheets for so long I actually can’t remember when I started… It must have been after my first job, since we used Excel, but other than that it’s lost in the years. Over that time I’ve gotten fairly comfortable with various functions in Google. Things like vLookup, or Index/Match, or Unique. I’ve got many of them memorized, which is a great place to be in since I can just pull those tools out and apply them to different situations.

Even though I’m (fairly) comfortable with many functions, I still use a feature Google has called Function Help. This displays information about the function I’m using on the screen so I can easily reference it.

Why?

There’s a few reasons I use function help, but mainly it’s to learn more. Having on-screen examples and guidance makes exploring new functions a breeze, and having a reference showing me where I”m at in the function helps avoid mistakes.

1. Habit - Over time I’ve just gotten used to having it up on my screen. Honestly it looks a bit weird not having it there!

2. Remember things… - Sometimes I know a function JUST enough to type it in and start filling it out… but I forget some key piece of info about it. This makes it incredibly frustrating since I”m close to getting it right. Having function help on the screen avoids that.

3. Learn new things - Many times I’ve had function help up and noticed something I didn’t know about a function I thought I knew, or I learned an entirely new function. Having the help right under my work makes it SUPER simple to learn

Where?

When you type in a function you may have noticed this little blue question mark. That’s telling you function help is hidden, and clicking on it will show it to you.

After you click on it Function Help will expand and give you the basic view.

1. Active Argument - The argument in a green box is the one you’re entering now. This makes it easy to see where in the function you are (especially helpful for nested functions).

2. Addition Arguments - Other arguments this function accepts

3. Optional Argument(s) - These always appear last and in brackets. These are optional, but the function will default them if they’re not entered.

4. Expand - Click to expand the function help and see more info, including examples

5. Close - Click to close function help (returns you to the blue question mark)

Clicking on the expand carrot will give you more information, including examples. This is a great way to learn more about functions.

See this live here:

What's better than "Status" in JQL? statusCategory

Searching for issues in Jira by status can be tricky. Every installation has a different slate of statuses, and that list can even vary within projects. While there are some more “standard” ones, like “Waiting for customer” sometimes a status like “Declined” will show up and throw your searches for a loop.

My old workaround was to keep a running list of statuses, especially those in the “Done” state, that I would add to queries. This looked a bit funny since I had to add “status in (“status 1”, “status 2”, “status x….”), but it got the job done. Unfortunately it made it hard to onboard new folks to the project and really frustrated users.

There’s a better way

Fortunately the nice people at Jira have a solution! Recently I’ve almost entirely stopped using “Status” for my day-to-day quering. There are specific cases where I need to use it, but generally it’s been replaced by statusCategory.

When an Admin adds a status to a project they have to select a category for it:

1. To Do - This status signals the ticket is pending work. Common examples include “Review”, “To Do” and “New”.

2. In Progress - This status signals the ticket is being worked on. Common examples include “In Progress”, “In Development” and “Waiting for Customer”.

3. Done - This status indicates work on the ticket is complete, or no further work is necessary. Common examples include “Cancelled”, “Completed”, “Finished”

How to use it

StatusCategory is similar to any other field in Jira : statusCategory = (value) - where the possible values are “To Do”, “In Progress” and “Done” (note they are case sensitive!.

I typically replace “Status” with “statusCategory”, so instead of using status = Completed I would use statusCategory = Done. This does make the query broader, but ensures I capture EVERY ticket that no long requires owrk.

Examples

1. Find all tickets in project ABC that are in the To Do category

   1. statusCategory = “To Do” and project = ABC

2. Find all tickets in the ABC project that are in an open sprint and in progress

   1. Project = ABC and sprint in openSprints() and statusCategory = “In Progress”

Check it out live:

The importance of Header Styles

I’ve (finally) figured out that formatting is an important part of a wiki. Shockingly folks don’t appreciate reading giant walls of text, so understanding how to break up a page in a way that improves it’s usefulness is important. One way we do this is with headers.

Headers are useful in breaking up the page into discrete sections. I think of them like chapters in a book - they signal to the reader what is coming up, and let folks skip around to more interesting sections if they like.

A VERY common way to do this is simply by changing the size of the text, or by bolding it.

While this DOES make the text bigger and bolder, it can rob you of some interesting features built into knowledge systems.

Header Styles

Instead, use header styles, NOT font sizing, to break up pages into sections. Header styles will also break up the page with clear headers, but have a major advantage over bolding and font sizing - they interact with the tool in different ways.

In Confluence

Using header styles in Confluence lets you do some pretty cool things like:

1️⃣ - Automatically generate a table of contents - The Table of Contents (TOC) macro will generate a TOC based on headers on the page. Easy!

2️⃣ - Send a hyperlink directly to that specific header - each Header will have it's own link, letting you send folks directly to it.

3️⃣ - Easily standardize look and feel - Using header styles will ensure your headers always look the same between pages.

1. Click the text size drop down & select your size

2. Type it in!
   

In Google Docs

Header styles in Google Docs let you easily create a table of contents and link to headers

1. Select the header size

2. Type it in

3. Google automagically makes a table of contents

Label Management in Confluence

Labels are a great way to help manage content, but tend to spiral out of control as anyone can add a new label to a page. This results in a large number of similar, or unneeded, labels, which clutter your system and make it harder to manage.

Why label management is important

Over time your system will collect more and more labels. Many of these will likely be legitimate labels used to help manager your knowledge base. Over time, however, you will start to collect typos, deprecated (un-needed) and duplicate labels.

Common examples include:

• Plural vs Singular - “benefits” and “benefit”

• Typos - “beneift” not “benefit”

• Unneeded - “Excel” (but you no longer use or need this)

At best these labels clutter up the screen when selecting new labels - at worst users add them to documents which will confuse and break your search and other features.

A Solution

Setting up a regular label review (similar to a content review) will help you manage and update your labels. There are two macros that will help you

1. Labels List - Gives you all the labels in a specific space in alphabetical order

2. Popular Labels - Displays all labels in a specific space sized by use

Labels List

1. A-O

   • benefits

   • content

   • faq

   • formatting

   • ireland

   • kb-how-to-article

   • macro

   • monthly

2. P-Z

   • policy

   • project

   • publishing

   • quarterly

   • retrospective

   • search

   • usa

   • yearly

3. 0-9

   • 1-on-1-meeting

This is useful for quickly seeing how many labels there are, and if there are any potential duplicates / un-needed labels. Click on the label to see a list of pages with that label.

Popular Labels

Generates either a list of labels or a heatmap. The list will display labels in descending order of use (most used at the top), while the heat-map displays them alphabetically and changes the size based on use (most used is bigger).

• macro

• monthly

• content

• formatting

• policy

• search

• benefits

• kb-how-to-article

• project

• publishing

• quarterly

• 1-on-1-meeting

• faq

• ireland

• retrospective

• usa

• yearly

• 1-on-1-meeting

• benefits

• content

• faq

• formatting

• ireland

• kb-how-to-article

• macro

• monthly

• policy

• project

• publishing

• quarterly

• retrospective

• search

• usa

• yearly

Don't be afraid of labels (or hashtags)

I recently spent some time browsing my company’s Confluence knowledge base and noticed that a LOT of articles didn’t have any labels. I’d bet this is because labels are mostly hidden when you’re writing pages - there’s no obvious spot to add labels during editing, and after you publish they’re waaaay down at the bottom. I imagine that many folks simply don’t know they’re a thing, or completely forget they’re there.

This is a bit of shame, since labels are a great way to help organize and drive content. They’re not even a foreign concept, since I’d bet many of us are already familiar with the concept of labels under a different name - hashtags. Platforms like twitter use hashtags to help folks find and organize content, much the same way Confluence uses labels. We’ve all seen tweets with a whole bunch of different hashtags related to the content - so why not do this with kb articles?

Labeling an article doesn’t take much time and has a lot of benefits. It helps the search function find things, but also drives gadgets like “content by label”, making dynamic page construction a lot easier. The few seconds an author takes to hit the “L” key and type in some keywords will definitely pay off, especially as your kb grows in size.

In addition to helping folks consume your content, it will make your life easier when you have to update things. For example if your onboarding process changes, you can just search for the onboarding label and know what to edit. You can even add a specific label to help you find content that might need to be updated regularly (I tend to add “monthly-review” to articles like this).

Depending on your needs, an article may end up having several labels (or more!) - and that’s ok! As long as each label is there for a reason and ties into the content, it doesn’t hurt anything, it just makes it easier to find and sort content.

This is a great feature that I think is really underutilized - be sure to check it out and see what you can do with them.

Onboarding New Team Members

Many times I get to kick off a project with a team that has worked together before.  This certainly has its advantages…. Everyone generally knows how everyone else will act and work with the group.

Other times, though, I've had team members join mid-project.  This could be due to someone leaving the company, being out of office or needing more resources to get the job done.  Regardless of why, this new joiner can disrupt the team in several ways - they may communicate differently, they don't know the norms and they have to build relationships up from nothing.

Ensuring the new person feels welcome and meshes with the group is critical to its success.  Frequently I see this process being ignored or sped up in the name of 'get the job done'.  I find that while this approach may get them doing work more quickly, it doesn't result in an optimal outcome.  Sure, they're working, but they’re also lacking connection with their team.  They're less effective because they don't know where to go for some things, and because they don't know how to really work with everyone else.

I've found a few things can help get someone new onboarded and success :

• Make sure they meet everyone - this sounds simple, but make sure your new team member has time to connect with everyone else on the team.  I've found that prepping them beforehand with some background can also help guide the conversation (e.g. Sally has a background in coding, she's a great resource for X).

• Get time with them early - don't wait until they've already finished their first week!   Meet with them early and often, this both helps demonstrate that you care about them and their success, but also ensures they have time to get a feeling for how you operate.

• Proper resourcing - make sure they have whatever access they need to do their job as soon as they join.  Nothing saps morale faster then not being able to v successfully because your account isn't live.

• Ask them how you can improve - this new member will bring in new experience and knowledge that can help your team.  Asking them for their input on what the group can do better both shows you care about their thoughts, but also helps them buy into the group.

It does take time and effort to integrate new folks to the team.  That time is more than well spent - not only will the team benefit from their skills and time, they'll benefit from being part of the team.