5 ms·

"It’s hard to do anything there because for any idea you propose, three or four teams will run in shouting that they own that, you can’t touch it, and oh by the

"It’s hard to do anything there because for any idea you propose, three or four teams will run in shouting that they own that, you can’t touch it, and oh by the way, they’re not working on it for a few years. Microsoft calls this “cookie-licking”, and it’s obviously not good, but it’s very common there. I’ve heard from folks at other big names in the area that a lot of companies have this problem. And it’s ironic, because there’s an infinite amount of work to be done, and yet somehow it’s entirely covered by their existing staff, with no room for anyone to do something new. It’s pretty crazy." I work at Fitbit and I'm very glad that cookie licking is not prevalent here.

vanderZwan 9y ago
For now. This is a kind of cultural shift that happens when companies grow. It doesn't happen overnight, nor does anyone actually want it to happen. But in practice it seems to nearly inevitably creep in. I'd love to read more about reasons why, and what can be done about it.
- aaron-lebo 9y ago
  Maybe these orgs are just too damn big. Google is 75k people, MS 124k. Those are on the small side, I can't remember which tech company, but they're at 600k. They're also chained to stock prices and earnings. They can't commit to any product for any sizable length of time. I'm gonna preach it until I try it or die and figure out it doesn't work, but my genuine belief is these companies are too big to effectively function or to counter threats. If your company population is a small town, how many middle managers do you have? Tens of thousands?
  - tenaciousDaniel 9y ago
    Not necessarily a tech company, but I worked at Disney for a few years. They have about 500K employees. It's such a large company that their own companies sue each other. Like, our team couldn't use some Disney IP because we had to have our legal team clear with their legal team. That's when you know a company is too big. Edit: by "their own companies" I mean all of their subsidiaries.
    - gamblor956 9y ago
      Using another company's IP would always require a legal agreement... Size and common ownership are irrelevant.
    - digi_owl 9y ago
      Could have sworn i read about Sony, via intermediaries, sued itself. This because Sony both produced media devices with a record/copy capability, and content.
  - fauigerzigerk 9y ago
    If they are too big to effectively function or counter threats then how did they get that big in the first place? Clearly size has benefits that compensate for some of the undeniable downsides. It's almost a tautology. Also, look at the great organisational and cultural variety among big companies. Size is not the only thing that defines organisational complexity and effectiveness.
  - digi_owl 9y ago
    Would not surprise me if it hits somewhere around 150 or so, as that is supposedly the number of people we can directly keep track of in our heads.
- zerkten 9y ago
  Part of it is about changing the incentives and how people are "paid" for their work in large organizations. What drives performance for individuals or groups within an organization, isn't necessarily going to ensure that the organization as whole operates without friction. For me, this fits under the topic of "alignment" that leadership teams in large organizations talk about, but many people are ignorant to, especially when coming from acquired startups. If you decide that identity (user management, directory services or whatever broad feature) is a core service and put a group in ownership of that then every other team may end up with a dependency on that group. Initially, pooling resources seems like a good idea, but it becomes the critical path and they end up taking more and more incongruent feature requests as the rest of the organization grows. Eventually identity are a bottleneck, but are challenged with feature request brokering between other teams. Relative to other groups in the org identity becomes this monster team and you are left wondering if it should really be one group, or include leadership from other parts of your organization to ensure it can account for all requests and more effectively broker.
  - candiodari 9y ago
    And then you, as a high level manager, throw the rudder entirely the other way. Now every department, or even every team has their own account database, their own chat, their own ticket system, their own crm, their own docs, and everyone else gets locked out of all of those.
