Welcome to the end of RailsConf. My name's Sumit Jain, and I'm the development director at Unabridged Software.

I'm gonna talk to you today about leveling up teams. This conversation of leveling up teams has been going on for a long time now. I think since the coming of coding schools, we have found repeatedly over the past several years to say nothing of the past three days a constant stream of ideas

is that we should value mentorship. That said, I don't think that anybody disagrees with that. Did anybody come to RailsConf thinking mentorship is worthless? And luckily, over the past three days, you've been convinced, finally, that mentorship is a good thing. Probably not. We all agree that mentorship is valuable.

Still, I'd say that life is harder for junior devs than maybe it ever has been. So there's some kind of a disconnect somewhere. What's the issue? Are we lying? Are we just secretly haters of mentorship? I would argue, actually, some of us are.

There's this idea, I think, for a lot of developers that our skill isn't Ruby, our skill isn't SQL or JavaScript. Our skill is that given enough time, we can solve any problem by ourselves. And so when we see that other developers need active mentorship to solve those same problems,

it's borderline offensive. And so it's worth considering, if you're building a mentorship program at your company, that that attitude may be somewhere inside of your developers, that this idea that you shouldn't need mentorship, so why should we work extra hard to provide it? That's probably a small minority of us.

I don't think that most of us identify with that attitude, at least consciously. For most of us, we just don't know how to mentor. There's a hopeful assumption that mentorship skills are in you as long as you've been doing this for long enough and as long as you're good enough at it. But they're not intuitive skills. Sometimes the very things that you think you're doing

that are going to be valuable mentorship to your junior developers are anything but. And so given that these aren't intuitive skills, I thought it would be worthwhile to at least talk about things you can do that over a long period of time or a short period of time, maybe you will slowly become a better mentor.

And these are not values judgments. In fact, many of these tactics might not work for you at all. I expect maybe, for some of you, none of these are gonna be that useful whatsoever. So I tricked you, you're here now, and it's rude to leave, so you're stuck with me. But ultimately, what I'm hoping

is not so much that you get direct value out of every single one of the numerous tactics I'm about to present. Mostly it's to consider this. I think you'll get more value out of debating the merit of the tactics to follow than you will from just taking this idea

that mentorship is good and letting that simmer. This passive idea that if you let that value simmer, you'll just become better at mentorship. To me, all that is is companies recognizing that mentorship has become a trendy value in the marketplace, and now they need to say that they're mentors. So you'll do better disagreeing with these tactics

and debating them amidst yourselves than you will just by taking the value of mentorship at face value. Okay, every time you see a fun picture, that's a tactic coming up. So the first one is provided you have a lot of questions being asked in whatever channels you use for questions, I would suggest codifying some format

for asking those questions. Probably this is done implicitly already because the pattern that I have in mind is inherent to everything we do as problem solvers, let alone engineers. I would say that you can lint a question in the same way that you can lint your Ruby or JSON or anything else.

The pattern that I think is the most useful for question asking is probably the one that you expect and you expect it because it's there in every single unit test you've ever written. Codify it, write it down. Tell your employees, your team members, this is how we ask questions now. What are you trying to accomplish? Give me steps. What did you expect to happen and then what actually happened, right?

This is not a revelation for any of you, I would think, because this is, again, what every test looks like, but the idea that you can make this an enforced format for every question before you answer the question, I think that there's power to that tactic. The reason I like this is because, first, it allows the question asker to slowly,

more methodically understand their question. Why are they struggling? Well, now they have to spell it out for you. Sometimes they'll even get the answer before they finish writing the question. The second reason I like it is that it gives you the mentor, the question answerer, a way to be helpful without jumping to the end

and just giving them the answer. As you help them formulate the question, because it's hard to do this a lot of the times for questions, but as you help them formulate the question in this way, you're being helpful. You're mentoring, but you haven't jumped to the end and saved them a stack overflow. Instead, you're walking them through the process of solving problems, probably similarly to how you do.

Okay, new image. I'm gonna kind of be rushing through these. Not rushing, but I'm not gonna spend as much time as you might think I will on each slide. Okay, I know Slack usage is a little bit controversial today. We're finding ourselves distracted, but if you're using some channel

for frequent communication, there's a good chance that that channel allows for private messages like Slack does. So what I'd like to suggest is a rule that you can't have technical conversations in Slack private messages. Anything that is technical. I mean, if you've got an HR concern, find a private channel, but if you have a technical

question of some kind, put it in a public channel or a private channel, but put it in the channel where all of the eyes for that team can see it. This does a few things. First, it exposes the most knowledge possible and pain points. There's a good chance that somebody else

