Washing Away Imposter Syndrome - Bart Farrell - Data on Kubernetes Community

In this episode of ShipTalk, we are joined by Bart Farrell who leads the Data on Kubernetes Community. Bart certainly has not had a traditional path to technology with stops in theology and talent management. Bart has made two leaps, one into tech and one into a more bleeding edge/crypto part of technology, running stateful workloads on Kubernetes. 

Not being afraid of change and finding confidence in courage in incremental success is key. As an engineer, you might be looking at working with any new technology or a new paradigm/process. You don't have to give a talk in front of 50,000 people to start learning or even be an expert. Part of the human element is that a community can help you complete your story. Imposter syndrome plagues many in the engineering community, learn that you are not an imposter and more in this episode. 

Transcript

Ravi Lachhman  00:06
Hi, everybody! Welcome back to another episode of [the] ShipTalk podcast. I'm your host, Ravi Lachhman. I'm very excited today to be joined by Bart Farrell. Bart actually runs the Data on Kubernetes Community. Bart, for those of the listeners who don't know you, why don’t you tell us a little bit about yourself?

Bart Farrell  00:22
Very great to be here, thanks so much for having me. As you said, my name is Bart which for starters is already a little bit unique, not very common. But anyways, I'm from Northern California originally, but I've been living in Spain for the last nine years. I basically got into tech around five years ago; I always have to explain this [for] full disclosure: I am not a programmer; I'm not a DevOps; I'm not a systems administrator, DevSecOps, whatever you want. I come to tech from the human side, and I got into tech five years ago. I got recruited by a British software development company that had a development center here in Bilbao, which is in the Basque Country in the north of Spain.

Since then, I have been much, much closer to tech. I worked there for three years doing talent management, organizing events, [and] starting communities about a lot of different things. And then about two and a half years ago, I started working on my own as a freelancer and being involved in different projects related to audio visual production. [I’m] still doing talent management as a freelancer in a digital marketing agency and a random assortment of other things.

Last year, a good friend of mine, Demetrios Brinkmann—shout out Demetrios— who had previously started [and] is still running the ML Ops community was invited to start the Data on Kubernetes community last year in July. He got it he got it kicked off, [and] a few months later, because of some personal commitments, he contacted me saying, “Hey, would you be interested in taking over?” And I didn't have to think too hard about it— [I] just kind of jumped right in. And so here we are right now.

Ravi Lachhman  02:06
Perfect. What really amazes me about Bart's story is that Bart took two leaps of faith back-to-back. So there's no one road into technology— there's no one road in, and no one road out. People spend different levels of time [in it]. But Bart not only went from a non-technical background into helping organize technology communities. Bart is in what I would call a crypto community: Data on Kubernetes. I'll try to frame it up for some of the listeners— Kubernetes might be the shiny penny. It’s becoming more mainstream, but an area that's still on the bleeding edge is persistence or data. And that's actually very hard since the platform came out six years ago— data has been a weak point. The platform wasn't designed for persistence.

Now, there's been a lot of advancements, but Bart dove into it. You went from a light technical background straight to the deep end, which is very inspirational. Can we talk a little bit some of the ebbs and flows of that journey? There's lots of ways to contribute— and Bart is an excellent example of that.

Bart Farrell  03:21
That's a really good point. To backtrack a little bit, too and to give even further background about myself [to] see the contrast, but also understand why maybe it wasn't so strange for me to get involved in this space— taking into consideration the very point you just mentioned that it's quite niche, is my academic background. I went to the University of California at Santa Barbara, and I majored in religious studies, which is not a common thing to study at all. And so I'm very accustomed to being an outsider and perhaps being in different spaces, [as well as] the constancy of people say[ing], “Well, why are you going to study that?” or “How can you apply that?” Well, there are a million different ways you can apply that, and we'll probably see a couple more along the way.

Then, I got my master's degree in Near Middle Eastern Studies, because I lived in Egypt. I studied Arabic there, that's where I met my wife; my partner, she's from Spain, [and] we met there. Because of that kind of background and then going into a different kind of background, being in different space has been somewhat comfortable for me. And on top of [that], a lot of [what] I relate to is that when I arrived in Egypt in 2009, I really didn't know a lot of Arabic; and when I arrived in in Spain in 2011, I really didn't know a lot of Spanish. I spent the first two years living with my mother-in-law, and she doesn't know English, so and I didn't know Spanish. So this learning experience of really starting from zero is something [in which I was] fortunate I wasn’t doing for the first time.

