Guest John Doran

 

 

Spotify | iTunes | Sticher | Google Play | Player.fm | MyTuner Radio

 

Hello, and welcome to the podcast. I’m your host Dave Albert. In this show, I talked about technology, building a company as a CTO and co founder and have guests to discuss their roles in technology and entrepreneurship.

Today, I’m joined by John Doran, Director of Engineering at Phorest Salon Software, speaker, and one of the organizers of this year’s shipitcon here in Dublin, which is a community-driven nonprofit conference about software delivery. Thanks so much for joining us, John.

John: Hey, Dave, thanks for having me.

Dave: Yeah, that’s great. Would you give us a little bit of background on yourself?

John: Yeah, sure. So as I have been working here in Phorest for the last three and a half years, and really, really enjoying it, we’ve got really high growth business, lots of great challenges, technically, around scaling the system. And lots of great people here. So yeah, really happy there. And then also, this year, I’ve been helping organize Shipitcon, which is an awesome conference, which is really focused on the delivery of software and yeah.

Dave: Yeah. Let’s start with shippitcon, because that’s, that’s really interesting. What’s, what’s the background of it?

John: Yeah, background, there are a few guys it says, in 2017 did the very first shipitcon in Dublin, Tom, Ross, Kenny, and another person. And essentially, it was a really, really great success. I went along myself, brought my team along and thought was a really great event to us to together, get yourself out of the office, gather some thoughts around software delivery, listening to some really great speakers, with their kind of thought leadership around it. And like a really good day, there were about 150 folks there, it was in the Mansion House. And it just felt like a really good formula for success. So last year, it didn’t happen. So essentially, I know Tom should have docker meetups and many other things. So we just said, Let’s get going again this year to see what we can do. And we’ve made some serious progress in the last couple of months, to say the least really excited about it.

Dave: So how is it different? What does community driven?

John: Well, yeah, so does a few things. Like, the first thing is like, We’re not trying to make any money from us. And we’re not trying to actually, you know, push a brand or do loads of advertising, it’s really about getting people together to really focus on like on software delivery, and bring really great speakers. And also encourage local people who may be talking around the meetup circuit and haven’t really got out there to do a talk. I really just trying to get everyone together to push that kind of agenda. So like, for example, will give any profits back to charities, we’re going to try and get some charities there to actually be like do a stand, the main way will actually pay for it, because it’s quite expensive, like to fly some of those bigger speakers over to actually feed 200 people in mansion house, lighting all that good stuff. So the main thing really is we’ve got some really great sponsors on board to help us out. So that’s been awesome. And ticket sales going to be a very small amount of money really enough to ensure people have skin in the game to attend.

Dave: Gotcha. So have you announced any speakers yet?

John: Yes. So our first big speaker was our first speaker was actually Sam Newman. So he’s the author of building microservices. He’s a really great, great speaker. He has a lot of great content on breaking apart monoliths, server lists. He’s a really, really great speaker. He’s worked in taught works for 10 plus years. I know he’s, he’s, he’s on the speaking stage. So yeah.

Dave: Great. And it will be at the Mansion House?

John: Mansion House again, it’s booked, it’s positive paid. Yeah, so hopefully, I don’t need to pay anything out of my own pocket. And we can get all the sponsors on board. So if anyone’s listening and wants to help out, certainly, feel free to reach out to me.

Dave: What’s the, what’s the date?

John: It’s the 6 of September. So we’ve got a good few months. And so Sam is our first speaker announced we’ve got another really a really great speaker 95% along the way, so I was checking my email very early this morning to receive confirmation. And yeah, so so. And then there’s also actually some really great talk submitted, we’ve got about 45 talks submitted. And we need to spend a lot of time going through to make sure that we have a really good balance of speakers and the right topics. So for us, it’s a lot about the future of shipping software. And we want people to think about where where they’ll be in 10 years, and where we will be as an industry and sort of pushing that as some of the subjects into some really great talks from people who are in stripe, intercom, the service framework, just to name a few, like just really excited about some of the talks I’ve been submitted.

Dave: Nice. So is it going to be a single track?

John: It’s a single track yeah, it’s a big room, and we’re hoping for 150 to 200. But to be honest with the speakers that we’ve got lined up, I think we could nearly do 300. And we’re doing some other things as well. Like, we’re going to try and get a quiet room maybe for people who need maybe need that little bit of space to share those. We’re going to try and make it as good as possible. Yeah.

