Implications of the Silicon Valley Autonomous-Engineer Model

April 7, 2021

In my previous post I suggested a new way of looking at (and therefore comparing) organisations: considering them as a collection of services which they offer their members, and then looking at how each of those was delivered.

In the back-and-forth on twitter which followed, Krisztina suggested I have a look at a blog post on how Silicon Valley-like companies “get” software engineers, while others don’t. After a quick read, it seemed like a great opportunity to try out my approach. This post is the result.

Written by Gergely Orosz, the main argument of the post is that the way Silicon Valley companies organise results in faster innovation at a company level, better professional growth for engineers, and more bang for their salary-buck. It’s well written and well-argued. From his biography it is clear Gergely has extensive experience working for multiple SV-type companies and I see no reason to doubt the accuracy of his conclusions on how they operate.

Gergely structures things by listing seven things which makes them realise these benefits. I’ll follow the same structure, tackling each in turn.

First up is autonomy . This is autonomy to select what to work on, autonomy to subdivide that work, and autonomy to decide how to tackle it. There is also autonomy as to how much time to invest in a given task (e.g. paying down tech debt or delivering new features). Unsurprisingly there is little / no micro-management. Engineers are self-managing.

Looking back at the services I’ve identified, which ones are at play here? We clearly have skill/resource allocation - this service is being performed for the engineers, by the engineers. It also seems as if decisions are happening (e.g. “should we pay this debt, or work on a new feature?”) and again, this is done by and for the engineers individually, or perhaps in teams. The post is generally individual-centric, but not exclusively.

Reading on a little we can also spot (long term) direction with the call to “solve problems that the business has” (how we know what these problems are is partially addressed later).

In section two we get our first explicit comparison with non-SV/traditional companies. Banks being mentioned specifically. Here we see how hierarchy is the solution in traditional companies for the services we have seen delivered by autonomous individuals (and potentially autonomous teams) in SV-co’s. In traditional companies decisions are taken higher up, by managers. No decisions are taken by developersI’d argue that there are, given that development is all design decisions, but I get the author’s drift here. . I too have seen structures like this where decisions required lower down the hierarchy had to be packaged and sent up the line to the appropriate echelon, where a decision would be taken, and passed back down again to be implemented, most likely to a specific team which had (at least theoretically) the appropriate skills/resources to allocate.

This is compared (still interestingly using a pyramid-graphic) with the SV-co doing decisions at the bottom level, but taking into account “business context” which is passed down to them from higher up. That makes more sense. It could be argued that this “business context” is the (long term) direction which we could see was acted on above, but were unsure where it came from. This might also be input into the decisions.

We then move on to the next critique of non-SV/traditional companies: the problems around skill/resource allocation which arise from the fact that software engineers are expensive and need to be constantly fed with work. I have little argument with this diagnosis, and it’s interesting to see here the introduction of another key service (called out here as a skill that’s explicitly hired for) and that’s communication. In SV-co’s, where work is not being spoon-fed to engineers, and where engineers are expected to have an impact worthy of their salary, they have to ensure that they have the information they need to maximise this. I’ve met many engineers where this was clearly a skill of theirs, and (until the global pandemic) it was one of the articulated reasons Netflix didn’t open another development office - the impact of cross-site working on engineer-to-engineer communications was deemed to be too high to bear.

In the examples which follow, another service can be discerned in phrases such as “have we checked with the legal team?” and also “if we combined project X and project Y” and again “can we delay the project by a month, until the new infra is ready, to avoid double work”; this service is co-ordination. Clearly, if this information is not acted on, then it is only communication, but we can assume it is, and that co-ordination results.

In section three we get lots more information which could all be labelled “communication”. Compared to the non-SV/traditional co’s we are to believe there is a lot. It is interesting to note that one older SV-co, Apple, does not have such a transparent approach. It is also worth pondering if this is all the information, if it is truly open, or if there is an element of selection and boosting happening.

Section four introduces aspects which again touch on services we have already mentioned; namely (long-term) direction, communication and co-ordination. While it’s undoubtedly the case that these interactions and guidance-seeking do happen far more in SV-style co’s, I can’t help wondering if some of this is down to size, and location. I have known many people at non-SV/traditional places gain very similar insights and inputs but via un-official routes: meeting up after work, chatting in the canteen, etc.

