Episode 69 ·

Nick Veenhof - CTO of Dropsolid

Today we are talking to Nick Veenhof, the CTO of Dropsolid. And we discuss making the transition from startup to enterprise, organizing your teams around people rather than projects and connecting the dots between business processes as a CTO.

All of this, right here, right now, on the Modern CTO Podcast

Currently, Nick is fulfilling the role of Chief Technical Officer at Dropsolid. Before this he fulfilled the roles of a Scrum Master and Principal Software Architect at Acquia.

Technologies he works with on a day to day basis are languages such as GoLang, Python, Ruby, PHP and Amazon AWS and Google Cloud services.

You can easily find more about nick by googling Nick Veenhof or his alias Nick_vh to find some of his open source contributions. Some examples can be found at https://www.drupal.org/u/nick_vh and https://github.com/nickveenhof.

Transcript

(Joel Beasley at 00:00:00) Hello, my friends. I'm curious to know how many of you have a leadership pipeline. We know that great leaders grow companies because we talk to them here on the show every day. But what are you doing to create great leaders within yours? If you're a CTO, it is 100% your responsibility to grow and improve your people beyond just their coding abilities.

(Joel Beasley at 00:00:20) We've built a tool that improves your people in their craft and in leadership. Visit leaderbits.io to learn more. Today, we are talking to Nick, the CTO of Dropsolid, and we discuss making the transition from startup to enterprise, organizing your teams around people rather than projects, and connecting the dots between business processes as a CTO. All of this right here, right now on the Modern CTO podcast. Here we go.

(Joel Beasley at 00:00:49) This is the Modern CTO podcast. Where are you located?

(Nick at 00:01:01) I'm in Belgium. So it's 5 p.m. now.

(Joel Beasley at 00:01:06) Wow. How did you get there?

(Nick at 00:01:08) I live here. I was born here. So yeah, I did travel around a bit to Boston and to Spain, but I ultimately ended up back home, basically.

(Joel Beasley at 00:01:20) Yeah. Boston is growing as a huge tech area.

(Nick at 00:01:25) Yeah. It's massive.

(Joel Beasley at 00:01:26) So what were you doing there?

(Nick at 00:01:28) I was working for Acquia. Acquia is, when I joined, it was a startup with, I think, 60 people. I think they're around a thousand or 800 people right now in year four. So they were booming massively. I was recruited as an intern initially in Belgium and then with a requirement to move to Boston to be part of the main office.

(Joel Beasley at 00:01:56) And what's their main goal there?

(Nick at 00:01:58) The main goal of Acquia is probably two parts. One is the main driver of making ambitious digital experiences with open source software, mainly with Drupal, if you've heard of that software.

(Joel Beasley at 00:02:14) Yeah.

(Nick at 00:02:15) So the creator of Drupal is the CTO of Acquia. That's how I ended up in that world, and that same software is still probably 90% of my working hour goals in the current company I work for. So it never really left me.

(Joel Beasley at 00:02:38) So how do you say his name? Drais? Is that how you say his name?

(Nick at 00:02:41) Dries.

(Joel Beasley at 00:02:41) Dries?

(Nick at 00:02:42) Or in Flemish, Dries. And his last name is even more difficult. It's Buytaert.

(Joel Beasley at 00:02:49) Buytaert. Yeah, it's just not how it looks like you would say it.

(Nick at 00:02:54) Exactly. Yeah.

(Joel Beasley at 00:02:55) Yeah. And so you got to work with them at Acquia when they first started?

(Nick at 00:02:59) Yes. So when they were, well, somewhat small, I joined. And then after a couple years, as I lived a year in Boston, I moved back to Belgium. I worked from a remote office for them. I really wanted to make a certain difference in the tech world in Europe because I saw that it was really difficult to grow adoption on a bigger scale in Europe as there's a lot more smaller to medium businesses in Europe compared to the US, which is kind of logical because you have all these small markets here in Europe. So if you want to grow big, you either have to do something really, really right, like Google or Facebook, or you probably will stay somewhat small.

(Joel Beasley at 00:03:44) What's the average size? Like, 10, 15 people, 30 people?

(Nick at 00:03:48) Well, of an average small to medium business, probably 10 to 20. Maybe a lot of them will go up to 60, maybe 80, but it's difficult to go higher.