is gonna have that same question if they don't already. Now, they don't have to ask it again and they've seen that question asking is something that this team does a lot of. There's something else that it does. If you're the team lead or in a position of leadership on the team, now you get to see what the most frequent questions are. And if you can see what people are repeatedly

asking questions about, that's a pain point and it might be something worth you investing some time in shoring up operationally or the documentation or something. But if you don't have this rule in place, your most insecure developers, the ones most in need of help are going to be reaching out to people privately and getting help

and now you don't see any of that. There's a sentiment about stupid questions that is probably so prolific that you could predict it without me even telling you all of it. It's everywhere. You hear people tell it to newcomers, to any industry, to any field.

It's a way to give them reassurance. You don't have to shout it out. I'm not gonna do one of those. All right, one, two, three, but mumble amongst yourselves if you feel like you know what this is. There's a good chance that you've heard this time and time again. I would argue it is a mistruth or at least a partial mistruth. There is such a thing as a stupid question,

if only because the asking of it makes that person feel stupid. It's not that the question is inherently a stupid question, but if somebody has a question that they don't feel empowered to ask, telling them, look, there's no such thing as a stupid question, that's not very helpful advice. Instead, let's accept the fact that as humans,

we have ego and there's really not much that a team can do to completely negate the impact of having an ego. And so instead of just telling people there's no such thing as a stupid question, give them a place to ask stupid questions. So why don't people ask stupid questions? You've got the Slack channel,

you've got whatever room is there for general technical questions, but people won't ask because it's not anonymous. For the ones that we feel the most insecure about, we don't want our coworkers to know that that's something we don't know. When we hear four other developers over there laughing hysterically about something related to the code base, but we don't even know what that thing is,

that's stupid question. Not because our actual ignorance is stupid, but again, it makes us feel that way. So where do you go? IRC. Train your developers on how to connect to Ruby, Ruby on Rails, whatever, but there are channels full of developers that at least in my experience are

maybe sometimes a little bit short, but helpful. It's an anonymous place where you can quickly get a new alias if you find yourself feeling too insecure to keep your old identity. It's a place where you can actually go and ask questions that nobody else should see from your perspective.

This doesn't mean that companies are off the hook, this doesn't mean that you get to hold a culture where people should feel bad for asking questions, but at the very least it gives your developers an outlet when there is something that they just can't quite muster the courage to ask. Okay, a little bit of a new frame then.

One of the misconceptions about new devs is that, or that many seniors can have that is, is that they're struggling with something due to a lack of coding knowledge. So when the junior and senior work together, the senior assumes that the thing they need to explain is related to how the code works

or related to how the Rails framework works. Aside from being unhelpful, that misdiagnosis can be particularly infuriating for the junior dev because, first, they're not struggling because of the API. I know there's nothing on the slide, by the way, if you're wondering. First, it's infuriating for the new developer

because that's not why they have that problem and so you're not being helpful. But second, it's also infuriating because now they're afraid that other people on their team underestimate them so much that they're explaining some basic part of the application. Junior devs often have enough coding knowledge to work their way through a problem.

What they're missing are business knowledge and tooling. Think about what the path is or what paths, plural, exist for getting unstuck when your problem is code. You can Google it. You'll find stack overflows, stick-a-binding.pri in it, even just brute force trial and error

and you sometimes will find an answer when your problem is code. What do you do, though, when your problem is that you have eight different classes and you understand every single one but you still can't solve the problem? What do you do when you know that a bug was caused by a form submission three months ago but you don't know how to get logs for that far back?

That's frustrating because you feel like you've learned the things that you're supposed to know by now but it's this extra knowledge outside of code that's holding you back. Business knowledge and tooling are among the most opaque parts of writing software to new devs. This knowledge tends to live just in the brains

of your senior-most developers and it's why we're so desperate to cling to them and we don't wanna lose them to any other company. It's because we recognize that code knowledge, while important, tends to be one of the first things that people get proficient with and we need to hold on to our seniors. So there's no silver bullet for this. This is a very hard problem to solve

but a couple tactics that might help. First, consider removing or at least documenting the abstractions that live in your application that are everywhere. I'll explain what I mean by this. It's unlikely that a new developer is very familiar

with anything beyond the Rails way of doing something in your application. So if your application is littered with patterns or abstractions that change how forms work, for example, it's gonna be frustrating for a new dev to jump in and find that what should be an easy task is actually now unfamiliar to them. Using cells or Draper for views or Virtus