Section five continues this theme for me. I’ve rarely witnessed the “up and over” style of communication being mandated, but it is true that when you do see peer-to-peer, probably cross-team communications and co-ordination it will be less frequent, more ad-hoc, and not relied upon as a definitive means of collaboration.

Gergely does have a point here about the hierarchy’s role in communication however. One problem I see again and again is that hierarchies typically communicate down relatively efficiently, but are terrible at facilitating communication upwards. He is also right that peer-to-peer communication is faster, and higher-bandwidth. But is frequently also has the blessing / curse (select those which apply) of being un-targetted and unfiltered, leading to information overload. I agree here that managers can play a role in mitigating these issues by facilitating the right conversations. This sentence adds nuance to the predominant view in his post that “engineers just talk directly to other engineers” and gives the hierarchy some residual role in comms. It’s also worth pointing out that it’s refreshing to see a post which argues for increased autonomy but without assuming that means the end of hierarchy. I’m agnostic about it, but it does show a degree of independent thought and nuanced consideration.

Skipping section six as it’s not relevant to this view, we arrive at the seventh. This is all about recognition, another of the services, although viewed through the lens of attraction of talent and the salaries they are paid. It could be argued that this is the section which closed the argument and is intended to justify the vast salaries devs can command. I’m not sure this section really lives up to that promise however. Admittedly, many SV-style co’s have infrastructure (discussed in section six which I intentionally skipped) to optimise the delivery lead time of developers features, but I’m not sure every SV-style co is jam-packed with devs delivering features of the calibre suggested, all day, every day. I also know that for many, the salaries can be a major source of stress when things aren’t working, and when a company is solely structured to provide recognition along these lines, many other things fall by the wayside, leading eventually to many products which are definitively a “success” but also of questionable social good. The “like” button mentioned in the article could be argued to fit this profile for example.

Given all this , I have little issue with the underlying argument of the closing paragraphs (although I do take issue with the characterisation of devs in non-SV co’s as “factory workers” as much as I do the “10x engineer” trope). Software is indeed eating the world, and those companies which see software as delivering value, rather than as a cost centre are storing up trouble for themselves. I do find it hard to believe however that these SV-co’s are comprised soley of devs and “managers”. Now, admittedly I haven’t looked at job postings recently, but I’m pretty certain there will be many other folks playing roles directly related to delivery of software not mentioned here. This tunnel-vision severely undermines the argument of this article in my mind, because by placing all the credit in the hands of a blessed few it makes you wonder about what’s missing.

That thought is what takes me onto other issues which arise from this incomplete view. What about the other services which the author doesn’t choose to mention? Namely, constitution, conflict management, and learning. I can take a guess at the latter. In many SV-co’s they hire devs who are deemed “senior” and beyond, so a majority of the fundamental learning has been achieved earlier in their career. What further learning does take place is typically “on the job”. (Netflix define their approach to this in their Culture deck (slides 119 and 121). I won’t go into this any further as the other two are far more important.

Now, Netflix are clearer on these also, most notably in their calling out their intolerance for “brilliant jerks”, but they are singularly notable for taking this standpoint. Elsewhere in SV-co’s there is frequently an ad-hoc, or worse still, lip-service approach taken to these essential elements. Susan Fowler’s Whistleblower goes into these topics in great detail, specifically in the case of Uber, which is one place the author has also previously worked. What Fowler calls out in her book is that not only were these aspects terribly implemented, they were set up in a way to protect the company, and those working there who were senior / had greater tenure / were cis, white, hetrosexual men, all at the expense of the individual. Subsequent events at the company have shown that what had grown up was in many ways a monoculture. Undeniably, the engineering was world-class. The products shipped helped Uber become one of the largest and most valuable companies in the world. The goals outlined in Gergely’s post were achieved. But at what cost? After writing this post, I’m more convinced that all services are provided by all organisations, but it is important to get them all right, not just the ones which seem to be directly making the company money.

Well , that’s my first end-to-end deployment of this lens on organisations. It was interesting to write, and helped me think about things in a methodical way. It also felt as if it made sense, allowing me to pull apart a few concepts into their constituent parts, and see some parts in light of others. But that’s just me. I’d love to know what you think. If you have any thoughts or any other kind of feedback please leave a comment below or alternatively reach out to me on Twitter. Thanks!