Goldblog
GitHubSiteTwitter

Team Construction Pitfalls

January 23, 2021

The Death of Socrates (painting) The Death of Socrates: the "gadfly" of Athens [source] ā€œI know that I know nothing.ā€ - Socrates, paraphrased by Plato, paraphrased

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:

  1. Donā€™t deprive junior developers of senior developers (or vice versa)
  2. Donā€™t deprive new developers of area experts
  3. 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 occurences 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

Hamsters swarming
Despite the context, these are not implied to be junior developers. They're frontend developers being shown a new framework. [source]

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.

Aladdin and Jasmine on the flying carpet
How "senior" developers feel explaining why their opinions are best. [source]

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 scepticism 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:

  1. Donā€™t deprive junior developers of senior developers (or vice versa)
  2. Donā€™t deprive new developers of area experts
  3. 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.

Josh GoldbergHi, I'm Josh! I'm a full time independent open source developer. I work on projects in the TypeScript ecosystem such as typescript-eslint and TypeStat. This is my blog about JavaScript, TypeScript, and open source web development.
This site's open source on GitHub. Found a problem? File an issue!