for your form objects or other popular tools that speed things up in Rails for developers that know enough about it to get them, that's one thing but you're gonna have a junior developer that you tell very simply, go add an update action to that CRUD resource and they're like, yes, finally, I know all of those words. I can do this. And then they look at it and it looks nothing like

what they learned and that's because you have a layer of abstraction between standard development and your Rails application and that was never communicated. Maybe there's a small line at the top that includes a module that they're supposed to know totally changes how active record is gonna handle that one form but they haven't internalized

the Rails way as much as you have and as a result, it's just a frustrating process for them and now their self-doubt continues to bubble. These tools, these patterns, these things that we do to make the life of a senior developer easier, they're not inherently bad. I'm not saying you have to kill all of them. What I am saying is that if you're going to keep them,

you have to at least discuss the ramifications on new developers and how they'll take to your application. Either remove them or write something in a very clear place that tells new developers this is a change that we're making to how we develop Rails beyond your basic 15-minute blog.

Here's what you should check out to get familiar with it so that you can actually contribute. One of the reasons that you might be proud of your code base is that you have factored it down into very small classes that each contain a few concise methods. We often talk about how this makes code easier

to reason about, easier to test. All of that is true but a trade-off can sometimes be that it makes it really hard to get a macro-level understanding of what's going on that touches all of those small classes. Sometimes it's a lot of effort to traverse through the long chain of join tables

to figure out which one column needs to be updated. Again, there's no silver bullet to fixing this. Method documentation can help you understand the inputs and output of a single method but usually that doesn't help you with the high-level understanding of what that class is about. The goal with what I would call domain-level documentation

but the term is confusing, call it whatever you like, the goal is simply to make the macro-intent of smaller classes more explicit. The more testable, the more modular your code is, great, but for humans trying to get an understanding of the business logic driving the need for 18 classes,

that needs to live somewhere. Don't assume that 28 consecutive belongs to and has many statements, expresses the full intent of some class. Sometimes a paragraph at the top is a lot better. It's easy for me to say this standing up on this stage, go document all of the domains in your application,

go figure out a way to make the macro-level explicit, writing that out is a big job, I get it. It's not easy to document a complex system. That said, part of the reason why it's hard is because as engineers, we love to find the perfect data structure for documentation and that holds us back.

Are we gonna use this folder structure for our documentation? Should that big block of code comment go at the top of the class or should it be like a markdown file in a subfolder of app models? All of those decisions will eventually mean that you just don't write anything. A fix for this is using screencasts as documentation. Don't write it at all.

Take five minutes, record yourself talking about those 18 classes, explaining why those 28 consecutive association lines mean what they mean, and put that in a Google Drive. No elegant data structure, just five minutes if it ends up being six, no big deal. If it ends up being 20, honestly no big deal there either,

just try to keep it short. Record a video that explains to the viewer why this code exists and what it does. You'll make that in a literal five minute time period and you don't have to worry about where it goes, just stick it in a Google Drive. If you end up with a whole bunch of them, figure out the folder structure and stuff later.

Don't worry about figuring that out first. If you are so blessed as to have hundreds of documentation videos, you'll make time to put it into a folder structure. What else? Pair programming. Pair programming is great. If it's working for you, keep doing it. It's a wonderful technique. I have nothing bad to say about it except that sometimes it just doesn't work.

Sometimes it's hard to make it practical. Sometimes the gulf that exists between two developers' skill sets makes it so that pairing is just frustrating for everybody involved. Sometimes, sometimes the best thing is to just spend some time helping the more junior developer ramp up context

so that they are pairable. Instead of pairing, consider, just for a while, watching other devs work. Let go for this time for a short while that we need to have equity between every single one of the developers on our team.

If it's just not possible, then you're not doing anybody a favor by trying to force it in. You can get a lot out of watching a more experienced developer just do their job, not really even expecting them to teach you anything. Just sit next to them for 20 minutes, two hours, whatever's comfortable, just watch them.

Sometimes experienced devs don't even have the awareness of how much they know. And so they can't teach you it because they're not even aware that they know it. So their unconscious competence is now a barrier to teaching. And so instead, just let them watch. Sit somebody next to you and consider

all the things that they are learning that you would have forgotten to call out directly if you were trying to teach them. How you phrased that Google query. The manic but methodical way that your mouse moves around technical documentation because you've learned to intuit where the meaningful bits are gonna go.

How you organize your screen, shortcuts you use in your code editor. How you debug in production by grepping for the unique ID of some record. Things that, again, you would just do but now they're seeing you do it. And as very intelligent pattern detectors, you'll find that they are picking up on a lot of what you're doing without even realizing it.

