DEV Community: Rob Ocel

This Dot Labs Engineering Levels

Rob Ocel — Tue, 10 Mar 2020 23:45:00 +0000

Introduction

There are many different qualities that make software engineers successful. Each company has their own unique set of needs regarding developer skill sets and seniority.

As we continue to grow in numbers at This Dot Labs, we’ve begun to ask ourselves what qualities we most look for in developers, what traits exemplify our conception of a senior engineer, and how we can drive mentorship at the company with clear guidance about how every employee can work towards their next promotion.

We’ve decided to share our thoughts with the community in the hopes of spurring conversations among your team. If you haven’t mapped out a career path for your engineers, we hope that you take the time to start talking about what that would look like. A clear purpose at work leads to higher employee satisfaction and retention, better outcomes for customers, and overall lower costs across the board. It’s truly a win-win-win!

What’s a senior engineer, anyways?

Titles are a funny thing. We know that they’re important. They convey responsibility, status, and achievement. When you’re applying for a job, it can really matter if your previous roles say “senior engineer” or “architect” instead of simply saying “developer”.

However, I’ve known people that tout their CTO experience of the small startup they co-founded, or brag that they were the Senior Architect of their 3 person company. Do their experiences match the experience of other CTOs or Senior Architects? Not necessarily.

More important than titles is what a person actually accomplishes at their job or enables for their customers or team members. Therefore, we think there’s a difference between the title “Senior Software Engineer” at a company and the concept of a senior engineer (as opposed to a junior or mid-level engineer).

Outside of the context of titles, we consider the journey from a junior engineer to a mid-level engineer to be a journey of learning. You gain knowledge by learning the software development patterns, rules, and how-to. The journey from being a mid-level engineer to becoming a senior engineer is a gain in wisdom. You learn how to transcend the rules and how to deliver value to your customers however you can with a strong knowledge of tradeoffs.

We’ve known “Software Developers” who were mid or senior developers, and we’ve known “Architects” who might still be mid-level in the grand scheme of things.

Rob Ocel

@robocell

@ladyleet @sarah_federman @burgessdryan IMO, the junior->mid journey is a gain in 'knowledge'. You learn rules, tech, how-to. The mid->senior journey is a gain in 'wisdom'. You learn how to ask why, when to break rules smartly, and how to deliver results, even if the solution isn't as fancy.

01:28 AM - 14 Nov 2018

11 106

We want the difference between engineers and senior engineers to really mean something at This Dot Labs. Here are the key distinctions we make as our developers become senior developers:

Culture Stewardship - As developers make the leap to senior developer, we expect them to take an active role in promoting and improving the company culture. We want people to take ownership of their part in making the company culture vibrant, interesting, and inclusive. Building developer communities is in the DNA of This Dot, and we want our senior engineers to exemplify this both internally and externally.
Team Focus over Individual Focus - Mentorship is another thing that we take seriously both internally and with our customers and the community. Whether it’s the fact that every employee at This Dot Labs meets regularly with a mentor (and may have mentees themselves), that we invest in our Apprentice Program that helps women get their first job in tech, or that we offer training and mentorship to all of our clients as a key differentiator in our projects, we value the ability of our developers to help others grow, learn, and be successful. We expect our senior engineers to not only be responsible for their own performance, but also to make sure that everyone on their teams are fully successful as well.
Customer Awareness - Our senior engineers take a larger role in interacting with our customers on a daily basis. While all of our engineers work alongside our customers, and we center our customers in all of our work, our senior engineers are responsible for managing client expectations, establishing strategy, deciding milestones, and setting a good example for the other members of the team. At the end of the day, This Dot Labs is a software consultancy, and giving our customers a positive return on their investment in us is critical to our success.
Business Awareness - Many of us develop software both as a career and as a passion. However, we have to remember that we’re also operating a business that all of our employees rely on to support themselves and their families. Therefore, as our developers transition to more senior roles in the company, they are responsible for more of the financial success of their projects and the company at large.

Why not just hire all senior engineers?

At This Dot Labs, we love to talk about our PAM stack. In the PAM stack, we discuss that teams with junior, mid, and senior level developers are more successful (and cheaper) than teams made up of exclusively senior engineers.

A big reason why this is true is that our senior engineers are often asked to operate at a higher level of abstraction. Our senior developers think at the team or organizational level, consider both our internal staff and external customers, and have to consider both the technical and financial ramifications of their work.

We like to think of this in terms of something like Google Maps. If everyone is looking at the Google Earth view, you’ll miss a lot of details. But, if everyone is looking at the StreetView level, then you’ll miss a lot of context. We need people at different zoom levels to be successful as a company.

It’s important to have the right blend of developers. The right blend of developers means having people who are not only focusing on different levels of abstraction, but that those developers feel fulfilled in their career when focusing on those tasks. This is the value of having engineers of many different levels on your teams.

Introducing the This Dot Labs Engineering Ladder

Here is how we’ve decided to break down the engineering roles we currently have available at This Dot Labs. It’s important to also note that we’re a growing, primarily web, primarily JavaScript, primarily front-end, framework agnostic software consultancy. For now, we have a single-track ladder, but we’ll continue to revise and expand this in the future as our teams grow in both size and complexity.

