I work at Fitbit and I'm very glad that cookie licking is not prevalent here.
I work at Fitbit and I'm very glad that cookie licking is not prevalent here.
- 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.
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.
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!
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.
They will actually fight having an "export to google sheets" feature, because it would cost them a lot of headcount.
And of course, demanding that managers learn a bit of basic (and I do mean basic) programming ("querying" would be a more apt description) to, for instance, do SQL queries on the database so they'd include those statistical measures ... that's just so out of the question it's not funny. There seems to be this need for managers to be the dumbest, most idiotic (but agreeable) people that just do whatever their boss asks of them, mostly by subtly threatening whoever is below them. "Good" companies leave 1 level above the rank and file that actually gets promoted from the rank and file to prevent the worst of the inevitable backlash. And yes, Facebook also definitely works like this, from what I've seen during an extended interview.
I can think of 10 examples of this I've seen where I work in the last year.
If X is big, say, "build a new data mart (over the next 6 months)," then your considerations are very relevant. That should have a plan and buy-in from all of the relevant stakeholders; it's a legitimate project and needs the organizational ceremony involved in such.
If X is small, say, "make this internal API return an additional integer field from a datastore it's already using," then that sounds like bureaucracy and politics needlessly impeding development. This is a minor enhancement.
I guess the trouble is that even a small change like my example could be substantial in a large enough organization. Maybe adding the integer field means a new version of the API has to be published, or maybe adding the integer field means DB indexes or caching strategies have to be updated. Even so, the API team should have established processes for solving these issues. So instead of a simple change taking a few hours, it takes a few days, still not a huge divergence of resources.
From the parent using the example "Fine I'll do it for you, I need it now," I'm assuming they're talking about very small scope problems, which would not substantially affect the schedule for Y.
And remember, Y is already being affected, because it requires X to get completed.
So it's not really a matter of working on X when you should be working on Y; it's that progress on Y has halted due to a missing X dependency. What can we do to get Y moving forward again?
At the ground level engineers are frustrated because if they could just get "those idiots" to do the one thing they needed they could make progress. Without ever realizing that they were the "those idiots" in someone else's dependency tree.
If you are a senior technical leader (or want to be one) it is always worthwhile to follow these threads to figure out what is going on, even though it might seem like a distraction. The larger the organization the more challenging this can be but most people will tell you what they are working on and why its important (which is to say what will be fixed/improved/made possible by its delivery)
- Fine, I did it for you in my 20% time. Will you review the code?
- Sure, thanks! And here's a nice peer bonus too.
But maybe that's a thing of the past? It's been many years since I worked there.
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;
The GraphQL spec is pretty good too;
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.
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.
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?
Edit: by "their own companies" I mean all of their subsidiaries.
This because Sony both produced media devices with a record/copy capability, and content.
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.
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.
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.)
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 :-)
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.