How does it happen that a fresh new product team can sometimes create tech debt before its first release?
I’m not talking about the normal growing pains of expanding a small area of code; I mean the really divergent patterns that make existing developers think “this is so off; why didn’t they talk to us?”. Maybe this isn’t an issue you’ve experienced, but for me, it’s been a consistent pain point with new product teams I’ve been on or partnered with over the last near-decade.
In this blog post, I will provide vague anecdotal observations and associated reasoning to support the following three tenants:
- Don’t deprive junior developers of senior developers (or vice versa)
- Don’t deprive new developers of area experts
- Don’t undervalue tech debt in long term planning
My intent is to describe how unfortunate situations and timing can force developers to make unfortunate choices they otherwise wouldn’t have made. Each anecdote is an anonymized amalgamation of real occurrences I’ve repeatedly observed and/or participated in.
Preamble: Junior verses Senior
When does someone become a junior developer after learning to code? When do they become mid-range, or senior, or staff, or principal, or whatever else? What counts as “experience”, and how do you measure it?
There is no one-size-fits-all answer to any of those questions. If you’ve started to learn to code, you’re a developer. For the sake of easier writing, let’s consider “junior” to be people who haven’t yet gained repeat experience effectively performing the tasks described below, and “senior” to be those who have.
1. Overstocking Junior Developers
Anecdote: two junior developers on a relatively new team were tasked with creating a new variation of an existing, tech-debt-heavy page. They gave an initial dev estimate, started working on code, and quickly realized they’d need help to overcome a greater-than-expected amount of existing tech debt. They met with an experienced developer who gave advice on how to overcome that debt. Under perceived pressure to complete the assignment, however, they copy&pasted several folders of legacy code and edited them for the new page variant.
Some requirements of developer project planning are inherently difficult when you haven’t already planned multiple projects. Writing RFCs, accounting for existing technical debt, updating stakeholders — you want to give people help when doing these for the first time. A healthy development team should pair its junior and senior developers together on advanced tasks such as project planning and architecture changes. Only a fool would “blame” the intern or junior developer from the anecdote.
Amusingly, every time I’ve seen this happen, the developers went above and beyond their role in attempting the rewrites, and deserved commendation for their efforts!
I’m not saying junior developers shouldn’t participate in or even help lead major new investments — practical experience is a great way to build seniority. Nor am I saying junior developers can’t build big things — they can and should. I’m saying no developer, regardless of experience, should be given challenging tasks without an active support network.
Time and time again I’ve seen new developers given advanced tasks without adequate support, struggle to meet unrealistic goals, then blame themselves. What an effective way to burn out your new developers! At the very least, when tackling larger tasks, new developers should be paired from the start with a more experienced developer who can assure them the assignment should be treated as a safe learning exercise.
Understocking Junior Developers
Similarly, it is unhealthy to have too many senior developers on product teams. While some teams -such as platform owners- might need many years of experience in each developer, most product teams are excellent opportunities to give your senior developers experience in mentoring juniors. Just as you don’t want juniors to be impeded on their own, you also don’t want seniors to stagnate in their knowledge sharing, intaking fresh new ideas, and ability to create understandable architectures.
Junior developers provide a fresh perspective to a team that should not be underestimated. If you don’t think you need them, or if you don’t think your teams have time for them, I question you sharply.
2. Understocking Area Experts
Anecdote: an existing team onboarded a set of contractors to help them create a more advanced version of their existing pages. The contractors were given a large, discrete chunk of the project. After their code started to land into the main branch, other teams noticed it didn’t use existing design system components or recommended logical patterns. Eventually the project was scrapped and code deleted for being too difficult to integrate with existing areas.
There is no such thing as a “Greenfield project” in software development. In an existing organization, there should be established precedences and guidelines around how to structure code. Even in a brand new organization, the first developers already have existing areas of familiarity that should inform early technical decisions.
When an organization adds new developers, it is unhealthy to ask them to create code before onboarding them onto the existing guidelines and structures of the team. To truly onboard an developer onto a team takes months or more of having them work in the existing codebases with the existing developers. Thus, it is unhealthy to spin off a new team solely with new team members, regardless of their general experience level.
When you match area experts with developers new to the organization, both sides benefit. Area experts can inform the new developers on existing areas of investment and/or tech debt that should be factored into their work, along with why structures were set up that way. New developers can bring fresh ideas and a healthy set of skepticism to a project, then work with the area experts in improving code accordingly.
3. “Aggressive Goals”
Anecdote: a new team worked with upper management to propose what could be created in a year given company priorities. Resultant business goals and OKRs were based on a very optimistic version of that timeline, referring to internally as “aggressive goals”. The team opted to start product work quickly instead of writing RFCs or laying groundwork with platform owners. Additions to existing code were made quickly and added an above expected amount of tech debt, the cleanups for which were added to the team backlog but not started on before launch.
Deadlines can be useful for getting a team to hustle effort and prioritize effectively. There are certainly many good justifications for a fast pace: critical business needs; proving a team’s value; acquiring early user experience data to inform later experiments; … But at what point does adding early tech debt for the sake of speed no longer worth it?
Introduced tech debt can be costly immediately after or even during a project. The earlier an architecture is rushed together or a “temporary” measure introduced, and the longer until it is cleaned up, the longer it negatively affects the system around it.
In my experience, referring to team goals as “aggressive” sometimes implies pushing the team beyond what it would normally be comfortable achieving. I’ve been burned too many times by a perceived urgent need for release followed by long periods of inactivity. Over time, this is not healthy.
If these statements interest you, I would highly recommend reading Slack by Tom DeMarco, which includes excellent points on how overly aggressive goals contribute to inefficiency and team burnout.
Conclusion
Mistakes in organizing large groups of people, developers or otherwise, are inevitable. I hope you can be well equipped to predict and mitigate some common pitfalls after reading this blog post:
- Don’t deprive junior developers of senior developers (or vice versa)
- Don’t deprive new developers of area experts
- Don’t undervalue tech debt in long term planning
In conclusion: if you’re setting up a product team, make sure it have a healthy mix of junior and senior developers, a healthy mix of fresh faces and area experts, and realistic timelines to strive for.
Many thanks to the excellent John Reilly for proofreading and discussions in the creation of this blog post, as well as my esteemed Codecademy coworkers: in particular Calla Feucht and Matt Schiller. You can see the full discussions on this pull request.
Liked this post? Thanks! Let the world know:
