Reading this ( https://www.economist.com/business/2023/07/06/a-lego-lovers-guide-to-preparing-for-the-ai-age ) article inspired me to put down some long-held thoughts.
the success rate is more uneven within industries than it is between them. The best retailer may be more digitally productive than an average high-tech firm, and the worst retailer may be as bad as the worst government entity.
This is something I'd suspected for a while; it's nice to have some confirmation. It's been a bit of collective wisdom for a while that tech companies are more productive than brick-and-mortar businesses. But is this causation or just correlation? More evidence is pointing toward the latter.
I have two of my own takes The Economist didn't present (not overlapping but not mutually exclusive).
It's about hiring and management practices
Some of the ones that have become commonplace at "tech" companies haven't infiltrated as far as they should have into others.
Project tracking: breaking projects into discrete parts, each hours' or days' (maybe weeks' but never months') effort
Project ownership: giving each project a clear responsible party
Project estimation: (see "grooming" in Agile-speak) having a team, including people *not* responsible for implementation, agree on a rough timeline
Retrospectives: discussing, on a regular cadence, what went well vs. poorly on a recent project
Bug tracking: a searchable record of known flaws and complaints
Change/decision tracking: keeping a record of *why* each decision was made, by whom, and when
Artifact creation: any complex instruction needs to be written as a discrete document (*not* verbally, *not* in a chat app) that can be referenced later
"Principal Engineer": career paths that allow for seniority and high pay without having a fief of people that report to you
Some of these practices emerged in software because they're almost impossible to do without. A SaaS business might have a single product for 20 years - when does that project "begin" and "end"? An entire profession has emerged around figuring out a way to define discrete projects, regardless. A publication, performance, or manufacturer will find certain breaking points forced upon them – though they each benefit from being more thoughtful about intermediate ones.
Group project estimation is particularly beneficial for nebulous or open-ended projects. You might get away with having a mechanic tell you how long a car repair will take, but how long should it take to “write a blog post about this new widget” or “research different vendors for that jawn”? Agreeing that a blog post should take an hour, versus that it should take a week, implies two very different sets of contents for that post. Is also engenders some amount of understanding as to what the person working on it is doing - and therefore how good of a job they’re doing. If you’ve ever heard someone say something like “it took her four hours to write an email?” unironically, this could be for you.
Others seem intuitive in some contexts, but sometimes sacrilegious to suggest in others: does the top salesperson have to run the sales team? Is it not clear that those are different skill sets (or worse, a conflict of interest)? Does the coach need to be the top goal-scorer?
What even *is* a tech company?
By 2000, most Americans had internet connections. For TV, the equivalent year was 1954. If making an app or selling ads online in 2023 (nay, 2006) makes you a “tech company”, then why don't we think of Don Draper in 1960 as a tech pioneer?
Perhaps Diner’s Club (1950, T-minus-4) isn’t PayPal (1998, T-minus-2) today because they didn’t think of themselves as a technology company. Or perhaps it’s the other way around - we don’t think of them as a tech company because they didn’t innovate. Apple continues to be a “tech company” 40+ years after the launch of the Macintosh… what about Ford in 1950? Studebaker?
Direct-to-consumer
Build vs. Buy, Again
Third comes the question of whether to build a new digital infrastructure or buy it. The answer is mostly to build. Rather like Lego’s eight-studded bricks—six of which can be combined 915m ways—there are many software applications on the market that can be combined to create proprietary systems. But the job of orchestrating them should not be outsourced.
This is an underrated observation. I like to tell people that computer code is just a contract that’s so specific not even an inanimate object could screw it up. It’s a systematization of your business practices.
If you’re a lender developing automated underwriting software, the engineer leading that effort is, in essence, running the underwriting operations department – they have the exact same responsibility as (what would have previously been) a Senior VP of Something – their role should be thought of as such, not as an arcane specialty.
This is why I prefer to do “consulting” rather than “contracting” or “agency work” – I want to develop that institutional knowledge with my clients, work on the parts of their business that are unique to them, and level those up using my own outside experience and expertise.