(Joel Beasley at 00:04:00) So do you find a lot of duplication then? Because there's these small clusters, like, duplication in ideas, the same idea done over and over with different brands in different areas?

(Nick at 00:04:12) Probably, yes. But because there's so many languages, not everyone will know. Because you don't really know what's going on in France even though that's so close to you. I will probably even go further. We don't know in Belgium what's going on in the French part of Belgium because it's a different language and a very different culture, also business and tech wise.

(Joel Beasley at 00:04:32) Really? That's something so unique because I don't have that here.

(Nick at 00:04:36) No. It's really unique. In the US, so far as I understand, it's quite easy for a person to relocate to some other state because that's where you got the job. And a lot of people do that, and it's a lot of fun. And it's always the same language and most likely the same culture more or less. I know there's some differences here and there, but that's—

(Joel Beasley at 00:04:55) There's small differences, but they're not unlivable. You know? You can always find your group in every area.

(Nick at 00:05:04) But maybe if you move to Spain from Belgium, you have to learn Spanish because not everyone will know English, and your own language will also not work at all. So that's very different.

(Joel Beasley at 00:05:17) Yeah. My sister moved to China, and she has been there for a couple years. And she's explaining to me how different it is, culture wise, language, and she just learned Chinese.

(Nick at 00:05:29) Yes. She has to, I guess. It's the same with businesses. And instead of languages, you have to learn how the culture works of your customers. It's very, very different to do business in Germany than in Belgium, than in Holland, than in France. You can't just build up a SaaS product and expect it to work in that culture. It's really tough.

(Joel Beasley at 00:05:50) So you've been a Drupal contributor. I'm still learning how to speak.

(Nick at 00:05:57) Yes. It seems like it.

(Joel Beasley at 00:05:59) Right? I don't know what's going on. Yeah. Drupal is not a normal word. Is that—what language is that from?

(Nick at 00:06:06) It's a funny story if you want to know.

(Joel Beasley at 00:06:08) I do.

(Nick at 00:06:09) So Dries is from Belgium as well. And he first wanted to create a community, and he wanted to name it to the Flemish word of a village, which is called dorp, D-O-R-P. Now, he was registering the domain names, and he mistyped them. And he wrote D-R-O-P, which is drop. So then they started a little brainstorm and said, "Okay. How can we now use this in our advantage?" And it became, from drop in Dutch, druppel. And to kind of Englishify it, it became Drupal.

(Joel Beasley at 00:06:46) That is so amazing. That's why that word just threw me. Because I say it in my head, but I don't say it out loud much because, you know, when I'm reading and writing code, you see it all the time. You can't not see it. Right? So you've been contributing there for over a decade, which is pretty cool.

(Nick at 00:07:05) Yeah. Within Drupal, it's probably longer than 10 years right now.

(Joel Beasley at 00:07:08) So have you contributed to the source at all?

(Nick at 00:07:11) Sure. I, basically, did my master studies—or I don't know if that's the same name in the US—

(Joel Beasley at 00:07:18) Yep.

(Nick at 00:07:19) And one of the end goals there, usually, you do some internship, but it was also a massive project. So one of those massive projects was me to create kind of a better search ecosystem in Drupal 7 back then. So a lot of the searching and indexing code in a contributed module in Drupal came from me and guided by a lot of other people in that Drupal space.

(Joel Beasley at 00:07:45) Yeah. Go, Nick.

(Nick at 00:07:47) Yes. But obviously, then you learn to know a lot of other people. I got to learn a lot of other skills, and I grew into very different roles. So today, I have to admit, my contribution ratio went way down, unfortunately.

(Joel Beasley at 00:08:03) Well, that's okay because you're contributing in other ways. Right?

(Nick at 00:08:06) Right. Yep.

(Joel Beasley at 00:08:07) Yeah. So that's what you do. I mean, that's sort of—we talk about this a lot. You know, when you're starting now and you're writing code, that's your entry to the world because once you show that you can contribute and bring value, you're hard pressed to find people in managers or executive positions now or senior leadership positions that didn't write code for a good chunk because you have to understand where you're coming from. Right?

(Nick at 00:08:31) Right. Yep. You have to understand from the basis to these high level conversations. That's what I read in your book, by the way, as well. So thanks for that. It kind of confirmed what I was already thinking.

