←back to thread

210 points dakshgupta | 1 comments | | HN request time: 3.011s | source
Show context
bradarner ◴[] No.41841731[source]
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."

replies(4): >>41841863 #>>41842117 #>>41842527 #>>41848369 #
dakshgupta ◴[] No.41842117[source]
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.
replies(2): >>41842280 #>>41843454 #
1. johnrob ◴[] No.41843454[source]
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).