Amidst all of this chat about training and mentorship, it's easy to forget about the after. After you've got a team that is suitably leveled up,

don't lose them. Stick on to your talent. You invested in them, hopefully, and you want them to continue to grow within your company. These are big topics. So tactics for these could be really an entire conference unto themselves. But a couple things that I think are useful, especially within the context of junior devs

in this industry, affirm the hire. This is a difficult field that we've all chosen. Every day we solve problems that feel just a little bit beyond our abilities and then somehow we find a solution anyways. We've learned to live inside of that fear,

uncertainty, frustration, and it's very engaging work. But it's very difficult work. And for a junior developer, sometimes that job is double difficult because they're doing it while also trying to silence a raging self-doubt that they don't actually belong on your team. And if you just ignore it and pretend that that's not

there and let their smile tell you the full story, then you're missing out on a big part of the dynamic inside of your team. It is such a small action, but for some of your more insecure new hires, or really just for all of them, in your one-on-ones, simply saying you were a good hire

could go miles just to let them know that though they may have self-doubt, they're a good part of the team and things will get better eventually. But at least you've mitigated to some degree this idea that they're afraid that they should never have been hired in the first place or that they're gone as soon as you find somebody a little bit more competent.

That fear will be in them and it'll be easy for you to ameliorate it. This one's a little bit harder to explain. Let me paint a picture. Five devs on a team. There's the boss, three experienced devs, and then one newer developer.

Every day, everybody works hard, but of course, like with a lot of teams, there's a bit of gift sharing and Slack and there's some chit-chat in the hallways about unrelated things. When that happens, usually it's the three experienced devs that are doing most of the gift sharing, most of the chit-chat, right?

If you're a more junior developer in the audience, you're probably gonna relate to this one person, right? The more junior developer. If you're maybe a tech lead or an engineering manager, maybe you're thinking you're the boss. Whatever you are, consider that as the story finishes. The three developers are enjoying themselves, chatting, taking their breaks. It's not like they're doing a bad thing, wasting time.

It's part of the acceptable amount of the day that we want people to waste, 20 minutes, 30 minutes, whatever your culture might be, four hours. And so, the question is why isn't the boss joining in and why isn't the junior dev joining in? And the reason, maybe, could be that the junior developer won't join in

because they're afraid that if they are seen to be having fun, that the secret's out. The reason they're getting just one story point done every sprint is because they're having too much fun hanging out with everybody. They don't wanna seem like they're enjoying their job. They wanna be like the boss who's heads down all the time working through the day.

And so, there are a few fixes to this. One is better communication on your team. Tell people that it's okay to waste time, that they should have breaks as part of their day. Some teams are better about this than others. Some teams are really good at doing this without saying anything. It's just part of the personality or the ethos of the people leading the team. But think about what it is for your team

and at least be deliberate about it. I would say, though, that the best fix for this doesn't come from any of the employees. It comes from the boss. If you're an engineering manager and you feel like you are always heads down and you feel like the tone that you're setting on your team is one that taking 20 to 40 minutes out every day for a break is no good,

add five minutes to your calendar every single day to deliberately waste time with your employees. Just see what happens. Give yourself that break. You probably need it too. A lot has been said and written about investment time. I've written a little bit longer of an article about this, which if you wanted to learn more

about my thoughts on it, you could read, but just a couple things here that I wanted to point out. If you're not familiar, investment time is at some companies, like Fridays every lunch, they'll lecture on some gem that they're learning about or something like that, but it's any kind of extracurricular, so to speak, work that's done and supported by the company.

I'm a fan of it, but I think that sometimes teams squander opportunities to get the most out of investment time. Mostly, this has to do with failing to prioritize depth over breadth. Most of the investment time that I hear about is things like, oh, on Friday,

I'm gonna have, we're gonna have lunch brought in, and one of our devs is gonna talk about a new JavaScript framework that they've been tinkering around with. But the problem is that developers don't need another avenue for getting breadth added to their world. They're getting that already. Breadth of tech ecosystem is being flung at them from every direction.

Depth is elusive. How do you factor depth building into your investment time? I think before I talk about how you would do that, a quick point about this is that if you were to talk to the people on your team who do have depth, talk to your most senior developers, ask them how they got that way.

Did they read some article that gave them depth? Did they read eight articles? Did they read 800 articles that gave them depth? I doubt it. Most of the developers on your team that have depth got it because at their previous job or previous previous job, they were the only dev and they needed to learn some skills. And so it's irrational to expect anybody else

to build depth any other way. You have to create an environment where your less senior devs are gonna be confronted by the need to build that depth. So give them a long-running project. Give them something big to build that isn't gonna have stakeholders

