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.

Tool Tip - Send Later

While I try to only work during “working hours”, which are generally 8-5 Monday to Friday, but can go all over the place, I typically find myself being inspired to do work at odd hours.  I also frequently find myself writing emails that should be sent at a more opportune time (for example a project update shouldn’t go out at 5 PM on a Friday… no one will read it anyways, PLUS it will get buried in their inbox by Monday).

In the past I’ve drafted those emails and then manually sent them later. This both allowed me to funnel my inspiration when it struck, but also to get information out at the best time.  It did, however, require me to remember to actually send them.  That’s when I discovered the “send later” feature of gMail and Slack. 

This does exactly what it says… it will send your message at some later time.  It completely removes the delay between writing an email and sending it later.  I’ve found it particularly useful in scenarios like:

• Sending emails when folks are more likely to read them - especially useful if you’re writing updates on a Friday or late at night.  Having it send early the next morning brings it to the top of their inbox.

• Queuing up messages for people in other time zones - for example scheduling it to drop into a coworkers inbox at 8 AM their time, even if it’s midnight my time)

• Sending myself reminders to do something - I’m constantly sending things to myself in the future so I don’t forget something

Continual Improvements (Retrospectives)

One of the things I like most about Agile project management are the retrospectives.  I do understand that they can sometimes feel onerous, or frequently have folks complaining about yet another meeting, but they allow us to do something to ourselves that we’re doing for our systems - continually improve.

Many of us are constantly focused on questions like “how do I make salesforce easier to use?” or “how do I ensure new hires can get their equipment faster?”.  These questions are all basically a variation of “how do I continuously improve where I work?”.  Many of us keep grinding away answering that question without taking (or making) time to step back.  Retrospectives are our chance to change that question to “how do I continuously improve how I work?”.

Continual improvement is something we can do on our own, but I find it takes a LOT of willpower and energy.  Critically examining my own work, habits, etc. is hard!  Having a safe group to help me with this makes this a lot easier.  There are, however, some ground rules that have to be followed:

1. Honest collaboration - everyone on the team has to have a mindset of helping the group improve.  This isn’t an opportunity to blame Sally for that fire she caused, or Sam for forgetting to push an update.  It’s an opportunity to identify ways to prevent the next fire from happening.

2. Everyone contributes - These meetings can easily be dominated by one or two voices.  While they may have good points or ideas, there’s the rest of the team that doesn’t have a chance to share their insight.  Everyone on the team has expertise and experience they can bring to the table if we just let them.

3. Document it - Once you’ve got the time set aside and the ideas flowing it needs to be documented… after all, it doesn’t help anyone if you take that time and then forget what you learned.

4. Make it regular - This isn’t a one time thing.  Time should be taken for continual improvement on a regular basis.  Making this habit part of your working cycle will help everyone get involved and begin moving towards better versions of themselves.

 Exactly what these retrospectives looks like can differ, but the end goal is the same… making time to ensure the team is able to both improve the product, but also to improve themselves.

Ticketing system transition grace periods

Moving to a new ticketing system (or starting one for the first time) can be jarring for everyone.  Customers won't know how to ask for help, agents won't know how to update things and process managers will be scrambling for metrics.  These challenges are common to all system changes, after all change is hard (citation needed).

To help combat this I find having a brief 'grace period' after deployment to be very helpful. During this period agents won't be too harsh on folks putting in tickets improperly, managers won't be expected to have a complete grasp of everything and agents can be forgiven for missing new SLAs or mis-tagging tickets.  The length of this period can vary, but in general at least a few weeks is needed to help with the transition.

This grace period doesn't mean I'm not paying close attention to how things are going.  Instead it's the exact opposite.  With all the new changes and process I'm paying more attention to possible challenges.  The grace period isn’t just for the team, it’s also for me to figure out what adjustments are needed to further improve how things operate.  Taking extra time and energy to identify, and correct, defects at this stage will pay off later since it's all new.  