(Joel Beasley at 00:08:45) Yeah. It's so great. You know, I get about three people a day who write me now about the book.

(Nick at 00:08:50) Okay. That's good.

(Joel Beasley at 00:08:52) Yeah. It's—you know, because before you put it out, you're all nervous. How's the world going to respond? You don't really know. And then when you start getting just an overwhelming amount of positive and, you know, thanks for discussing—it makes my day. That's kind of one of the things I scan for every day is those letters or those emails from people. It's just really, really cool. So you went from Acquia, and now you're CTO of Dropsolid.

(Nick at 00:09:23) Exactly. Yeah.

(Joel Beasley at 00:09:24) Now that's an easy name to say.

(Nick at 00:09:26) Yes. You probably hear the familiarity there as well.

(Joel Beasley at 00:09:31) Ah, you got it. That was great.

(Nick at 00:09:33) I'm not native. So yes.

(Joel Beasley at 00:09:36) By the way, your English—you sound like native speaking English. What's your native language?

(Nick at 00:09:41) It's Flemish. Well, Dutch.

(Joel Beasley at 00:09:43) Dutch? Yeah. Excellent. Yeah. Your English is on point.

(Nick at 00:09:46) So probably of the years that I spent in the US. But yeah. So Dropsolid is also doing a lot of business development with Drupal. So that's how I got into that sphere as well. And they were focused on that small to medium markets in Europe. So I saw that opportunity. I saw the tech part I fully mastered somehow. Or you can never say fully mastered, but I was very confident, at least.

(Joel Beasley at 00:10:15) Yes.

(Nick at 00:10:16) And then there was this position and—okay. Now we need someone technical because we're in over our heads right now as the current owners. We cannot lead our dev team any further than what we already did right now. So that's why I stepped in. It fully embraced that idea that I had that Europe needs to grow and that these small to medium markets also have so much opportunity to be more digital. I had that confidence of the technical level, and I had the opportunity to learn all these business processes and be a lot more influential in a very different way.

(Joel Beasley at 00:10:49) So how did you meet Dominique? And by the way, I love that name, Stijn, because I have a friend in my city named Stijn that everyone wants to call him Stijn.

(Nick at 00:10:59) Stijn. Okay.

(Joel Beasley at 00:11:02) Everyone calls him—because it's S-T-I-J-N. And I look here, and I have two connections in—I have two friendships in common with Stijn.

(Nick at 00:11:09) What's his last name? Because we have a couple of Stijns in the company.

(Joel Beasley at 00:11:13) Delanghe?

(Nick at 00:11:15) Stijn Delanghe. Yeah. It's one of our project managers in the company.

(Joel Beasley at 00:11:21) Yeah. He shows up first on my LinkedIn because I know Ben and some other people with him. But, yeah—

(Nick at 00:11:26) I'll tell him.

(Joel Beasley at 00:11:27) Yeah. Dominique and—and by the way, Stijn, the guy that's my friend in my town, he's a really cool person. So I like him a lot. I don't even know where he's from. I just saw that name. I'm like, I know that name.

(Nick at 00:11:40) When we travel to the US or maybe when you come to London, I'll take him with me.

(Joel Beasley at 00:11:44) Yeah. Yeah. Yeah. I—we had some friends visit from Finland last month. That was really cool.

(Nick at 00:11:51) Cool.

(Joel Beasley at 00:11:51) So how did you meet Dominique? How did you get involved with the project? How did you meet him?

(Nick at 00:11:57) Well, so I think last year or a year and a half ago, I was somewhat frustrated with probably the growth of Acquia where it was, and yeah, there were some frustrations, which is kind of normal when you work in a company for four years. And I think for the first time in my life, I said yes to a recruiter on LinkedIn.

(Joel Beasley at 00:12:19) They're always putting it out there, though. Right?

(Nick at 00:12:21) Yes. They always try. And but it was for a very different position. So, obviously, I then said, "No. I'm not interested. I'm good where I am." But he kind of said openly, "Look. It's for this company. It's with that person. Would you be willing to just even have a lunch with him?" So I did, and Dominique explained me his goals and what he wanted to do with the company, all his dreams. Dominique is a very inspirational CEO in the sense that he has a lot of dreams. And obviously, with the people that we are right now, we will never achieve it, so we need to grow. And there's a lot of things ahead of us, which is very good to have if you're joining a new company.

