These are my raw comments, as someone who has spent 50/50 of my 20+ year career in small and large companies. So I think I have a good understanding of both.

Seeing like a software company

Author: zdw

URL: https://www.seangoedecke.com/seeing-like-a-software-company/

• By “legible”, I mean work that is predictable, well-estimated, has a paper trail, and doesn’t depend on any contingent factors (like the availability of specific people). Quarterly planning, OKRs, and Jira all exist to make work legible. Illegible work is everything else: asking for and giving favors, using tacit knowledge that isn’t or can’t be written down, fitting in unscheduled changes, and drawing on interpersonal relationships. As I’ll argue, tech companies need to support both of these kinds of work.

  • Note: What does “contingent factors” mean here? Not defined so sounds smart but no idea what it means in practice.

• Likewise, it should be obvious to any practicing engineer that engineer-driven work goes far more swiftly than work that is mandated from above. Engineer-driven work doesn’t need to be translated into something that makes sense, doesn’t need to be actively communicated in all directions, and can in general just be done in the most straightforward and efficient way. This is why tiny software companies are often much better than large software companies at delivering software: it doesn’t matter that the large company is throwing ten times the number of engineers at the problem if the small company is twenty times more efficient.

  • Note: But how do we know the software that was delivered “fast” and “efficient” actually provided value and helped customers and the business? Also who pays for this fast software? Certainly not the engineer. Engineer-driven work is essential, but if it doesn’t help the business it’s a side project. It takes input from a lot of perspectives to figure out what’s worth experimenting with. Especially in small companies where there’s not a lot of money to go around.

• The processes that slow engineers down are the same processes that make their work legible to the rest of the company. And that legibility (in dollar terms) is more valuable than being able to produce software more efficiently.

  • Note: What does “slowing down” mean here? Is writing the wrong code faster better? How do we know that moving fast on something is valuable?

• Note that “shipping high quality software” or “making customers happy” or even “making money” is not on this list. Those are all things tech companies want to do, but they’re not legibility.

  • Note: This is a false statement, at least for us. All of those things are important.

• Why are these capabilities so valuable to a large software company, when small software companies can do without them?

  • Note: Reminder that 90%+ of startups fail.

• But enterprise deals (a) can take many, many months to set up, and (b) require making long-term feature commitments.

  • Note: (a) is true, (b) doesn’t have to be (we push back on this a lot).

• In the pursuit of legibility, large tech companies make simplifying assumptions about the nature of tech work. For instance, they assume: * Any engineers with the same job title perform roughly the same. * Engineers can be shuffled and reorganized without substantial loss of productivity. * A team will maintain the same level of productivity over time, if it has the same number of engineers. * Projects can be estimated ahead of time, albeit with some margin for error. The more time spent estimating a project, the more accurate the estimate will become. Of course, all of these are false.

  • Note: This, I agree with, and it annoys me too.

• Project estimates are largely fantasy. More accurately, they’re performative: the initial estimate determines the kind of engineering work that gets done to deliver by that estimate, not the other way around. For this reason, breaking down a project into parts and estimating each part often delivers a less accurate estimate, because it makes it harder for engineers to align with the overall ship date.

  • Note: This depends on when it happens. Read “high integrity commitments” https://www.svpg.com/managing-commitments-in-an-agile-team/

• All of this makes the work very legible, but none of this is compatible with work that has to be done right now. What do you do when there’s a sudden, urgent technical problem - maybe you’re about to overflow your int ID column on the users table, or some very large customer is experiencing a show-stopping bug?

  • Note: This whole scenario, culminating in this example, is wildly disingenuous. That’s just not how “urgent” work works, certainly not in our team. When have we not changed priorities to deal with a prevents or urgent matter (like audit logs storage).

• All organizations - tech companies, social clubs, governments - have both a legible and an illegible side. The legible side is important, past a certain size. It lets the organization do things that would otherwise be impossible: long-term planning, coordination with other very large organizations, and so on. But the illegible side is just as important. It allows for high-efficiency work, offers a release valve for processes that don’t fit the current circumstances, and fills the natural human desire for gossip and soft consensus.

  • Note: I don’t necessarily disagree in principle but what bugs me here is that this post never talks about whether or not the illegible work is actually important / valuable work. That makes this whole thing a giant misnomer. Let’s talk about how to make room for urgent, valuable work. I’m all in for that. But this post does not discuss value at all.