B&G’s Mentorship Framework

“I wish we could hire more junior people. small project consulting makes that hard, for us at least. if we had a product or much bigger project teams, slotting a junior person in would be so much easier.”

That’s a message I got through chat from someone I know. And while I understand the source of it, I want to challenge everyone to flip the scenario. I’ve been delaying writing about this for a long time, for reasons I’ll tackle in a bit, but this comment pushed me to just do it. Not because the person who said it is wrong, but because I feel the need to promote a counterexample.

Part of why I have delayed talking about this publicly is because I wanted to do it when I have an undeniable success story that I can share. Ironically I am compelled to talk about my experience with Jr. Devs on the back of a huge loss and failure. So here it goes…

In previous posts (here and here) I’ve written about my mentoring work through B&G. Mentoring is what we do at B&G. In 2018 alone, up to this point, I have been the only Sr. level engineer and mentor at B&G but I have worked with and mentored 3 Jr. Devs as my direct contractors, 2 dev interns hired by a client, and 1 UX intern hired by another client. All while running and delivering on projects as a consultant in the role of either Software Architect or Fractional CTO to 4 clients. So here’s how it all happened, from the beginning:

2015

In 2015 I left a job at a company where I was climbing up the ladder and could have had the “power” I wanted along with the comfort of being a salaried employee in a multi-million dollar company, because of a toxic culture. But at that job is where I had my first crack at mentoring, and being successful at it (imo).

The company was interviewing candidates and I got the opportunity to meet a couple of the candidates that were being considered at a hackathon. The dev manager and another manager were heavily leaning towards one candidate, and heavily opposed to another. I was of the complete opposite opinion. The person they were favoring seemed to me like a mistake waiting to happen, whereas the person they were opposed to seemed to me like the most qualified person we could land at the company. To me, it was clear this candidate had the highest potential to be one of the most productive employees at the company. This candidate was a workhorse. So I fought hard to make a case for hiring them, and eventually the company hired both.

I took on the responsibility for, Jad, the hire I advocated. Jad sat next to me in our open office, and at that point, I had unofficially started my own mentorship program within the company. At the time, I was not in a senior position, so taking that step was a risk. I spent 3 months molding my apprentice. I used pairing heavily. I used code reviews. I was tough, because I knew that Jad could handle tough constructive criticism and being pushed. Ultimately, Jad became one of the most productive devs in the company and earned the respect of everyone on the team and management alike. Jad is someone I could rely on and trust completely. The other dev, btw, was a complete dud.

When I left the company in 2015 I wanted to recreate that experience I had with Jad, but at a bigger scale. I wanted to be in a place where I could set a certain culture of collaboration and respect to everyone, and I wanted the company I work at to be a place that welcomes women, minorities, and any “outcast”, unlike the last company I worked at, which gave me bad reviews for putting on noise canceling headphones because I liked to concentrate while coding in a distracting open office setting.

That’s when I decided that the only way for me to achieve all of that is to start my own company. That’s when B&G was born.

2016

From 2011 to 2015 I was living as a digital nomad, going from one place to another. In 2015 I moved back to the US, wanting to settle down. I got married, started my own company, and moved to Austin, a part of the world I didn’t know much about and knew no one. So in 2016 I took the time to establish myself, and place some seeds to form some roots for my new life.

I worked for most of 2016 on one single project, as a lone dev. Trying to pay the bills and establish some sort of track record for B&G. I also spent a lot of time going and participating in local groups like Austin on Rails and AustinRB.

Towards the end of the year, I met Naghmeh. Naghmeh had just graduated from a local dev bootcamp and was having a hard time finding a job as a developer.

I offered to help Naghmeh. I figured I’d answer any technical questions she had, do some interview prep, etc. I didn’t have a project to staff her on, and I didn’t have the resources to support a full fledged apprenticeship program.

Then, I was approached by an entrepreneur who wanted to hire a consultant to build a product for his startup. As many of these stories go, the entrepreneur didn’t have the money to pay the (very low) rate I was asking for, so I figured this small consulting gig would be a great opportunity to devise something for Naghmeh. I could charge a lower rate since the work would be done by a Jr. Dev. Ultimately, the relationship is symbiotic. The work gets done, which is a win for the startup, and Naghmeh gets some form of a real world experience under her belt. The risk for me was low because the project was simple enough that if anything did go wrong I would have been able to step in and salvage it by working late nights on it. At the same time, however, it was simple enough that I could set Naghmeh up for success by providing all of the pieces and planning required to simplify the job.

Naghmeh did an awesome job. The product got built. She learned a few things. But eventually, work dried up for me. I didn’t have projects for myself to work on and neither for her.