Dave: Great. I look forward to hearing more about it. And hopefully attending.

John: Cool. Thanks.

Dave: So can you tell me a little bit about your role? Like your actual day to day.

John: Yeah, so this is just the Shipiticon is just the side piece. And yeah, my day to day is really responsible for engineering in Phorest. So what that means is essentially product delivery of time and scalar scaling the business. So we’ve got 30 people in product and engineering. And I’m responsible for five teams that are comprised of the delivery. Yeah.

Dave: How, how big was the company when you first arrived? At least the IT department or the development group whatever you call it yourself.

John: There were five people in the engineering group when he joined three and a half years ago, our CEO was the product owner. And we had, essentially a bare bones setup, we were just really trying to do our best to keep things going and make ends meet. And in terms of the company itself, there were roughly 75 people when I joined about 1800 customers. So our customers are SMBs, now we’ve got over 200 people, and over five and a half thousand customers, new regions, Australia, for example and Germany. So yeah, it’s been exciting to see the different stages of the company, because it’s definitely it’s not the same company I was when I joined, we’re in this lovely office today. And yeah, it’s cool to see there are different challenges and be part of actually solving them.

Dave: So So what was the infrastructure like, back in the beginning, back in your beginning?

John: And yeah, so to talk, like, the main infrastructure of the Phorest system was essentially one cloud formation stack, which, which lived and comprised of everything that the system had that was deployed, so one of those is for the US and one of them for Europe.

Dave: And what was the journey from where that was to where you’ve gotten to now?

John: A pretty big journey, I would say, essentially, that big stack was growing and growing in size. So take, for example, the easy two instances were huge. And there were lots of, essentially, throwing caches at artists to cope with the load, because more customers coming on board. And those big servers that were stayed full, kind of struggled with that. So to break that down just so many different components to try and to solve that problem. But to take it away from infrastructure from a sec, it would, it would kind of start the workflow. So when you look at the workflow of the team, and they’re delivering software, maybe once a month, or maybe once a quarter, and you know, like, just like some maybe a lot of code smell, but like a team smell with me that like the CTO at the time he, he did frequent take a holiday when I bring his laptop with him because something went wrong, he’d have to redeploy that stack would take a long time to deploy, when it actually needed to. So like hours and hours of change, testing changes, making sure nothing broke, even configuration changes and stuff was really slow and tedious. So it things like that. And then you look at when you look at like something like that I was actually reading this tonight, like the Joel test for, like the answer test for Yeah. And one of them is the ability to ship changes, fast to production and having automated testing and that kind of stuff. And it was missing. And it was some really good foundations in Phorest when it was originally built around the integration tests and stuff, but decayed over time will be safe to say and ignored. So yeah.

Dave: That’s as a founder and CTO myself, I totally understand that you’re not always making the best possible decision, you’re making the best decision at the time.

John: Yeah, with the resources that you have.

Dave: So there’s a lot of times that you were choosing not to do something in the best way for the need for speed.

John: And when it kind of catches you out is when you don’t maybe look at or track some of those decisions you make and actually go back and fix them. Because if you keep going forward, then you might get into a state of decay.

Dave: Yeah. I’m constantly I that’s what I found is that the team and the team and the work, the flow of work in the team are the hardest challenges. And the tech itself is not simple, but it’s a much simpler, it’s a known problem to be solved.

John: It’s a lot easier to tell the computer what to do than the human unfortunately.

Dave: What have you learned through that process with helping manage the flow of work?

John: Essentially, you need to be so confident to in your software, that you can click a button and ship it to production. And you need to get to a stage where you have really good sent essentially really good comfort zone and assurance assurances that what you’re building what you’re shipping is safe. So creating a safe environment and safe, safe automation around that really important. And then what it does is it unlocks this great kind of Pandora’s box of goodness because you’ve got product owners are getting builds that aren’t just running on a developer’s machine. And they’re getting, you know, feedback from customers some, you know, stuff that we’ve introduced over time, like feature flags, and all that good stuff. Just unlock so much for us.

Dave: So how do you actually implement your feature flags, because that’s a topic that’s extremely compelling.