When I started looking into this idea of Data on Kubernetes, I had some resources because of the company I'd worked for. They had started using Kubernetes in around 2018, and by chance, my desk was next to the IT Ops area. And so I was with everyone when they had done a migration to the cloud in three months with Azure— so working with that whole tech stack, and then also the Big Data stack of Hadoop, Spark, Storm, Elastic, Hive. [It was] all these different technologies, then start[ing] to mix these things in the Kubernetes space.

And so it wasn't the first time I heard about Kubernetes, and it was also very helpful because I already had people who I could reach out to that had been extremely supportive. I'd also been in the meetups. So once getting in the space [and] getting a better idea what this is all about, [it was] understanding that at the end of the day, as much as we talk about technological things, we're talking about basic problems, right? Like, I have a pain point, I have this data, [and] I need to move it or I don't want to move it, or what's the best way for me to be treating my data, to be testing the quality of my data. At the end of the day, we are talking about frustrations, about people trying to get to the bottom of things to make things better. In that sense, those are spaces where I feel very comfortable with. Obviously, there are technical limitations that I have. But I'm very, very lucky to be surrounded by some fantastic people that on my team (will have to give some shout outs later) that make that part easier for me, or that at least I know people I can delegate to [in order] to help me out.

Ravi Lachhman  06:30
Yeah, that's fantastic. It’s almost learning through osmosis— [and] you hit every one of the key distributed systems that is out there! So certainly you've learned a lot in the last several years of your journey— we'll talk about how people [can] get involved with DoK a little bit.

But let's talk a little bit more [about] the human problem. People might be a little shy, and especially I can be shy. [Chuckles] This could be therapy with Bart now: Bart, the therapist. I keep reiterating that you hit the reset and started again, twice, in a very rapid succession. As an engineer, a lot of times we get comfortable with what we know, and change is hard. That's the biggest part of change— culture or organizational change. As a person, let's say I had no idea what the next big technology is and then some other technology came up (it doesn't have to be Kubernetes related). What would be your advice for me to get over my fear of the unknown? You did it better than anybody I know.

Bart Farrell  07:46
That's awesome. I mean, change management is such a huge topic, and it's something that I have, unfortunately, not researched as much as I would have liked to. How do we define when folks are really ready to make a change? What are the necessary steps to say, “Okay, this is the old way, we're going to be making the transition to a new way.” And that's interesting, because that's exactly what we're talking about in our community a lot of time. We have people that are DBAs, that are DevOps, that are software developers. We have frontend, we have backend, we have systems administrators, we have all these different kinds of backgrounds. And so what we're really trying to do as a community is to define what does it mean to be a data engineer, or an SRE, who's going to be running safe workloads on Kubernetes?

And those things are difficult. So once again, a lot of what the community is about is “Look, you’ve got to have a can-do mentality, you have to understand it.” Because it's simple as this, right? If we think about in your case, can you think about other changes that you've had to make in your life apart from software, whether it's from moving to a different city, or [something else]? Can you think of an example?

Ravi Lachhman  08:53
Oh yeah, definitely. I like how this is making the problem more human. It's more than, “Oh, I don't understand this technology.” It's, “Yeah, absolutely. I think most of us have moved around a little bit. And most of us have changed jobs. Most of us go through the ebbs and flows of life.” So there's always change.

Bart Farrell  09:12
That's it. [It’s] understanding that those changes are going to make you a better person, a more flexible person with the ability to tackle a different set of problems. I think what a lot of it's about is to say like, Okay, well, if you've done this, you can do that. A lot of it is about building confidence.

And it's something that we encounter again and again. Actually, in our most recent meetup we talked a lot about the issue of imposter syndrome. People are so afraid— and I understand. Believe me, I suffer from it as well, which is why I'm always as clear as possible, as quick as possible about my technical limitations so there aren't any misunderstandings. I'm not going to tell people that “Oh, yeah. When I was spinning up this cluster, this is what I did”. [Rather], it’s “No, but I can refer you to someone who has done that they can probably help you out better.”