matt_s 9y ago
It'll come at some point, even from your own team perhaps. It occurs when there are two teams that have a common need and one of the teams has deep knowledge of the space and maybe has a working POC but is too busy with other work to do anything. The cookie is licked at that point unless the culture is that the team with the POC will freely give up their work to another team. Its not human nature to do that though.
CoolGuySteve 9y ago
What really drives me up the wall is this exchange I've had repeatedly: - I want to do X - But we're responsible for X - When can you do it? - We're understafed, so years from now - Fine I'll do it for you, I need it now - You don't have the proper permissions Basically when some mid-level manager holds a feature hostage so they can grow their little fifedom, essentially trying to promote themselves by growing the org chart underneath them.
- slivym 9y ago
  Right but there's a mirror image problem, which is that you're working on Y, people need Y, your team is resourced for Y. So if you go off and do X, then why are they paying you to do Y? Let's cut the headcount on Y, and invest in the team working on X. When the opportunity for more resources is on the table for X, no one is available to work on X. When they're looking to cut head count, everyone is working on X. Where X is some poorly defined but essential feature.
  - vanderZwan 9y ago
    > So if you go off and do X, then why are they paying you to do Y? What you describe kind of suggests upholding strict divisions per team like that is one of the main causes of the problem. Wouldn't being more flexible of temporarily joining another team as a guest work? I imagine that for a number of situations this could work: - I want to do x, my team needs it - But we're responsible for X, and x falls under that - When can you do it? - We're understaffed, so years from now - Fine I'll do it for you, I need it now - Didn't you hear we are responsible for X? If x is not done right we are the ones who get in trouble for that. - So make me a temporary guest member of your group, vet my work to make sure it's ok, and share the credit for x. - Ok, that actually sounds like a good return on investment for us, welcome to the team!
    - candiodari 9y ago
      Good luck getting your current manager to agree to this ! Are there any organisations that allow this ? I mean in theory Google's 20% time allows for this, but all traces of that (like the calendar and gmail labs) have systematically vanished from their products. And that happened years ago, it's not like that was yesterday.
lettergram 9y ago
That is a huge problem at the majority of places I have worked. I think that really comes into play when they have too many employees and not enough projects.
- chubot 9y ago
  There is ALWAYS enough work to do; there are always enough projects. Most software companies are constantly failing their customers, including Google. It's just that nobody WANTS to do that work :-( Usually because, rightly or wrongly, they feel they won't be rewarded for that work. Or because they don't have the expertise to work on it, or the patience to attain it. Yegge is pointing this out, and I agree with him (although I honestly I didn't find the pitch for his new company to be particularly compelling.)
  - digi_owl 9y ago
    And once you remove the money incentive/whip, it gets even worse...
deleted 9y ago
[deleted]
natbobc 9y ago
DRY as a concept needs to have better bounding. I think it's counter productive in many instances. (Albeit highly useful in others.) I've observed discussions with people citing it becomes particularly pathological when DRY is employed by Enterprise Architects. From my experience I tend to agree with that statement. I think RFC's (SHOULD, MUST, NOT, etc) with a reference implementation are a much better approach. If you want to move quickly use the reference. If it doesn't fit your use-case for whatever reason, document why you're branching out and get on with it. Obviously this approach poses an issue where documentation diverges from reality but ideally writing it down first will help clarify the objectives. Ideally the ABI/API for anything that's shared wouldn't be changing that much so maintaining the document shouldn't be too erroneous. If it is it might be an indicator to encourage duplication. Pieter Hintjens RFC's for ZeroMQ is a great example of what I mean; https://rfc.zeromq.org/ https://rfc.zeromq.org/ The GraphQL spec is pretty good too; http://facebook.github.io/graphql/October2016/ http://facebook.github.io/graphql/October2016/ Yes all of these things take time to write up but if you're going to constrain someone by saying "use this and under no condition nothing else" then it should be well documented.
digi_owl 9y ago
G+ anyone? Managed by an ex-MSer, and wormed its way into every damn part of Google for a time. After he left Google, i swear someone in the company management accused him of being a "cookie-licker" in an interview.
mrep 9y ago
I can't remember where but I read that Nest initially wanted to build the Echo competitor but was blocked by Alphabet because another team wanted to create it. That's the kind of stuff that would infuriate me.
Roboprog 9y ago
As the father of an autistic child, I’ve experienced “cookie licking” at home as a literal thing. Seriously, the kid dumps a bunch of snacks out and “marks” them all for herself, later. That term was immediately grokked when he said it :-)