John: Talk about that for a while. So on the front end, we, over the last couple of years have moved a lot of our native point of sale to a web. And part of that for us is using launchdarkly, which is a feature flagging product that we bought in. So rather than going to build our own, we leverage off them. And it’s, it’s been a game changer would say for us. We’ve been able to control our role, it’s really tightly between our beta testers and even internal people, we can control who sees feature flags based on the type of user their, their, their region, somewhat a really cool kind of ways of targeting user. So that’s been really powerful for us and, and what it’s actually that us to do is we even feature flags, some of our refactoring or technical work. So we literally ship every PR to production. We test it, we test it by using like a revision key, so it’s not active. So we would have like a version of every PR we ship is in production, we would get that Sharky and tested. And then once you’ve tested it would activate it. So really, really powerful for us. And we’ve gone from shipping, like once a quarter between the front end back end 40 times a week to production. So I know like there are other companies that claim to have hundreds and hundreds of thousands per day, but we’re small like we’re still maybe only 15 engineers at the end of the day. So it’s pretty impressive anything,

Dave: It’s when we set up our automation pipeline. So we check out in PR gets merged, that then ships to test automatically deploys, and then we just tell our bot, to ship it to production, we’re not quite ready to ship straight to production, we don’t have enough controls in between, commit to.

John: Yeah, and that’s fair to say like, we put a lot of the ownership on the engineers to make that final step of activation. It’s not like we have such good test coverage there that we know every last thing will be sorted out. But we try to evaluate the risk level when we do activate. So it’s kind of continuous delivery with, you know, very low friction to get it to actual deployment.

Dave: I’d love to see a more detailed description of how that actually works with the activation.

John: Yeah, I can try talk to it. But

Dave: No, no, I understand that doesn’t necessarily suit audio.

John: Yeah so one of our engineers who champion that he called lightning deployments. And the idea is that you’re your back, you actually your front end is served by essentially a URL that that’s the stores the HTML in Redis cash, and the keys for the HTML are different versions of your application, and they get returned by the server. So give us a lot of flexibility and control there.

Dave: That’s, I still can’t I mean, just audio can’t do it justice. You have to, you have to see pictures. But yeah that’s a that’s really, what’s sorry, we’re going to say something. Oh, just I was gonna ask, you mentioned having your CEO was the PO there in the beginning. And we’re in a very similar situation. Can you talk about the challenges that that may have cost?

John: Yes, yeah. So I guess the first thing is that when the CEO tells an engineer to do something, they do it without really questioning it. And that’s great sometimes, but maybe sometimes it’s in the interest of getting a sale across the line or fixing something for a very pissed off customer, and then maybe not taking the interest of many customers, their priority versus want. So they are the needs of the many outweigh the needs of the few sometimes and actually run, run and build a lot of foundations of Phorest with a few engineers on it, it stood the test of time. And there’s lots of really great stuff in there. I think one thing would be that we didn’t really appreciate the value of designers at the start. So we didn’t really have that. So you see a lot of in the older products that we, we haven’t been rebuilding a lot of very similar, just, you know, database tables on the UI, essentially, because is no engineer, sometimes are pretty good at that side of things. So he just plopped the data on the screen. So there are just a few things. But also, it has an effect on the business as well. Because when CEO is so involved in the product, and we’re trying to scale, the focus is getting you know, burnout essentially happens when you’re trying to do too much.

Dave: So yeah. And that’s one of the things you also see is that obviously, the CEO has a load of responsibilities and keeping the business running and keeping the business and customers or money or whatever. So they’re not always available to make decisions at the time that would make as convenient.

John: Yeah, yeah. So Patti joined as a head of product. At the same time, I joined, taking a lot of that responsibility away from Ronan. And I think one of his first jobs was to tell some customers no to some things that was promised.

Dave: So let’s see. I know, I guess we’ve already covered that I saw in some of the slides you sent over to me the PR to production, but we got to talk about with the lightning.

John: Let’s talk about the Docker stuff a little bit.

Dave: Yeah, yeah.

John: Yeah. So we mentioned like, at the start, the Phorest was when we joined, like very much a single stack, and a big server that was getting like really expensive, and had lots of caching and stuff. So the big thing for us here was that we needed to become, like, able to scale better and, and decompose that big system. So for us, that meant removing the caches. And to, to break apart that bigger system. So rather than five servers living in one cloud formation stack and being deployed, the same time to just break them into their own containers for in our case, so we moved everything to be in Docker-based. And then as part of that, then we plug that in like we brought Jenkins in because there was no ci, the build tool was like a command line up with a server that lived in the office somewhere. So we got rid of that had Jenkins started shipping those smaller components on Docker to like, environment. So there wasn’t, there was a test environment, which was very brittle. So just having like, a very clean slate of Tech Dev, staging production, and just actually starting to ship those components to those environments and start testing the moves. So yeah, that was kind of the journey there. It makes sense.