So I think a lot of what we are talking about here is that [a lot] about change management is not having to make such a big jump. It’s how can we break that down, [to ask] what's the first step to start getting there. So a lot of what we're trying to generate in our community, [is] resources [and] conversations so that people don't have to feel— we often say, like, you don't have to go outside of your comfort zone; you have to expand your comfort zone. And you do that in bite-sized portions— that it's not that you have to just jump right into something else. (It’s something that depends on the mentality, some people don't mind that). But [the aim] is to make it more comfortable for people, so that this doesn't seem so foreign or so difficult.

As we were saying previously, Kubernetes, has now been around for some time. It's becoming more accepted at an enterprise level, [and] we see more and more companies making that change. Some companies are still resisting that for a lot of different reasons. But we're even getting to the point where it's becoming normalized; we could say even mainstream, depending on who you talk to. Some people still say, “Whoa, whoa, whoa, that's definitely over my head.” But it’s like you've been working in tech for 15 years! Think about all the different changes in technologies, new versions and updates, you've had to work with. It’s just kind of looking at it another way. There's a cultural shift, there's a paradigm shift.

I think also the cloud-native shift about moving away from vendor lock-in— that is also a difficult thing for some people because they've always been used to having one provider for one technology or another. But like I said, I think about a lot of it in the same way as [I do with] Scrum— you take a big thing, and you reduce it down into user stories, more bite-sized pieces. I think it's the same thing with any other kind of change you might want to make in your life.

Ravi Lachhman  11:23
Very eloquent. It's the very agile or Scrum methodology, that incremental success breeds success. You can apply that to change management, too. If you're able to accomplish just a little bit at a time, you're building confidence; I think a lot of folks suffer from imposter syndrome. And that's it, right? It's the analogy, do you have to boil the ocean at once? Taking company politics out of it, a lot of times bringing change takes a long time. Like it doesn't happen overnight. The bigger the firm, the more stakeholders— it's a long play. It's not a two-week change. As a software engineer, we had another guest on, David Sudia, [and] he also said it pretty eloquently— that things take time, things take more than two weeks, dealing with people.

[Jokingly] Kind of more therapy with Bart, I like this. When do you stop becoming an imposter, if you have imposter syndrome? [It’s a] super abstract question. As a sufferer of imposter syndrome, when can I say I am not an imposter anymore?

Bart Farrell  12:31
It's really good that you mentioned because just yesterday, I was talking to somebody who I consider to be an extremely talented engineer who has these brilliant ideas. They kept repeating that “I feel like I'm not good at anything. I just feel like I'm an imposter.” I think that happens as well, too, that there are some people out there that are really, really loud, but then you start scratching the surface and there's not much underneath. That can kind of be a threat to some folks— that feeling that you have to have a big personality.

But I really think that too often we focus on the things that we don't think we're capable of, instead of the things that we are capable of. And a lot of times, we don't give ourselves that pat on the back, or track our progress. I mean, look at all the things that I have done— and I definitely would say that I'm probably too hard on myself sometimes. You’re your own worst enemy. Or, as the Offspring said, “I'm just a sucker with no self-esteem.” But I think that really, we need to be more proactive about documenting the things that we're doing well, [and] about giving recognition to others who do things well. Creating a culture of that kind of recognition [allows us to] really build ourselves up to see like, “Look, I don't have to be a superhero. But there are things that I definitely do well, and then I have confidence that I can speak about them.”

Once again, I would say this too: this Kubernetes space— CNCF, open source, all this kind of stuff— I have never in my life seen such an open and well welcoming community. And I want to give a shout out as well to Dan Pop from PopCast because in one of his episodes, he’s [like] “Go out there, join a SIG.” After this call, I'm going to have my first meeting with the contributor experiencing. And once again, it’s something I never would have thought about doing, but it's because you message these people, and they respond in such a kind way that all of the things about imposter syndrome dissipate quickly.

But I really think is a personal exercise that is very healthy. You don't need to build up an ego, but just write down a list of the things that you have achieved simultaneously. Also be conscious of the things that you would like to improve, or the things that you will delegate. I'm very, very clear about the things that I'm not good at— and so that's why I try to surround myself with a fantastic group of people who can help me out.