2017

2017 started very slow, and since Naghmeh is a mom and needed something that could provide the type of benefits her family needs, she went on the hunt for a permanent position and was able to leverage her experience with B&G to find a job.

At this point I had a lot to consider. New companies struggle to get over the 2 year hump. Many say if you can make it past the first 2 years you should have a good chance of making it. The Small Business Association stats indicate that 30% of businesses fail in the first 2 years (source). That’s a lot! So while I was trying to make sure B&G survives, I was considering what effects would a repeat scenario like Naghmeh’s would have on the company and on the apprentice.

The decision I took was based on the following answers to these questions:

1. Would a potential hire/apprentice be comfortable working with me and take on a temporary gig?

What I could presume is that someone who graduated a bootcamp and has been searching for a job for a while, many months in some cases, would welcome this opportunity as opposed to sitting idly. Some people would have an easier time with this arrangement than others, so I might be favoring someone who is privileged enough to not need insurance or any of the benefits you would get at a full time job. On the other hand, that’s all I could offer and felt that some form of work and payment is better than none. Especially since the demographic I was targeting was females making a career change into software development, and that is an under-served group. My goals were always to grow enough to be able to then provide everything I wish I could provide, but this would be a stepping stone towards that.

2. What’s the cost to B&G and me for doing this?

There’s a lot involved in this answer.

Time: It takes a lot of time to mentor and train and manage a Jr. Dev. Would I have time to do it? I’ll make time. Can I afford to take time away from something else I could do for this? It’s a sacrifice I would happily make.

Financial: Would I be doing this for free and would it be costing me money? The plan was that if I would do this again I would do it with someone who could be independent and take responsibility of their own development. They would spend a couple of weeks getting up to speed using resources I would provide. Frequent pairing sessions of an hour or two would help make sure some basic concepts are familiar. Then I would assign the person a project to work on which would be a billable project where they would be making B&G the money that would pay their hourly rate and also compensate me a tiny bit for the investment I’m putting into the Jr. Dev. It wasn’t going to make me rich or anything, but it would allow me to do it without going broke myself.

Turnover: What would it mean if this apprentice left and took a job somewhere else? Win-win for everyone. If I can’t hire them permanently and they are able to leverage what they did at B&G to find a new job, I consider that as a win for everyone. I would have gotten to do what I wanted to do, mentor, as well as affording me the opportunity to work with a client I might have not been able to land otherwise. The apprentice gets to use B&G as a bridge between the bootcamp and the next job. The new company gets to hire someone who’s better ready for that job. Many would say that investing in a person who then leaves is a waste, I don’t subscribe to that kind of mentality.

Scenarios: What’s the worst case scenario? I contract someone who turns up to be a bad fit, does not perform the work they’re supposed to, tarnishes B&G’s name, and ruins a relationship with a client. I expect this will happen at some point, I don’t think anyone or any company/agency is **** from this. It’s also a risk I’m willing to take if that’s what it would take to give to the community in the way of mentoring Jr. Devs. What’s the best case scenario? I find a person I want to work with for a long time, I’m able to work with this person on multiple projects and B&G grows so this person becomes part of the foundation for B&G to be able to hire them and others and take on more works and more clients.

So all in all, from the perspective of the apprentice, as long as I am completely honest with them about the expectations they should be able to make an informed decision on whether this is a good fit for them or not. And from the company’s perspective, there are risks that I am willing to take for the sake of building towards achieving the company goals.

That said, 2017 became the year where I would put all of this to a test.

In July 2017 I started working with Sam. Sam picked up coding on her own while being a stay at home mom. She has a background in mechanical engineering, and took time off to give birth and take care of her baby. While doing that she had an idea and to implement it started learning coding on her own and picked up Ruby on Rails. The situation with Sam was very convenient, she did not need the bells and whistles of a full time job. Her situation allowed her to take a chance on me, she needed the kind of flexibility I was offering that other jobs weren’t because her kid was not yet in school full time so being able to work part time was convenient to her, and not many companies want to hire a Jr. Dev on a part time basis.

The first few months with Sam were relatively easy. I was involved in the project she was working on, and I was performing code reviews, and we would set up pairing sessions when needed, but for the most part Sam was independent enough that it felt like I was able to put the process in cruise control and we would all be fine. So much so that I started looking for other women to work with in parallel. I’ll come back to Sam in a bit, but first the next story.

Since things were going well with Sam, I started interviewing other candidates to grow the team. The plan I had started working on is the ability to groom someone that would take over some of the coding responsibilities I had with a client that would free me to focus on mentoring and building a team as well as some biz dev to get some more clients. So I hired Sarah to work on a mini project as a way to test out the relationship at a low cost. The project was paid for by B&G and not a client, but used a real world scenario type of project so it mimicked a real project. Sarah was great, but she had student debt and other responsibilities so understandably she chose to take a job with a big company for the stability.