breathing down their neck the whole time. Let them work on it for a long time. Let them launch it and let them find that there are issues with scaling it or let them add some of those patterns that end up being prolific across the app and see how they fare with them. But let them do whatever you would have the other senior devs do

and just don't let the senior devs touch it because this is something that's meant to provide depth to the newer developers, not breadth. So I would really reconsider the learning lunch approach because as much fun as it is and it's good for team bonding, it might be sacrificing an opportunity to add depth to a team and instead just doing an easier, let me introduce you to one gem per week

type of mentality. And finally, if you are gonna do this, try to allocate enough time. Two hours every Friday for lunch is just not enough. First of all, it's two more context switches in the day. Mostly it's just not enough time to really write any code to get deep in anything. So give it a full day if you can.

Leveling up your developers continues as you want them to become bigger parts of the industry. If you want your developers to eventually come to conferences and speak, you can have them start to write prose. Every time they implement something new at your company, have them write a tutorial about how they did it.

So one of them implements Elastic Search in your application, great. Have them write a blog article about that process and then stick it on the company blog. Benefits of this are actually pretty numerous because for one thing, when you are writing something for the first time or implementing a new utility for the first time, you're probably just following

some kind of paint by the numbers implementation of it, but you're gonna miss some things. And when you write an article, it forces you to crystallize what you've just learned. Also, your more senior devs can do a technical edit of that article and find that there are things you should have mentioned but didn't. And maybe that's a gap in the knowledge that the junior developer has.

It creates documentation. Every time you do this, that's internal documentation that explains for that application why we used this pattern or this library. And of course, as I mentioned, it builds authority. Your junior developers, your senior developers, everybody's gonna benefit from boosting their personal brand. Your company as well can benefit from that.

Some of the most well-respected companies at this conference as Ruby consultancies made a lot of their authority through the writing of these blog articles. Maybe they do great work. Maybe that work is not meaningfully greater than everybody else, but that brand is untouchable.

This is the last one I've got. People in general, and engineers specifically, are very, very good at gleaning wisdom from patterns. And so, for example, how you manage a meeting, if that's what you're doing right now, how you manage a meeting probably has a lot to do with how meetings were managed at your last two jobs. Nobody ever sat you down and said,

Alec, let me teach you how to manage a meeting, step by step, right? Probably, you just saw it done. At some point, somebody asked you to do it, and then you did your best to confidently recreate what you had seen for many years. And that's how we train our managers. At some point, some of your devs will want

to become tech leads. And instead of having a more abrupt transition into that role, just let them audit those meetings now. Let your devs see what it looks like inside of a mock-up review session. Let them see what a sprint planning meeting looks like. Let them see what it looks like when stakeholders are a part of it

and how the tone changes all of a sudden. Give your devs the opportunity to have extracurricular knowledge being built, and slowly, they'll start to bring other people up with them as well. I probably should have switched to this slide before, but this is what I just said. At the end of the day, like I said,

this is not about here's a playbook, go follow these things exactly, and now you have a mentorship-driven team. What I'd really prefer is that you ask yourselves and ask your team if these are things that would be useful for you, and sometimes they won't be, but that debate, I still think, would yield more value than just thinking to yourself,

mentorship, we need to be it. That's not gonna give you a lot. Disagree if you'd like to, but at the end of the day, this is gonna give you more return than anything else. I mean, I said no values judgments, but this is at least one. Your junior devs are probably more competent than you give them credit for, and if you try to help them without listening to them, there's a good chance that you're just gonna frustrate them,

miss the mark on what they're actually asking you, and every time you do that, you make the next session of pairing, the next instructional session, harder. So debate this stuff amidst yourselves, but also listen to your devs as you continue. This is something I started working on just today.

I don't know if it's gonna be useful or not. This is not the actual thing, but it's a screenshot of the various tactics that I've talked about today aligned with some of the values that I think they might provide, like questioning format might help other people become better mentors. This is about a fourth of the table,

which I haven't actually styled up much yet, but it is on my website, so if you wanna look at the whole thing, you can look at it. Your Xs might go in different places than where I placed them, but again, the point is to mostly talk about it, not to just take this as a concrete plan of action. If you do want to look at slides, they're up now,

and if you want to talk to me, good luck. I'm gonna be leaving for a flight pretty soon, but you can tweet at me at cemetjane. As I mentioned, I'm the development director at Unabridged Software. We're in Omaha, Nebraska. If you are looking to hire a consultancy or if you're looking to work at a consultancy, let me know, and I'd love to put you in touch with the right people.

That's all I've got. Thank you.