(Joel Beasley at 00:13:04) So you go into the company. How did you get the current team to sort of accept you as their leader and to follow you?

(Nick at 00:13:10) Well, so because I was already somewhat known from the community, from the Drupal community—

(Joel Beasley at 00:13:16) Oh, you're a rock star there. That's right.

(Nick at 00:13:18) Well, we don't like to use the word rock star because that gives a lot of pressure, and then we see a lot of people burn out because they wanted to be a rock star. A leader then. Yeah. So we need to be careful with these words, I guess. But at least I was somewhat known, so I didn't have to prove my technical ability initially. So the harder part was to kind of show that I was capable of defending them in business processes somewhat.

(Joel Beasley at 00:13:44) So were they getting a lot of change of direction from the leadership, and then you kind of have to come in and make sure that you can control the change so you can deliver stuff on time? Is that what it was?

(Nick at 00:13:58) Yeah. I think you can maybe mention it like that. The hardest part was that it was a culture of who shouts the loudest, if that's something you can say.

(Joel Beasley at 00:14:09) Yeah. Yeah.

(Nick at 00:14:10) And I worked really hard to move it into a certain agile flow that worked for that company. So every team has its own boards, but they are being able to borrow out team members to another team if it gets busy. But it also then reflects into the financial reports of that specific team that they borrowed out that person because each of the teams in our company have a certain bookkeeping, if you will. And they need to somehow also prove that they're profitable. But if there's a lot of pressure in one team to finish a certain project because of a certain deadline of a company, or a client that we work for, it's possible to loan another member from another team without impacting their profitability. So it was a very difficult system to set up in business processes, and I think that's also what I wanted to talk to you about, which was something I was missing a bit in your book, is that as a CTO, you're also responsible in connecting all the dots between all the different systems in a company. And understanding in a 60 to 80 people company as we are in right now, it's already very complex. I can understand that if you're a 100 or 400 people company, it's insanely complex. So that was my biggest challenge in the last year is to connect all the dots and to make sure that there are systems and not frustrations and emotions.

(Joel Beasley at 00:15:37) That's correct. Because after you get that down, the repeatable pattern, as you start—because where you're in is you're in a transition from growth to enterprise. So you have different problems to solve at each different level. When you're a startup and it's just you, you're developing the pattern for the actual code base, right? Because you're the lead developer. And then once you have that pattern established with you and someone else, you start adding people.

(Joel Beasley at 00:16:01) And now you have the problem of going from startup to growth, which is where you're collecting teams. Right? So now your core pattern for your software is solved. Right? You know what's going on, but now you have to organize people around working together and teams and, like you mentioned, the profitability.

(Joel Beasley at 00:16:16) And then once you have teams, you start to get groups of teams, and that's when you're going from growth to enterprise. And now you have to have a system for organizing groups of teams. And then from there, it just goes as far as it can go. Unless there's another way to state it, but from what I've seen all the way up to 10,000 people, you just get groups of teams. And once you've mastered groups of teams, it just can scale as far as you need it to go.

(Nick at 00:16:42) Right. And getting to that phase with those systems in place that make sure that the team is stable and that there's enough control mechanisms for that team that they're able to control as well. So not as a system to kind of beat on them with a stick and say, "Go, go, go." That doesn't work. They need to be able to see the dashboards. They need to be able to control those dashboards. And I think even more important, they need to agree on what those KPIs are for them.

(Joel Beasley at 00:17:11) Well, they have to buy into them and believe them.

(Nick at 00:17:12) Buy in. Yes. So that was a really difficult part as well. Like, what are KPIs for a development team that doesn't do their sales? So we have product teams. We have product integration teams. For product teams, it's easier because that's basically R&D. And you, as a company, know that you allocate a certain amount of your budget to R&D, and then you follow the regular agile flow of, "Okay, this is what our roadmap is. This is our capacity," et cetera, et cetera. But for those product integration teams, it's a lot more difficult, at least in my experience.

(Joel Beasley at 00:17:47) So tell me a little bit more about the product integration teams, what they do exactly.