Apprentices - Let Me Google That For You

Our apprentices are getting their first experiences working professionally as software developers. We expect our apprentices to participate in team activities, processes, and the company culture. Otherwise, we expect them to work under the supervision of other developers and/or mentors to complete tasks. Our apprentices are great and growing developers, and usually they have deep expertise in other fields before coming to software development. The extra support given for those in this role is to ensure our apprentices have successful first development experiences, which are so vital to getting more roles in the future.

Software Engineer I - Street View Developers at the Software Engineer I level are expected to participate in the company culture, write and test their code proficiently, work closely with other engineers to accomplish tasks and implement features, and to attend and contribute to all team meetings and processes.

These developers are able to deliver routine tasks on-time with limited supervision. These engineers are working with their mentors to learn software development patterns, best practices, and the software development lifecycle.

Software Engineer II - Neighborhood View Developers at the Software Engineer II level are responsible for all of the same things as those on the Software Engineer I level, but with a little more complexity and scope. These developers are responsible for helping guide and mentor more junior developers and apprentices. These developers are able to write and test code proficiently, but with a greater knowledge of design patterns, approaches, and libraries than more junior developers.

We expect these developers to deliver moderate tasks and features on time with little supervision. These engineers are working with their mentors to learn about software architecture, even more development best practices, and team leadership in preparation for becoming more team focused senior engineers.

Senior Software Engineer I - City View Developers at the Senior Software Engineer I level are responsible for activities at the team level. These developers are responsible not just for participating in the company culture, but they are relied to contribute to and improve it as well. These engineers have knowledge of several design patterns and architectural solutions.

These individuals are able to deliver significant features on time with little supervision. These engineers can work as either the lead engineer or technical lead of a client project. With their mentors, these developers are working on software architecture, team leadership, and soft skills. These engineers often mentor junior engineers and apprentices.

Senior Software Engineer II - State View Developers at the Senior Software Engineer II level are different from engineers on earlier levels in two significant ways. First, they are responsible for mentoring not only internal developers but also client developers, while also working with clients to define new features. Second, they are responsible not only for delivering excellent work under little supervision, but also helping a team to deliver their features on time as well.

These developers have advanced knowledge of coding standards and architectural approaches. These engineers not only attend and contribute to team meetings and processes, but can also lead those activities as well.

They are capable of operating as the technical lead on a client project. With their mentors, these developers are focused on team leadership, soft skills, and strategy. These engineers are responsible for mentoring engineers of all levels and the apprentices.

Senior Software Engineer III - Country View Developers at the Senior Software Engineer III level contribute significantly to the company culture and are recognized as leaders by their peers. These engineers regularly mentor other developers both internally and externally.

They have a deep knowledge of various frameworks, libraries, and architectural patterns backed with significant experience and wisdom. These developers work with team stakeholders to define new features and project strategy. Not only can these developers lead team processes and meetings, but they embody a spirit of process improvement.

These developers are focused on how to embrace quality and consistency across different project teams. They are capable of operating as the technical lead of multiple projects or the technical and project manager of a single project. These developers can manage and grow successful teams with little supervision. With their mentors, these engineers are focused on strategy, relationship management, and entrepreneurship.

Architect - World View At the moment, architects are the highest level in the engineering ladder at This Dot Labs. Eventually, it might become necessary to split the role up into more granular levels. However, developers at the Architect level contribute regularly and significantly to the company culture and represent the company in a public capacity.

These developers regularly mentor other engineers (both internally and externally), including senior engineers. These engineers have subject matter expertise in technologies, methodologies, processes, and/or patterns critical to the success of our customers. These engineers are responsible for contributing to the sales work of the company including the scoping of new contracts.

These developers are responsible for driving process improvement at an organizational level. They can operate as the technical manager, project manager, or client relationship manager of one or multiple projects. These engineers are able to drive organizational initiatives to success with little supervision. With their mentors, these engineers are focused on senior leadership, strategy, relationship management, entrepreneurship, and sales.

Conclusion

Having documentation like this on-hand is critical to the success of our mentorship relationships at This Dot Labs. People have a better understanding of what is expected of them, what they can expect of those around them, and how they should focus their goals and work to reach the next step in their careers.

We hope that this look into the engineering team at This Dot Labs will spark interesting and useful conversations on your team. If you like anything that you’ve seen here, please feel free to reuse any of our descriptions.

Additionally, if you’re looking for development work or even some help in setting up your own mentorship processes and establishing an engineering ladder for your own team, reach out to us at hi@thisdot.co. We’d love to work together with you to tailor your products and processes that transform your team, your corporate culture, and improve outcomes for your customers.

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

Rob Ocel — Thu, 19 Sep 2019 20:44:31 +0000

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.

Volunteering at the ngGirls event in Kansas City

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

Bikeshedding - Developers favorite minimally productive pastime

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.

Popular, well-documented, feature-rich CLI tools are available for all frameworks and stacks

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!