We’re joined for this episode by the wonderful Kelly M. She’s the founder and Executive Director of Sweet Trades, a non-profit focused on helping individuals land living wage jobs, a Senior Software Engineer at a fortune 100 company, and a Data Scientist at a U.S. National Lab. So you can see why we were excited to book her in for a chat.
Kelly switched into DevRel from technical writing, but before all of that she got a degree in left-handed puppetry. Well, not really. She jokes that it would have been just as useful as her actual degree, which was in HR. Kelly is a huge advocate for following your own path, and believes that a colourful background can only come to serve you well in DevRel.
She speaks about how DevRel, while holistic in a sense, also needs to be practical. There comes a time when DevRel’s need to put on their business hats, especially in the current climate. Metrics aren’t everyone’s favourite thing, but Kelly believes that knowing the value you add to a company will not only increase your confidence, but genuinely help you with job security.
She also tells us about her current project, her non-profit, Sweet Trades. Kelly became attracted to tech initially for the reason a lot of people do: adequate compensation. But she went on to learn that tech doesn’t have to be the bastion of a financially secure career. Many roles in various trades can be higher earning positions than a lot of tech roles, and Kelly is on a mission to bring light to these roles and make their presence known. Not just to graduates, but to young adults in urban areas that often have even less access to information about these jobs.
Find out more and listen to previous podcasts here: https://www.voxgig.com/podcast
Subscribe to our newsletter for weekly updates and information about upcoming meetups:
Join the Dublin DevRel Meetup group here: www.devrelmeetup.com
Interview Intro
Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.
Today I’m speaking to Kelly Mor, who switched careers into dev rel via the path of technical writing. Kelly has a whole bunch of insights in how to understand what your developers are doing. And the essential advice that your documentation should allow immediate feedback, right there, in the docs themselves. And if you’re not doing that, you are missing out on essential understanding of your user base.
If you’re like most developer advocates – and I include myself in that – you might be a little unstructured in your approach. Kelly is a great example of deeply structured thinking, which we could all benefit from. Okay, let’s talk to Kelly. [0:00:59]
Main Interview
Kelly M
Richard Rodger: [0:01:01] Kelly, welcome. It’s great to have you on the Fireside with Voxgig Podcast talking about developer relations. How are you today? [0:01:08]
Kelly M: [0:01:09] Hi, Richard, thanks for having me. I am wonderful. How are you? [0:01:12]
Richard Rodger: [0:01:12] Awesome, so – very good, yes. You’re in a slightly warmer part of the world than I am, so I’m a little bit jealous. You have been a technical writer, a technical evangelist, developer advocate – covered all the bases in developer relations. And for a lot of people who look at those roles, sometimes they wonder how do you get started?
How do you get into those roles? Do you have to be able – do you have to have a wonderful public speaking ability from day one? It would be interesting maybe to talk about your career history, how you ended up in this role. Did you choose it deliberately? Did it choose you? Start wherever you like – start at age three or start after college or start at the first dev rel job. [0:02:06]
Kelly M: [0:02:11] I landed in dev rel; it was happenstance. It wasn’t intentional; I didn’t even know what developer relations was. What happened was, when I was in software engineering bootcamp, I just started to write technical articles on what I was learning, and I was publishing them on Medium.
And eventually, the technical publications on Medium would ask me if they could feature whatever it is that I wrote on their publication. And then it became a side gig, where I would write for the publication; get a little bit of money out of it – all while I was still studying at the bootcamp.
And when it came time for me to graduate and find a fulltime role, I was intentionally trying to leverage all of my previous experiences and newly learned skills, with what’s going to happen next. And for me, that was 1), teaching, because I used to be a teacher, 2), banking, because I used to be a banker, and then 3) software engineering.
So, what does that all equal to? I guess that equals developer advocate at a fintech company. Because I already speak the language; I already know the laws and regulations. I’m already a part of the culture in that sense, and then now I’m also a software engineer who knows how to write. So, that’s how I learned – and that’s how I landed my first developer advocate role. [0:04:01]
Richard Rodger: You can do Excel; you can balance – literally do a balance sheet and get it to actually balance. Plus, you can code. [0:04:11]
Kelly M: [0:04:11] Yeah, but that’s not exactly what I was doing at the bank. There’s a lot of different laws and regulations, and there are so many that goes into banking, especially if you’re a branch manager. It’s your obligation to make sure that none of your tellers miss out on any kind of forms that’s going to get you in trouble with the Feds. [0:04:32]
Richard Rodger: [0:04:35] Attention to detail is good software, right? [0:04:37]
Kelly M: [0:04:37] Yes. So, keeping those things in mind. And all of the rules and jargon and terminology, they all transfer back to the fintech industry. Just because they’re not a brick-and-mortar type of bank, they still have to abide by the same laws and regulations as Goldman Sachs or Bank of America. [0:05:00]
Richard Rodger: [0:05:02] Do you think it’s necessary to have additional experience outside of software development, to bring something more to the developer relations role? A lot of people who start off as writers and end up doing technical writing and then become developer advocates. But you have a bunch of domain experience in the finance industry. Does that help only specifically with fintech roles or does it help in general? [0:05:34]
Kelly M: [0:05:37] With me, I narrowed it down that way, so I can reduce the competition for myself. What do I have that I know not many people have? I have those three things; I have teacher; I have banker; I have software engineer. So, what can I apply that to? In terms of, is it necessary to have a different set of backgrounds before breaking into dev rel? I don’t think so, but I think it can only help you.
For – as an example – this is not a dev rel example; it’s just a general tech example. I mentored a peer of mine when I went to [Correlation One?] Time: 0:06:25 – which was, by the way, the best education I’ve ever received in my life – was at a data science type of bootcamp taught by Professor Natesh, who’s a Harvard professor and statistician.
But anyway, my – this peer, she was from Brazil like me, and she had a lot of background in the automotive industry. And she asked me: “I have all this experience in automotive and now I’m learning data science; what can I do with this? Is it even valuable? Should I even keep this on my resumé?” I’m like, “Yeah, you should. You can apply to four. You can apply to all these companies.” And now she’s a data analyst at Tesla. [0:07:11]
Richard Rodger: [0:07:12] Of course. That’s exactly where you need to be, right? [0:07:14]
Kelly M: [0:07:15] Exactly.
Richard Rodger: [0:07:16] And they must need hundreds of them – wow, okay. It’s pure software devs. I did – I studied mathematics, but endued up working – building websites straight away. And that’s all I’ve ever done. So, it’s – and people like me who’ve done that tend to end up building dev tools startups and that type of stuff, because we can’t go out – we don’t know how to go outside that domain. It’s interesting that you mentioned fintech, because I came across a great example of developer relations in fintech recently. Are you familiar with a startup called moderntreasury.com? [0:07:56]
Kelly M: [0:07:57] Yes, I am. I think they’re actually a YC company; I could be wrong. I tend to follow those companies a lot, because they are the changemakers in society. But I’m familiar with them. I think I got headhunted by them a couple years ago when I was still in fintech, but it’s a great company. [0:08:16]
Richrd Rodger: [0:08:17] They seem – they have this really great content production engine. About a year ago, I was working for a client and I needed to build a ledger. It was a consumer fintech application and we needed to build a little ledger, so double entry bookkeeping, the whole thing. It was for reward points. And I’d studied high school accounting – never managed to get a balance sheet to actually balance in an exam. I got close, but accruals – I could never handle accruals.
But Modern Treasury published a series of articles on how to implement a banking application, which was an absolutely wonderful resource. Now I don’t particularly need their full-blown APIs, but if a client in future comes to me with that type of application, they are the people that I’m going to go to, because they have delivered this amazing developer-focused content. And it gives me such good vibes that those are the guys I’m going to do business with, because they clearly care about developers. We’re not talking 1,000-word article; we’re talking – that must have been- [0:09:44]
Kelly M: [0:09:44] Simple, straight to the point. The Grandma test, as Maria said yesterday. [0:09:49]
Richard Rodger: [0:09:50] Absolutely. That’s – for me, that’s the power of developer relations, is that you can form a relationship, even if you aren’t speaking to someone. Have you experienced anything like that yourself? Have you seen that in action? [0:10:08]
Kelly M: [0:10:10] Have I seen straightforward tutorials like that? [0:10:12]
Richard Rodger: [0:10:13] Yeah, and then the effect of them, that somebody is saying to you: “I read it six months ago and it really helped me at the time.” And maybe you think of you guys now, right? [0:10:22]
Kelly M: [0:10:24] I actually haven’t. I actually haven’t. When you’re in the nitty-gritty of it all, you’re only focused on your own particular product that you’re trying to convey to the customer. And if it works, then they launch quickly. If it doesn’t, then you need to improve your docs; create a tutorial – things like that.
What I tend to do is – this was something that I took from Cassidy Williams, who was director of dev rel at Nullify a couple of years back. She did something with her team called Using All the Parts of the Buffalo. First, what she would do is build a sample app on GitHub; open source it, then create a concept article. And that’s where the grandma test comes in, where you’re explaining what the technology is at a high level, conceptually.
And then create a technical article like a tutorial, how-to, with the code. Then go on a podcast and talk about it, and then have that podcast syndicated on YouTube. And then maybe even do a livestream on what you build and have also syndicated. So, having that straightforward approach and explaining it in different ways, over and over again. [0:11:47]
Richard Rodger: [0:11:48] Yeah, and two different media, because people learn in different ways. You said you’d been a teacher before. [0:11:54]
Kelly M: [0:11:56] Yeah, that was a while ago.
Richard Rodger: [0:11:58] A while ago. And that’s a critical skill for being a developer advocate as well. [0:12:04]
Kelly M: [0:12:05] Yeah, this is really great. Let’s touch on that. There are a couple of different approaches to teaching. There is teacher to student, which is the most common and the most boring. There is student to teacher, where you’re explaining to the teacher what you’ve researched, how it applies to society, what you can do with it in order to get your grade.
And then there’s the student to student, where you’re working in a group project or maybe you’re explaining something that you are researching or trying to build to another student who can take that and implement it in their own project. Those are really good approaches to look at and copy, from the education industry into developer relations. [0:13:02]
Richard Rodger: [0:13:03] Yeah. And they give a framework or mental models for thinking about how content can be used, or how you would – so you’re trying to think about how the flow of information, I guess – and is student to student effective? It’s – you assume the teacher has to know. [0:13:26]
Kelly M: [0:13:26] A student to student?
Richard Rodger: [0:13:27] Yeah, you assume the teacher has to know stuff. Or do they co-discover things? [0:13:32]
Kelly M: [0:13:34] I see what you’re saying. Let’s apply this to – let’s apply these two approaches to developer relations. Teacher to student – the developer advocate to external developer, developer client. That’s going to be your tutorials, your concept articles, your open-source project. The student to student – this could be me as a student – as a developer advocate learning about a partner client technology. And I’m going to pick on some names here. [0:14:15]
Richard Rodger: [0:14:16] Go for it.
Kelly M: [0:14:17] I don’t work for any of these companies; I’m just giving examples. Let’s say I’m a developer advocate at PayPal and for whatever reason, I want to do an example of how to use my API using Next.js. So then, I would maybe peer program with a developer advocate from Versel, who I think runs Next.js. And I’m learning their technology; they’re learning my technology. We’re building something great together and we’re sharing that with our audiences and we’re gaining more audiences.
The student to teacher would be the support engineering calls that we would jump on as developer advocates. The client developer would maybe say something like, “I’m really stuck on this. I don’t know what to do.” “Well, what have you done so far?” And then we would talk it through.
More than often, the – just having that peer programing session with them. Even if you don’t know the underlying technology that they’re trying to implement with your API, it’ll get them to the right track. And if it is something that is wrong with our own product or our own API, we’ll go ahead and fix it. But sometimes it’s not; sometimes it’s them trying to implement our technology into a language or a library that we don’t have demos out yet for. [0:14:17]
Kelly M: [0:16:05] Because it always – you always wonder how, if you produced some open source or if you’ve produced an API, where to have the most impact. Because people expect there to be reference documentation, but then you often find that’s all there is. I’ve implemented again so many APIs where it’s like, “Yeah, it’s fully documented.” No, that’s just – it’s just reference documentation. Where do you even start?
And that ends up being a bigger cost for the company, because you inevitably have support calls then because stuff doesn’t work, but there’s no examples. My go-to north star metric is, you gotta have sample codes, sample app. Because at least with a sample app, I can cut and paste it, and at least I can get started. And that’s also a factor- [0:17:08]
Kelly M: [0:17:10] And then also, even if it’s for a language that they’re not using, the fact that maybe we have the sample code out there in JavaScript or even in a lock format, they can copy and paste that now to GPT and get it to translate to whatever language it is that they’re working on. [0:17:32]
Richard Rodger: [0:17:32] Yes, which is super useful. And you’ve worked in a number of different firms, doing the technical evangelist or the developer advocate role. Can I ask you – could you compare practices? Because a lot of the people that we speak to on this podcast – you find a lot of companies take very different approaches, different approaches with regard to metrics, different approaches with regard to how they organize developer advocates within the company.
You have startups where the founders of the developer advocates – you have companies – seen a lot this year that are – that don’t even understand the value of what developer advocates are doing and are laying them off, which is a bad idea. But comparing all the different places that you’ve worked, what are some of the highlights in terms of practices? And what are some of the really good things that could be applied going forward? [0:18:36]
Kelly M: [0:18:47] My favorite way to do dev rel is being as close as I can to the product engineers of the developer tool that I am trying to gain a community for, or trying to sell. And with that, it’s really important to – if you’re starting a dev rel program from scratch – to have that dev rel team as close to those developers as possible.
That way, that dev rel can learn the technology in a way that they’ll be able to explain property to the audience and build demos for. And not have any type of blockers to their time and focus on explaining the product in a way that the user’s going to be able to use and launch as quickly as possible, and for them to gain the most value.
That’s my favorite way to start. That’s not necessarily where dev rel should be forever. As the company grows, there’s different functions of the dev rel team that should be built out. And if the company’s lucky enough to have hired a dev rel from the start, maybe when they’re ready to exit or even maybe a little bit earlier, then they can start building out an evangelist team who’s responsible for going out to conferences, talking about the product; doing podcasts like these – all the fun stuff. [0:20:58]
Richard Rodger: [0:20:58] They call it the fun stuff. More like hard work, but anyway. It only looks fun from the outside, folks. [0:21:08]
Kelly M: [0:21:10] Yeah. But with that, they do incur more costs, so this is where you’re going to find those evangelists more in marketing, because love or hate it, it is an expensive department. Which if you look closely – and maybe this is just my surrounding network – the layoffs that I’m seeing right now is coming from dev rels that are housed in the marketing department. [0:21:42]
Richard Rodger: [0:21:46] That’s interesting.
Kelly M: [0:21:48] But I don’t think that this is – how can I say this? I don’t think that that is the only underlying cause. It’s also important to follow or set metrics for yourself as a dev rel team, if you are fortunate enough to be in one and not just in someone else’s department. To set metrics that align with the underlying company mission. And whatever that mission is, the underlying mission under that is to increase revenue.
And I’ll just go over some of the metrics that we went over again yesterday, so I did that, the community stream with you all. But for startups, those metrics can be something like time to first launch. How long was it taking our customers to launch before and after our efforts? And those efforts can be things like gathering data from the developer documentation; do a few feedback loops.
Versel again does a really good job of this; if you scroll down to one of their docs, you’ll see they have three or four happy and sad faces. And they have a little input box where the developer can give them feedback on whether or not what they read was helpful for their – whatever that they’re building.
And then the dev rel would then in turn take that feedback. And usually, when someone’s giving you feedback on docs, it’s because something went wrong. And then create that ticket and then sell whatever it is that was wrong with that documentation. And then after that, hopefully it’ll help the customer.
And we can also gather data in different ways, so if you’re doing a support meeting on Zoom, Zoom has the capability for you to gather – or for you to prompt the developer with a survey after your meeting. Was our meeting helpful? What did you like about it; what didn’t you like about it? And then we would take that data and improve on our calls.
And the community forum is also something else to take a look at. How many questions are we answering over and over again? Are we – is it because we’re not answering it thoroughly? Maybe we need to answer a little bit better, or maybe we need to create a demo app for an open source, so the users have an example to look at. Things like that. So, doing everything we can to reduce time to first launch. And that’s important, because as soon as they launch – the sooner they launch, the sooner we get money.
And there are other metrics, like obtaining new users and that student to student approach where I’m a developer advocate at PayPal and I want to do something with Next.js. Maybe we can ask your audiences by doing up a pair programming sample app together and that’ll work out our main users. And then seeing how many of those users are returning to – and becoming monthly active users. And that right there is a metric that VCs love to- [0:25:41]
Richard Rodger: [0:25:41] Yeah, that’s the big one, right? MAUs. [0:25:44]
Kelly M: [0:25:44] How many monthly active users do you have this quarter, or how many monthly active users do you have this month? And then conversion rates. With all of our efforts combined, and maybe we’re doing a Hackathon, if we’re at an enterprise company. Maybe we’re doing certain events. Out of all of those new users that we gathered, how many are now paid users? What is that conversion rate? [0:26:18]
Richard Rodger: [0:26:20] What strikes me – it makes me feel a little bit like - a bit like an amateur – is the structured nature of the approach that you just outlined. It pays attention to the details and aligns what you’re doing with the purpose of what you’re doing. There’s a lot of the earlier generation of developer advocates – I include myself in this – who were coders before or startup founders.
And it’s – let’s speak at random conferences; let’s go to random meetups. Let’s hang out or – in random Slack rooms. And we’re doing developer relations and I met people and they bought stuff. And I don’t know, but yeah, I’m just going to Maus keep doing it. And it does work, because I didn’t starve, but I was never able to tell you whether a specific conference was where I should have been putting in effort. At one point I remember turning up to a meetup in Copenhagen of all places, and there were five attendees. I flew all the way from Dublin, Ireland, to Copenhagen in Denmark – it’s a lovely city – to speak to five people.
For me, what you’re advocating is part of the professionalization of developer advocacy. And hopefully, one of the benefits of that is that senior leadership stops asking, “What’s the value that you guys are bringing?” Because the accounts department is professionalized; their value is clear. Marketing- [0:28:26]
Kelly M: [0:28:26] It’s very important – sorry, go ahead. [0:28:28]
Richard Rodger: [0:28:29] Marketing, sales, whatever.
Kelly M: [0:28:35] It’s really important for all dev relers to be able to put a business hat on. And not only try to enjoy the role as much as they can, but try to look at it from the perspective of, what you really are is the field CTO. And the field CTO needs to make money for the company; how are we going to do that? [0:29:05]
Richard Rodger: [0:29:08] Yeah. It’s a little bit of growing up, little bit of professional maturity. It’s – this is how you make your startup successful, as opposed to, it just randomly happened. [0:29:22]
Kelly M: [0:29:22] And keep your job.
Richard Rodger: [0:29:25] And keep your job, in these times, absolutely. I felt this year that there was quite a lot of discussion around, if we can just find the right metric and optimize around that, then value is clear. But it’s not just about a number; is it? It’s like you said; it’s about aligning the activity with the purpose of what you’re doing, and ultimately, is it profit generating. Which a lot of coders don’t like to think about; we don’t like to think about profits. It's – let’s solve problems with code as opposed to business strategy. [0:30:03]
Kelly M: [0:30:03] Relationships.
Richard Rodger: [0:30:04] Yeah, and relationships.
Kelly M: [0:30:04] Yeah, it’s business strategy and relationships, yeah. [0:30:06]
Richard Rodger: [0:30:07] I know. And this is something – and I don’t know if they spoke about this much in the bootcamp, or if you’ve seen this discussed much in organizations that you worked in. But one of the things I like to say to our junior engineers – and I see them – I see the junior engineers doing this. I’m not saying it’s a mistake; it’s just a natural behavior, where they have a problem and they try to code their way out of it. They spend all weekend coding or pull all-nighters and whatever. And a lot of the time those problems can be solved by speaking to people. [0:30:44]
Kelly M: [0:30:46] Or walking away from your computer and taking a walk with your dog. [0:30:50]
Richard Rodger: [0:30:51] Yeah. It’s – because your subconscious brain can solve problems. But a lot of the problems are not coding problems; they’re people problems, or not even people problems. They’re just – you just need to find some mutual understanding. And for most clients, they’d rather have specific things done, not perfection.
Speaking of mentoring and looking after junior engineers, you also have a really interesting enterprise, social enterprise, that you work on, called Sweet Trades. Which is something I also wanted to talk about because it looks really interesting. Maybe you could talk about that for a little bit. [0:31:31]
Kelly M: [0:31:32] Yes, thank you so much for bringing this up. I started Sweet Trades earlier this year. At first it was something else that I could do outside of work, because right now I work full time at an enterprise company. And I don’t know if you – I think you mentioned you had this experience where you were working at a startup and then for whatever reason, you landed in enterprise. And the culture is very different.
So, when that happens, you’re only utilizing maybe 5% of your skills if you’re lucky. So, I needed to find a way to utilize all my other skills. Outside of becoming a data scientist for the US lab, I wanted to do something of my own as well, So, now I’m juggling those three things: the Fortune 100 company as a software engineer, the data science role at the national lab. [0:32:38]
Richard Rodger: [0:32:38] So, what are we talking, four hours’ sleep a night maybe?
Kelly M: [0:32:41] -and Sweet Trades. I think I’m balancing them all pretty well though. I started Sweet Trade because – I’ll back up, so I can make a little bit more sense and for context. I’m an immigrant to the US; I was originally born in Brazil, as were my parents. And when we moved here, we – I for one, I followed the narrative. Go to university; get a degree; have a good job. That didn’t happen to me.
Did have a good job in banking while I was in university but then I quit to finish up my degree as quickly as I could, and when I got my degree, I couldn’t find a living wage job. I couldn’t even find a job that paid me as much as I was getting before. So, I have all these student loans and I have nothing to show for it except for a piece of paper. I joke with people that I got my degree in left-handed puppetry, because that’s how useless it is. But it’s actually in business; it’s an HR degree. But I couldn’t do anything with it.
I saw my brother, who went to uni for computer science, and at his graduation he had recruiters from Siemens come up to him and ask, “Are you looking for a job?” Outside a graduation. He ended up working at Lockheed, but anyway. And six months from working, he got his house; he’s set for life.
And I thought, that’s what I’ll do. I was already coding anyways, because I was working for – around startups, I should say, so, I saw the benefit of the skills. I was doing things like free code camp, but I wanted to do something a little bit more polished with the network that I could take advantage of.
And at that time, I was going to – I was doing YC Startup School, back when they had just opened it to the public, open sourced it. It was – I think it was a mistake, because I remember getting an email saying that, “Welcome, you’re in.” And then I got another remail about after – “Sorry, that was a mistake. No, you’re not in.” And then the third email was like, “You know what? We decided to open source it to everyone who applied.” [0:35:35]
Richard Rodger: [0:35:39] That’s like startups, up and down.
Kelly M: [0:35:40] A rollercoaster. But it was still valuable, the Startup School was. I learned more about business going to YC Startup School than I did getting a business degree, four years – for four years, and Startup School was only a couple of months. But anyway, at one of the talks, Paul Graham was there and he said, “If you’re here and you’re not a technical founder, your job for the first year of your company is to get coffee for your technical founder.”
I’m like, “Okay, I’m not getting coffee for anyone.” So, I ended up enrolling in Lambda School, which is now BloomTech. It’s a – it was a YC backed company, so it was already – and then worked that – I was around. And I wanted to do data science before, but they didn’t have the data science on the data science. They didn’t have – nobody had graduated yet. I saw that their rate at the time for software engineers landing fulltime roles was 97% after graduation, so I’m like, “Okay, I’ll do software engineering.” And then boom, couple years later, six great years- [0:37:02]
Richard Rodger: [0:37:03] Yeah. That’s the grooves.
Kelly M: [0:37:03] I want that story for everyone. And I worked at Career Karma for a little bit. To this day, Career Karma is the best company I’ve ever worked for – great founders, amazing mission, amazing culture. And while I was there, I enjoyed it, but I always thought, there’s a lot of other ways for people to get living wage jobs that isn’t necessarily in tech. And those are other trades like electrician, plumber, mechanic.
And as I was digging more into that earlier this year, I thought, let me just start this nonprofit, where I’m evangelizing this way. And I started with the technology arm of it, because I’m a technologist, but I’m looking forward to diving into [inaudible] Time: 0:38:15 those trades. I am currently looking for two more board members.
So if you know anyone who has nonprofit board member experience, please send them my way. I’m actively looking, so I can incorporate – [inaudible] Time: 0:38:27 in Florida. The first – my first cohort of software engineers, I partnered with my friend Mario, who’s – he works at General Assembly and is now a board member at Sweet Trades. And I asked him, “I need – I want someone to develop the Sweet Trades website, but I don’t have any time for this. I work two jobs.” [0:38:54]
Richard Rodger: [0:38:55] Already. This is my third job. [0:38:57]
Kelly M: [0:38:58] Yeah. So, can you send me some software engineers that maybe they graduated and they’re having a hard time finding a job. Because Career Karma builds a really amazing workshop. I think it was called The Secret to Getting A Job In Tech Is To Already Be Working In Tech.
And then I go into all these details on how you can do that. And I implemented the – this program for them; it was a three-month program where they got a real-life experience in what it was like to work at a company. We did firm planning together; we put a peer program together. I let them review FPRs. Looking back, it was a lot more work. [0:39:48]
Richard Rodger: [0:39:49] Yeah. That sounds like hard work.
Kelly M: [0:39:50] -than I expected.
Richard Rodger: [0:39:51] That sounds like an actual software project, like a consulting gig without getting paid. [0:39:55]
Kelly M: [0:39:56] Yeah. It would have been as fast if I just did the website myself, to be honest, but it was so rewarding. All of the engineers that worked with me landed their first software development role, fulltime, paid, because of the program. And this is something that I want to roll out again next year. But I’m very excited to dive into the other trades. For example, an elevator mechanic, starting wage is 160,000 a year. And that’s more than what some software engineers make. [0:40:40]
Richard Rodger: [0:40:41] Everybody needs elevators, right?
Kelly M: [0:40:43] Yeah. So, very excited to start evangelizing those types of programs, getting them more exposure into urban high schools that are particularly in urban communities – I have a talk coming up with one of the local high schools here – and exposing these types of jobs to high school students, so they’d know the option. [0:41:13]
Richard Rodger: [0:41:13] People don’t even know the exist, right? That’s the thing. [0:41:15]
Kelly M: [0:41:16] They don’t; they don’t.
Richard Rodger: [0:41:22] And there are people who – the type of work that they do, perhaps they’re better sorted to physical – fixing physical things, and they’re genius at it. They’re equivalent to Larry Page writing search engines, but they fix elevators. But that’s amazing, because even creating the idea of the possibility, that’s the most important thing. So many people don’t even know that these things are possible. [0:41:59]
Kelly M: [0:42:01] I sure didn’t.
Richard Rodger: [0:42:01] That is really inspiring.
Kelly M: [0:42:02] I didn’t know those things were possible. And the university degree was still forced down my throat, but I thought this was the only way to get a living wage job. And I see people still believing this, even after they get their left-handed puppetry degree. They’re like, “I need to go back to get another degree. I need to go back to get another degree.”
And I know someone is going to point out, “Hey, Kelly, you’re in the process of [inaudible] Time: 0:42:28 right now.” But I just want to say I’m doing that because I’m not in a startup right now, so I’m only utilizing a small portion of my skills. And when you don’t work at a startup anymore, you – it’s – you stop learning at the level that is high caliber. And I never want to stop that, so I’m probably always going to be in school. [0:42:57]
Richard Rodger: [0:42:59] That is the great thing about-
Kelly M: [0:42:59] Unless I work at a startup again.
Richard Rodger: [0:43:01] Exactly. That is the great thing about startups is, you get to go in every lane. In a bigger organization, you have to stay in your lane. If you try to go out of it, you annoy people; people get upset. [0:43:12]
Kelly M: [0:43:12] Yes, 100%.
Richard Rodger: [0:43:16] A social enterprise is a startup all the same, so that’s totally amazing. You never know where that’s going to go. [0:43:23]
Kelly M: [0:43:23] I’m definitely learning a lot. Yeah, for sure, definitely learning a lot. [0:43:26]
Richard Rodger: [0:43:26] That’s so awesome.
Kelly M: [0:43:27] And I’m also learning how much harder it is to get funding for a nonprofit than it is for a for-profit startup. [0:43:32]
Richard Rodger: [0:43:34] Yeah, I’m sure.
Kelly M: [0:43:36] It’s tough.
Richard Rodger: [0:43:36] That’s – oh, my goodness.
Kelly M: [0:43:38] But that’s okay, because I don’t need that right now. And if anything, I could fund it myself. [0:43:43]
Richard Rodger: [0:43:48] All the listeners here know about it now, so you know where to go. Kely, thank you so much. This has been super interesting and useful. I’m feeling – it’s not shame, just wow. I could have been way more disciplined when I was doing developer advocacy; I would have been so more effective. So, that is a lesson learned. And then the Sweet Trades thing, that’s super inspiring, so I wish you a great deal of success with that. And stay in touch and let us know how it goes. [0:44:23]
Kelly M: [0:44:23] Thank you so much.
Richard Rodger: [0:44:26] For sure, we’ll check back in. Kelly, thank you. Have a great day. [0:44:28]
Kelly M: [0:44:29] Thank you, Richard, thanks for having me.
Richard Rodger: [0:44:31] Bye-bye, bye-bye.
Endnote
Richard Rodger: [0:44:33] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:45:01]