(Nick at 00:17:51) So Dropsolid has a certain install profile. And with those install profiles, we build these websites and integrations with other tools like Salesforce and competing systems like those. The R&D team builds that install profile and expands on them and has the time to really dig in and take the time to do it well. Those integration teams, they use that software and build those ambitious experiences for those companies or those clients that come to us to say, "Look, we need this, and we want all of this stuff to happen." There's another team, a strategy team in our company that says, "Well, clients, maybe you should start small." That's already a very difficult conversation, and then, obviously, it needs to happen.

(Joel Beasley at 00:18:38) So the product team is sort of building the—in Ruby, I'd call it a gem. Right? Sort of building the connection with the Salesforce or with whatever. And then the product integration team is actually building the client's needs on top of that using that tool?

(Nick at 00:18:52) Okay. Maybe the name in some companies is professional services for these product teams depending on how you call it. And that's also a transition that the company made since I got there. Before that, they only had professional services. But obviously, if you only have that team or that division, you're always building from scratch. And that's not very profitable.

(Joel Beasley at 00:19:14) Well, and they're different types of developers typically.

(Nick at 00:19:17) Yes.

(Joel Beasley at 00:19:17) Yeah, you'll want different people. You'll want the people that are building those gems to be building gems all day.

(Nick at 00:19:23) Yes. Yeah.

(Joel Beasley at 00:19:24) Right? And then you'll want the people who are doing the client part doing that all day. It's just who they are as people. So then how did you solve the problem? Did you take the finances of what the client is paying for the experience and then put that as their sort of KPI, like a portion of that budget and say you can't spend more time than this? Or how did you come about the resolution of that?

(Nick at 00:19:47) No. No. So there's a couple of different KPIs, and there's a project manager that obviously takes care of the scope. And the team itself does the whole sprint planning or the project planning. But we don't plan the full project. And depending on how the project is sold, it could be that we're selling sprints. So we're not committing to a certain scope and time. Because if you commit to scope and time, then you're probably killing your business.

(Joel Beasley at 00:20:18) Yeah. No. I found that out real fast.

(Nick at 00:20:20) Yes.

(Joel Beasley at 00:20:21) That was ten years ago I learned that.

(Nick at 00:20:23) Yes. Right. So that's also something that we don't do anymore. Or if we do that, it's actually with a different part of our business, which is called Cool Drops. And Cool Drops is for the small businesses, and that's purely productized. So it's kind of going to the supermarket and say, "In my website, I want this and that and that." And the juniors, junior developers that started our company, are in charge of building those websites. So there, it's okay to do it in scope and time because we know the end result, and we know how long it takes to build that end result. So that's a very different—yeah, it's a predictable process. The bigger developments are not very predictable. So there, we sell them, if we can, in sprints. Otherwise, we sell them in packages and say, "This is must have," et cetera, et cetera. And we kind of commit on at least having the must-haves in a certain budget. Now, how the team does its KPI is that they have sprints. And it could be that teams work on different projects at the same time in the same sprint. So what I've seen in a lot of companies is that you organize your team around a project and not around people. But the difficulty is basically working together with people. And I don't know if you've encountered that in your interviews. It's not something I read a lot about yet in the book. But I did in other books. And if you organize your team around people and you put different projects in it, but you say, "Okay. From the start until in two weeks, this is the amount of stories that we want to finish. And we as a team commit to finishing these amount of stories. Okay. Fine." After three of those two-week periods, you can have an average, and that's the basic Scrum philosophy. If you take your average of the last three weeks—of the last three sprints—you can most likely predict how much you can handle in the next two if your sizing of these stories is somewhat accurate and similar to your previous sprints. So what the KPIs for those teams is to keep that number, the average amount that they can do on a full-time engineer division basis, stable.

(Joel Beasley at 00:22:47) You said something that really piqued my interest. You said organize around the project versus the people.

(Nick at 00:22:53) No. Organize around the people, not the projects.

(Joel Beasley at 00:22:56) Sorry. I just—I wrote it wrong.

(Nick at 00:22:58) Yeah. So the teams are stable, but it could be that projects move within teams, or it could be sometimes that you, as a team, borrow someone from another team. That one person still is part of the other team even though it's borrowed to another team. It sounds complex, but for those teams, it's really useful to identify themselves with a team and not as "I'm just a part of a chess game where I'm needed for a company."