Dave: I had a question, in my head and it just flew right out the window. I’m sure it’ll come back. Anyway, what? What are some of the things you wish wished that you had known when you started that, you know, could have helped your journey?

John: I was only asked this question today. So I’ve got some some ideas fresh in my mind. And I was talking to some of the engineers about it. So and we were really early adopters of ECS. So ECS is container orchestration, Amazon’s container orchestration framework. So if a container becomes unhealthy, it will bring it back to life. It will manage your green blue deployments, all of that good stuff. So because we were very early adopters, there was no framework, there was no Terraform to integrate with that that was. So we spent a few weeks and we wrote our own little framework that kind of just proxies, Amazon’s API’s, written in Python, it is very simple. But looking back, if we hadn’t waited six months, we could have, we could have gotten some some some really great tools and in fairness now hasn’t changed in two years. And we haven’t seen the need to, but for newer stuff, we are using Terraform, and the service framework and stuff. So it’s a little bit inconsistent. And a couple of other things. So again, being early adopters of Docker, we decided to host our own Docker registry. And like three weeks later, again, Amazon released its registry. So have I think that’s a big thing, just having to host stuff. Try to avoid it at all costs.

Dave: Yeah, absolutely. That’s the last job I had before starting Medit. We were at the very early stages of Docker, and hosting an internal registry, at the point when the registry didn’t even have authentication. So I had to basically write some Lua code, which I didn’t even know, with an engine x fork to be able to connect to our elder system. And I was quite proud of it. But it was one of those times where weeks of work went into something that then ended up in the bin.

John: Exactly. And imagine like that registry going down or something like you don’t when you do stuff like that you don’t really take them seriously enough. And imagine then, like your containers and production needed to pull an image that wasn’t there something so that’s nasty. So another one we would have done as we were breaking a monolith we needed a Message Broker. And our use case really filled RabbitMQ. And so by doing that, we’ve been able to break apart the system and build it very much event based. So part of our system, we act on events and do something from that. Because we’ve got a lot of notifications and events and stuff in the system. And we’re hosting ourselves has been painful. I would really wish I had have just paid someone to holster RabbitMQ at the time, we will look at that and do it very soon because it’s taken up too much overhead.

Dave: Can you say what the differences between it and something like ask us or that what you thought you needed?

John: Yeah, so um, yeah, as we could very much use SQS for our use cases right now, particularly, because we’re using lambda and SQS and SNS could tie together very nicely. At that time we weren’t. And we’d have a lot of consumer like consumers coming, consuming events, a different from different queues. And it was the right use case at the time. And now we also have, we also have JMS stuff going on with active mq. So there’s a lot of different types there’s MQP, JMS, SQS and SNS, there’s a lot of notifications happening the system, I would think, yeah, if-if I had the time, or it could have taken that time with the star, it would have just consolidated into one. Yeah.

Dave: It’s always easier to make decisions after.

John: Yeah, exactly. When the features are live and working, it’s hard to cultivate the time, particularly if they’re not problematic. If they’re just taking over and they’re not causing any stress, with the bigger problems to solve, in some cases.

Dave: How has React Native worked out for you guys?

John: Yeah, so that’s an interesting one. And we ship, we onboard 200 customers every month. And each of those customers on a separate package, say 150, get an app. And that app is customized for them. And you can imagine teaming and customizing and buying App Store accounts for all those people is time-consuming and laborious. And then the other thing is, we five and a half thousand customers and say like, say 50% of them have the app, so two and a half don’t have it iOS and Android. So that’s five test and binaries if to manage. And it’s five like it’s 10,000. Like, there’s a lot of code base there to manage. So if you could imagine a bug fix, and this new payment stuff with stripe, if something needs to change there, we need to ship a lot of code to actually fix that. And a big thing for us with React Native was, hey, we only need to manage with with with this new mechanism. One JavaScript bundle for iOS one for Android. and codedeploy will manage all of that for us. So that was huge for somebody kicked off that really already part of that last December, figuring out how that that those, how those operational efficiencies would really work for us. And the side fact was our Android app was terrible. Customers weren’t happy with it. So we needed to rebuild that from scratch. So we were thinking, hey, let’s look rather than spending the next few months building not just Android, let’s go all in and try and get some really good efficiencies for the business while we run it. So to answer your question, I’ve never seen a project go so well, Torchwood, they’ve, they’ve literally a really strong senior engineer who joined us here with a lot of background in iOS, development of mobile. And he’s just, he’s just a pro. And he came in and picked up the React Native side of things. And he’s mentored a graduate who’s come up to a really high level to work on that up with them. And they’ve completed this most of it now we’re ready to start beta testing. So really impressive. I am really impressed. I had taken a bit of a risk on it, to be honest for them. Yeah, so far, so good.