Implementing a new ticketing system (or really any systems) presents an opportunity to set expectations on how folks interact with it.  Once everyone has had time to learn bad habits it will be MUCH harder to reshape behaviors.  This makes having a set window where everyone acknowledges they’re still learning, and ensuring folks are actively aware they need to change, very important in this shift.

I also find that treating this grace period like a retrospective and regularly review everything with the team (and customers!) is beneficial.  I find calling attention to mistakes, and using them as learning opportunities, is a great way to help the team improve during this time and helps provide the best transition possible.

Misalignment within stakeholders

Alignment with stakeholders for things like expectations and priorities is incredibly important (citation needed).  Indeed, it takes up most of my time as a project manager as a misunderstanding here can lead to poor outcome (at best).  While this can be challenging, at least project managers have some control over it; we can communicate with those stakeholders to ID and set those expectations.  The harder challenges come from misalignment within stakeholders.

Imagine a scenario where you agree on a set of priorities with your main stakeholder.  Your team executes on that, and then provides the final deliverables on time.  And then things go sideways.  It turns out what you delivered wasn't what was really needed.. despite being what was agreed on with your stakeholder.  You and your team might rightfully be confused as to what happened… after all, everything was agreed on and delivered on time.

Despite that agreement, it turns out you weren't working on what was really needed because your stakeholders weren't aligned.  This misalignment could be because stakeholders at the same level didn't align with each other (for example two managers on the same team), or it could be because management above whomever you worked with had a different set of priorities (a manager and their director).  Regardless, you and your team have delivered the wrong thing and may take a reputation hit because of it.

At the surface level this seems to be a problem for your stakeholder to solve.  After all, THEY weren't aligned.  At its core, however, this relates to not properly engaging your stakeholder group.  It's possible you didn't properly ID who you should speak with, or maybe you did, but then didn't share enough information.

This risk can be mitigated by ensuring your RACI is as complete as possible (especially the Inform group), and ensuring you communicate out priorities for your next Sprint / project / etc.  Personally I tend to share this with my stakeholders leadership as an FYI on a regular basis (monthly or quarterly depending on the group), just to ensure they've at least received this information.  At worst it's adding an extra email address, at best, it saves a TON of headache. 

Expectations with transitioning to a ticketing system

The move to a ticketing system is a necessary step in a company's growth.  It can be an exciting shift (especially for the support teams using it!), but it can also be cause for some heartache, especially for the end users expected to use it.  The root cause tends to be change… those individuals are going from simply emailing or talking to someone to now having to use a System.  

Generally it doesn’t matter what system is used, there’s now a process to follow.  That process could be as simple as using a new email or more complex like having to go to a website and fill out specific fields in a form.  This change results in friction, especially when expectations for what those users should do aren't clearly set.

Exactly what is expected can differ, but regardless of specifics, what an end user is expected to do should be considered during the deployment process.  Taking time to think through what they’ll need to do, speaking with some directly, and adjusting your system to help make things easier does take time, but it will pay off in the end.  

Failing to think this aspect through can lead to a lot of friction as your new process and system is rolled out. Customers, after all, are the ones who are coming to you asking for assistance. They’re the ones who may not be able to get their own work done, and now knowing how to reach out for help, or not knowing when help will be provided, can make their lives a lot more miserable.

Below are a few questions I ask myself to help figure out what those expectations are.  By no means a complete list, but a good starting point that will help you get into the head of the folks expected to use your shiny new system:

1. Who will be putting in tickets?  I prefer that the person experiencing the issue report it, but will it be OK for someone else to submit it?  What about agents submitting on behalf of a user?

2. What is the expected response time?  Knowing how long to wait for a reply or resolution is critical, but to protect your team and also to keep users comfortable with timelines.  Having this clearly set and shared is important.

3. Where/how should tickets be entered? Ensuring everyone knows where, and how, to enter tickets reduces frustration, especially if it changes. You should also consider what happens if someone puts in a ticket the 'wrong' way.