(Joel Beasley at 00:23:29) Oh, it creates a sense of clarity and certainty because, you know, this is my team, but right now, I'm doing something different than where I belong. And that way, you always know where to go back to your tribe.

(Nick at 00:23:41) Right? It's your tribe, basically. Yes. Correct. And that really helped bring some stability in the company.

(Joel Beasley at 00:23:48) Now how do you structure leaders within your teams?

(Nick at 00:23:52) So there's different roles. There's an architect role. There's a Scrum Master role, and there is an estimation engineer role. The last one is some role that we invented ourselves.

(Joel Beasley at 00:24:04) Yeah. We've all been there.

(Nick at 00:24:05) Yeah.

(Joel Beasley at 00:24:06) Feel like we need this person to just be giving estimations because we're spending all of our quality doers' time creating estimations.

(Nick at 00:24:18) Well, so the those people with those roles are basically responsible of the output of that team when it comes to that subject. So it doesn't mean that no one else in that team is able to do estimations. It just needs to pass through that gate of that person.

(Joel Beasley at 00:24:32) That's smart. So the best roles form out of necessity.

(Nick at 00:24:36) Yes. But it was difficult to find out, like, what's the structure and then how can we make sure that we have this quality assurance in terms of not just code quality because that's kind of an obvious given. And there's so much lectures and sources to find online, like continuous integration and all those things. That's the easy part. The hard part is to commit on, "Okay, what did we do? Did we do it right? And is the value that we bring to that customer the value that he wants?" Like, I'm sure you know that cartoon where someone wants to build a swing for a kid, and then it becomes a swing with a tire. And then, ultimately, it's a really horrible swing because it always gets passed through other people. But in the end, the kid is not happy.

(Joel Beasley at 00:25:23) Right. They say a horse designed by a committee is a camel.

(Nick at 00:25:27) Something like that. Yes.

(Joel Beasley at 00:25:28) Yes. If you get a group of people to design a horse, it'll look like a camel with all the humps and the lumps and everything. No. And I find that there's a lot of companies that'll say, "Oh, we do Scrum," or, "Oh, we do Agile." And you go there, and it's like, "Yeah. You log your issues in Pivotal, but this is not what Agile and Scrum is."

(Nick at 00:25:47) You're just using Pivotal as—

(Joel Beasley at 00:25:48) —a to-do list.

(Nick at 00:25:49) Yes. Yes. Yeah. Yes. And that's also something I brought in not just in the development teams, but also in marketing team, in the sales team. Because if you try to do this methodology right, which is bringing the right value to that customer in a predictable time, more or less, you need to be able to sell it as well as a salesperson. And that was also really challenging for me. Like, how do you explain all these methodologies to a very different group of people that I've never interacted with before?

(Joel Beasley at 00:26:21) Right.

(Nick at 00:26:22) That was difficult. And not just explaining it, but also make sure that they use it themselves as well in maybe the most basic form because you cannot force to go all the way for certain teams. But at least having a backlog, having an understanding of how long something takes more or less is difficult.

(Joel Beasley at 00:26:42) Having something that is being used properly is better than having nothing at all. And then it's also about, you know, injecting it here and there and slowly building because you can definitely kill the morale and make it overcomplicated and get people frustrated. And then you have to deal with the human part of angry people. Right?

(Nick at 00:27:02) Yeah. So you have to be very careful. Don't go too quick.

(Joel Beasley at 00:27:05) So how large is your team currently?

(Nick at 00:27:07) The company is 75 people right now. There's 60 full-time employees, and there's a bunch of interns right now. So it's kind of skewed towards interns in this period. But in the summer, it'll probably go down to 65, but we're intending to grow.

(Joel Beasley at 00:27:25) How many of those are developers?

(Nick at 00:27:26) There's 30 developers, I think. 30 to 35.

(Joel Beasley at 00:27:32) I see you have five or six teams.

(Nick at 00:27:34) There's five teams indeed. So there's the three professional services teams or the solution integration team. There's an R&D team. There is this Cool Drops team, which is the junior developers. And there's also the infrastructure team, which I didn't count yet, but this is also very important because they're kind of the backbone for all those teams.

(Joel Beasley at 00:27:54) Explain that one. I'm curious.

