4 ms·

That sounds like a quick way to shut down collaboration across the team...

ekoontz 5y ago
I think in the some cases like people mentioned above, it's no longer collaboration but more of a consultation. The benefit is only going in one direction: to the consultantee. In that case, you need some way to make the nature of that relationship explicit and valued. Otherwise these consultants begin to feel they're being put in a position of working for someone else without management recognizing that and compensating it as such.
egman_ekki 5y ago
...and get shit done. I mean come on, who asks a person in another team to help with a regular expression. There has to be a line somewhere. You can be a go-to person for an obscure technology, some complex framework, but being a go-to person for regular expressions? What's next? Go-to person for iteration?
- phailhaus 5y ago
  How are you supposed to get work done on a team, if any question asked to another team member is immediately seen as "unproductive"? It's not just about regexes. I'm having trouble debugging a system, who do I ask? Nobody, apparently, because if I do then I might incur a "bill" from my own coworkers!
  - DaiPlusPlus 5y ago
    You wouldn't be logging time spent on stuff that's part of your actual responsibilities and/or for your same team (under the same manager) is fine - the whole "internal market" stuff applies to inter-team work, especially work/asks/tasks that don't go through the chain-of-command (i.e. from IC1 in team A to IC2 in team B without going through either Team A's manager nor Team B's manager).
- squeaky-clean 5y ago
  When I joined it was about 15 employees. When I left it was about 150 (but still under 30 devs) so this wouldn't really be reasonable. But part of the problem was they did know simple enough regex for what they wanted to accomplish. Having a few simple regex and some application logic around them would have done it. But they'd often think "that sounds messy, squeaky-clean can probably solve this in a single regex." And while I probably could, it would not be good code nor would it be more performant.

I think in the some cases like people mentioned above, it's no longer collaboration but more of a consultation. The benefit is only going in one direction: to the consultantee. In that case, you need some way to make the nature of that relationship explicit and valued. Otherwise these consultants begin to feel they're being put in a position of working for someone else without management recognizing that and compensating it as such.

egman_ekki 5y ago

...and get shit done. I mean come on, who asks a person in another team to help with a regular expression. There has to be a line somewhere. You can be a go-to person for an obscure technology, some complex framework, but being a go-to person for regular expressions? What's next? Go-to person for iteration?

phailhaus 5y ago
How are you supposed to get work done on a team, if any question asked to another team member is immediately seen as "unproductive"? It's not just about regexes. I'm having trouble debugging a system, who do I ask? Nobody, apparently, because if I do then I might incur a "bill" from my own coworkers!
- DaiPlusPlus 5y ago
  You wouldn't be logging time spent on stuff that's part of your actual responsibilities and/or for your same team (under the same manager) is fine - the whole "internal market" stuff applies to inter-team work, especially work/asks/tasks that don't go through the chain-of-command (i.e. from IC1 in team A to IC2 in team B without going through either Team A's manager nor Team B's manager).
squeaky-clean 5y ago
When I joined it was about 15 employees. When I left it was about 150 (but still under 30 devs) so this wouldn't really be reasonable. But part of the problem was they did know simple enough regex for what they wanted to accomplish. Having a few simple regex and some application logic around them would have done it. But they'd often think "that sounds messy, squeaky-clean can probably solve this in a single regex." And while I probably could, it would not be good code nor would it be more performant.