Dave: Nice. I wanted to use it. But we just had too much data. I couldn’t justify risking our core data on a technology that we had zero control over that, you know, Facebook had yet a bit too much control of

John: So for us the way we solve it was the worst case scenario, we get an Android app by the end of the day so that that’s Dave: Let’s just download a phone. So you would download a card would you, you would be able to. Yeah, so you didn’t have any sort of technology issues.

John: Our main challenge would have been the calendar view. So we display a bunch of availability. We’re pulling down like we’re hitting a rules engine to display availability for salons. And it’s heavy on performance to pull that down and scroll. True, very nice calendar but Nicola has done an amazing job on actually forked one of the rack native calendars, and he’s built an awesome solution. So that would be our main challenge. Definitely.

Dave: Okay. Yeah. No, it’s uh, it’s always nice when it does work. Yeah. I’ve known some other people who’ve had issues, I think I think they were able to carry on but are just a massive amount of data. And yeah, just wreck. Yeah. You know, something like lost Redux. Yeah, or one of those data.

John: So we like we looked at even another challenge for some apps might be they need native capabilities, like 99% of our use cases are covered. So we’re cool on that. Because essentially, it’s a booking flow with personalized, you know, login loyalty points, that site side of things. And then push notifications and stuff like that which are handled.

Dave: Yeah. Yeah, that’s a, you know, it’s a, it was the right move for us not using it. But also, our iOS app has been out for a year on our Android app is coming out this week, or something yet, soon, very, very soon. It’s either this week or next week, depending on

John: We always have this challenge where we build on iOS. And then we say, Okay, let’s see how it let’s check, check the product data, check the usage. Let’s give it a bit of time and see how it works. But we never come back to it like we are, we have another app, our software staff member app, which is for like Salon staff members. And there’s a couple of features that are just lagging behind. So if the, if the branded app goes well, we will probably look at rebuilding their staff up and revenues. So one, one thing not to do is mix React Native and native. Yeah, it’s a very, it’ll bring you the Hell,

Dave: I can imagine. Yeah, yeah. But, you know, when I first looked at react, which was now is two and a half years ago, so the state of it now was nothing like what the state it happens to

John: That famous article from Airbnb, why they walked away from React Native, one of their main things was they built a Frankenstein app where it was built. And every time a new developer went to build the screen, it would be Oh, should just be native, native, all that kind of stuff.

Dave: So yeah, yeah, it’s I could have imagined being in exactly that type of situation. So that I see that you’re using code push?

John: Yeah code push is our solution for essentially distributing bug fixes and updates to those apps, Microsoft Corporation, really, really impressive presenter.

Dave: So that you don’t have to typically update the entire mobile application through like the iOS app store, or Google Play Store, or whatever. But you would push the code that the application on the user’s a device within a download the newest load of content.

John: So it’s really powerful there for us as a business is routed on, you know, a bug for 5000 apps having to run CI jobs to build all of those IPAs, and it because you literally just update your bottle of JavaScript, and every user gets it. So now you don’t even need to go to the App Store on wait. And then the other thing is actually a lot of customers rebrand or get sold or rename or whatever. So that’s just really easy for us to change that stuff. It’s a quick question fashionable, how, you know, you could literally build, you could ship new features, you can like change the whole flow of your app. So you’re kind of breaking the review guidelines, but it’s a gray area.

Dave: Yeah, that was my next question is, have you had any issues? with apple? or?

John: Yeah, we’ve, we’ve had lots of issues at Apple. So we are apps that were all on one developer account for a long time. So we’ve got about 1500 apps under Phorest. And when they started cracking down on the branded template in app guidelines, essentially, they wanted to clean up the store. And they wanted to prevent people from having coffee apps. So for us, that meant every salon who has an app needed to have their own app store account. So that’s a big change for us as a business and operationally to actually do that. But we’ve embraced it and we’re moving forward.