(Nick at 00:27:56) So the infrastructure team is responsible for the whole server infrastructure on which the solution teams basically build their products on or the client project on. And their responsibility is, at least what I told them, is to become useless, as in—

(Joel Beasley at 00:28:15) I love it.

(Nick at 00:28:16) —the sense that they shouldn't be needed on a daily basis. And that's also a really difficult problem to solve. And maybe you can call it with fancy words like DevOps, but you cannot put all your infrastructure in the software development teams because that's also very frustrating. You don't want to do Linux kernel updates or any of those things in your professional services teams.

(Joel Beasley at 00:28:40) Well, that's true. Yep. Yeah. So have you started sharing any of your knowledge through talks or writing?

(Nick at 00:28:47) So well, that's interesting. So in July, there is a Drupal Developer Days event in Lisbon. And I proposed a session, and let me see if—I'll send you the link in email. But it's called "A Developer's Flight Over the Cuckoo's Nest." It was basically my story that I'm telling you on this podcast as well, on how I got from that developer to the role that I'm in right now and how can you scale a company with Drupal and all these different connections, all this Agile flow. So I'll make that presentation public as well, and it will be recorded.

(Joel Beasley at 00:29:27) Nice. That's in July?

(Nick at 00:29:28) That's in July. Yeah.

(Joel Beasley at 00:29:29) Excellent. You're gonna do great, man. Are you presenting it in English?

(Nick at 00:29:32) It's in English. Yeah.

(Joel Beasley at 00:29:34) Yeah. I mean, I loved all the different parts of it. I think you just nailed it.

(Nick at 00:29:39) Thanks. Yes.

(Joel Beasley at 00:29:40) Yeah. With a cold too. It's like you're a—

(Nick at 00:29:43) You can hear it, my cold? I hope not. No. No. No. No.

(Joel Beasley at 00:29:46) But you said it. But I'm saying if you have a cold, that's like an athlete training. You're training under harsher conditions than where you're going to have to perform. Right?

(Nick at 00:29:54) There is actually a Drupal company in Iceland, so maybe they get that credit of training under very harsh conditions. But—

(Joel Beasley at 00:30:02) Oh, man. They have their people out hauling ice and stuff and—

(Nick at 00:30:06) Maybe. Yeah. To keep the service cold, it could be. Yeah.

(Joel Beasley at 00:30:09) Yeah. I always said that. I said, "Look. If I talked to a Bitcoin mining company who was asking me about putting solar panels on their building, and I said, 'Well, your company is in Florida, so solar panels are great, but I would just go put the building on an ice cap somewhere.'"

(Nick at 00:30:26) Yes.

(Joel Beasley at 00:30:27) Because Florida is so hot. I mean, the average temperature is 83 degrees, 85 degrees year-round. And I mean, it gets hot. You're paying a lot of money for air conditioning. I was like, "Just go put it in Antarctica or, you know, somewhere reasonable that's—"

(Nick at 00:30:41) I think I read that some Chinese companies moved to Canada for those Bitcoin mining rigs. So maybe that's cheaper in the end for energy. I don't know. But they moved from China to Canada probably because it was cheaper.

(Joel Beasley at 00:30:58) Yeah. You don't have to cool—I'll tell you, I live in a very hot area. Do you live in a cold area or a warm area?

(Nick at 00:31:05) Average, similar to New York, but less snow.

(Joel Beasley at 00:31:10) Okay. I live in a place that never gets snow. It's like a tropical area, right? So I mean, on Christmas, you can go to the beach.

(Joel Beasley at 00:31:19) It's like 70-something on Christmas, right? So that's the type of area I live in. But in the summers, it gets very hot. So it's either warm or hot.

(Joel Beasley at 00:31:32) And so you don't want servers here at all. It's expensive to cool them.

(Nick at 00:31:39) But Amazon or Google doesn't have a data center over there because they are so busy with those regions that I—

(Joel Beasley at 00:31:46) They do, but they'll put them on a city on the water. So, thank you so much for hanging out and talking. And if people want to find out more about you, which they definitely do because you're awesome, how—other than looking through the Drupal source code, right—how would they learn more about you?

