Idea Transcript
Eric Elliott Follow Compassionate entrepreneur on a mission to end homelessness. #jshomes Javascript, tech education, electronic music, photography, film, viral apps. Oct 14, 2016 · 13 min read
The Essential Guide to Building Balanced Development Teams
Balanced Rocks — Ronel Reyes (CC BY-NC-ND 2.0)
According to StackOverflow’s 2016 Developer Survey, participating in a mentorship program is more highly correlated with job salary than a PhD, and devs value learning new things over other job motivators like building new things, believing in the company mission, and promotions. Good mentors can help manage most of the top challenges developers face on the job, including: •
Unrealistic Expectations (by understanding when and how to push back & manage expectations when the management process is faulty)
•
Poor Documentation
•
Inefficient Development Processes
•
Fragile Code Base
Senior mentors play an indispensable role on development teams. But it’s hard to find true, qualified senior developers with the experience to guide a team well. Take a good look at your team. Does anybody have more than 6 years’ experience building production apps at scale? Do your team members feel like they have a trustworthy guide and mentor who continually pushes them to improve their craft? If the answers are “no”, you’re really missing out. There are lots of reasons that good mentors are hard to find and retain, but it starts with the team management. There’s a lot you can do to build a much more efficient and much more well-rounded team that developers will be excited to be a part of for years to come. In Silicon Valley, many engineers either move into management or drop out. That’s not just bad for senior developers. It’s bad for employers. It’s bad for team culture and morale. It’s bad for team productivity. And it’s bad for junior and mid-level developers who are robbed of great mentorship opportunities. If you’ve been in a software development role for very long, perhaps you’ve felt the pressure to move up into management. If you’ve decided that’s a route you want to take, it helps to get an idea of how to build an optimal team, and the culture to match. Building a well balanced team is an essential element of building a high velocity development team.
It Starts with People If you want to build something great, it starts with great people. Team building is about much more than hiring for the right skills. It also means finding individuals who will fit in with and balance the rest of the team. As a manager, it can be tempting to view other team members as cogs in the machine. It would be convenient if you could stick them in any position and expect them to perform according to your expectations for that position. Fortunately for everybody, that’s not how real teams work, so your first task is to learn to recognize in yourself the temptation to value your team members by the number of work tickets they close.
The single biggest mistake I see tech leaders make is to assess the value of individual team members by the number of tickets they close.
That mistake is the root cause of the number one challenge faced by developers: Unrealistic expectations. When you focus on an individual’s count of closed job tickets, you ignore the wider context of the project work and normal team dynamics, and the results can be disastrous: Poor morale, poor developer retention, and slowed productivity. In reality, there are two different kinds of developers, and your team needs both in order to deliver optimal productivity: •
Senior mentors with a deep understanding of application architecture and dev team productivity, and an ability to teach it to others.
•
Junior, mid level developers & individual contributors, whose jobs are to develop features or fix bugs under the leadership and guidance of their senior mentors.
Not all individual contributors are junior. Many are talented senior developers who simply prefer to focus on cranking out features and fixing bugs rather than get swept up in the complex dance of mentorship, setting management expectations, and people leadership. Startup culture in the San Francisco Bay Area tends to try to group everybody into group 2. That’s short sighted and wasteful. We’ll get to why in a moment. Let’s get a couple definitions out of the way: •
Senior: Somebody with deep understanding and proven experience building real applications at scale.
•
Junior: Somebody with limited experience or knowledge who is eager to learn and improve their craft.
“Senior” is not about seniority in years. I’ve met developers with 15 years’ experience whom I would classify as junior developers for the purposes of building teams, and others who have 2–3 years’ experience whom I would trust to architect a greenfield app from the ground up. That said, “senior” is definitely not something that happens overnight, and the skill scale is a broad gradient, not binary. Nothing can replace the lessons learned from years on the job. In Malcolm Gladwell’s book, “Outliers: The Story of Success”, he proposes that the 10,000 hour rule applies to many skills: It takes 10,000 hours of practice to achieve mastery of your craft. That means that a software developer requires about 6 years’ of practice to master the craft. This absolutely rings true to me. However, mere experience is not enough to ensure progress. In “Peak: Secrets from the New Science of Expertise”, Anders Ericsson & Robert Pool explain that practitioners must engage frequently in deliberate practice, where a learner works constantly on the edge of their abilities — a sweet spot where they feel both challenged and confident. Additionally, as a mentor and teacher, I have found many other aspects that can radically improve the learning performance of developers. In particular: •
Collaboration / pair programming
•
Code reviews
•
1:1 mentorship
If you want your team to improve quickly, you need to encourage those practices.
Why Your Team Needs Strong Mentors Some team members will be outliers in terms of their knowledge and their ability to craft architecture and set good examples for the rest of the team to follow. When they’re engaged in those activities, their contribution is a force multiplier, lifting the productivity of the entire team. In addition, these contributors will see more general solutions to common problems, and build tools that will help the rest of the team be more productive. (Other team members will, as well, but perhaps not as often). On a team of 6, if 1 member is a strong mentor with a force multiplication factor of 2, that means the remaining 5 will accomplish the work of 10. You may have heard the term 10x developer. Mentorship is the most realistic way to make a 10x contribution. You may be thinking that my math is wrong now, because don’t the other contributors deserve the credit for their 1x contribution? Maybe some, but it’s not that simple. The real number of developers you need to help to reach 10x lies somewhere between 5–10.
How to be a 10x engineer: help ten other engineers be twice as good. — @peterseibel
Let’s dig a little deeper. This part is hard for many people to understand or fully appreciate: A junior or mid-level developer may be able to close tickets. Maybe even quickly. However, the junior developer lacks the vision and experience to understand how technical choices they make today will impact the whole team productivity in the future. In other words, an unsupervised junior developer can be a fractional force multiplier, which creates a drag on the entire team’s productivity. Left unsupervised, junior developers will toss quick fixes in the general direction of every problem they face, frequently miss root causes, often cause regressions and fires, and leave heaping piles of technical debt in their wake. Junior developers will also frequently struggle with complex problems, pulling other developers away from their work to help out. Mid-level developers (typically with 2–5 years’ experience, remember, this is what many bay area job postings consider “senior”) will come up with working solutions to complex technical problems, but those solutions will tend to be complex themselves, and hard for other team members to understand, which also creates a drag on team productivity. Skilled senior developers will often come up with deceptively simple solutions to complex problems and teach other developers how to do the same. So, don’t hire juniors, right? Wrong. The junior developer may be very smart, and a very good learner. It’s simply a lack of experience and understanding that creates the negative drag effect.
In a mentorship culture with lots of pairing and code reviews, even novice developers quickly become great contributors.
But hiring junior developers without senior mentors for guides is effectively synonymous with stashing time bombs all over your code base.
The Real Danger When a development team encounters productivity challenges and large technical debt problems, it’s tempting to blame it on individual developers. “This one is closing 1/5th as many tickets as this other one, so clearly, that’s the problem, right?” Wrong. The root cause of tech debt is a management focus on short-term, microproductivity at the expense of long-term macro-productivity. When you let work byproduct pile up long enough, eventually it will clog the machine. Managers frequently make the mistake of thinking that ticket velocity can be used to judge the performance of individual contributors. That simply isn’t true. People don’t work in a vacuum. They work with each other. Your most knowledgable employees will quickly become the go-to mentors that everybody turns to with questions, and this is a good thing. That mentor/senior dev is responsible for keeping the machine clean and well-oiled, preventing clogs that will derail the whole team. But senior mentors won’t close a lot of their own tickets. Instead, they’re going to be focused on code reviews, unblocking the rest of the team when they encounter new challenges, and working to optimize the entire team’s long-term productivity. The thing that engineering leaders need to understand is that your most productive team members are often the ones closing the fewest tickets.
The force multipliers on your team would be wasting their time (and yours, and the rest of the team’s time) if they were acting like individual contributors, trying to close their own tickets quickly.
You don’t need your mentors closing tickets quickly. You don’t want your mentors closing tickets quickly. The last thing you want to do as an engineering leader is put pressure on them to do so. You need them helping the rest of your developers learn to architect the app in a way that allows the team as a whole to maintain smoother velocity. Bay area startups correctly value speed and agility very highly, but they’re terrible at understanding how to build a culture where speed and agility naturally flourish. They’re too focused on closing specific work tickets today to remember that it’s the culture of learning and mentorship that will ensure the long term health and stability of the aggregate team velocity & productivity going forward.
If you want to assess the value of a senior developer or mentor, instead of looking at individual ticket velocity, ask the other developers on the team how helpful that mentor is.
Another great way to verify that your mentors are being productive is to look at their code review activity. They should be conducting lots of code reviews full of great advice about how the code could be improved in material ways at the architectural level. A hallmark of an inexperienced reviewer is one who is focused more on inconsequential stylistic issues (semicolons, capitalization, whitespace, etc…). A great mentor will be teaching timeless software engineering concepts, design patterns, and how to write code that is easier for other developers to read and maintain.
Why Every Company Wants Senior Developers Every company wants “senior” developers because they correctly believe that senior developers will have a better understanding of how to build an application that is naturally resilient to the changing requirements of the customers and product managers. Senior developers are naturally less likely to produce mountains of technical debt as they close work tickets, and most will need less hand-holding to get up to speed on a new codebase.
Why Few Startups Have Real Senior Developers Our standards for what we mean by “senior developers” have shifted over the years. When I was just starting out as a professional programmer, it was very common to see job postings for senior positions requiring a minimum of 5, 7, or 10 years’ experience. Today in San Francisco, you’ll see similar roles listing a minimum of 2-3 years’ experience. Part of the reason for this change is because there is a shortage in the labor market for developers who not only have the requested experience, but also possess the knowledge and ability required to do the job. But we still have jobs to fill. So we hire people with a little less experience, give them “senior” titles, and hope it all works out. It won’t. As I mentioned above, experience isn’t everything, but when it comes to the role of a senior mentor, experience still matters a lot. There are some things that nothing but life lessons will really teach. There is a really big difference between senior on paper, and actually senior developers. A developer in the field 3 years lacks the real life experience of building multiple production apps at scale. They simply haven’t been in enough roles for enough time to see it happen more than once or twice. That means they don’t know all, or even the most common ways development teams get into trouble.
You can fill an ocean with the things a developer 3 years in doesn’t know they don’t know.
But we hire them anyway. Because they’ll do a good job at building stuff and fixing bugs, and that’s almost always good enough for a while.
Why Most Companies Struggle to Retain Senior Developers As I’ve just explained, a lot of the “senior” talent hired in the San Francisco bay area is not really senior. They’re less experienced developers willing to work for much smaller paychecks than real senior developers, who in San Francisco expect to earn north of $150k/year. A developer 3 years in will feel lucky to be earning $130k/year. The median salary of a software developer in San Francisco is just north of $100k/year. (Note to outsiders, that sounds like a lot, but in San Francisco, it won’t go very far after you pay rent). Many tech founders in the bay area are young themselves. When you’re young and free of attachments, you can afford to share an apartment with four roommates and take home a small salary while you hustle to raise funding rounds and hire other people. It may sound insane to a young founder to hire an “out of touch” developer for the same price they’d pay for 2 less experienced “senior” developers, and it may sound outrageous for a CEO to pay a senior developer more money than they will be taking home. Young startups typically view a true senior developer’s salary as “expensive”.
Ironically, what’s really expensive is running a team without any good mentors. Mentors improve the ROI of your entire development team spend.
San Francisco company cultures are frequently geared toward younger workers, including grueling hours & frequent after-hours company activities, such as parties, dinners, drinks, trivia nights, ping pong tournaments, and bbqs. Employees with families often feel like they’re not part of the company in-crowds when they opt to return home to families in lieu of attending such activities. If you want to better understand how to attract and retain great mentors, you should reach out to a good agent. Agents typically only work with established senior developers, and their full time job is to find ideal roles for senior developers. They can help you understand how to craft a working environment that senior developers will thrive in. Taking a job with a young startup isn’t the only option for senior developers. Experienced companies like Adobe, Google, IBM, and Microsoft value senior talent, and are willing to pay a premium for it. Google has famously lured developers of successful apps with millions of dollars worth of compensation. Microsoft recognizes that it needs both senior and junior developers, and aggressively recruits at both ends of the spectrum. Some senior developers get frustrated with the bay area job market and drop out of it, instead opting to build their own apps or start their own boutique software development agencies. Still others are simply baffled about why they are under-valued by the valley startups, and struggle to find work.
Why Every Company Needs Junior Developers When you treat every developer as if they’re senior developers you can trust with complete autonomy, what you end up with is a team that fails to learn from each other and grow together in skill and productivity. When you hire junior developers, you take it for granted that you’ll need to build a culture of learning so that you can foster junior developers and share experience among the whole team. This culture leads to more pair programming, more thorough, more productive code reviews (as opposed to trivial style nit-picks), and a lot less knowledge siloing. When team members mentor each other frequently, it takes them out of the head space of their individual work, which gives them a better picture of how their work fits into the larger context of the application. One of the large problems development teams face is that individual contributors tend to specialize in their little corner of the application domain (which leads to enhanced productivity when they work in that domain). But they do so at the cost of a productivity drop when other team members attempt to work on that part of the app. Aside from these benefits, teams need junior developers because nobody has told a junior developer that something is impossible. They’ll take on the impossible and sometimes find a way to make it happen, and they won’t be bogged down by “this is how we’ve always done it.” Perhaps the most important reason to hire junior developers is that it’s hard to find senior developers who really know what they’re doing. The hunt for a good senior developer can take many months, and it’s important to balance the opportunity cost of moving now vs moving six months from now.
Conclusion Why is it so hard to find good senior developers? Because we’re not fostering enough junior developers into the system. What we’re doing now is unsustainable in the long term.
If everybody only hires senior developers, where do new senior developers come from?
And if we fail to value true senior developers, who will mentor our fresh recruits? How will we pass deep knowledge to the next generation?
Level Up Your Skills with Live 1:1 Mentorship DevAnywhere is the fastest way to level up to advanced JavaScript skills: •
Live lessons
•
Flexible hours
•
1:1 mentorship
•
Build real production apps
https://devanywhere.io/
. . . Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and cofounder of DevAnywhere.io. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more. He works anywhere he wants with the most beautiful woman in the world.