Can You Really Build a Product With Hard Single-Stack Developers?

Snazzy buttons? Sorry, not my job mate!

Today, we’re going to talk about working with developers, but I wanted to take a second to talk about working with the sales team.

Saeed Khan and I are running a new course for B2B product managers - “Working with Sales - Masterclass for B2B Product Managers”. It’s part of Maven’s “Maven 100” event, and you can get 25% off the ticket price until the end of Sunday 9th June. It’s late notice, I know, but go grab it while it’s hot. Otherwise, grab it anyway!

Ok, on with the newsletter…

---

I ran this poll recently to see what sort of developers product managers were working with. The results came out differently from how I thought they would, but they got me thinking about the best “type” of developer for a product team.

Credibility Disclaimer: I’ve worked as various flavours of developer before going all-in on product management. I started my career programming green screen dumb terminals before graduating to front-end web development and eventually full-stack web applications.

What is a stack?

Good question! Before we argue about the pros and cons of full-stack and single-stack developers, we should define what a “stack” even is. Not everyone’s a techie after all!

If we keep it simple and talk about web-based SaaS products, we can logically split the application into some core areas, each of which we can consider a “stack”:

• Front-end - all of the stuff that runs in your users’ web browsers and provides them with an interface to interact with.

  • Popular front-end frameworks and libraries include Angular, React, Vue and 150,000 other frameworks that seem to pop up daily. These all ultimately end up as JavaScript in a user’s browser. Some people still stick to raw JavaScript or jQuery (🥰) but most modern product developers will use a library or framework.

  • This code is generally served from your servers, but executed in the user’s web browser. All of the code is ultimately visible and accessible to the end user.

• Back-end - all of the stuff that runs on your servers and deals with retrieving, updating and storing data, as well as the business logic that runs on that data.

  • Popular back-end languages include NodeJS, Java, Ruby on Rails, PHP, .NET and many, many more.

  • The code is hosted and runs on your servers and the front-end will interact with it in a controlled manner, generally through some form of API that gives CRUD (Create, Read, Update, Delete) functionality.

• Database - the nuts and bolts of storing and managing the data efficiently and performantly.

  • Popular database servers include MongoDB, PostgreSQL and many others.

These are sweeping oversimplifications and there are lots of edge cases, but they are sufficient for the sake of argument.

Types of Developers from my Pie Chart

Let’s go back to the categories that I asked about in my poll:

• Full-Stack Developer - a developer who, broadly speaking, has expertise across all of the stacks and can comfortably work on all aspects of a feature.

• Soft Single-Stack Developer - a developer who strongly prefers one stack, but will happily dabble in other stacks if the need arises.

• Hard Single-Stack Developer - a developer who can literally only work on one stack and, in some cases, will actively reject working on or learning about other stacks.

Remember, based on my poll, 22% of respondents work with "Hard Single-Stack Developers”. I’m going to go out on a limb here and say that these people are going to have the hardest time making products.

The Everlasting Feature Request

Consider the following scenario. A product manager needs a new feature developed. Let’s assume that they’ve done all the relevant discovery and scoped the feature as tightly as possible. It’s all down to the development team now!

Not all development will touch all stacks (for example, that annoying broken animation on the submit button is front-end only) but most features will need to touch everything. Let’s imagine that this new feature requires some front-end UI work and needs to pull data in from the back-end to present it in an interesting way. Users can then interact with it and potentially change data on the back-end. All in all, this is a very standard use case seen by product managers across the world on a daily basis.

This product manager is working with a team of hard single-stack developers. This automatically means that this feature is broken into two or three separate chunks of work with totally different people required for each chunk, and everything will be stuck together at the end. The development team needs to collaborate on what needs to be done by whom and the order it needs to be done in. Detailed technical specifications will be written before the work can be started.

The front-end team works on the UI and the back-end team works on the API. After it’s all done, it gets wired up and… oh no! Someone missed something in the specification, or the format of a field is not as expected, or the API endpoint needs to have an additional field added to it.

Whatever the root cause, the application isn’t working as expected and it needs to be fixed. The front-end developer refuses to touch the API and the back-end developer is busy working on something else, so now we have to wait. Everything is blocked but, eventually, the back-end work is done. However, now the front-end developer is working on something else!

The cycle continues for days, weeks or months. Eventually, after several rounds of back and forth, the feature is finally completed.

By the way, I’m not making this up for fun… this scenario has happened to me several times in my career. It’s also totally avoidable.

