"How" and "Why" - towards a more user-centric Atlassian application administration

[#1]

Let's start with an assumption I have regarding us Admins…

We only believe we know our Users‘ needs, what‘s best for them and for our Applications. We never actually verified our hypothesis on a grander scale. Really, we don‘t actually have a clue what‘s going on in our Users‘ minds nor in our applications.

Anybody triggered yet? Good! That means there is at least some truth to it. If not, I'll just speak for myself then.

Atlassian Tools are central to our everyday work. Confluence has all the knowledge, Jira all the tasks. Improving these tools and saving each person just a minute a day, quickly accumulates to ~ 100 hours a year total (200 work days * 300 employees) for our medium sized company. Cloud Migration was one of these improvements - or so we thought. If you've checked out my article on our grand migration success (or was it?), you'll know that we could have done much better on considering our users' needs.

Research shows that user participation & Change Management is one of the top key factors in an IT project's success. So why aren't we doing more of that?

As a matter of fact, we've got a lot to learn from our Users: We can find out about current usage, use cases and what features are missing in their daily work. They will tell us all about their expectations, requirements and unfulfilled wishes - whether we like it or not.
Also, only they know what new Feature Rollouts are actually relevant to them and their work.

That is A LOT! Assuming we acquired all that knowledge already, we would know our key (& friendly) users and use them for testing, we could build Roadmaps, plan for changes and build trainings that suit their needs. One more thing, that the Product Managers among you will love, is optimising costs: we no longer need to buy Apps that aren't being used in the end, only pay for licenses that are nessecary and will be able to build strong Business Cases because we can finally measure the expected value more accurately.

Sounds great - but how do we get there, you may ask.

"How do we get there"?

While there are several methods that don't require *talking* to your users, the most effective way to figure out their needs is indeed asking them about it. I know, that's unfortunate and certainly not efficient but nessecary.

While I won't share all my knowledge in this blog post (that's what my corresponding presentation is for - hit me up if I should talk about this at your event!), I will share my biggest secret:

"How" and "Why".

No, that wasn't a question to you all. It's just two of the most powerful words when it comes to Requirements Analysis.

Let's imagine I, Rebekka, administer a Confluence site and want to find out more about what Alice thinks and needs.

R: Let's talk about the Confluence search.

A: I don't like it.
R: Yet you use it anyway.
A: Yes.
R: Why do you use the search even though you don't like it?

A: I need to find things.
R: Why do you need the search to do that?
A: Because the contents aren't stored in a clear structure.

R: Why is that?

A: We don't have restrictions or specifications on how to structure our spaces.

R: Why are there none?

A: Nobody is responsible to create these restrictions.

….

R: Let's get back to the search. How do you use the search.

A: (What a stupid question..) I simply type in a word.

R: How do you use the search bar specifically?

A: I type a word in the input field and click search?

R: I guess you heard of filters? How do you use those?

A: Not at all.

R: How else do you find specific contents then?

…

Using How- and Why-questions will change the level of abstraction in your conversation.

"Why" will move you further away from the original question, giving you a broader understanding of the topic. We found out, that the search isn't the actual problem. It's how contents are stored and more so a missing standard. People just don't know where to look for it.

"How", on the other hand, will get you more details up to the point where you're getting more or less the same answer to your how-question.

Obviously the example is constucted and it would feel unnatural in real life but you get the gist. If you use the two words (or similar question words) together with other clever questions in the right setting, you'll walk out the conversation much more knowledgeable than when you entered it.

Use that knowledge to improve your company's Atlassian Apps and it will not only make your users happier but also your life easier. Tried and tested it myself :)

Still with me? Fab! I love to talk all about good question & content users and will gladly speak at your event about it. Whether it's an ACE, in-person, online, English or German. Hit me up in the comments or on LinkedIn <3

---

Credits for illustrations used in this article go to vectorjuice at Freepik

[Bill Sheboy]

Hi @Rebekka Heilmann _viadee_ 

Thanks for your article.  In addition to 5-whys and other root cause analysis (RCA) methods, please consider "Job Shadowing" or "Pair Programming" methods to learn more about how team members use (or do not use) Atlassian tools to help them deliver value. 

By either observing (or guided-doing in the case of pairing), we may get past the "Knowledge Bottleneck" challenges where a person is so accustomed to doing things in a certain way, it becomes automatic and they miss communicating the steps taken.  The direct interaction will lead to the "why do that", "what are you doing now...that seems different than what you asked", etc. prompts which will help admins learn more and have context for suggestions made and experiments tried.

Kind regards,
Bill

[Rebekka Heilmann _viadee_]

Hi @Bill Sheboy 

thanks for the Comment!

While I won't share all my knowledge in this blog post (that's what my corresponding presentation is for - hit me up if I should talk about this at your event!), I will share my biggest secret:

My presentation covers more methods, including Field observation & System archeology :) So yes, you are absolutely right. There's of course more to asking questions than just "how" and "why" as well. I might cover more things in future Blog posts.

[Jason M.]

Much appreciated for providing this article & practical guidance on a topic that's typically overlooked or forgotten. Usually due to having to plow through hectic workloads & manage a wide variety of user expectations vs. what's feasible on the platform. Thanks!