Atlassian alumni make up a part of the Easy Agile team, with several former Atlassian staff working within the Easy Agile business. We had a chance to speak to another member of this extended alumni ‘family’, Boris Berenberg. Boris is an ex-Atlassian who eventually went on to found the New York HQ Atlassian Solution Partner Atlas Authority.
It was a particularly exciting day for us to catch up with Boris, as after a mere 3 1/2 years, Atlas Authority achieved Gold Partner status with Atlassian.
Personally, I had the pleasure of working just metres away from Boris in the San Francisco office. It was great to hear his journey, and learn how the Atlas Authority team have grown to double-digit staff members based in multiple countries in such a short amount of time. Meet Atlas Authority, an Easy Agile Partner.
How did you end up working for Atlassian?
I found Atlassian because a friend that I went to college with told me about this company that he was working for that paid to send him to Amsterdam for three months. And I thought that sounded cool. So this ‘perk’ was the driver for me getting into it.
An obscure way to ‘find Jira’!
Well, I started my in-depth learning of Jira at Atlassian because I helped write a lot of the performance tuning documentation when I was there. A lot of this work was done by the Sydney support team and I ended up dealing with most of the performance-related tickets that were coming into the San Francisco office at the time.
So when I left Atlassian, my particular skill set that very few other people had was, how do you make your Jira faster?
How do you get a performance improvement on Jira? That was my expertise.
So after Atlassian, you started Atlas Authority?
I needed something after Atlassian and I went to work for another company. During the interview process I recommended they look for a contractor for a few months but they still felt the role required a full-time staff member. So I joined them. It was a great job and a great team. Three months in, I was sitting there with nothing to do, kind of like I had predicted. So I went to the CTO, who was my boss at the time, and I said, look, my number one mandate has been to reduce Atlassian spending at this point. I'm going to go work somewhere else and wishing you guys the best of luck.
And at that point, I went to go work at Uber, and Uber was probably the best team I've ever worked on in my life. We're working with one of the largest Atlassian deployments in the world at the time; we were just all on the same page. Having that level of understanding and shared expectations on a team was just out of this world.
So because of my tenure at Uber, I had some ideas at the time around how an Atlassian practice should be run and I started Atlas Authority to see if my ideas were right or wrong. If my ideas turned out to be right to some subset of the market, then we could be a successful company.
I guess three and a half years later, we are. We are now almost 10 people in 3 countries.
So would you class your expertise as being Atlassian application performance focussed today?
Well we used to focus specifically on that, for instance, we helped the largest telco in America reduce their average Jira page load time from 12 seconds to 4.5 seconds. So a huge improvement.
At the same time, whilst our business grew, Atlassian was doing a really great job of improving the performance and stability of Data Center deployments, and they've done a really great job in Jira 8.0 around indexing performance. If you monitor Jira releases, you'll see that there's a pretty steady stream of performance-related and scale-related issues being resolved.
We knew that we couldn't continue to focus on that. We've kind of become a more general Atlassian partner at this point. We still tend to work with very large Data Center deployments with people doing highly technical implementations that involve very heavy, hands-on analysis, or writing custom code. We do data transformations from migrations from and to the cloud. We help with plugin migrations. Still very complex problems, but different from where we started.
Today, we also have a portfolio of 13 Atlassian Marketplace apps we call our own.
Were these marketplace applications from customer needs?
We created Atlas Authority’s marketplace business in a couple of different ways. Atlassian has a regular event called Ship It. Back in the day when I first joined, the support team was notorious for not participating in these events because while everyone else can stop doing their jobs for 24 hours, the support team found it hard to participate because they had to respond to customers. So I did my best to participate.
I created the Markdown Macro app and took second or third place for that Add-on during the ShipIt. And I won a ticket to the Dropbox developer conference at the time when the Developer Relations team picked me as their winner.
When we got started with Atlas Authority, Atlassian actually granted us the ability to continue to manage that plugin. And so at this point, it's grown to about 5000 installations and millions of end users. We push updates to it regularly & it started our journey into the Atlassian Marketplace.
Which add-on do you think solves the biggest problem?
Our customers are predominantly large organizations. Communicating within them is tough. For instance, people will say, “Hey, you know, my CTO doesn't understand the work that we do in Jira. If we purchase a reporting plugin, it may serve that information up better”. The thing is, a CTO doesn't want to go to Jira in the first place.
Most CTO’s sit in twelve meetings a day and make technical decisions. There’s not a lot of time to go digging through a tool. So providing a Monday morning email that summarizes exactly what's going on in the various initiatives automates updates and improves communication.
It means that you can bring the right message, in the right format, to the right person, at the right time.
The ‘push’ nature and the ubiquity of email makes our Notification Assistant for Jira a real elegant solution.
Does Atlas Authority use Agile methodologies to run the business?
I have had an interesting journey with Agile because when I was working at Atlassian, I built a tool using my 20 percent time. The tool did great, but the project completely failed because we hit the goals of the finance team and not the support team that was paying for the work that we were doing. So classic project failure scenario. A really hard lesson, and a reminder why a core tenant of Agile is to ensure your stakeholders are involved in what you’re building.
Now in the consulting world and owning our own products, we deal with Agile constantly, both in a delivery capacity as well as an internal capacity. Internally, we happen to use Scrum for a lot of the software development work we do. We heavily utilize Kanban on the support side.
So that was how you ran into Easy Agile products?
We were essentially using Easy Agile Roadmaps for two things. Our product development org is a bit scrum-fall. A portion of waterfall at a high level. Similar to program level planning, or doing theme or initiative level planning, but using a roadmap. And then we break it down as we get close to it and use a more traditional methodology to accomplish that.
On the other side, we were also using Easy Agile Roadmaps as a tool to visualize our consulting engagement work. As a way of seeing which customer engagements are running in parallel and what resources are associated with those customer engagements.
If we have a person working part time on a customer migration, and that migration is going to take three months, we need to be able to visualize that. We needed a light-weight tool that could deliver this for us at that time.
So you use Easy Agile Roadmaps to run your business! We are honoured. Have you encountered us at any customer sites?
We do, but we don't notice them for all of the right reasons!
We resell a lot of plugins, and a strong statement of support of Easy Agile’s tools is they work so well that we don't have to do very much handholding of customers. We don't have to do a ton of training. The UX is done really well. The visual design is done in such a way that it fits into the narrative of Jira as visual design. So a user doesn't need to learn a new visual terminology.
From a performance perspective, from some other vendors, we may see obscure issues. For instance, when we may see a background synchronization job running and it’s causing everything to slow down. Another common issue that we see is that large organizations tend to have similar time-based patterns of plugin usage when it comes using these tools. Another example is when everybody across the organization does their P.I. planning on the same day at roughly the same time.
If that tool is not built in such a way that takes into account this parallelism you can encounter serious problems when people are depending on the product. A lot of the time an application may have low usage 90 percent of the time. And then 10 per cent you will encounter crazy spikes in terms of what that application is asking Jira's backend to do which can make it all fall over.
I don't think we've had to deal with a single complaint about Easy Agile apps in three and a half years of consulting. That's amazing.
Thanks for your time Boris, but I have to ask, did you ever get to Amsterdam?
So that's a great question. So during my interview with Atlassian, they asked me why I applied. I mentioned the secondment was a common thing I heard about the company. They said, absolutely, you can do that with us. I should have gotten it in writing as it took over 3 years to get there!
But it was worth it the wait, I had an amazing time. I loved Amsterdam and I've gotten back five or six times since then.
It's been one of my favourite cities in the world that I've ever gone to and I particularly enjoyed working with the team there.