The road to Bitrise: an interview with Damien

Damien Murphy shares with us his journey to Bitrise, his defining career moments and what he would do for a career if he wasn't doing this.

At Bitrise, we value our people. That’s why we want to introduce you to Damien — our Solutions Architecture Manager from the US. Read about his journey to Bitrise, what it is possible to achieve at Bitrise and beyond, and his most-defining career moments. 

Why did you choose to work at Bitrise?

I have been a mobile developer since 2005 — even before iPhone and Android existed. In college, I built J2ME games. At the time, I was building a breakout clone, a wap website, a bus time table, a course time table app — it got to the point where people were calling me asking when the next bus was.

I really enjoyed mobile in the early period. 

After college, I joined a mobile travel app agency. I helped build and manage the largest travel apps in Asia for iOS and Android.

Then, I joined SAP (in the mobile innovation center) — and over my 3.5 years there — we built more than 300 mobile apps prototypes. We got these prototypes out to the sales team, they took them to some events, and they pitched it to customers. I was involved in the sales side, the event side, and the mobile side. 

When Bitrise came up I kind of thought, “okay, this is a pre-sales role for a mobile company, and DevOps was something I was working on at SAP as well”. So, it was a perfect combination of the three things I was already doing and loved. It really hit the sweet spots for me — and that’s why I joined!

What’s your role at Bitrise? How does your role contribute to your wider career journey and provide opportunities for the future?

My role has evolved a lot at Bitrise. I joined Bitrise as a Solution Engineer. Over the course of 6 to 9 months, I became the manager of the Solution Engineering team and was the first Solution Engineer in the US. And my counterpart, Tamás (Tamás Bazsonyi Solutions Engineering Tech Lead at Bitrise), was the first one in EMEA. So between the two of us, we managed the two regions. 

Every time we sealed a deal, we worked on the post-sale support. But, that pile just got so big, it took up 80% of our time. Eventually, we split these two jobs and that helped a lot; we were able to focus on hiring more people with sales experience (less with mobile development experience) and for solution architecture, we didn’t have to hire people with sales experience — we could hire people who had mobile development experience.

Later on, as a customer experience team and workload group, we expanded our team to 7 in total. At that point, we needed to specialize in our roles, as the team and workload was growing. At the start, solution engineers were doing pretty much everything (customer success, account management, solution engineering, pre-sale, and post-sale work). 

As a customer-focused solutions team, we had more and more work to do. 

A few months ago, I shifted from the pre-sales role into the post-sales role full time and I’m building out the solution architecture org. Now, we have two teams that specialize in both pre-sales and post-sale and that allows everybody to be more efficient. It is a better experience for prospects and for customers because these two teams work close together and communicate on daily bases. 

In the future, I would like to focus on automating how we can improve our customer’s journey through onboarding to adoption. 

What was the lesson that you learned along the way, that you wish you had known right from the start?

I think the process of learning lessons is the lesson in itself. If you know all the information from the start, then you’re not going to learn anything new and your work might not resonate with you as much. Learning the lesson is always the best way to know things.

The most important thing I’ve learned at Bitrise is how important people are and the importance of caring and sharing with your colleagues.

Aside from that, one of the things I’m learning now is how to explain how I got to a conclusion. I need to make sure that there is a context between the problem and the solution. You need to bring everybody up to speed so they understand what the suggestions and solutions are. I’ve got better and better at documenting my thought process.

Do you have any tips you’d like to share with aspiring Risers?

Getting to know people is one of the most important things to learn. You should focus on getting to know your team and your stakeholders you’re going to work with over time. This is especially important in remote work. 

​​What kind of skills do you need to have to work effectively at Bitrise?

One of the things I look for in a candidate is their ability to proactively do something without my intervention or without somebody asking them. The reason that is so important is the autonomy that comes with both solution engineering and solution architecture, it is a very unusual role where you actually don't work very much with your teammates. You primarily work with customers/prospects and other teams. Solution engineers will work with account executives, BDRs, SDRs and maybe even sales ops. They probably would not work with each other very much. The same goes for solution architects, we work a lot with support, CSMs. Our team is made up of individuals from different teams. 

Being proactive is very important. If you are not working on the same project with somebody you are essentially working with a group of different team members. If you are not proactive then you essentially won't have any guidance on what to do. 

Be curious, question everything.
If you see something that you think can be improved, then test it out. If you can’t find the documentation, maybe it’s not there, go and write it.
If I look back, some of the best things I’ve done weren't the things my manager asked me to do. Those were the things I’ve just seen that a customer needed and I was trying to help those customers achieve their goal. Necessity is the motor of invention. 

What’s your favorite method of learning?

You learn way more by failing to do something. 

If you’d like to read documentation, you can read all the documentation on a topic you want. But, until you actually try to put it in practice, you won’t know what roadblocks you will run into. The documentation probably won’t tell you that on step two or in step three, an integration will fail in your environment because of a particular setting — you learn that by doing it.
We decided to create 13, one-hour training sessions with the support team led by me and  Atanas (Atanas Chanev, Senior Solutions Architect at Bitrise).

What we’re doing is helping the support team by “doing” rather than sitting through a one-hour meeting where we’re showing them how it works perfectly. We go through it with “trial and error”.  

I was failing while I was doing the training sessions which was great so they could see how you solve those issues. Showing the support team the process of what is possible was a real “AHA” moment for a lot of people in the training.
When you do it it’s completely different when you just follow a “read me”.

No items found.
The Mobile DevOps Newsletter

Explore more topics

App development

Best practices from engineers on how to use Bitrise to build better apps, faster.

Community

Meet other Bitrise engineers, technology experts, power users, partners and join our BUGs.

Company

All the updates about Bitrise events, sponsorships, employees, and more.

Insights

Mobile development, latest tech, industry insights, and interviews with experts.

Mobile DevOps

Learn why mobile development is unique and requires a set of unique practices.

Releases

Stay tuned for the last updates, new features, and product improvements.

The Mobile DevOps Newsletter

Join 1000s of your peers. Sign up to receive Mobile DevOps tips, news, and best practice guides once every two weeks.