[bradarner]

Don't do this to yourself.

There are 2 fundamental aspects of software engineering:

Get it right

Keep it right

You have only 4 engineers on your team. That is a tiny team. The entire team SHOULD be playing "offense" and "defense" because you are all responsible for getting it right and keeping it right. Part of the challenge sounds like poor engineering practices and shipping junk into production. That is NOT fixed by splitting your small team's cognitive load. If you have warts in your product, then all 4 of you should be aware of it, bothered by it and working to fix it.

Or, if it isn't slowing growth and core metrics, just ignore it.

You've got to be comfortable with painful imperfections early in a product's life.

Product scope is a prioritization activity not an team organization question. In fact, splitting up your efforts will negatively impact your product scope because you are dividing your time and creating more slack than by moving as a small unit in sync.

You've got to get comfortable telling users: "that thing that annoys you, isn't valuable right now for the broader user base. We've got 3 other things that will create WAY MORE value for you and everyone else. So we're going to work on that first."

[MattPalmer1086]

I have worked in a small team that did exactly this, and it works well.

It's just a support rota at the end of the day. Everyone does it, but not all the time, freeing you up to focus on more challenging things for a period without interruption.

This was an established business (although small), with some big customers, and responsive support was necessary. There was no way we could just say "that thing that annoys you, tough, we are working on something way more exciting." Maybe that works for startups.

[bradarner]

Yes, very good point. I would argue that what I’m suggesting is particularly well suited to startups. It may be relevant to larger companies as well but I think the politics and risk profile of larger companies makes this nearly impossible to implement.

[dakshgupta]

All of these are great points. I do want to add we rotate offense and defense every 2-3 weeks, and the act of doing defense which is usually customer facing gives that half of the team a ton of data to base the next move on.

[bradarner]

The challenge is that you actually want your entire team to benefit from the feedback. The 4 of you are going to benefit IMMENSELY from directly experiencing every single pain point- together.

As developers we like to focus. But there is vast difference between "manager time" and "builder time" and what you are experiencing.

You are creating immense value with every single customer interaction!

CUSTOMER FACING FIXES ARE NOT 'MANAGER TIME'!!!!!!

They are builder time!!!!

The only reason I'm insisting is because I've lived through it before and made every mistake in the book...it was painful scaling an engineering and product team to >200 people the first time I did it. I made so many mistakes. But at 4 people you are NOT yet facing any real scaling pain. You don't have the team size where you should be solving things with organizational techniques.

I would advise that you have a couple of columns in a kanban board: Now, Next, Later, Done & Rejected. And communicate it to customers. Pull up the board and say: "here is what we are working on." When you lay our the priorities to customers you'd be surprised how supportive they are and if they aren't...tough luck.

Plus, 2-3 weeks feels like an eternity when you are on defense. You start to dread defense.

And, it also divorces the core business value into 2 separate outcomes rather than a single outcome. If a bug helps advance your customers to their outcome, then it isn't "defense" it is "offense". If it doesn't advance your customer, why are you doing it? If you succeed, all of your ugly, monkey patched code will be thrown away or phased out within a couple of years anyway.

[FridgeSeal]

Whilst I very much agree with you, actually doing this properly and pulling this off requires PM’s and/or Account Managers who are willing and capable of _actually managing_ customers.

Many, many people I’ve dealt with in these roles don’t or can’t, and seem to think their sole task is to mainline customer needs into dev teams. The PM’s I’ve had who _actually_ do manage back properly had happier dev teams, and ultimately happier clients, it’s not a mystery, but for some reason it’s a rare skill.

[bradarner]

Yes completely agree. This is hard for a PM to do.

I’m assuming that the OP is a founder and can actually make these calls.

[dijksterhuis]

the reasons PM stuff is ‘hard’ in my, admittedly limited, experience often seems to come down to

- saying No, and sticking to it when it matters — what you’ve mentioned.

- knowing how the product gets built — knowing *the why behind the no*.

PMs don’t usually have the technical understanding to do the second one. so the first one falls flat because why would someone stick to their guns when they do not understand why they need to say No, and keep saying No.

there are cases where talking to customer highlights a mistaken understanding in the *why we’re saying No*. those moments are gold because they’re challenging crucial assumptions. i love those moments. they’re basically higher level debugging.

but, again, without the technical understanding a PM can’t notice those moments.

they end up just filling up a massive backlog of everything because they don’t know how to filter wants vs. needs and stuff.

— also i agree with a lot of what you’ve said in this chain of discussion.

get it right first time, then keep it right is so on point these days. especially for smaller teams. 90% of teams are not the next uber and don’t need to worry about massive growth spurts. most users don’t want the frontend changing every single day. they want stability.

worry about getting it right first. be like uber/google if you need to, when you need to.

[johnrob]

I thought you made the rotation aspect quite clear. Everyone plays both roles and I’m sure when a bigger issue arises everyone becomes aware regardless. Personally, I like this because as a dev I can set expectations accordingly. Either I plan for minimal disruption and get it, or take the on call side which I’m fine with so long as I’m not asked to do anything else (frustration is when your expected to build features while getting “stuck” fixing prod issues).

[rkangel]

> You've got to get comfortable telling users: "that thing that annoys you, isn't valuable right now for the broader user base. We've got 3 other things that will create WAY MORE value for you and everyone else. So we're going to work on that first."

Yes, but you've got to spend time talking to users to say that. Many engineering teams have incoming "stuff". Depending on your context that might be bug reports from your customer base, or feature requests from clients etc. You don't want these queries (that take half an hour and are spread out over the week) to be repeatedly interrupting your engineering team, it's not great for getting stuff done and isn't great for getting timely helpful answers back to the people who asked.

There's a few approaches. This post describes one ("take it in turns"). In some organisations, QA is the first line of defence. In my team, I (as the lead) do as much of it as I can because that's valuable to keep the team productive.

[ramesh31]

To add to this, ego is always a thing among developers. Your defensive players will inevitably end up resenting the offense for 1. leaving so many loose ends to pick up and 2. not getting the opportunity for greenfield themselves. You could try to "fix" that by rotating, but then you're losing context and headed down the road toward man-monthing.

[CooCooCaCha]

Interesting that you describe it as ego. I don’t think a team shoveling shit onto your plate and disliking it is ego.

I feel similar things about the product and business side, it often feels like people are trying to pass their job off to you and if you push back then you’re the asshole. For example, sending us unfinished designs and requirements that haven’t been fully thought through.

I imagine this is exactly how splitting teams into offense and defense will go.

[FridgeSeal]

> For example, sending us unfinished designs and requirements that haven’t been fully thought through

Oh man. Once had a founder who did this to the dev team: blurry, pixelated screenshots with 2 or 3 arrows and vague “do something like <massively under specified statement>”.

The team _requested_ that we have a bit more detail and clarity in the designs, because it was causing us significant slowdown and we were told “be quiet, stop complaining, it’s a ‘team effort’ so you’re just as at fault too”.

Unsurprisingly, morale was low and all the good people left quickly.

[dakshgupta]

To add - I personally enjoy defense more because the quick dopamine hits of user requests fix -> fix issue -> tell user -> user is delighted is pretty addictive. Does get old after a few weeks.