Well, here we are, another month down. At let me say, you guys killed it last month!
We got well over 1,000 views last month! That almost doubles the previous month and is easily the biggest month the blog has had to date. Thank you all for commenting, liking, and sharing the blog with your friends and colleagues! You guys are what makes this all possible!
Today’s topic is a bit different. This item was suggested to me by a colleague. In a nutshell, he wanted me to look at the difference between being an Atlassian Admin and an Atlassian Consultant.
As you may now, I was a JIRA Admin before starting my current job. But seeing as I have only been a consultant for six months, I decided to call in some help. So welcome to the blog David Higdon, Olena McMurtrey, and Neil Taylor. They will be lending their thoughts onto the topic and answering some questions I posed to them!
How did you get started with Atlassian Components?
Neil: So, the first job I had out of college – they were running a helpdesk – and this was before JIRA Service Desk was around. But they were like, “Hey, We’re using this new product called JIRA.” And that was when JIRA was on version 4. So I got to adapt that to run a Service Desk for about ten thousand Dialysis Facilities. It was an interesting use case for the product, and I don’t know if they chose the right product for that, but it got me in the door with working on Atlassian.
Olena: Coyote Creek had both Microsoft and Atlassian teams; I started in the Microsoft division, and with time transferred to Atlassian team. I got passionate about Atlassian products, and enjoy helping clients to tune their systems with best practice approach.
David:
So, one of my good friends leaves the company I’m working for and joins a software company. And their Engineering Team at this software company was looking for somebody to help manage their middleware space from a Unix SysAdmin perspective. At the time, I had 27 years of experience as a Systems Administrator – of which I had spent six managing the middleware space, and they felt I would be a great addition to their team.
As this company was coming out of the startup phase, they were looking to get a little more structure in place and a bit more formality in their processes, and for someone to help them standardize and automate things of that nature. And being an Engineering Department, they are big on Atlassian Products. They had two instances of JIRA – one external for Professional Services and their Customers, and then an internal system for their Software Developers. They were using two instances of Fisheye/Crucible. The Professional Services instance looking at SVN and Engineering instance was looking at GIT.
So, my first day on the job, they sat me down, and they said, “Here you go, here are two instances of JIRA and Fisheye, and here are the hostnames.” I had to learn Jira ASAP and prepare to upgrade the system. So, I’ve never heard of Atlassian at that time, so this is how I got introduced to Atlassian – literally diving into the deep end.
Rodney: I was working as a consultant for First Responder Dispatch systems at the time – that being the systems the operator is typing into when you dial the emergency number.
However, that job required a lot of travel, which was not a good situation. Looking around my company, I noticed an open position for a Linux Administrator. Now this company prided itself on being a Microsoft shop – so of course, I was the one dumb enough to raise my hand and say, “Yes, I know Linux!” I applied and interviewed, and was honest about my experience, and got the position of managing some Linux based development systems.
So day one, I go in, and I’m getting the grand tour. We go over my server closet, the perforce server, our backup process, and finally, JIRA and Confluence. I’m given admin rights to the systems and told, “Congratulations. You have a day before you start getting tickets, and by the way, we want to upgrade the systems this quarter.” At that point, nothing left to do but start learning one ticket and google search at a time.
How did you become a consultant?
Neil: So, I put JIRA on my LinkedIn, and a consultant company contacted me and said, “Hey, we want you to come be an Atlassian consultant for us,” because they had a client that was using Atlassian products. I interviewed for the position, and they offered me a job, and I thought, “Well, hey, let’s give this a try and see some other Atlassian environments out there.”
I have to admit that Atlassian wasn’t on my radar when I was in college. I also didn’t see my career going from Atlassian Admin to Atlassian Consultant, but I’m happy with the way it worked out.
David: Over my years, I had quite a few opportunities presented to me before I joined Coyote Creek. I had offers for Backend Sales or Consulting but never took the opportunities. Before I joined Coyote Creek, however, I had two separate Engagements with them and enjoyed the experience and the expertise they provided. It was a combination of being a little older in my career. After twenty years of being on the front line supporting mission-critical applications, I was ready for a new role.
My introduction to I.T was as a Computer Operator working graveyard at Oracle. And about a year into the job, I met some Senior SysAdmins that worked in the Development Datacenter, and they had all the latest cool toys. As I built a relationship with these guys, and they told me more about what they did day today, there was one aspect of their job that stood out. There were never on call. I quickly discovered that being an Engineer for Developers and supporting their systems was the dream scenario. You get all the cool toys, do the same kind of work, but nobody cares if a system is down Saturday at 10 PM.
That job at the software company was my first opportunity for that kind of work – only supporting Engineers and Developers, and there is nothing mission-critical about code deploys because it was all about the next release. So that was my first dip into that situation I always wanted since starting I.T. Consulting is kind of a natural progression there, so when the opportunity came up, I made a move.
Rodney: Honestly, I avoided becoming an Atlassian Consultant for a long while. My previous experience with it left a bad taste in my mouth, and I worried about a repeat of that experience. However, when I was in the job market last year, it got the point where I had multiple offers. I was clear during the interview with Coyote Creek that I didn’t want to return to a scenario where I was traveling more than 25% in any given month ever again. They agreed, and all told they had the better offer, so I signed on with them. And it has been a much better experience than with my previous time as a consultant.
What do you feel is the biggest difference between being an Admin and a Consultant?
Neil: I think the most significant difference is that the consultant has the space to look at the bigger picture and to make the recommendations towards best practices. When you’re an admin in the trenches, you get so busy with the day-to-day “Hey, I need this workflow” and “I need this project” that you can lose sight of that. That’s where a consultant can come in and lead you away from some nasty rabbit holes.
David: You do not own the system or application. For where I am at in my career now, I am not looking to support environments 7x24x356, so this works out great. It can be challenging, though, if you want to make updates or correct areas you were not requested. That is still the old Admin in me. However, I still really enjoy Architecting solutions and problem-solving. I spent many years in the service industry, so it’s also the customer service aspect, and being able to provide solutions to people is what drives me today.
Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s not a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.
What do you wish more Admins knew about being a Consultant?
Neil: That our role is to make everyone’s lives easier – including yours. We’re not there to try and complicate anything, but instead to make everything easier. And a lot of times that includes making the Admin’s lives easier, because we don’t want the interface to be messy and there to be a bunch of overhead either.
At times I feel admins think, “Oh, they’re bringing in a consultant, they are going to try to to over-complicate this project.” But that’s not the case, we want to make everything easy too.
Olena: I think a lot of Admins don’t know how exciting it can be, how there is this non-stop race to learn new technology. It takes a very hungry approach where you want to learn new things and take on new problems all the time.
David: You do not come right out of school into a consulting role – spend time as an Admin or an Engineer to develop the technical skills to take on such a role. Additionally, develop the soft skills for communicating with your clients.
Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s never a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.
Final Thoughts
Neil: Being a consultant is unique because you are jumping from one thing to another. At times, it can be fast-paced and intense, but it keeps you from getting stuck in a rut. You are always learning something new, so you never feel you are getting stale.
Also, no one’s setup is the same, everyone is doing a slightly different thing, so it’s always an adventure.
Olena: To be a good consultant, you have to be a good Admin first, as you have to learn first-hand the pain-points of someone using the products daily. It’s like learning colors before you start the whole painting. It provides a background on how better to support clients to close the gap between the business and technical sides.
David: The best and worst aspect of JIRA is you can do anything 10,000 different ways, and as a consultant, you have to peel that back. It may or may not be the best way. But there have also been times I’ve discovered that the way I did it wasn’t the best, and the way that someone else implemented it was better than mine, so I can learn from that way.
Someone told me this a long time ago, “There is nothing more permanent than temporary!”. After all my years supporting everything from mission-critical environments to lab systems, I found this to be true. Countless times someone told me they would need access for X amount of time, or they rack some computer here for a week or need root for the day or need to run their app on my system until the budget is approved to buy new hardware.
Rodney: I feel that being a Consultant and being an Admin are two sides of the same coin. Each one emphasizes different skill sets, but you both build off of the same necessary base skills. But at the end of the day, it’s still up to all of us to learn and grow.
And that’s it for this week!
So, I’m trying something new with this interview format here – and honestly, I’m nervous about how it will play out. So if you enjoyed this post, please do take the time to like it and leave a comment!
Don’t forget you can also subscribe below to the blog to get it delivered each week directly to your inbox. You can also follow theJIRAguy on Twitter!
But until next week, this is Rodney, asking, “Have you updated your JIRA issues today?”
The Jira Guy 
1 Comment