Ravi Lachhman  14:57
Perfect answer, and it's something that's hard to wash away. Funny, I actually, like you, joined my first SIG a year ago. For the listeners who don't know, a SIG is a special interest group. It's a way for people to start contributing to a specific task or specific goal. I used to have this notion that there's an air, like, oh, you have to be someone very important, or someone very special to join a working group or a SIG. That actually was not the case—I was joining a sub-foundation of the Linux Foundation, so a more specialized group of folks. And that was it, right? Like we all have different skills that we bring to the table and the collective, we're helping each other learn. I'm getting to interact with people that I know are competitors to my firm, which is pretty funny. That's putting the human face them.

Another question I have, because you have such a good background in talent management is, is I think a big part of a big challenge as an engineer— how do your accomplishments follow you around? I'm curious because you have the most talent management experience, a human-centric experience. Part of what we do as engineers, we have to pay the bills, right; we have to refine our skills, we have to go and be better at the craft. But also, there's a monetary incentive for us to do certain things; my Audi lease doesn't pay for itself downstairs. So how can your accomplishments follow you around? How can you get people to know the work that might be part of where the imposter syndrome falls in?

Bart Farrell  16:33
I think that's a super good point. I see people struggling with that a lot. It doesn't mean that everyone needs to give a talk in front of 50,000 people— like, that's okay. I think it's statistically proven that most people would prefer to swim with sharks than speak in public; I don't know what it is exactly. But the point is, use a little bit of creativity! Don't write down limitations, write down options. [For example], okay, maybe I don't want to give a talk, but I can write a good document; I can support somebody else to prepare their talk.

And that's also once again, I think the beauty of being in a SIG— there are tons of different ways that you can contribute. In my case, it's probably most likely going to be translating stuff from English to Spanish, etc. But like I said, I think that there might be a characterization of a stereotypical definition of “Oh, this is what success means is going out and doing this or doing that.” But in reality, I think there are so many different ways, and seeing people that are like, “Okay, I'm not going to give a talk for 50,000 people, but I'm going to go help this NGO with their webpage, and they're going to be eternally grateful. And that's a way that I can have an impact. That also enhances my personal brand, being able to show what I've done.”

Often what you tell people is to find some kind of personal project, get your GitHub repo updated, get something out there. And once again, it doesn't have to be jumping into [writing] a book for O'Reilly. Obviously, there are people that are at that level. But like I said, start small; get a blog, try something, and maybe the first thing that you do isn't going to necessarily work. I can talk about lots of things that I've done that haven't worked. But I think people need to understand that that's also part of the process. There's going to be some trial and error. There's going to be some give and take, but just be patient and kind to yourself. Don’t expect it to necessarily work on the first time; that's another thing too. Also, get people to give you feedback— I would say that's very important, too.

Ravi Lachhman  18:32
Oh, yeah. You know, I live in the generation of instant gratification. But it takes time, you're making an investment in yourself, and that feedback is super important. That's something that I had to get better at receiving— as an engineer, I used to get feedback, maybe once a month during code review. And as I became more senior, I start participating in more code reviews, and then we switched to Agile, so it was two or three weeks sprints. Now as a people leader, I get feedback throughout the day, which is something that’s taken me my whole career to accept. No one likes to hear criticism; you like to hear praise, right? We're human. But good point: part of making yourself better is [the] ability to accept feedback. As an engineer, a lot of times you hang your hat on your solution— like, “I wrote this, we wrote this.” But the only constant in technology is change; change is about to happen.

[Taking] the conversation in a little bit [of a different angle]: for the listeners, Data on Kubernetes. So as a crypto space— in a very rapidly evolving crypto space— we get to kind of take a peek behind the scenes and see what's going on. Maybe talk us through a little bit of the journey on the inception of Data Kubernetes, the community, and then what's current going on. How do you start building momentum in such a crypto space?

Bart Farrell  20:05
Very good. So essentially, the community was started by—big shout out to MayaData, Evan, Murat, Brian, Eric, a ton of people at MayaData— great people that I have been lucky enough to be in contact with. Kiran as well. And they basically realized that there is the potential of “why are we leaving this topic of data outside the Kubernetes space? Why are we not bringing this more into the fold?” And they also realized that they weren't the only ones that were thinking about it. What's also interesting, too, is that the more people that I got in touch with, I [was like] I’ve been thinking about this for a while as well— and I'm glad that there is a space where people can have these conversations.

