I love building companies and I love building inclusive teams. So today we're gonna talk about something called the P MS A, it's inclusive arch architecture and we created this because, you know, we really do believe that there needs to be a framework for actually creating sustainable development teams.

Uh If you're not a developer and you're listening, this is also just really good for building inclusive teams generally as well. So what is Pam stack? Pam stack is basically process abstractions and mentorship. So these are kind of the three pillars that Pam Sack is made out of and we're gonna be exploring these through the talk. Uh Today, we're gonna talk a lot about, you know, how inclusive architectures enable juniors because just in the, you know, in development and I I, you know, in tech generally, right, like you're seeing a lot of underrepresented folks come in, women come in uh as junior developers.

So we do talk a lot about how, you know how companies and teams can make places more inclusive for juniors. Uh some of these things, you know, some of these things will include less maintenance. So creating a good code base that is not just reliant on a handful of senior developers. How do you create less stress on your team, more retention, you know, help save the company money. Uh How do you create easy conflict resolution? How do you create generally a more approachable code base so that you don't have to spend top dollar on every head count um lowering the cost of the project. How do you increase development speed by using the right tools? And of course, more inclusivity which helps juniors actually get hired, right? Because your team can actually, you know, support them. So, uh like Anna said, my name is Tracy. I'm the CEO of a company called the Do Labs. We are hiring, it's so much fun. Um We're a team of about 50 developers. We're 100% global worldwide. So you don't have to necessarily be anywhere. Uh We're also remote. I love that I will never go back. Um And it's just a really awesome team. I think the reason is because we, you know, even though work is work and we're helping companies do really amazing things through consulting. We really believe in helping uh underrepresented folks get into tech.

So we have a really strong apprentice program uh that everybody really gets back by and believes in. There's a lot of mentorship within the company. I'm also on the RXGS core team, Google developer, expert Microsoft MVP, and I just do a ton of stuff for the community with the community. You can always find me on Twitter at Lady Elite and don't be scared to just message me and say hi. I'm always happy to ask uh answer any questions. So let's just talk about this idea that juniors are not successful in your teams. This happens a lot in development teams where it's like, man, we can't, we, you know, juniors just, you know, aren't successful for some reason. Right?

But a lot of times it's actually not the fault of the juniors, it's actually the fault of the teams, right? A lot of people believe that, hey, juniors don't succeed because of X, but it might actually be because of the teams. If you don't make inclusive decisions in your codebase, people can't understand it easily uh structure in the team is the team structure, right? Um Some of these might be early reasons for failures when juniors start your team. But you know, these decisions of, you know, uh complicated code bases or structures of teams actually affect everybody, not just juniors. Um Here are some great examples of why juniors fail. So if you have co onboarding documentation, juniors have to ask for everything, there's nothing they can reference on their own is that their fault, no individual excellence, right? So if you're just relying on a handful of seniors and seniors have to micromanage juniors to make sure they don't make mistakes, it gets annoying. Uh If juniors make mistakes, it directly affects users uh which is not good either, right? So also complex code base, you don't need to overcomplicate things when doing development and design. Um Are you using the right abstractions that help, you know, juniors succeed on code base uh and helps the rest of your team be more productive?

Those are questions to ask and you know, another thing, right? I mean, there's this idea that like, hey, if you just hire the most amazing people, nobody needs help, right? So with juniors, that's really hard as well. If you don't have that culture of mentorship and review, then you know, nobody wins and you know, again, this hurts everybody. It's not just the juniors. Uh If you have bad onboarding docs, it's hard to onboard people, uh individual excellence, then you have these hit by the best fears. People are really experienced all of a sudden that person leaves, what do you do? You know, you can lose tons of time, um complex codebases. Like if things are hand rolled, you're not using a framework, then it's really difficult for anybody to get productive. Uh There's this one team that, you know, they say that it probably takes about a year for somebody to be productive on a codebase. Can you imagine hiring somebody and then not feeling comfortable for an entire year working on a project that's wild, but that happens a lot. Um Also, you know, if you don't have mentorship, then senior developers are just gonna leave. Architects are just gonna leave because you're not trying to develop and treat people from within. So, talking about PA MSEC, we'll go through a process first.