Dave: And it’s kind of pain that the force that but

John: Yeah, it’s put up some businesses is like completely out of pocket. Like if you can imagine there’s a lot of companies out there who to do that. And let’s do it. So the solution is that you, your customer buys apps, or can you do that? So for us, that meant having really good automation around our we use the fast lane for all of those meals right now. You need to have really good automation there to be able to switch code sign and all that stuff.

Dave: Yeah. And I have you had major issues, since the Phorest to the two factor authentication?

John: You can imagine we’re getting salon owners to sign up for accounts. And we need them, we need them so we’d like you. You can only do three, you can only authenticate three accounts on your phone before he stops. Yeah, so it’s, yeah, it’s fun. Our automation is pretty good. We have actually a team in the Philippines who, who managed a lot of this stuff. So there’s this there’s actually a Slack channel that when an SMS comes in that the verification code doesn’t have a Slack channel that can use it and lots of fun stuff there. We had to get creative.

Dave: Okay, how do you do road mapping?

John: Oh, good. That’s a big question.

Dave: Because that’s a major challenge we have. I have.

John: Yeah. So. Yeah. So from a product point of view, we don’t really we don’t try to look at what’s common in nine months time or in specific quarters, we look at like, what are the problems we’re trying to solve now? What is coming up next? And what are we going to look at in the future? So we look at it in those three ways. And when we’re working on stuff, Now, obviously, we’re very clear on how we’re going to solve the problem. And that obviously comes from a feed of what’s up next and what we’re looking at what’s coming up next. We talk to our customers a lot. We go to work in the Salons. We use prototyping we, we use our user voice community, in product surveys to really drill down on what they need. And we only flesh that out. And essentially, you know, involve a lot of the team and look great company and those decisions as well. Strategically, like we set our goals for over the next three years. And everything we work on should feed into those things. So for us, it’s getting to 12,000 salons, it’s increasing the average bill of the end user of the salons and it’s also to increase the revenue of the salons by 10%. So we’ve we focused on our decision making on them and back to what the company is set out to do, which is really to help small SMEs to run and grow their business. So our decision making is all based on that. And our roadmap is always now the next future.

Dave: Okay. How do you typically actually work is that like in sprints? Kanban?

John: Sprint’s typically Yeah, so I mentioned we’ve got five teams, but four of them are product development. So two-week sprint, some of them do one week somewhat one of them have been experimenting with the base camp six-week cycle model. And that’s very effective when you’ve got small bursts of work, but not very effective when you got huge, huge pieces of work. Yeah, so we’ve got it what works was really well is typically to experience keeping Jira probably we’ve got product owners for each team designers, and it works quite fluidly. A lot plan on changing anytime soon.

Dave: Good. Good. Yeah, that’s a we haven’t hit the right mix of the right thing yet. I mean, we get, we go through really productive phases when we can focus on something and deliver. But having a very busy product owner. It’s tough.

John: It takes discipline like it really takes discipline, says no to people and to prioritize properly. Because what we’ve made a mistake before just has I call them spinning plates, just too many things going at the same time. And what you just make yourself less effective at the end of the day,

Dave: Hundred percent. If you’re looking at JIRA, and thinking, I wonder what I should be working on it, definitely not using the tool or the techniques

John: We should we try to like each team, I mentioned has a specific vertical on the roadmap, and they’re very much aligned to the problems that that that the roadmap and vertical slice of the roadmap are trying to solve. So each team should have a very clear goal. What are we trying to achieve by the end of this? What like, what is our product usage going to be when this feature is delivered? What revenues is it going to make? Or has, how’s that going to affect the bottom line? We tried to be data-driven around that. I was going to mention about like knock it hard to finding a hard to get the right mixes, likes, we’ve got like 50% of our team is distributed. So some people just maybe have to drop their kids to school really early in the morning and stand up maybe doesn’t suit sometimes. So we like you have to be flexible like some do it at 11. Summer 10 used to be you know, some do use actually automated status updates. You kind of has to pick what’s right for the mix of people.

Dave: Where are your remote people?

John: Everywhere. So got a guy in Cork, got four people in Poland, a person in Hong Kong, one person in Italy and France, and soon to be Argentina as well. So yeah, like, our main kind of rule is if you’re, if you’re going to be working remotely for us, you need to stick to our time zone. And that works pretty well. We tried to get folks over twice a year for like off sites, company gatherings, all that.

