I recall talking to someone who was very very happy to brag that his company was doing "everything just like Google" and following the exact same practices he read the company did on various engineering blogs.
I asked him what was the compensation like and how he managed to get kids from Stanford to work at his company instead of their startups and he just gave me a blank stare. Said something about how they were not in Silicon Valley and paid median salaries and that he had "no trouble finding Google caliber talent in the local market." and that "it's not really the local market's customs to give stocks to coders".
I don't understand your point, you don't need "kids from Stanford paid in stock" to run a monorepo, k8s (borg), bazel (blaze), SRE and whatever else you can read on the blogs. That's literally the point, to spread ideas around the industry so everyone can try them out.
Now I would understand the complaint if that company had the same hiring hoops as Google but a dud of TC but that's an orthogonal issue.
I think the point the author was trying to make was that the example company was doing “everything like Google” EXCEPT being as picky about who you hire, paying as much, and aligning employees with stock options.
If you try to bake a cake following a recipe, but only using half of the ingredients listed, you are going to get an odd cake.
I guess I disagree. Yes, you need a high class talent to move the field forward but once the new frontier is conquered, it ceases to be a frontier and everyone else can enjoy the fruits. Regular engineering practices of today are cutting edge of yesterday.
Israel seems to do pretty well, by which I mean Tel Aviv. They always go US or global first for obvious reasons but there’s no a priori reason Europe couldn’t have a genuine startup hub.
While your argument is hard to prove wrong because the US ranks third in population as a single nation, I am skeptical that there is somehow a market population threshold that allows Silicon Valley in a country of 3X10^9 but not, say, 1.2X10^9 (Japan).
The argument there is that America has sufficiently exported enough culture via traditional means that using American products is not that strange.
Japan has a lot of cultural exporting, but certainly has its differences. And is not exactly known for being internet-forward. Korea is internet forward but is similarly culturally niche; kpop stans are pretty much in their own bubble, one that’s big enough to cause havoc in international music charts but still a bubble. And China’s Internet is double different because of the insulation of the Great Firewall.
Of course, how much stock one actually should put into this is up to the reader.
At this point I think we have moved quite far from the OP's acquaintance's comment. It's quite clear they meant operation day to day. The procedures Google follows and processes they have developed are out there and quite publicly available. Anyone can follow them with even a mediocre engineering team.
It actually has these. Mostly in the extreme south east and in some other places where the boundary of the ice was in the ice age. Highest point in the Netherlands is about 300m above sea level.
I used to work for a CEO who was always going on about "we're going to be the google of x". No 20% time, no food provided, low pay, horrible management and would hire any random contractors that applied, but we had an xbox we were allowed to use after work "just like google". Half a billion dollars later they failed to be the ask jeeves of x.
The other big cargo cult you often see is agile. Press an "agile" company on what agile practices the follow and more often than not you'll just get "we do daily stand ups". Ask them what they think the most important rule in the agile manifesto is and you'll get blank stares, they can't even read the cults literature.
Well, isn't that the magic of picking the right tooling? You then don't need superstars to operate the system. That sounds like a productivity coup. It is, natural, of course that the productivity accrues to capital rather than to labour in this relationship.
In fairness, cargo culting can be good in very targeted ways.
My company didn't have a clue on what to purchase for software development equipment or how to organize it. As a result, they observed what Google did and copied it to the best of their ability as their pocketbook would allow. Although it's not perfect and they have no idea why it works, it's certainly better than anything they could organically have come up with.
I'm reasonably certain you're describing a delusional or deeply ignorant person--not someone who actually follows meaningful Google-esque practices of any sort. "We use Guava and are looking into Go"-level overlap with Google and not much more.
I mean I really get why people like using npm and Typescript is great, but the whole “web-tech got adapted for backend then adapted back to web” just makes everything so unnecessarily complicated.
I think a lot of this “using frameworks without knowing why” is just because people read articles about them and how-tos and get excited too quickly, and Google just shows way more tutorials about how to do something in React than in plain JS.
What are lambdas in this context? I thought those were just another name for closures?
I've been there in two projects, both of which took far longer to build and neither of which ended up with anywhere near the amount of traffic or need to build things using that architecture.
That said, I had a project last year where we used a serverless platform for a product / ecommerce platform (Gatsby, Netlify, Contentful, Commercetools, JS/TS) where it worked pretty well.
Now that I've been stuck actually working with agile in the field for 15-20 years, not sure I think we get to call that and Scrum cultish anymore. They're more just popular productivity footguns at this point.
Scrum is a way to generate progress reports and accountability.
My current employer doesn't do it (they have a 'stand up' but it's just everyone telling what they're working on while nobody listens), and I have no clue when what will be finished - and neither does management.
I mean for my current project which will probably keep me occupied until the end of the month, I got a design document with a pretty decent todo list, but someone had already Decided that it would take about 5 days.
So far they don't seem confrontational or critical about it though, so idk, I guess they're okay with it.
Sources of truth are: the implementation, the business, customer satisfaction. And if you want to go deeper: technical debt, developer satisfaction, developer retention.
The more distracted you get with planning, the worse your product becomes and the more disempowered your developers become.
Scrum can work only if it is kept down to earth. But as soon as product managers stop meeting with developers, you have entered the path to technical bankruptcy.
Scrum is meant to promote collaboration between product manager and developers, but in most cases, product managers get away with avoiding this responsibility. And the reason is because scrum does not have provisions to keep product managers accountable...
Scrum does not define real deliverables for product managers, therefore in practice it becomes the opposite of what it promotes.
agile wasn't really a process, just a manifesto. All scrum did was package itself as a marketing strategy to enterprises while the rest of the agile advocates face palmed and slowly walked backwards from "agile" as it became more and more poisoned.
Shame really, Software Philosophers like Kent Beck kind of got lost in all that noise, who always emphasized the human aspect of software creation
That is a funny question (in the good sense). I would argue the VCs are cargo culting themselves, but of course another could argue that once the VC money has moved into the pockets of the programmers, then the important part of the process is done.
I just doesn't necessarily create any useful software.
1) You can hire people that can use it effectively.
2) It is robust, production ready.
3) Emphasizes a set of traits that you are interested in, such as productivity, performance, high concurrency, low latency, binary size, compatibility, etc.
To the clueless this may seem like bikeshedding and cargo culting, but that is not necessarily the case.
This is a good article, written in 2000. I think it was my introduction to the term "cargo cult" way back when.
> We call the imposter organizations sweatshops because they emphasize working hard rather than working smart
I wrote on a whiteboard at an office, early in my career, "Company motto: Work harder, not smarter" out of frustration following a meeting with a manager where that phrase was nearly stated verbatim. I had thrown in a ton of OT getting things working (I was young), including a nearly 36-hour run (7am Monday to 6pm Tuesday, with a few hours off for lunches, dinner on Monday, and a trip home to shower and change Tuesday morning). The OT was worth it, I fixed the thing that was blocking us and I set it up so that we wouldn't have that issue in the future. I identified various areas where procedural improvements would reduce our error rate in cases where we had repeatedly run into the same issue (or similar issues with a common root cause), and it was discarded by this manager with something like the above motto and "We don't do that here". This meant that I was going to get lots more OT (yay money!) but I just wanted to sleep at night again.
I still do this after 15 years! Commitment means creative autonomy though. If valid solutions get tossed out by impostors then it becomes impossible to sustain. Or when authoritarians and people low on agreeableness traits start trying to make everyone predict all implementation details up front under the guise of process improvement (it allows unexperienced managers to pretend they understand details).
There is a minimum level of mutual co-operation and diplomacy required to nurture commitment and ownership, and alas it seems so uncommon as soon as a team goes over 5 people IME, unless the business is REALLY careful about hiring for openness and agreeableness.
I left my last job for many reasons, but fiefdoms were one of the big ones. I had a manager, when I brought up increasing automation in testing, say: But then what would the testers do?
My answer was: Automate more tests and test more systems, no one is being let go but now we can do more across the team and organization.
The threat of losing personnel though, to a reorg as the needed numbers changed, was enough to stop managers from doing things that would improve their product and the quality of life of their teams. It was pathetic.
Yeah I've never seen an increase in automated testing have the effect of laying off testers. Usually it results in testers moving up the food chain a bit: they get involved with the automation, help with things like CI integration, and find more time to devote to test strategies, documentation, etc.
That was one of my points as well. Our testers weren’t technicians flipping switches. They were engineers and computer scientists who designed test cases, maintained them, ran them, and analyzed the results. I wanted to free them from running the test cases (which could take weeks when the full suite was executed) so they could do more of the rest.
I'm not sure. I think most people know to at least pay lip service to "collaboration", even if they're awful at it. The best bet would be directed questions about how they have achieved collaboration in the past and how they might try to improve collaboration as a manager in your office. But you're pushing into mind reading territory, you'll need to be able to observe where they came from and what was actually done there. If it's an internal hire/promotion this is feasible, but it's not possible, in general, if you're hiring from outside your company.
Thanks! So, seems to me you're saying it's more important to look at what they actually did in the past (if there're any ways to find out), rather than listening to what they say.
Makes sense, humans are so good at quickly learning what sounds good and others want to hear, are they not
Many engineers/Creative professionals chafe at being told how to work, so they will resoundingly push back on any procedural change. Usually you'll find that as an individual contributor you have wide latitude to develop in any manner you see fit as long as you earn the trust of your manager and can satisfy his leadership's tracking requirements.
On paper I often work in a scrum team, in practice I subdivide my own work along arbitrary story guidelines to make sure that at the end of the spring I have the requisite number of points + 20% on average. If someone else needs to pick up some work, I'll slice off a whole workstream for them - and then we'll subdivide the workstream to have the requisite number of points + 20% for them as well. I've worked in agile shops for 8 years at this point, and this approach has yielded the best results for both myself and the company - but "not using scrum/agile" is a great way to be viewed as rocking the boat in an unhelpful manner.
Process improvements are typically valued at zero unless and until a director (or above) is annoyed by the issue addressed or, worse, their bonus may be impacted.
Process improvements are perfect CYA. You hand it in in writing, get a written turndown because too expensive/annoying/whatever. When shit hits the fan, you are covered. I like process improvement.
Other than that, I only saw one improvement realized. It was one a colleage turned in, got rejected. Then turned in again almost verbatim by a manager 2 layers up, who got it accepted and got the bonus for it...
Or they get read by the consultants who then take credit for the suggestion and get paid. Granted, the consultants are also a blame sink if the suggestion doesn't work, or ruffles feathers.
On a tangent, Cargo Cults in the Pacific are a more complex phenomenon than many people assume.
I remember in college I had a great Pacific studies professor and one of the topics he touched upon was the idea of cargo cults as a form of disruptive political protest. I forget the details of his argument, but I think this article captures the gist of it - https://www.scientificamerican.com/article/1959-cargo-cults-...
I also think there was an element of trying to play Americans off of other colonial powers, although I can't find any citation for that.
> The Whites, who possessed the secret of the cargo, were intercepting it and keeping it from the hands of the islanders, to whom it was really consigned.
Replace “whites” with “establishment” and “cargo” with jobs and “the apocalypse” with revolution and you have the essence of a conspiracy theory or extreme political movement.
Edit: this next bit is disturbingly prophetic:
> Of course the cargo never comes. The cults nonetheless live on. If the millennium does not arrive on schedule, then perhaps there is some failure in the magic, some error in the ritual. New breakaway groups organize around "purer" faith and ritual. The cult rarely disappears, so long as the social situation which brings it into being persists.
For mine, it is one of the great pieces of writing/oratory of the last couple of hundred years and addresses so many of today's issues head on. It would be nice if it became very dated, let's work on that.
Steve McConnell is great. Of the "Code Complete" fame. I recently read his "More effective agile" and it's a great modern introduction to Agile. Lots of actionable advice.
His "Software Project Survival Guide" is great too, a bit dated but a great read. Saved more than one project that was close to the abyss when I joined.
This is really more "cargo cult software engineering management".
Cargo cult software engineering is also a thing: Patterns (chosen without knowing when to use them or why). OO vs FP (picked without knowing when to use which, and why). Languages and frameworks (chosen without knowing when to use which, and why).
I don't think the author is trying to say "don't try anything new unless you have evidence", but "don't use something without understanding why". Experimenting with a practice to understand it better is a perfectly valid reason. Adopting a practice and expecting it to magically solve your productivity problems, without understanding why and whether the tradeoffs are appropriate, is not a valid reason...that's cargo culting.
Another way to look at it is...what are your expectations? If you are using something with the expectation that it'll magically solve your problems, and you don't really know why...you're cargo culting. If you're using something and suspecting that it'll solve your problems, and you expect to watch it and gather feedback and evidence on whether it's actually helping or not, and potentially axe it in the future if it's not working out...that's not cargo culting at all, but effective process.
Experiment. If you desire evidence-based management, you have to seek out case studies (and actually consider them, not discard them when brought to you like one manager did to me, "Show me the evidence." "Ok." "Whatever") or run your own experiments. Even if you do seek out case studies, you will still want to run your own experiments because what works for X may not work for you.
Find a low impact project or a project that can absorb a potential setback and try it out. If it fails, you at least gave it a shot. If it succeeds, promote the idea among other teams and projects. You can always apply a sanity check on ideas before trying them, just like in other things.
"I heard that having a foosball table in offices increases productivity by 25%."
"That doesn't sound right, but we can try to create better break areas."
> Find a low impact project or a project that can absorb a potential setback and try it out.
That's how I introduce every new thing to the companies I've worked for. Use it in a non critical project first. The problem with using a new thing is a critical project is if anything goes wrong the company hive mind will scapegoat the new thing and you.
We should be debating process versus commitment, though. “They can both work” is a bit facile.
Work isn’t (typically) done except in the context of workers’ lives. These paradigms incentivize different behaviors and cultures and there are real impacts on the lives of workers as a result. It’s a mistake to purport that we can ignore those consequences in an evaluation of what works.
I think one of the points in the conclusion is that these two ideas aren't actually on a spectrum, but rather are more orthogonal with each other. It's not a true binary choice so there isn't a real debate to be had between the two. Process doesn't preclude (though it may constrain) individual empowerment, and individual empowerment does not preclude (though it may constrain) process.
There are processes which actually do, to some extent, encourage individual empowerment. I would put the trend to distributed version control systems like git as a boon to both process and individual empowerment, as an example. I can use it much more freely to experiment in my feature branch than when using a system like SVN (in many classical scenarios of using SVN), but the pull request system integrated into many git server systems is itself a process approach to control (and hopefully improve) the development work.
I agree, but also consider the choice of the worker. Commitment comes from motivation; the motivation can have a very large impact. A friend of mind went to work for Google, did 5 years as a Senior, got a load of cash, married his dream girl from high school back home and is now traveling the world with her. This is his idea of heaven. Personally I would never have committed like he did; but this is my choice. The problem comes when people are lied to and bullied into doing things that they don't want to with no positive outcome for them.
We're heading towards an era of cargo cult where Apple's silicon is viewed as pure magic and developers scratch their heads over why they are now paying 60% to be in the App Store considering that they are doing the exact same things as when the rate was still 30%.
Right now a lot of small dev shops are wondering why they are paying 15% when the rate used to be 30%, so you're almost right (factor of two) just in the wrong direction.
> these organizations look at successful companies like Microsoft
Except they don't anymore, because nobody worships at the altar of Microsoft, because while they were once revered as Gods, they no longer are. Now substitute Google, Tesla, etc...
The tech industry would advance faster if we paid more attention to technology than market dominance.
The publication date for the article is in 2000. Take "like" and extrapolate to today, you don't actually seem to be disagreeing with the author under that view.
> … we should be looking for ways to raise the average level of developer and manager competence.
Ha, I wish! The vast majority of companies I worked for never wasted a thought on this. It seems clear to me that there is much room for improvements on that axis, irrespective of organizational style.
I think you're wrong. Most companies would run out of effective work for better staff. Rather than drive innovation and develop new competative advantages with it, they just want the status quo. So mediocre employees and managers make sense. They don't rock the boad.
Neither approach is wrong when used correctly! What a wonderfully written article.
I feel like 98% of articles and opinions in popular media could learn a lesson from this articles template. So often folks are busy arguing the obvious extremes that they completely miss the point of what actually matters.
There are some fundamental limits to commitment-focused culture though. People have life obligations. Even if they wanted to work 60 hours a week, their sick mom or their childcare or their kitchen renovation or an especially busy graduation season for nieces and nephews just requires their time, and their knowledge that their job is secure and they won’t be penalized on raises, rewards, etc., for simply having a life.
Because of this, the commitment-focused path just doesn’t work, flat out. At best you can use it briefly to exploit unwitting young people who don’t know their worth and don’t have enough self-confidence to say no, and ride that into a pump and dump IPO situation, after which your company will promptly become process-focused and all the young people will quit and be replaced by mid-career people who don’t mind inheriting the mind-melting tech debt as long as you pay well and only expect 40 hours per week.
There's a trick to get more out of employees that's almost never discussed: Make their life easier.
Childcare for a late meeting is an issue? Why not have childcare at the office? Pay enough and the kitchen improvements are the contractor's problem and not your employee's.
> Not having childcare is not the issue, wanting to spend times with your children is the issue. You can't outsource that.
It's simple accounting really: If you want your employees to work 5 more hours a week, you need to free 5 hours from their schedules. Obviously, quality time spent with children or a spouse is the last thing employees will be willing to sacrifice. But running errands? Cleaning the house? Doctors appointments? Meals at work? Make these frictionless and you'll gain in productivity.
You'll gain hours, but not necessarily productivity. Which is a common mistake in management thinking. An extra hour of work out of an assembly line can produce an extra hour's worth of product, there's a pretty clear and measurable extra output there. In software, and a lot of other design work, this correspondence is less precise. For Cody the Coding Machine you may get a real extra hour of output from him. From many others, you'll find they extend their breaks from 15 minutes to 20 minutes, lunch goes from 30 to 45 minutes, and the extra time is taken up by meetings or answering emails.
The productivity doesn't come from extra time, it comes from alleviating stress and increasing the ability to focus. If my thoughts at 2pm are, "Wait, is it my day to pick up the kids? I've got a 3pm meeting, I've got to text the wife to let her know I can't get them today." I'm unfocused. Childcare, consequently, can relieve me of those thoughts. Same thing with bringing in food or having medical and fitness options available. They relieve some stress/unproductive time spent thinking and planning, which will hopefully improve productivity overall, but extra hours recovered from this are not necessarily more productive just by being available.
Even for actual assembly lines, that’s only true to a point. Data from WWII bomb factories (so, highly-motivated people) shows an asymptotically-smaller gains after about 48 hrs/week.
Hey, why not have a 'company store' where people can buy everything they need right at the office instead of having to spend precious minutes travelling to some questionable generic store. Think of all the time saved. While you're at it you could even extend credit to the employees for anything they might want to buy, and have their payments come directly out of their paychecks. How convenient! You could even issue company scrip instead of dealing with the costs of payment processors. There's lots of room for innovation here!
Google tried this. They set up this cadillac in-house childcare system, as you'd expect from Google, but it got out of hand as it scaled. When they switched to charging the parents more of the program cost, there was a huge backlash. Even with the higher price they couldn't meet demand, leading to waitlists and eventually a random lottery just to get a place. I bet Google management wish they'd never started the whole thing now.
If there's one thing you can count on 'disruptors' to not understand, it's grandfather clauses. You raise your rate for all new 'customers' and your overhead rate stops looking like a line going toward infinity.
Your reward for being at Google for 5 years should be that you get the rate plan from 2 years ago when your first kid was old enough for daycare.
My reward for being a Netflix customer for 6 years should have been that I still got the old rate.
Saves the extra drive to daycare as well as the stress of not meeting the pickup time (most daycare charges very high after-hours rates to discourage this; I’ve seen $50/15 minutes).
> At best you can use it briefly to exploit unwitting young people who don’t know their worth and don’t have enough self-confidence to say no, and ride that into a pump and dump IPO situation
That's basically the business plan in a lot of places.
Agreed, and we software engineers just keep letting them do it to us by agreeing that leetcode algorithm hazing should be the absolute measuring stick by which all software hiring is judged.
If you feel like you barely squeaked your way in the door as someone was whipping you and yelling “dance monkey dance” then you’re helping them identify you as a gullible goober they can pay peanuts (relative to your value add) while overworking you, and get you to thank them for the sweet ping pong and happy hours.
Until young candidates just say no to this shit, then it’s an abyss of open-office, grab-ass culture we have no one to blame for but ourselves.
I recall talking to someone who was very very happy to brag that his company was doing "everything just like Google" and following the exact same practices he read the company did on various engineering blogs.
I asked him what was the compensation like and how he managed to get kids from Stanford to work at his company instead of their startups and he just gave me a blank stare. Said something about how they were not in Silicon Valley and paid median salaries and that he had "no trouble finding Google caliber talent in the local market." and that "it's not really the local market's customs to give stocks to coders".