vanderZwan 9y ago

For now. This is a kind of cultural shift that happens when companies grow. It doesn't happen overnight, nor does anyone actually want it to happen. But in practice it seems to nearly inevitably creep in. I'd love to read more about reasons why, and what can be done about it.

aaron-lebo 9y ago
Maybe these orgs are just too damn big. Google is 75k people, MS 124k. Those are on the small side, I can't remember which tech company, but they're at 600k. They're also chained to stock prices and earnings. They can't commit to any product for any sizable length of time. I'm gonna preach it until I try it or die and figure out it doesn't work, but my genuine belief is these companies are too big to effectively function or to counter threats. If your company population is a small town, how many middle managers do you have? Tens of thousands?
- tenaciousDaniel 9y ago
  Not necessarily a tech company, but I worked at Disney for a few years. They have about 500K employees. It's such a large company that their own companies sue each other. Like, our team couldn't use some Disney IP because we had to have our legal team clear with their legal team. That's when you know a company is too big. Edit: by "their own companies" I mean all of their subsidiaries.
  - gamblor956 9y ago
    Using another company's IP would always require a legal agreement... Size and common ownership are irrelevant.
  - digi_owl 9y ago
    Could have sworn i read about Sony, via intermediaries, sued itself. This because Sony both produced media devices with a record/copy capability, and content.
- fauigerzigerk 9y ago
  If they are too big to effectively function or counter threats then how did they get that big in the first place? Clearly size has benefits that compensate for some of the undeniable downsides. It's almost a tautology. Also, look at the great organisational and cultural variety among big companies. Size is not the only thing that defines organisational complexity and effectiveness.
- digi_owl 9y ago
  Would not surprise me if it hits somewhere around 150 or so, as that is supposedly the number of people we can directly keep track of in our heads.
zerkten 9y ago
Part of it is about changing the incentives and how people are "paid" for their work in large organizations. What drives performance for individuals or groups within an organization, isn't necessarily going to ensure that the organization as whole operates without friction. For me, this fits under the topic of "alignment" that leadership teams in large organizations talk about, but many people are ignorant to, especially when coming from acquired startups. If you decide that identity (user management, directory services or whatever broad feature) is a core service and put a group in ownership of that then every other team may end up with a dependency on that group. Initially, pooling resources seems like a good idea, but it becomes the critical path and they end up taking more and more incongruent feature requests as the rest of the organization grows. Eventually identity are a bottleneck, but are challenged with feature request brokering between other teams. Relative to other groups in the org identity becomes this monster team and you are left wondering if it should really be one group, or include leadership from other parts of your organization to ensure it can account for all requests and more effectively broker.
- candiodari 9y ago
  And then you, as a high level manager, throw the rudder entirely the other way. Now every department, or even every team has their own account database, their own chat, their own ticket system, their own crm, their own docs, and everyone else gets locked out of all of those.

matt_s 9y ago

It'll come at some point, even from your own team perhaps. It occurs when there are two teams that have a common need and one of the teams has deep knowledge of the space and maybe has a working POC but is too busy with other work to do anything. The cookie is licked at that point unless the culture is that the team with the POC will freely give up their work to another team. Its not human nature to do that though.

CoolGuySteve 9y ago

What really drives me up the wall is this exchange I've had repeatedly: - I want to do X - But we're responsible for X - When can you do it? - We're understafed, so years from now - Fine I'll do it for you, I need it now - You don't have the proper permissions Basically when some mid-level manager holds a feature hostage so they can grow their little fifedom, essentially trying to promote themselves by growing the org chart underneath them.