(Nick at 00:32:04) On LinkedIn, I think there's some profile information. I also have my own website, but I really need to take care to update that with much more recent information. So I wouldn't recommend you to go there yet. But yeah, LinkedIn is a great source of contacting me if you'd like to meet me or maybe have a conversation on how you think I could improve, or maybe if you need some information on how we do things in our company. I'm very open to show you all the mechanisms and tools that we have.

(Joel Beasley at 00:32:34) That's what it's all about, because those were tools that were not easy to come by. You had to figure it out. And so now it's kind of like what we do as people in our community—we share with the other generation so that we can grow.

(Nick at 00:32:49) APIs are key. Like, if you are not using APIs or if you're using tools that don't have APIs, please stop using them because they will fail you.

(Joel Beasley at 00:32:58) Screen scraping isn't like something we should—

(Nick at 00:33:00) Just don't do it. Yes.

(Joel Beasley at 00:33:04) But that was the whole 2000s, though, man.

(Nick at 00:33:07) Yes. And we're still doing it. Like, we're building a scraper right now just to understand our competitor landscape. Yeah, to understand what is the system that competitors use, what clients are using those competitors.

(Nick at 00:33:21) So we're still doing that, but that's, I think, a valid use case.

(Joel Beasley at 00:33:25) You doing anything with Nokogiri or any Ruby stuff?

(Nick at 00:33:29) I did some Ruby back at Acquia, but never really fully in-depth. I'm more into Golang or a little bit of Python because we do a lot in infrastructure with Ansible.

(Joel Beasley at 00:33:44) Yeah.

(Nick at 00:33:45) So that's more of my go-to technologies.

(Joel Beasley at 00:33:48) I learned about—I saw Golang for the first time about five to six years ago, like right when it first came out, I think. I think that's when it came out. But I was at a developer talk, like a meetup.

(Nick at 00:33:59) Mhmm.

(Joel Beasley at 00:33:59) And the guy had written programming Golang for a satellite that was up in space. And he actually, in the talk, he rotated the satellite with Golang functions.

(Nick at 00:34:09) That's awesome.

(Joel Beasley at 00:34:10) It was so—I was like, oh my. And he explained how Golang was written to be, like, the first language that—I'm digging back six or seven years ago, so let me try to get this right. It was the language that was written on the concept of, "Oh, this is how a language would be if we did it when we had multithreaded processors." Is that the point?

(Nick at 00:34:26) Yes, something like that. But the more appealing part for Golang for me was that it's a single binary, and you can compile it for any system. And that, in combination with the modern cloud systems like Amazon and Google, is a perfect match because it can scale horizontally because it's a single binary.

(Nick at 00:34:47) It doesn't really care where it's hosted or where it is. So it's perfect for these containerized environments. Whereas Drupal is a software that's probably predating Golang as this—

(Joel Beasley at 00:35:01) Oh yeah. Yeah, Drupal's old.

(Nick at 00:35:03) Architecture. And it's using also file systems, and it's very complex in what it requires from a system, so it's a lot harder to containerize or cloudize, if that's even a word.

(Joel Beasley at 00:35:14) That's a word now.

(Nick at 00:35:15) Yeah. Yeah, that's a word now. So it's really hard to scale that. And there are some companies like Acquia, like I think Pantheon also in the U.S. that are doing this, but then for enterprises.

(Nick at 00:35:29) But smaller scale companies don't have the money to even pay for that. So—

(Joel Beasley at 00:35:34) I'm excited to see the talk. When you do it, you gotta videotape it and then post it.

(Nick at 00:35:39) They will record it for sure. So no worries. I'll send you the link in the chat in this podcast, but maybe you can also post it if you publish this.

(Joel Beasley at 00:35:49) Oh, of course. Yeah. I'll post it in the show notes. We post show notes, so we'll say what we talked about and everything like that. Yeah.

(Joel Beasley at 00:35:55) Nick, I like you. I can't wait till I'm out in your area. I'm gonna stop by and see you.

(Nick at 00:35:58) Yeah. Come to Belgium. Come to our office.

(Joel Beasley at 00:36:01) We'll have some waffles.

(Nick at 00:36:03) Yes. And chocolate and beer.

(Joel Beasley at 00:36:05) Oh, all the great things, right?

(Nick at 00:36:06) All the great things in life.

(Joel Beasley at 00:36:08) Yes. Awesome.