> [Don't] Personally fix bugs and ship features. You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end.
How do you write code without fixing bugs and shipping features? What do you mean by tiebreaker?
> How do you write code without fixing bugs and shipping features?
What I meant here is that you have to fix an occasional bug and ship an occasional feature, but only in order to remain an effective tiebreaker. Fixing things is no longer your primary job. During crunch time new managers often feel that the best way to help the team is to dig in and fix things themselves, but in reality they can help much more effectively by doing other things.
So fix an occasional bug, but remember, you're only doing it to stay in tune with the codebase, not to ship things faster.
> What do you mean by tiebreaker?
I'm talking about making decisions when half the team thinks "we should do X" and the other half thinks "we should do Y". If the team can't reach consensus someone has to decide, and as a manager, that's you.
No, it's a spectacularly bad thing. Unfortunately most dev cultures assume that it will always be necessary. In pretty much all cases it's a management failure.
But yet there's a day when you're ready to release, and therefore need to coordinate with engineers on monitoring the release and fixing last-minute bugs and dependencies, with ops on deploying the release, with marketing on writing a blog post, and with sales on communicating the features to the customers.
This day could be called "crunch time" even if no external deadline is handed down.
How do you write code without fixing bugs and shipping features? What do you mean by tiebreaker?