slivym 9y ago
Right but there's a mirror image problem, which is that you're working on Y, people need Y, your team is resourced for Y. So if you go off and do X, then why are they paying you to do Y? Let's cut the headcount on Y, and invest in the team working on X. When the opportunity for more resources is on the table for X, no one is available to work on X. When they're looking to cut head count, everyone is working on X. Where X is some poorly defined but essential feature.
- vanderZwan 9y ago
  > So if you go off and do X, then why are they paying you to do Y? What you describe kind of suggests upholding strict divisions per team like that is one of the main causes of the problem. Wouldn't being more flexible of temporarily joining another team as a guest work? I imagine that for a number of situations this could work: - I want to do x, my team needs it - But we're responsible for X, and x falls under that - When can you do it? - We're understaffed, so years from now - Fine I'll do it for you, I need it now - Didn't you hear we are responsible for X? If x is not done right we are the ones who get in trouble for that. - So make me a temporary guest member of your group, vet my work to make sure it's ok, and share the credit for x. - Ok, that actually sounds like a good return on investment for us, welcome to the team!
  - candiodari 9y ago
    Good luck getting your current manager to agree to this ! Are there any organisations that allow this ? I mean in theory Google's 20% time allows for this, but all traces of that (like the calendar and gmail labs) have systematically vanished from their products. And that happened years ago, it's not like that was yesterday.

lettergram 9y ago

That is a huge problem at the majority of places I have worked. I think that really comes into play when they have too many employees and not enough projects.

chubot 9y ago
There is ALWAYS enough work to do; there are always enough projects. Most software companies are constantly failing their customers, including Google. It's just that nobody WANTS to do that work :-( Usually because, rightly or wrongly, they feel they won't be rewarded for that work. Or because they don't have the expertise to work on it, or the patience to attain it. Yegge is pointing this out, and I agree with him (although I honestly I didn't find the pitch for his new company to be particularly compelling.)
- digi_owl 9y ago
  And once you remove the money incentive/whip, it gets even worse...

deleted 9y ago

[deleted]

natbobc 9y ago

DRY as a concept needs to have better bounding. I think it's counter productive in many instances. (Albeit highly useful in others.) I've observed discussions with people citing it becomes particularly pathological when DRY is employed by Enterprise Architects. From my experience I tend to agree with that statement. I think RFC's (SHOULD, MUST, NOT, etc) with a reference implementation are a much better approach. If you want to move quickly use the reference. If it doesn't fit your use-case for whatever reason, document why you're branching out and get on with it. Obviously this approach poses an issue where documentation diverges from reality but ideally writing it down first will help clarify the objectives. Ideally the ABI/API for anything that's shared wouldn't be changing that much so maintaining the document shouldn't be too erroneous. If it is it might be an indicator to encourage duplication. Pieter Hintjens RFC's for ZeroMQ is a great example of what I mean; https://rfc.zeromq.org/ https://rfc.zeromq.org/ The GraphQL spec is pretty good too; http://facebook.github.io/graphql/October2016/ http://facebook.github.io/graphql/October2016/ Yes all of these things take time to write up but if you're going to constrain someone by saying "use this and under no condition nothing else" then it should be well documented.

digi_owl 9y ago

G+ anyone? Managed by an ex-MSer, and wormed its way into every damn part of Google for a time. After he left Google, i swear someone in the company management accused him of being a "cookie-licker" in an interview.

mrep 9y ago

I can't remember where but I read that Nest initially wanted to build the Echo competitor but was blocked by Alphabet because another team wanted to create it. That's the kind of stuff that would infuriate me.

Roboprog 9y ago

As the father of an autistic child, I’ve experienced “cookie licking” at home as a literal thing. Seriously, the kid dumps a bunch of snacks out and “marks” them all for herself, later. That term was immediately grokked when he said it :-)