Um If your team sounds like this and I, I see this a lot in larger organizations uh where the success basically depends on the confidence and heroics of the people, not unproven processes, right? It's like, oh my gosh, we have to launch something. Uh you know, Rob can do it, you know, we need him, you know, that shouldn't be the way things are. There should be a good process in place to where everybody can be successful. And it's not just about that one individual person. Uh if you have a good process done, right? That means there's clear expectations, nobody's fighting about things, uh team engagement, co-operation, everybody understands what they're doing, who's responsible for what single points of failure. Hopefully, you don't have that as well.

Somebody can go on vacation, how nice uh everything's documented and backed up uh less of stress, right? When you really need to launch something and it's like, oh my gosh, so stressful, like that doesn't need to happen. Um Better process will help that also reducing those conflicts and power struggles, right? Like no politics, whatever it's all written down, everybody knows um an easy way to start developing process is to create plans. So when you're doing something, you can ask what needs to be done.

How are they gonna be done? When should it be done? Et cetera, et cetera, write those things down and follow them. Even as a junior developer, you can start doing this as you learn. Even as a new team member, you can start doing this as you learn and incorporate that into a process, uh something like uh you know, this code review right here, right? You write the purpose down like who's responsible for what, what happens when there's disagreements, right?

So again, no office politics, it's just written down. It also helps like with a ton of the bias within an organization as well. Um defining roles and responsibilities. This is also really important because uh in a process, if you say, OK, you know, peer reviewers are for this observers are for this au authors are for this, this is for, you know, um submitting uh pr and review your pr then again, everybody knows what they're doing, creating checklist.

I love this because joining a new team, like sometimes people just like know what they're supposed to do, right? But if you know what you're supposed to do and you're trying to scale your team, you're trying to bring on junior developers, anybody uh this is difficult. So for example, like maybe um you know, submitting APR, there's actually like 10 things you need to do and everybody on the team just knows that, right? If you join a team or if you're a junior developer, whatever you can actually, as you're learning, create checklists, even if you're on a general team and you just feel like, hey, let's let's make people less stressed out. These are awesome, right? Like maybe Friday, you know, you're ready to check out, you need to submit something and oh my gosh, you have a checklist so you don't have to keep worrying about it. You don't have to spend as much mental energy um reviewing everything as well, right? Like everybody needs review uh to make sure that their work is good. So it'll improve quality, cross pollinating ideas, um redundant learning, right? So if you can share different parts of the codebase and review each other's code, then everybody will understand the codebase better, which is amazing.

And also, you know, as individuals, if we feel like we have reviewers, then you know, things won't be so stressful, right? Because maybe something minor will be caught by another person. Um You don't just have to do code reviews, meeting notes, designs requirements, all these things are so important emails to clients to again make sure that everybody is actually on the same page and saying the same thing and agreeing to the same thing as you kind of start with, you know, this first pillar of the P MS A process, it's really important to, you know, start improving things and then say, ok, you know what we added a few of these things, maybe we added like these five processes.

Now, how do we do? Can we improve it? Um How do we improve our processes? Uh Should something change, you know, do we add annoyance or not? Right. There's so many different things to think about here to continuously, you know, think about how to improve your team as an organization abstractions are also really important that this is the second pillar of the PM stack. So we're gonna talk about a few tools abstractions and approaches that are gonna help your team be happier. So web development is just hard, you know, every year we need to learn something more and it can be difficult to get to, you know, the right level of success these days, right? Which leads to Java for fatigue. This is junior developers, mid senior, et cetera, et cetera because the web keeps changing. But the great thing is that there is such a rich ecosystem of frameworks, right? Like, you know, doing raw do manipulation, like might be faster if you're a senior developer, but you're leaving juniors behind, right?

So um a great example is, you know, I remember when I was trying to learn how to code and I was like, OK, I know this html cs S javascript thing. Look at these cool things I can like put on my website. Oh my gosh, this is so cool. And then I learned angular and literally overnight I was able to actually build like professional websites, some of which are still up today right after like two weeks of learning how to code. So I think that's like super amazing. And uh you know, if you're trying to learn how to code, I mean, you know, everybody has different ways. But if you're a team, like definitely choosing the right framework and if you're learning, trying to learn how to code, definitely choosing a framework as well to, to learn.