Dave: Yeah we did the same. We have some guys over in India. Yeah.

John: And then you have to kind of get along.

Dave: Yeah, it makes a big difference.

John: Yeah, I think like, read so much about this. And that there’s a big distinction between like distributed teams and, and remote workers. So they were distributed. I tried to make sure I use that all the time, because very much. It’s not about Phorest in Dublin being the HQ and these people being like, feeding into us. It’s we’re a team, and we’re very much distributed around the world. And I think it’s an important distinction.

Dave: I like that. That’s it. Definitely. We already embrace that philosophy if I hadn’t heard of the language. Yeah. And that’s good language.

John: Yeah. Cheers. words do matter. Yeah, exactly. Yeah. Especially when they’re written and people can’t see face to face.

Dave: Yeah. Yeah. So you mentioned earlier that you’re hiring, what types of roles you looking for?

John: Yeah, so I mentioned a big Rebuild of our products. And that’s a lot of front end work. So yeah, we’re always looking for good front end engineers, particularly were bought into Ember on that side of things. And then back end, a lot of our backend components are Java, kind of, you know, there’s just a lot of big data problems there and challenges to solve. So anyone who’s interested in that kind of stuff is very much like to talk to them.

Dave: If you are considering moving over to React Native, will Ember change to react if possible?

John: No, I don’t think so. Um, and, you know, there’s there’s lots of arguments there to talk about reuse and stuff. But our online bookings platform was built a long time ago. And Ember, we’ve built a lot of really good foundations, Ember is for me, built and designed and pushed by the community for big ambitious projects and gives you a lot of the things you need to do that. So it’s very much the right fit for you, man to work we need to do with us and the people as well. We have been very skilled in it. So yeah, it’s all JavaScript the end of the day. Some people are saying that.

Dave: with the, with the shipitcon, is there anything you’re you’re looking for from people? Do you need volunteers or?

John: Absolutely, so we need obviously, people to come will be good to start. And we really could do with some volunteers to help us out on the day with attendees, logistics, that kind of stuff. We’ve got four people on the team now. We’re doing great stuff, but particularly on the day of being great. And so if you think you know, you, if you think your company could do it, pushing your employer brand little bit, you know, sponsorship isn’t hugely expensive, and got lots of great people attending, so that could be really good for you. So yeah.

Dave: And so look, I’m, I’m sure some people are thinking that you know, I’d like to help but I’ve never done anything like that. That’s not a bear.

John: No, just literally come, we’ll put a T-shirt on you. And we’ll give you a role. It doesn’t even matter if you’re not technical like and it as well. Like if you’re thinking about maybe pushing yourself to deal with your first talk, would encourage people to submit a talk, if there’s something you’re interested in. And we’ve got people who would coach you on public speaking and help you with the nerves, but might be really good for you to push yourself at a conference on and then go for it.

Dave: Thanks. How did you get into speaking at the meetups and conferences?

John: And that’s a good question. And I don’t like it. I get very nervous, like, but I just do it.

Dave: You do very well.

John: And it’s really about like, I like to challenge myself in different ways. And technically I can. I could always write code and lump things together. But I’m just around meeting people and mean really interesting people like yourself, and I just really enjoy it. I get a kick out of it. Although it’s scary.

Dave: I’m sure it is. I’ve been delaying outlining for so long

John: The best way to do is commit yourself to even having really properly prepared and then you have to do it.

Dave: All right. Is there anything we haven’t touched on?

John: No, it’s been great. Lots of great topics covered. Yeah. an interesting way to start the day I say. thanks very much.

Dave: Alright, Thanks very much for joining us. And so call to action. Get your shipitcon ticket. Come, volunteer. Submit your talk. Anything else?

John: Absolutely. Check out our careers page at phorest.com

Dave: All right. And how can people reach you?

John: @JohnWilDorian. One L, at Twitter the best show.

Dave: Great. I’ll stick a stick a link to that and a link to shipitcon in the show notes.

John: Yeah, awesome. We also have an internal blog, which is not so much focused on the end users of Phorest but more so how we operate as a business and some of our philosophies around hiring, building a product, marketing, lots of different areas. So it’s called nothingventured.rocks. Gotta check that out as well. It’s good. Lots of good poster.

Dave: I’ll throw that link in there too.

John: Thank you.

Dave: Thanks very much. And thank you all for listening.

Until next time, remember any sufficiently advanced technology is indistinguishable from magic.