Dize Hacioglu is the CTO of Chicago’s mRelief, which offers an easy-to-use platform that helps families connect to SNAP food benefits. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits.
Chad talks with Dize about how the platform helps people navigate the often complicated food stamp benefits system, what her role as CTO looks like as a CTO who codes, and how she hopes to help facilitate the growth of the mRelief program and team.
- mRelief
- Follow mRelief on Twitter, Facebook, Instagram, or LinkedIn.
- Follow Dize on LinkedIn.
- Follow thoughtbot on Twitter or LinkedIn.
Become a Sponsor of Giant Robots!
Transcript:
CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dize Hacioglu, the CTO of mRelief, an easy-to-use platform that helps families connect to the Supplemental Nutrition Assistance Program. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. Dize, thanks for joining me.
DIZE: Yeah, thank you so much for having me.
CHAD: And thank you for all of your work at mRelief. It's a big help to everybody.
DIZE: It's my pleasure, and it's really an honor to be able to do the work that we do.
CHAD: Speaking of that work, tell me a little bit more about what the platform actually does for people.
DIZE: So mRelief is an easy to use platform that's accessible over text messaging or web that helps folks find out if they qualify for SNAP, formerly known as food stamps, and helps them apply in certain states or connect with community-based organizations who can help them apply if they'd like further assistance.
CHAD: So it's a pretty focused product, right? [laughs]
DIZE: Mm-hmm.
CHAD: But I'm sure that there's a lot going behind the scenes in order to make that pretty focused product happen. Is that right?
DIZE: Yeah, that's right. That's right. Yes, there are a lot of moving parts.
CHAD: [laughs] So what's involved in figuring out whether someone is eligible or not?
DIZE: So there are actually a few patterns that we've discovered as we've been expanding our work from just one state where we were just in California for a while and then expanding it nationwide. We found that eligibility typically falls into a couple of different buckets. So we've been able to turn that into code that helps guide people through the typical questions of eligibility and takes them through the flow based on their state's eligibility of requirements.
CHAD: I guess my next question was going to be without mRelief; how difficult is this for folks?
DIZE: So I think most folks typically apply hoping that they're eligible, and they'll only really find out after the application process has been complete. They may have wasted time at the office, time filling out the application, time waiting for a phone call from the office only to find out that they are not eligible.
CHAD: So you mentioned you started just in California, and you've been expanding from there. You mentioned there are patterns that you found. How different are things state to state? And what does your growth trajectory look like throughout the United States?
DIZE: The biggest differences between states are income limits, the threshold that a family has to fall under in terms of monthly gross income to be able to qualify. So that has been a big data collection research project that we've done to be able to expand to all 50 states. And from their past eligibility, applications also differ from state to state. There's no one platform where you can fill out the same questions that are asked.
CHAD: I was just doing an onboarding call with some folks who are joining the thoughtbot team. And on the call, there was one person in the United States, three people who live in different countries in Africa; I think one other person in Europe. And sometimes, when I'm doing the onboarding calls with them, I have to explain how disjointed things are in the United States and which things are state by state because it surprises people.
Well, one, it surprises people who aren't in the United States that we don't have certain standard benefits like sick time in the United States. And then it also surprises people how much is actually determined by the state that you live in, even with...because SNAP is a national program, right?
DIZE: Correct. Yeah, it's federally funded.
CHAD: Right. So even with a federally-funded program, it still comes down to certain things being different in certain states, which is often really daunting and surprising to people.
DIZE: Yes, totally, totally. And it also gets even more complicated in some states like California and maybe even Texas, where it's county-administered, so each county has a different process. Sometimes they have different applications even between counties in the same state.
CHAD: So is there a reason for this other than making it hard for people to get the benefit? [laughter] That might be a political question. I just totally exposed my -- [laughter]
DIZE: I think that's a very valid question because I think we've seen instead of cutting benefits completely, administratives put up to dissuade people or make it more burdensome for people to access benefits as a way of keeping them from benefits nationwide, not just like any specific state. So I think that's a very valid question.
CHAD: But it's possible that there are other reasons, right? So, for example, like, oh, it's administered locally, or income levels are different in different places, and so it needs to be...I was just curious whether there were other reasons.
DIZE: Yeah, I'm actually not sure about the reasoning.
CHAD: Yeah, fair enough. Fair enough.
DIZE: [chuckles]
CHAD: So you joined in 2017.
DIZE: Yes, I did.
CHAD: And Emily started in 2014.
DIZE: That's right.
CHAD: So what were things like when you joined?
DIZE: Well, I joined a team of two, and the two folks that were already on the team were the co-founders, Rose Afriyie and Genevieve Nielsen, and I was also joined by another co-worker who was hired at the same time as me. And we were only doing work in California, helping folks find out if they're eligible, helping them apply for CalFresh, which is the name for SNAP in California, and helping them through the post-application process like interviewing, collecting documents, getting a Lift ride to the office to get their card. So we were really focused on the end-to-end process in one specific, again, county because it's county-administered in California.
CHAD: So in just one county.
DIZE: Yeah, in San Francisco.
CHAD: And was there a tech platform at the time?
DIZE: Yes, we had our screener, and we had our simplified application.
CHAD: Had the founders created that?
DIZE: Yes.
CHAD: Okay. And how did they focus on...they're not in California, they're in Chicago, right?
DIZE: Yeah, we're based in Chicago.
CHAD: So why California and why that particular county? Do you know?
DIZE: I think it was an amalgamation of things (I don't know if I used that word right.), but they attended Y Combinator early on in the development of mRelief. So through that, they were able to get connections to the San Francisco Human Services Agency, who was our first big contract and allowed us to really develop the end-to-end process.
CHAD: So you joined as the third/fourth person on the team?
DIZE: Yes.
CHAD: And it may be obvious, but I'm going to ask the question anyway. What drew you to joining?
DIZE: I've always loved coding. For a long time, I felt at a loss how to combine my love of coding and wanting to pursue coding as a career with my desire to try to make a positive social impact in the world. And I don't think back in 2017; I was really aware of the civic tech space. In perusing job descriptions nationwide, I stumbled across mRelief on Idealist, and it sounded like the perfect match. And I remember feeling like this is my dream job. I can't believe I get to do this work and code at the same time.
CHAD: [laughs] So you joined as a software developer at the time. Did you have aspirations to be CTO when you joined?
DIZE: No. [laughs] No, I remember looking at Genevieve, our former CTO and co-founder, and thinking I have no idea how she does her job and never thinking that I would find myself in this position. And it's been a massive learning experience and also a growth opportunity for me.
CHAD: What are some of the things that you needed to grow into or to learn in order to get to that point?
DIZE: I feel like most of the learning happened after. The biggest thing that I learned to prepare me to go into the CTO role was basically a very comprehensive understanding of our codebase. I think most of the skills or what I need to succeed in this role came after.
CHAD: Well, actually, let me ask a related but different question. CTO actually differs in different organizations. So, what does your role as CTO actually look like?
DIZE: It definitely does. And I think my role has even changed a bit in the year and a half or a year and three months that I've been in this role based on the growing team that we have at mRelief. But my day-to-day basically looks like working with our product team to plan for new features. I like to code, so I try to do some coding at least every day and also general oversight and, I guess, strategic thinking.
CHAD: One way in that description that stands out to me, you know, some other CTO might describe their role as very much not working on the code, very much not even really working with the team or product, and more focused on the executive level of the company or the needs of fundraising or something like that. So it sounds like you're very much still product-focused and oriented towards working on the product.
DIZE: Yeah, I think that's driven by a selfish desire to keep coding.
[laughter]
CHAD: You're talking to someone who is in the exact same spot. There are times where I feel guilty about that.
DIZE: Yeah. [laughs]
CHAD: Here's my justification, [laughter], and I'll be curious in terms of your justification. I've done this for 19 years now. And I'm pretty confident that I would have burned out a long time ago if I didn't spend time coding. It's part of what I find rejuvenating and what I love to do. It doesn't mean that I can always afford to work on something for four hours straight, but it's part of what has made me be able to enjoy this work for so long.
DIZE: Yeah, I completely relate to that. If I wasn't coding, I don't know how long I could sustain myself [laughs] with so much responsibility. How do you find that balance?
CHAD: Well, I think part of it is freeing yourself up to not feel guilty so being really clear with others. Like, if someone asks for something from me, being like, yep, totally, I can do that. I can get it done by this day and pretty aggressively planning out my work or time, blocking my calendar and making it clear when I'm going to be able to have that thing for them.
And if that timeline doesn't work, then they can tell me that, and I can adjust. But that goes a long way towards when I am having a coding session that lasts half a day or something like that; I cannot worry or feel guilty that someone's waiting on me for something or that it's not what I should be spending time on.
DIZE: Yeah, that makes a lot of sense.
CHAD: What about you? Have you found things that work for you?
DIZE: I have been trying different things. I've been doing a lot of YouTube deep dives on productivity blogs, just different ways of thinking about prioritizing work and making sure that things get done. But I really like your point about allowing yourself not to feel guilty. And I do like to remind myself that I don't want to take the fun out of my job. I want that for other folks on the team, and I also want that for myself.
CHAD: The other thing that is on my mind when I'm doing something is there's this stereotype of the CTO who codes and makes a mess of things that the other people have to clean up.
DIZE: [laughs] Oh no. I didn't know about that.
CHAD: You know what I'm talking about?
DIZE: No. [laughs]
CHAD: Oh, no, no? It's like, oh, the CTO made commits at 9:00 p.m. last night. I guess I have to...and the build is broken.
DIZE: Oh no.
CHAD: I guess I have to...[laughs] so, does that describe you or no? [laughs]
DIZE: Oh my gosh. I'm definitely seeing myself in that description a little bit. [laughs]
CHAD: Oh no. [laughs]
DIZE: Literally, I was up last night pushing code to production, but I think it's okay. [laughter] I mean, I hope that that's not me. [laughs]
CHAD: I try to avoid that because, you know, I want to feel like my work is useful and valued and not creating more work for other people.
DIZE: Yeah, definitely. I agree.
[laughter]
CHAD: Tell me more about the tech stack for mRelief.
DIZE: So we use React and Rails. We're hosted on Heroku. Yeah, very basic.
CHAD: I heard that you use some thoughtbot stuff, so I assumed that it was Rails.
DIZE: [laughs] Yes. Yeah.
CHAD: That's great to hear.
DIZE: Yeah, I was messing with Paperclip this morning, actually. [laughs]
CHAD: Oh, well, Paperclip is deprecated. I'm sorry to tell you. [laughs]
DIZE: I know. [laughter] I had to fork it this morning to make a change.
CHAD: I still stand by that decision. I think it's important as sort of a community contributor that we signal overall direction and coalesce behind what's built into Rails once it was there.
DIZE: Okay, that makes a lot of sense.
CHAD: But yeah, was Rails in use when you joined?
DIZE: Yeah, we're using the same stack.
CHAD: How much has it grown over time, the codebase?
DIZE: I don't really know.
CHAD: That's interesting that you don't know. [laughs]
DIZE: When you say grown, like, I guess how is that measured?
CHAD: Oh yeah. I mean, is it more complex now than it was when you joined?
DIZE: Yes, definitely. Yeah, we've added new products that had never existed, and the fact that we've expanded to more states and our screener is nationwide that's added a lot of complexity.
CHAD: So, do you have ways that you manage that complexity, either in the code or in the business?
DIZE: What would that look like? [laughter] How would you manage that complexity?
CHAD: Well, I think it's a little dependent on where the complexity is coming from. So, for example, the screener is nationwide, you said, and so does the screener change based on where you're located once you start to fill it out?
DIZE: Yes, yes. The first question we ask is zip code.
CHAD: And then how does all of that branching work in the state-specific logic work? Is it all one big jumble of if statements and code, or is it factored out in some way to help keep that as clean as possible? And if the answer is it's all one big jumble of if statements, that's totally fine. [laughs]
DIZE: I was actually going to say both. [laughs] Because I think because of the patterns that we were able to establish, and the eligibility logic between all states, there's definitely some if branching, but there are enough shared concepts that we can keep it all in one to two files that are not too long.
Mid-Roll Ad
I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.
We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.
Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.
CHAD: So you mentioned the team has grown quite a bit. It seems like the development and design team is quite a bit bigger than two people now. How big is it?
DIZE: Well, the product team itself is eight people now, I think. And the team, the whole mRelief team, we just had two new folks start today, so I think we're at 20.
CHAD: What does your onboarding process for bringing new team members on look like from a technical perspective?
DIZE: So the first two weeks, folks are typically in a bunch of onboarding meetings just getting acquainted with the history of mRelief, our current processes, and stuff like that. But for our tech team, we like to jump in with them as soon as possible, get them set up obviously locally and have them contributing with some kind of low-hanging fruit tickets at first so that they have some code pushed up in the first week or two.
CHAD: Are you facilitating that through pairing with someone existing on the team, or are folks doing that independently?
DIZE: Depending on the complexity of the ticket, sometimes we pair. Mostly it's independent work.
CHAD: Some companies and some teams have the goal of like, oh, you know, first commit to production on your first day. Do you have anything like that either with the code or with the processes like benchmarks that you use of, like we really want this to happen but on the first day or in the first week?
DIZE: No, we don't have anything like that.
CHAD: At the size, you're at now, some companies start to break into sub-teams or squads or focus areas. Are you starting to do anything like that?
DIZE: I've thought about it here and there. But I think we all like sharing responsibility for all of the different products and getting our hands into all the different ways that we connect with users. So we haven't formalized anything like that.
CHAD: So that means you have one backlog of everything that's slated to be worked on.
DIZE: Yeah, that's right.
CHAD: Is that overwhelming sometimes?
DIZE: Yes. [laughter] Yeah. I don't know about your experience with backlogs, but I assume that they're always overwhelming.
CHAD: Yeah, that's a really good way of putting it. I think that not having it requires very aggressive management that a lot of teams are not willing to do. And then when you have a team of 10 or 12 people all working across multiple apps or all on the same app doing a lot of different stuff, that's overwhelming on the other side of just the amount of stuff that's happening every day can sometimes be overwhelming.
And people start to sort of step on each other. Oh, you know, we've got these two pull requests, and every time I go to make a change, something has merged into main that now my branch is behind. And if you're waiting for CI to pass and your CI is too long, something new has been merged in by the time your CI run finishes. Those are some of the challenges that I hear people facing.
DIZE: Interesting. What are those aggressive management things that you were speaking of to avoid backlogs?
CHAD: I think it basically means saying no to things. So I think when we talk about a backlog being overwhelming, one of the worst things that comes to mind mostly, and let me know if this is part of the problem you're feeling or not, but it's really long. And somewhere in there, there's like the bug that was created two years ago by someone that has never been addressed, or maybe it has been, and the ticket was never moved forward. And so you end up with 500-600 things and a long list that becomes then very difficult to ever really prioritize because it's not possible to prioritize that many issues. Does that resonate with you at all?
DIZE: That does resonate. I was scrolling through our backlog today, and I was like, when is this going to end? [laughter] I guess I hope that was normal. [laughs]
CHAD: It is normal, or I should say I think it's common.
DIZE: Common, okay. [laughs]
CHAD: I think it is a problem a lot of companies face. And like I was saying, I think one of the only solutions to that is basically, well, so either someone or a team that is very comfortable saying, "We don't need a ticket for that because we're just not going to get to it," or being able to delete something that you've not...or move it out that this was created two years ago. It's just not doing us any value to have it hanging around anymore.
DIZE: Yeah, that makes a lot of sense. That's helpful.
CHAD: And some companies do it by policy basically. They have a philosophy or a policy that says, "This needs to be a thing that comes up." They have a product manager who's paying attention to what's going on and is like, okay, this is the third time that this has come up. Now we'll create a ticket for it because we're actually going to do it. And you only create tickets for things that are for the next four weeks, for the next six weeks, and that you use something else other than tickets.
So one thing that I've found really works well for me, and I like this idea of the difference between a discussion or an idea and the work to be done is; for example, we often use Trello for project management and a Kanban board of the work that's actually happening in the backlog. But anything that's not a concrete item that we're going to actually prioritize and do is better off in a messaging system like Basecamp or another tool where it's more of like a discussion about what we might do, and we post designs and those kinds of things.
And it's not until it's actually okay; we plan to do this three weeks from now that it gets a ticket created. And if you're really aggressive about that, that works pretty well. But you really need to stay on top of it. And if someone creates a ticket for something, and then it turns out that you're not going to do it in a reasonable timeframe, it moves out and becomes a discussion.
DIZE: Oh, I really like that. That's a really great process. I feel like I'm using this as a [laughter] mentorship session. So thank you for that guidance.
CHAD: My pleasure. It's funny that we've hit upon this because I think it is a common problem. And then the other thing is like, okay, great, Chad, that's wonderful. I have 600 things in the backlog; how can you...I don't have a great answer for that [laughs] other than basically one of the things that I've done and seen other teams do is...so what project management tool are you using now?
DIZE: We're using Asana.
CHAD: Asana. It's basically creating another project and taking everything that's not going to be done in the next two or three weeks and moving it to another project and then saying, okay, what our process from now is going to be is we have a biweekly planning meeting, or we have a weekly planning session. And what we're doing as part of that is taking things from the project where we moved everything to, and we're only moving the things over that we're actually prioritizing and going to do in the next X number of weeks.
DIZE: Cool. That makes a lot of sense. Thank you.
CHAD: I hope that's helpful. [laughs]
DIZE: That is helpful. No, yeah, thank you so much. I'm still new, and I have so much to learn. [laughs] So this has been really, really informative.
CHAD: So actually, this leads me to something I was wondering about based on this conversation and just in general, is as CTO, who are you actually leading? And is there a separate product manager or a team that actually doesn't report to you?
DIZE: No. I basically lead the product team. We do have a product designer who takes on more of the management of the design part of the product team, but I don't think we've grown big enough to silo like that yet.
CHAD: And I don't recommend it. I think it's great when you have an integrated design and development team working together. At a certain size, yeah, you need to create divisions, and you need to, you know, that kind of thing. But it's better when design and development work really closely together to create something great, in my opinion.
DIZE: Yeah. I've also found that to be effective.
CHAD: You have people on your team with different levels of experience. How, as a leader, do you attempt to...I think you're a great example of someone who joined at the level of software developer and grew in their career to be CTO. Like, how do you help others do that?
DIZE: I think the biggest part of that is assessing how they see their career growing. I don't know if everybody wants to be a CTO, wants to be a manager, or just wants to continue to be an individual contributor at a higher level. So just trying to work with them to figure that out for themselves and then providing opportunities to gain that experience like leading a project, or taking on management responsibilities, providing more ownership, and leaving them to their own devices as much as they are comfortable.
CHAD: The fact that mRelief is a non-profit, how much does that factor into your day-to-day or your ability to build a team and hire or anything like that? Is that something that you feel on a regular basis?
DIZE: The biggest way that I feel it is hiring. I don't know if you're also experiencing this, but it's like, it's been a very competitive market, especially recently. And I know it's always been, but recently, I feel like it's turned up a lot. Trying to align compensation to the market has been a particular challenge.
CHAD: Where does the funding for mRelief come from?
DIZE: So we're funded in a couple of different ways, a couple of different streams. We are funded through grants, individual donations, and government contracts.
CHAD: Hiring, especially in a world where you're competing to hire against companies that don't need to be sustainable or profitable, like, they've gotten millions of dollars, and they can just spend it, that is tough. And thoughtbot has existed in that environment forever basically because we're a consulting company which started from scratch without any investors or anything like that.
And so we focused on being the kind of place that people want to work, having good benefits. We're not going to be able to compete against companies on compensation directly. And so we focus more on paying people fairly and what we can afford but being the kind of place that people actually want to work.
DIZE: What have you found to be the most, I guess, successful exploration of that?
CHAD: Well, it's evolved over time. There were a lot of things that we could put out there in terms of what it was like to work at thoughtbot versus what it was like to work at the typical startup company that made us special, and it wasn't anything radical. It was just like, you're going to work sustainably, and we're not going to approach deadlines in the same way. You're going to have agency over your work.
You're going to work with a really great, smart team of people who are all sort of like...the analogy I use is like a professional sports team. They make it look easy. And it's not super stressful all the time because you don't need stress in order to do great things; you need people who are given the space to do great work.
And I'll be honest; actually, we're one of the best places you can work if you want to do Rails work. Now, a lot of that stuff has evolved. I think startup culture is different than it was 15 years ago. And there are more companies where you can work in Rails that aren't as bad as they quite honestly used to be. We used to be able to point to companies and be like, you don't want to work there. And there are less companies that we can do that to now.
DIZE: Oh wow. Okay, so folks have started to kind of simmer down on expectations and just the hassle of startup culture?
CHAD: I think so. And then you have examples if you want to stay working in Ruby, then you have companies like GitHub and that sort of thing where they hire remotely. They've addressed a lot of the problems that they had in their culture. No company is perfect, but I think they've made it seemingly from the outside.
And from the number of thoughtbot people that we've had join GitHub, they seem to have addressed some of those issues. We've needed to, in some ways, double down on some of them, like in terms of really recognizing we can have a culture where you can actually have an impact on who we are and what we do in a way that you can't in a big company.
DIZE: Oh, yeah, yeah. That resonates for sure.
CHAD: Is that part of what you've done? Obviously, you have a mission-driven impact-oriented thing which I think probably draws people who want to do that, right?
DIZE: Yeah. And I think what we can offer that feels more unique is shared leadership. So like you said, having a lot of sway and impact on the way that the organization is run day-to-day because we really believe in distributing those responsibilities.
CHAD: What's next for you and the mRelief team?
DIZE: Well, we have some goals this year that mean expanding to a couple of more states. So we have our simplified application and also our assistance platform and about 12 partners, ten states, or something like that. And we want to expand to eight more states by June of 2023. So that's going to be a lot of our focus this next year.
CHAD: So you talked about how hiring has been a challenge. So I presume that means you're trying to hire some new people to be able to accomplish these goals.
DIZE: [laughs] Yes. Right now, we're looking for a full-stack dev experienced in React and Rails at least a year or two to help us with that expansion.
CHAD: Oh, that's another thing that has helped us hire is having an apprentice program where the majority...we don't take people who are brand new and teach them. But it's sort of like one level up, taking intermediate people who wouldn't be able to bill at the level us and our clients need them to and getting them to that level in a three to a six-month timeframe where we don't bill their time. They're paired with mentors. They work one on one with a mentor, and it's a rotation program. So they rotate the mentors. That has been really helpful for us.
DIZE: That's amazing. I would love to do something like that, and I would love to also even train folks from the ground up. I feel like that's like a pipe dream just based on capacity. But I think there are so many folks whose voices don't get to be in product development, and I'd love to foster that.
CHAD: Do you think you have the space to be able to do that, or do you think that what you're saying about it's hard for your team to have the bandwidth to train those folks?
DIZE: I think it's a problem of bandwidth, at least right now. Hopefully, it'll change.
CHAD: That's one of the reasons why we don't work with people in the beginning stages but rather someone who can be an effective pair for a Rails developer. That's a good point because they can learn a lot, but they're an effective pair. They're not slowing anybody down, and we can teach them primarily through pairing. Whereas if someone doesn't even know HTML, that is an issue that we haven't been able to...we can train, but it's hard to balance that and have enough bandwidth to teach people that.
DIZE: Yeah, that's brilliant. That makes a lot of sense. What kind of credentials do those folks usually have? Are they out of a bootcamp or self-taught?
CHAD: Some of them are out of bootcamp, and we could take more out of bootcamp. Out of bootcamp is actually a very fine stage. The problem is that there just aren't a lot of opportunities like this. And so, for example, for our last quarter's apprenticeship, we had four apprentice positions, two designers and two developers. We got 1,033 applications.
DIZE: Oh my God. Oh my God. Wow.
CHAD: And we screen all of them, and we respond to everybody but as a result of that, what it means is the more experienced people are likely to take up and get the spot over someone with no experience at all, which I don't love, but it's difficult to not have that happen.
DIZE: Got it. Very, very competitive. Wow.
CHAD: Right. Right. Our people operations person likes to point out that it's more competitive than Harvard.
DIZE: Oh my God. [laughs] What does that make the acceptance rate?
CHAD: I don't know. [laughs] Four out of 1033; I don't know.
DIZE: Dang. [laughs]
CHAD: It's low. In order to balance that a little bit and to strike a balance and find the people who I like to call the top candidates, like, they're not the most qualified, but they're the top. And I'm still working on this term but basically focusing on things that aren't just what they can do for code or their coding experience.
Like, the things that are important for consulting are like, do you have experience talking with people? Have you been a teacher? Have you been in retail? Even being in retail is a little bit of a plus over someone else necessarily who's just been a coder forever.
DIZE: Yeah, yeah, some kind of diverse working background.
CHAD: And at least I think it's really important that someone with a really strong background that lends themselves to being a good consultant is able to get an interview even if they don't have a lot of actual work experience. I think that that's really important, at least giving them the shot even if, after interviewing them, we think that we need to move forward this other candidate.
I think it's really important that the initial screening not completely screen out people just based on, for example, years of experience. We don't look at degrees at all. That's not even a factor in normal thoughtbot hiring. It's not something that we look at.
DIZE: Oh, good. That is such a cool program. I wish more places did that. [laughs]
CHAD: Oh, me too. It would make our job easier because we wouldn't need to reject so many people. We could refer them to these other places.
DIZE: [laughs] Oh my gosh. Yeah.
CHAD: We're actually changing the program for 2022 because we know that there are tons of people, not a lot of opportunity. It used to be that we would do interviews, and then we'd be forced to say, "We're not taking you now, but we are moving forward in the process with these ten people and whittling it down to the 2."
What we're doing now is we actually continue the interview process with everyone who passes the things that we're looking for. So we can get to the end of the process, and even if we only have two slots, we've identified the five people who would have been able to do it. And then what we do is we say, "We think you're a great fit. There are just not enough slots right now. So can we reconsider you or schedule you for a future slot?" That's what we're trying to do.
DIZE: Interesting. Has it been helpful?
CHAD: We're only in the second quarter of doing that. So we're still a little early with that change. But I can already anticipate the problem, which is there are too many people we would take.
DIZE: Ooh, yeah. [laughs]
CHAD: And so I carried forward 15 People from the last session, from the last quarter. And that 15 is more than...[laughs] and unless we're willing to then turn off applications so new people can't apply, we still get, you know, so the last quarter was 970 applications about.
DIZE: Oh wow.
CHAD: This quarter was 1,033. So one of the factors that has really helped with our hiring is we decided to go fully remote at the beginning of 2021, and that has really helped us expand to being able to hire a little bit more competitively by not competing against everyone in the places where we had offices previously.
DIZE: That makes sense.
CHAD: But I noticed that you're still a Chicago-based team, right?
DIZE: We're still Chicago-based, but we're remote now, fully remote. Our headquarters are here. We do have a lot of team members here. We also have folks throughout the States.
CHAD: On the development team too?
DIZE: Yes, on the development team.
CHAD: Oh, okay, great. So when did that...did that change with the pandemic, or did you have it before?
DIZE: It changed with the pandemic. So before, we weren't remote at all; we were always in person.
CHAD: Has that been a big change, or an easy change, or a hard change for your team?
DIZE: I think a pretty easy change. I think we're all...well, I don't want to speak for everybody, but it seems like it went quite smoothly. We do offer a monthly stipend for Deskpass in case anyone wants a physical workspace and may sometimes meet up to co-work for a sense of community and camaraderie. But other than that, folks seem to really enjoy it.
CHAD: Yeah, I think for us, it was also not a difficult transition when it came down to a lot of the work and that kind of thing. I think the biggest challenge for us has been we're bigger, and so there were people...and we very much we are local teams working with local clients. And so, there was a segment of the thoughtbot team that never opted in to a fully remote company.
And so they've understood the transition, but they didn't necessarily choose it for themselves. And so they have their choice of...like you said, it's a competitive market. It is important for teams to be clear about who they are and how they work. And if someone at the end of that says, "You know what? I understand, and that's not for me," I think that's okay.
DIZE: Yeah, definitely, like self-selection. [laughs]
CHAD: Yeah. Well, thank you so much for stopping by and talking with me. I really appreciate it.
DIZE: Yeah, thank you for having me. It was so lovely to chat. And thank you for all the great advice.
CHAD: I wish you and the mRelief team all the best and keep in touch.
DIZE: Thank you, you too.
CHAD: Oh, wait, if people want to find out more, we got to say the website. [laughs] And if they want to get in touch with you, where are the best places for them to do that?
DIZE: So our website is mRelief, so M as in mom, relief as in sigh of relief, mrelief.com. We're on some socials. Our name differs [laughs] based on the social, but we're on Twitter and, Instagram, TikTok soon. [laughs]
CHAD: Oh, wow.
DIZE: [laughs] Yeah, that's it.
CHAD: And that's where people can find the job posting as well?
DIZE: Yeah, on our website.
CHAD: Awesome. Well, thank you again.
DIZE: Yeah, thank you.
CHAD: You can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.
This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.
ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.
Support Giant Robots Smashing Into Other Giant Robots