Um the reason why firms are so good is because of the amount of effort they put into everything. So AMP is a firm developed by Google. And if you just look at this one tag, AMP image, that's all you have to use. OK. AMP image, right? It resizes it, it efficiency efficiently, loads it, it uh calculates things for you. Um You know, it makes it more performant uh content can be displayed at the place older. I mean, it's so crazy. But imagine if you just had an image tag and you didn't use the framework, you wouldn't have all this magic here. And that's why again, it's so powerful. Another thing that I could never live without and that teams should definitely be using are COIS right? Because, you know, we can do all the things ourselves. Um I personally never have because that's not the life I wanna live. Um And you know, teams should really consider this as well. Scaffolding a new project is really easy. Their config environment smart defaults out of the box performance, uh lazy loading trees, shaking ahead of time compilation, right? Like these are actively maintained. Um It's easier to migrate documentation is there life is awesome. So teams that aren't using cois highly recommend migrating to AC O I typescript is also beautiful and amazing. Um It's so great because it helps you understand your codebase better, right? You can understand the functionality of a project better. There's stricter rules which means there's less bugs.

Um Life is awesome with typescript, right? Like there's better error handling, you can get to the root of the problem faster. You have descriptive errors. Uh I love typescript for juniors as well because it helps juniors learn. Uh and it make them more careful when designing new things and teach best practices. So highly recommend integrating typescript. A lot of teams are these days um other things, design components, uh design systems, sorry component libraries are super awesome. You should definitely look into them.

Anything you can do to develop, to develop like a framework and understanding of how to work together and simplify things is awesome state machines also are really amazing, great way to isolate your business logic. Uh A senior developer and architect can design out a state machine of like what the logic within an application should be and then give it to a junior developer to implement and you know that it will be implemented properly because the instructions were given to you. So we talked about process and distractions, but we haven't talked about mentorship. And this is one of my favorite things because this is actually a culture shift from within your organization. So when we think about mentorship, right, like you should think about this idea that no employee can be promoted unless they nominate somebody to be promoted into their role. Now, if you think about that way, then all of a sudden, it's actually not beneficial to become like the best on the team, right? It actually becomes more beneficial for you to find and mentor other people on your team to take your role so that you can be promoted. So this idea of like rockstar developers, faith and the idea of rockstar mentors starts to rise.

Um mentorship is obviously awesome for mentees, right? It accelerates your growth, increases confidence, increases your communication skills because you have to talk about code, right? Mentees feel invested in and valued. Uh There is more upward mobility as well. Um And uh for others, it's also really good because, you know, it turns out that mentors and mentees are actually 70% more likely to stay compared to other employees. Uh It has uh mentors, teach the mentees. So it reduces the knowledge s silos within an organization uh really in increases employee engagement as well. And you know, it helps identify leaders, which is awesome too. Uh There's so many different types of mentorship. I mean, there's technical mentorship, you can do professional instruction, you can talk about non technical skills, career development, uh radical camera feedback also very important if you haven't heard of that, definitely look it up. Um So those are some things. But I think uh you know, another thing is OK, well, you know, OK, fine. We think mentorship is good, but how do I actually add this to my team? So we talked about this idea of again shifting the what a developer actually is, right? So doing things like formal one on one sessions, code reviews, pair programming, tech, talk, creating chat channels where people can just like talk about web development generally, right? Is so important to actually just get the team to start talking about what they know and what they're excited about.

And that really again increases the the the engagement and the success of an organization and that is mentorship. So we talked about a lot of things today. Um But again, it can just be summarized into this idea of process abstractions and mentorship. Um So, you know, how can juniors actually help their teams? Right? This is a question that we get a lot again, start writing things down when you are being taught, things, sharing it with the team, you know, uh mentoring other people, helping your peers who are being onboarded, ask questions. Don't be afraid to ask questions about the project, the code, the process, document them and then share them with others, right? Like sometimes when we are on our projects, people are like, well, do you have a document to share with me about this project? And you know, a lot of times we did not. So now we do, but those types of things are really important. Um asking for code reviews, doing code reviews on senior level code. This helps you understand the code better get feedback and it creates a culture of mentorship, like up and down, that's very important and sideways. Um And if your team just loves that and what you're doing, then ask them to formally incorporate it into the process.