So initially, they realized that there was a potential to get this going. And so with the help of some of the folks also at Data Stacks and Percona, they said, “Look, I think we can start getting people that can share experiences, because a lot of it is like,’ Don't tell me if I could do this, show me how you could how you have done it— what works, what didn't work.’” We also have to keep in mind as well to the question of use cases. And some use cases, and from what a lot of folks tell me, there are certain use cases where it's going to be better or might be more advisable to keep things stateless. In other cases, go ahead and you know, do it stateful. So that's kind of how this got going.

But basically, [it] was like, are there enough practitioners out there to start having meetups where people can share these experiences of things that have worked, or things that haven't worked in a vendor-neutral, non-sales pitch? And focusing on open-source technology is also a very important part of our community. That was kind of it. Through that, [it was] realizing, wow, we actually have people. Not only do we have people, we have people in— I couldn't even tell you how many different countries we've been in touch with; we've had speakers, I think, for well over 15 different countries.

So it’s not just something that's happening in Silicon Valley or only based in the United States. We're now expanding into other countries. We're doing meetups in Brazil, and Portuguese for folks who prefer to have that. We’re doing stuff in Spanish, hopefully going to start doing stuff in Mandarin. Seeing that this is something that is happening on a global level gives us much more confidence that we're not crazy lost prophets in the desert, that there is actual substance to this and that we can present things that are concrete. The technology is always wonderful, but always when we can apply it and see it on the ground functioning in a use case. It's not just being a cheerleader like “this could possibly work.” No, no, tell me how you did it. Tell me how you ran data streaming. Tell me about how you created this operator; tell me about how Container Attached Storage works. These are the kind of things that, like I said, once you say “No, no, I'm not crazy. I can give you an example. And my client, my customers are happy with this.” That I think is what really gives a lot more credibility. But really there obviously was a risk and this leap of faith of getting this started last year, but I think since then, the feedback has been very, very positive.

Ravi Lachhman  23:04
Yeah, that's fantastic. Like, “show me don't tell me.”

[We’re] coming to the back third of the podcast. [This topic] is something that I struggle with. It's doing something in the crypto space— a lot of times you're figuring stuff out for the first time, so you might not have a complete solution, right? Even going back to our incremental gains, or tiny gains— this is going to fall into imposter syndrome, and you've laid out a very good framework. This is fictitious. Now, let's say I don't have the complete picture. Like, I want to participate in Data on Kubernetes. But I don't have an end-to-end solution. Is it acceptable to show partial work? Like, “hey, I saw a very minute part of the puzzle.”

Bart Farrell  23:55
Oh, that's brilliant. And absolutely, what I would like to say as well— because when I got started, I was like, do we only want cheerleaders for the cause? But the thing is that anything, as long as it relates to— and once again, if Kubernetes is already big enough, data is even bigger. So we have tons of things that we can talk about there, right? But like you said, is that it doesn't have to be because that's an incomplete story. That's where community comes in and helps that person finish that story. That’s what that's about.

And the other thing as well, too, is we want to hear from folks that say, “No, we have the option of stateful or stateless and we went for stateless.” We want to understand the logic behind that to understand how we can make our arguments clear or make our case stronger. But once again, it’s that we need to hear from absolutely everybody. If it’s just an echo chamber of always the same thing, then we're going to end up being blind— and that's not healthy. So it's very, very good for us— and we don't need people pulling out weapons to be fighting to the death over this kind of stuff— and we want to encourage a comfortable inclusive space where people can have these conversations and where it doesn't end up In a brutal fight.

That’s definitely the message. I really want people to take that to heart because we don't mind having someone coming on saying, “You know, we got to this point and we realized no, we're going stateless.” And then we'll obviously we want to hear alternative voices say, “Well, I maybe would have done it this way, based on my experience on my use case.” All opinions are welcomed in the community.