Why Product Developers Shouldn’t Be Hard Single-Stack

I’m very much in favour of full-stack developers and strongly believe that all product developers should be competent enough across all stacks that are needed to take a feature from end to end.

This doesn’t mean that I want everyone to be a jack of all trades and master of none. Expertise is valuable! Experts can help with the hardest decisions, coach their colleagues on best practices, help with thorny issues and much more. However, if you have developers flat out refusing to touch anything that isn’t “theirs” then this can lead to:

• Product managers getting dragged into engineering management

All of a sudden, product managers need to deeply care about the capabilities of every developer in the team and, in the worst cases, start writing explicit front-end and back-end tickets or assigning work to individual developers.

• Everything slows down due to dependencies and (lack of) availability

If you need multiple people to work on everything then you’re inevitably going to hit scheduling conflicts. This means that every feature you develop will take longer than it has to. You also end up having to over-specify all features because, otherwise, you’re probably getting it back half-baked. Welcome to mini-waterfalls!

• Developers start to understand the entire product less

It’s hard to have a holistic end-to-end picture of how a product works if you’re only working on bits of it. This can lead to suboptimal solutions because one part of the team doesn’t really know how the whole product works, or what it’s used for. In the worst companies, it can lead to blame culture and tension between the teams.

• Developers start to understand the users less

It’s hard to empathise with or understand your users if you are disconnected from them. This is something that, to be fair, can affect back-end and database teams more than front-end teams, although I’ve found that all of them can suffer from this to some extent. In any case, this lack of user understanding can make it hard for engineering teams to come up with delightful solutions to their problems.

How to Fix It

Well, ultimately, product managers and even product leaders aren’t generally responsible for technical hiring decisions, but we can certainly make a case for what’s not working.

• You need good Engineering Managers

I mean, all companies should have good engineering managers, but they’re even more critical in companies with hard single-stack developers. These engineering managers can help bridge the gap between teams, resolve dependencies, and ideally help to shift attitudes. The engineering manager should be comfortable talking about and working with all stacks. Work with your engineering leadership to get the right managers in the right teams.

• Product Managers should focus on the user requirements

In hard single-stack situations, it’s very tempting for a product manager to start deeply caring about who needs to work on what. They may even start writing back-end tickets and front-end tickets. God forbid, you might even have “As a front-end developer…” bastardised user stories.

This is not a product manager’s job! Your job is to focus on the user requirements. Developers can deconstruct these requirements as they fit and write as many tickets as they need to manage their work internally. Remember, product managers aren’t responsible for managing developers.

• Factor dependencies into your planning

All estimates are fallacies, and hard single-stack estimates are even more so. There’s no getting away from it: If you have so many hand-offs in your development process then you have to assume that everything’s going to take way longer than even a pessimistic estimate. Keep your scope as tight as possible and, if pushed on dates, go longer than you expect.

• Get ALL the developers into some customer calls, or at least show them the videos

To be honest, even the hardest-hearted “headphones on” hard full-stack developer still has the same fundamental human desires as the rest of us. I’ve seen many an engineering team visibly delighted when watching real feedback from a real user who loves the product. When you’re stuck in one stack, it can be hard to empathise, so give them every chance to.

• Make a case for team change

To be clear, there’s nothing wrong with having a few hard single-stack people, but only if they’re experts in a certain thing that you need experts in. Remember, expertise is good! But, ideally with the support of engineering managers and the CTO, you need to make the case for change.

Every hard single-stack developer you have will slow you down. Do make sure to keep track of when things fall apart, not to name and shame people, but to help build a case for change. At the very least, try to start nudging those hard single-stack people into the soft column!

---

Podcast episodes catch-up

Here are a couple of podcast episodes to catch up on:

Firstly, I spoke to John Cutler about the Instagram-ification of product management, and how we’re all being made to feel bad by impossible standards and should make peace with product management instead.

This is a subject that’s dear to my heart and I definitely recommend listening to this one on your favourite podcast app, the podcast website or YouTube:

Secondly, I spoke to Nils Davis about product management resumes/CVs and how people aren’t showing their best side to recruiters. In this job market, putting your best foot forward is essential.

Check the episode out on your favourite podcast app, the podcast website or YouTube:

---

Thanks for reading

If you enjoy my content and want to keep in touch, here are some ways you can do that

Follow me on LinkedIn

Join my Slack group

Join my Virtual Networking weekly calls

Join my real-life London meet-ups

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions (although I’m considering a cheap, paid tier). In any case, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!