Let’s do a recount: So far B&G has taken in 3 Jr. Devs, 2 of them have gone on to find full time jobs and 1 is still with B&G up to this point. In fact, all 3 had received job offers at this juncture, and all 3 would tell you that the offers came because of their experience working with B&G. That’s a huge win in my book. Saying that B&G served as a bridge for 3 women to find jobs in tech is in fact the mission I set out to achieve.

Back to Sam. She did receive job offers to work for other companies, on a full time basis, with everything that comes with that. She chose to stay with B&G. That was a great boost of confidence, and pushed me to keep going. Sam finished 2017 on the B&G roster and contributed to a couple of projects.

2017 was a pilot year for B&G’s mentorship program. A program still in its infancy but that is developing while pushing the limits and doing something rare in the industry.

2018

2018 started with the goal of building upon the progress made in 2017 and the knowledge gained from the experiments done during that year.

Lessons Learnt

1. This is the path that I want to guide B&G on, even if that requires more work and would cost more money.
2. Many people and startup founders are still ignorant to the cost of software development and wouldn’t be able to afford most agency rates. Being able to provide the same services of a lower rate is one way to build a portfolio of clients without lowering the value of my own hourly rate.
3. When targeting women founded or lead startups, having a female oriented mission is valuable and attractive.
4. To support scaling I would need to scale some of the mentoring processes. For example, getting up to speed on the basic of Ruby and Ruby on Rails should not consume all of my time and should be delegated (to books in my case).
5. I can’t target high value projects and high profile clients with an entirely Jr. level team. Which means leaving some money on the table.
6. Scaling without another Sr. Dev on the team that can mentor will be hard, or without a dedicated Biz Dev person who can streamline the pipeline of projects coming in. Something I still have not figured out.
7. The probability is high that anyone that comes through the program will leave within the first 3 months.
8. The potential target for the program is someone will value the flexibility of the environment at B&G over benefits (like insurance and paid time off), since they will be subcontractors and not full time hires (at least at the beginning).

Keeping all of that in mind, I started 2018 hoping to stabilize some basic things, as well as completely switching the offerings of B&G from selling my personal time to selling B&G as a company and a team. The majority of 2017 was spent where I was working full time on one particular project, and Sam working on another. I could not successfully remove myself from the coder role on that project and replace myself with someone else while transitioning into a mentor and/or manager or CTO type of role. So I set out in 2018 to go after jobs that would not bind me in such a role again, which would free me to support mentoring multiple people on multiple projects.

I spent a bunch of time in early 2018 hunting for work and projects, while in parallel interviewing potential candidates to hire as contractors to start the mentorship process.

The first person I took onboard, we shall call them “Person A”*, was a great target. A female, parent who spent a lot of time making decisions based on their child’s needs instead of her own, who went through a bootcamp for a career change into tech, and who was struggling to get an opportunity. I did also have the perfect project that fit her skills. So, I started implementing the same process I used in previous cases. Mainly letting the Jr. Dev jump into the deep end of the pool, test their ability to float on their own, and assist when they can’t. While also making it a gradual process, can you float on your own? can you float while holding a 1lb object? how about 5lbs? How about while holding the object above your head and keeping it above water?

Soon enough I found out that “Person A” was not ready to be put in the situation I put her in. I needed to ease her into the needs of the job, so I pulled back and started over again by providing some educational resources to go through first, before attempting to write any production code. I also spent many long pairing sessions talking about the basics. That was the hardest challenge. Especially since while all of this was happening, I needed to staff the project “Person A” was supposed to be working on with someone else. In the meantime, I took on the responsibility of the coding, which is exactly NOT what I wanted to do.

Because of the experience I had gone through with “Person A”, I decided to switch up the approach a bit when hiring other people. I decided that what I would do is open up the selection to anyone who fit a small set of criteria:

1. Is the person a female or member of minority group?
2. Did you get into tech through a non traditional path?
3. Can I talk to you and have a conversation with you? (Necessary for mentoring, I can’t mentor someone I can’t talk to. D’oh!)
4. Are you able to dedicate sufficient amount of time per week to B&G (over 16 hours) and will you be able to go without pay or benefits for an extended period of time?

The first 2 criteria are aligned with the B&G mission of helping underserved communities get into tech. #3 is necessary for me to be able to give a lot of my time for the development of a person I don’t know very well. #4 is a criteria I hope to get rid of but is necessary at this stage of B&G’s growth, I am hiring the devs as contractors so benefits would not be included, and the initial phase will focus on learning outside of the scope of a paid project, so would not be paid time. I am fully aware that #4 contradicts in some way the mission to help underprivileged folks, and is something that bothers me a lot, which is why in “Person A”’s case I paid her for multiple months even though she was not contributing to billable work. But it’s not something I would be able to do for multiple people at the same time at the current stage.

With the new framework I contracted two new Jr. Devs, “Person B” and Sherry. I interviewed a few more people, most of them didn’t fit criteria #4 (it bothers me a lot that this is the case), and a small percentage did not fit criteria #3.

“Person B” was promising, but got offered a full time job within the first 2 weeks of contracting her and she decided to take the full time job. Student debt is a mother****er. Sherry on the other hand has become an instrumental part of the team. She is doing great work and learning (I assume 🤔) a lot on the way.

That is not all though. Summer of 2018 was action packed. One client hired 2 dev interns who are still in their first years of college, that became my responsibility to mentor and manage. Another client hired 2 interns as well, one of them, a UX intern, became partially my responsibility as well. Which meant that while everyone was on boats in Lake Austin during the summer I was managing and mentoring 6 Jr. Devs/interns.

At this point I had to have the hard talk with “Person A”, telling her that B&G was not a good fit for her needs as she needed a place that would give her more time and stability to be able to grow, and the ability to provide more 1 on 1 attention, which I was not able to provide given my workload. So although I was down to only 5 Jr. Devs/interns, it was still an eventful summer. It involved too many PRs for my liking, too many lines of code badly indented and unreadable, and too many conversation about very basic stuff, so much that I wish now there was a pill that people could swallow and they would gain all of the basic common knowledge about how the web functions. In fact, the Jr. Devs and interns weren’t the only people I had to explain some basic concepts to, there were CEOs, CMOs, COOs, CCOs, you name it, in the mix as well. And do you think all of those people were together in one room when I had to explain the same things to all of them? Of course not, it wouldn’t be my life if things were this easy!

Back to mentoring Jr. Devs though, after the summer experience I would add a new criteria to the list when considering who to hire:

5. Possess the ability to produce some kind of code independently. If the person can write some code without my direct involvement through every second of it, then I am able to assign them some billable tasks, and that helps. Otherwise, getting them up to that level is beyond the scope of what B&G and I can handle at the moment.

I also learned the following things through that experience:

1. Know what to prioritize while reviewing a PR. Some cases require to value progress over producing perfect code.
2. Never stop being positive and encouraging while giving feedback. Even if the person receiving it has been around for a while and understand that code reviews are about the code and not the person AND even though most of the feedback is neutral or constructive, that’s not enough.
3. Don’t lose perspective in regards to time. Someone who has done a great job and has become a person you rely on is still someone whose experience on the job is limited (2 years or less in most cases), and to project the same expectations you’d have of someone who had been doing this for 10 years is unfair.

That, in a very long and excruciating detail, is the story of B&G’s mentorship program. A program that started ad-hoc and has slowly transformed into a framework that will continue to develop.

This framework is available to others outside of the B&G team, as a service I provide to companies that can hire me as a mentor for a Jr. Dev they are considering to hire but do not have the internal resources to provide the proper mentorship. There are many companies with openings looking to hire devs and cannot find someone at a Sr. level, hiring a Jr. Dev is a great alternative. The company would be providing an opportunity to someone who would appreciate it, which would build loyalty. It is a much cheaper alternative, since any new hire would need up to 6 months to get up to speed on the ways of the new company regardless experience level, and within those 6 months a Jr. Dev could reach a level of productivity that is profitable for the company considering their salary level (even including the cost of hiring an external mentor).

The offer of mentorship is also available to members of the community who fit all 5 criteria, but given the cost of doing something like this with no return I would be stricter on assessing and applying those criteria. So if you are in Austin, and have interacted with me a bunch, and would like me to be your mentor, do reach out, the answer could be a Yes!

Side note: While everything was happening in 2017-2018 (including many other not directly related things), one other case did take place. Nikita is someone I met and knew would be a perfect fit for B&G had B&G been an established company with everything in place the way I envision it to be. A few missing pieces from B&G’s side made it a bad fit at the time, and of course criteria #4 was not a fit (DAMN IT!). So I mentored Nikita in a different way than the rest. I helped her throughout the interview process as she was hunting for a job. Nikita is part of the B&G family.

*: I have kept individuals who were part of a failed story anonymous out of respect to the individuals. The failures aren’t theirs to own and that should not be part of their “online profile”, but they are B&G’s failures and I will continue to be transparent about them.