Introducing the PAM Stack - a new framework for building sustainable, inclusive development teams

At This Dot Labs, we have the privilege of working alongside many talented junior developers through initiatives such as our Apprentice Program, and through mentorship events such as ngGirls. We've spoken with bootcamp graduates and self-taught developers. Despite the talent we see in these individuals, we regularly hear about how difficult it is to break into the web development industry.

At the same time, companies lament about how they can't find good talent to fill the many empty seats on their teams. These same companies talk about how expensive developers are, and how much attrition their teams encounter. We hear about how their projects are too important, their use cases too complicated, and their budgets too small to afford juniors. These companies bemoan the lack of diversity in their hiring pools, and in their teams. All the while, they turn their backs on juniors, which is one of the most diverse pipelines we have in this industry.

We endeavored to determine why juniors are struggling so much to find jobs, and why companies are so reluctant to hire juniors in the first place. What we discovered is that people feel juniors don't fit into their teams because of what the juniors lack (they need to much hand holding, the project is too complicated, bootcamps/CS grads don't team real programming, etc.). What these teams don't realize is that an inability to onboard and utilize junior level talent is actually a fault of their own.

Why teams fail juniors

The more we dug into this problem, the more we realized that the teams that best support junior developers also support their mid-level developers and senior developers as well. Some of the issues we found to most negatively effect junior developers are:

• Poor Onboarding Documentation - Juniors have no way to answer their own questions, so they're forced to ask for help on virtually every task. This makes the juniors feel inferior, and annoys the more senior developers.
• Reliance on Personal Excellence - On teams that require everyone to be personally responsible for making no mistakes, juniors require a lot of micromanagement or else mistakes end up releasing to the users.
• 10x Developer/Rockstar Developer Mentality - Teams focused on the highest performing members often lack an inclusive sense of camaraderie. These teams will freeze out junior members in times of stress to make more space for their rockstars. Spoiler alert: things are always stressful.
• No Review or Mentorship - Juniors need feedback to grow and develop into mid- and senior-level engineers. When there is no review or mentorship, juniors receive no feedback, and therefore remain stagnant, and learn nothing.

But these issues affect all other members of your team as well!

• Newly hired developers who do not have proper onboarding documentation will take longer to get up-to-speed. As a result, they sap more time from other team members in an effort to spin up and become effective. This forces teams to try to hire even more qualified engineers to try to trim down that spin-up time.
• Teams that rely on personal excellence are also crippled by "hit by a bus" fears. People become so critical to the development of particular parts of the application that teams fear projects would fall apart if those people left the team. This can create situations where those individuals feel they can do anything without consequence.
• Too much superiority leads to a lack of inclusion, which reduces the diversity of perspectives. This almost always results in a worse product for the end users.
• Mid-level engineers and even senior engineers need mentorship and feedback to grow in their own careers. Without this, these engineers will stagnate in their development and grow unhappy. Teams will be required to always hire from outside the company (at a severe premium), instead of hiring from within.

So, what does it look like when a team is truly supportive of all members on their team? What is the goal of the PAM stack, and our vision for successful teams?

• Success is person-independent, but team-dependent.
• Teams focus less on bikeshedding and irrelevant complexities, and focus on important user-centric features instead.
• A culture focused on innovation, excited about learning, and passionate about sharing knowledge throughout a team
• A wider, more diverse set of engineers, and skill levels on your team

Enter the PAM Stack

We looked at the teams that were most supportive of juniors. We saw that these teams were characterized by:

• Team members knowing what was expected of them, and what they could expect of others
• Applications structured in such a way that developers of all skillsets and experience levels could contribute meaningful and important work
• Cultures centered around mentorship, growth, exploration, experimentation, and sharing

These became the three pillars of the PAM stack: Process, Abstractions, and Mentorship.

Process

Too often, the activities of software teams are ad hoc, and rely on the individual excellence of team members. These teams struggle when things get stressful. Communication dwindles, technical debt grows, and important processes are simply ignored.

We advocate that when things are calm, teams should focus on defining their goals, the processes to achieve those goals, and how to handle the unexpected roadblocks that often pop up.

Well-defined processes are crucial to successful teams. They clarify expectations, improve team collaboration, eliminate single-points-of-failure, reduce stress when things get crazy, and even reduce conflicts and power struggles.

There are many ways to structure process on a project, and we don't advocate any particular solution as best. However, almost all processes follow a similar pattern:

• Define Expectations - When times are calm, write down what you expect people to do in various situations! Write actual plans!
• Describe How To Meet Expectations - Explain how to enact the plans! Checklists! Step-by-step directions! Training!
• Verify Expectations Are Met - Review all the things! Not just code! Review requirements, designs, meeting notes, process plans, documentation and client-facing documents! Have people in charge of running processes, and ensuring compliance!
• Record Results - Find meaningful metrics and keep them (ex: type of defects, code estimates planned vs actual, churn per sprint/release, etc.)
• Review Accomplishments Against Expectations - Evaluate your plans and your execution with the data you collected. Can you improve your execution? Your plans? Your metrics?

In future posts in this series, we'll dive further into each part of this process cycle. We'll describe how to write effective plans, how to pick useful metrics, and how to iteratively improve processes on your team.

Abstractions

There is so much to learn in modern web development. To deliver world-class experiences for our users, we ask our developers to be proficient in performance, security, accessibility, responsive design, progressive enhancement, browser compatibility, progressive web apps, and more! In conversation after conversation, we hear that complexity is a barrier to entry in our industry.

Therefore, we advocate the use of technologies that provide much of this complicated work for free out-of-the-box. Frameworks such as Angular, Vue, and React are amazing force-multipliers for junior and mid-level developers. They allow an ever-more-diverse set of developers to create powerful web experiences without needing to know exactly how everything is accomplished. These technologies are also well documented (with tons of training resources), which means it's easier for new team members to understand how to contribute to the application more quickly.

These frameworks often provide powerful CLI tools that help developers scaffold, build, and deploy applications with great performance and features. Gone are the days where teams needed to create bespoke Gulp and Grunt processes for every project. As with the frameworks, these tools have excellent documentation that really helps new team members get up-to-speed quickly, and get contextually relevant support for issues affecting their project.

We also advocate for the use of technologies, approaches, and libraries that isolate complicated business logic, or complex features, away from other concerns, such as building accessible semantic HTML and maintainable CSS. Along these lines, we support state management libraries such as NgRx, and state machine libraries such as XState. To reduce the complexity of UI development, we also support the use of design systems and component libraries such as material design and Shopify's Polaris. These tools help standardize the design and development of user interfaces, and often, these tools provide components that have accessibility, performance, and features built right in.

In future posts in this series, we'll dive deeper into each of these recommended approaches, and libraries, and explain how they help a team comprised of engineers with diverse skill sets.

Mentorship

The last pillar of the PAM stack (but certainly not the least important) is mentorship. The statistics on mentorship are head-turning. Engineers who are not mentored are significantly more likely to leave their team than those who are. Mentees are promoted at significantly higher rates than engineers who are not mentored. Interestingly, mentors also experience similarly elevated rates of promotion and advancement. Hiring is expensive, and on-boarding is difficult. It's significantly cheaper in the long-run to hire junior and mid-level developers and mentor them into the senior engineers, and architects, that your team needs.

To understand what it means to embrace a culture of mentorship, we ask people to consider what it would look like if people in your company could only be promoted if they found someone to take their place first. How would that change the way people interacted on a day-to-day basis? Suddenly, people can't just worry about "getting theirs". People have to look out for, mentor, and retain talented individuals so that they can eventually help them get promoted.

The cult of the rockstar developer fades. The cult of the rockstar mentor rises.

In future posts in this series, we'll explore how to set up a culture of mentorship; we'll show how mentorship always outpaces individual excellence; we'll walk through the different types of mentorship; and, we'll describe how to structure 1:1 sessions between mentors and mentees.

What can juniors do?

Sometimes juniors can feel helpless on teams that are not doing a good job of supporting them. However, there are some practical things juniors can do to start to affect change on their teams, even if the team isn't supportive. Ultimately, we suggest that people be the change they want to see on their teams. We advocate for juniors to ask questions, and contribute documentation where missing. Juniors should feel empowered to ask to review the code of others, and to ask people to help review their own code (even if informally).

In future posts in this series, we'll go deeper into some concrete strategies that have helped juniors sell their teams on a better way to build software, and teams. We'll discuss some of the common issues that different teams face that make some of the other PAM stack advice difficult (ex: how to implement mentorship when all developers are at the same peer level). Finally, we'll provide some resources to help teams get started.

Conclusion

We hope that this preview of the PAM stack has excited you. We're energized by the enthusiastic response we've gotten as we've shared these ideas with juniors across the country. We hope that whether you're the CEO of a new tech startup, a development manager building out a new team, a tech lead/PM managing engineers daily, or a developer still looking for their first job, you'll find this material engaging, challenging, and useful for building inclusive, sustainable development teams.

Need any help implementing the PAM stack on your teams? We can help! This Dot Labs is a web development consultancy focused primarily on front-end JavaScript development and mentorship. We can help review your team's processes, suggest improvements, and then work with you to implement them. Interested? Reach out to us at: hi@thisdot.co!