Ravi Lachhman  25:26
That's awesome. I think this is abstracting away from Data on Kubernetes— I tried to be a little more concrete there— which is good. I think almost all engineers suffer from that problem. I've never heard it said so eloquently: let the community help you finish the story. Because again, if you take a look at [an engineer’s salary]… my salary depends on me doing something. A lot of times you feel like you're in a little silo— and this one took me like my whole career until I made a more senior engineering role. I used to think that I have to complete it, because this is why I get paid. And if I asked for help, I'm not going to get paid.

Kind of related to my journey, there's nothing wrong with asking for help or even getting more opinions. I think that's extremely valuable— and it's a skill that a lot of engineers might be a little bit of [ashamed of], or struggle with. I think it made me a better person, participating in these communities, because you got a lot of different ideas all at once. Usually in a company, you're all marching to the same beat. Even if you and I are working on the same team, you're not working [for] the same employer, most likely versus getting a lot [of voices]— it's like going from like elementary school to middle school to high school, and then the university— the number of people who were from different spots come together [grows].

So the last question, I always like to ask— and I think you'll have a great answer to it— is an intrinsic question. Let's say you're walking down the street, and you just met young Bart out of UC Santa Barbara, with current Bart. So you're living in Bilbao, for a while, [and] you caught UC Santa Barbara Bart at graduation— what would you tell your past self? It can be any piece of advice.

Bart Farrell  27:25
That's really good; this is the first time that I've thought about this. I think really what I would say is “Don't worry, you're going to be fine.” And honestly, that's been the thing— I graduated college, and the first thing I did was I worked in a restaurant in New York, and I was also playing music in the subway to make money because I didn’t make a lot of money working in a restaurant, I was suffering from this [sense of] “what am I going to do with my degree, or how this is going to work?” Everybody just needs to know: you're going to be fine.

For me [now], it's so easy— you know, we have this Data on Kubernetes community. Create a community for yourself, surround yourself with folks that appreciate you for who you are— who trust your decisions, [and] who believe in you. I'm very lucky that in my case, that's been my family. I could have probably told 22-year-old Bart [that] it's a good idea to learn some programming. That wouldn’t have been some bad advice! Don't worry about it; but if you get a chance to learn a little bit of programming, that would have been smart. But mostly, I would just say [to] trust your instincts. Understand that you're not going to get everything right the first time, that it's been a little bit of trial and error, that you may not have the most linear approach of getting things— but you still get there. That's kind of how I would summarize [it].

Ravi Lachhman  28:39
That's awesome. It's very human-centric advice. Lastly, for folks who want to get involved with Data on Kubernetes, or DoK, what's the best way for them to get engaged and get involved?

Bart Farrell  28:49
Good. Alright, so we've got tons of different ways. We’ve got the meetups that are on every Tuesday. I’ve got say this, that in in March— when we're also going to have Tiffany, which is exciting— I want to do March Madness. So in March, I'm going to do two meetups every week. We're going to try not to overlap topics, obviously, so we'll have different offers on Tuesdays and Thursdays. Same thing in April as well— going to go really hard the next few months. And so if folks want to get involved, we've got our webpage— DoK.community. We're also on Twitter; we've got our Slack. [It’s] pretty easy to get in touch with me.

We also really try to identify a unique sort of character in terms of our community. We have a wonderful graphic recorder who does art, so people that are more visual thinkers can see a visual summary of what the speakers have been talking about. I'm also pretty shameless, and I also make hip hop beats—I do raps summarizing the things we've been talking about. So we try to create many different resources to make it more comfortable for people coming from different backgrounds. And we're only going to try to do that more.

Like I said, if you're a DBA, if you come from a different background—we want to be able to give you all the support that you need to make that transition more comfortable. We're always interested in speakers. If folks don't want to appear in a meetup, we can do a podcast; we can do a debate. It doesn't matter how young you are, how old you are— what language you speak, as well, for folks that don't want to do it in English. They can do it in any language they want; we're happy to facilitate that. So I insist, [and] I hope the message is understood, that we want to be as welcoming as possible in the same way that I've been welcomed into this whole Kubernetes, open source, CNCF space.

Ravi Lachhman  30:29
Awesome. Well, Bart, thank you so much for your time this afternoon. Until next time, listeners, this is Ravi with ShipTalk. Cheers.

Bart Farrell  30:38
Thank you.