—
Observations collected over 20 years in the tech industry.
These are my personal observations working in tech for more than 20 years — if someone noticed any of these laws of nature before me, I automatically give them full credit.
A technology that was built for good will eventually be also used for bad.
In tech we have this notion of “Happy path” — the expected behavior our good users will take, and we tend to focus on the beneficial use cases our customers will do with our product. This creates a blind spot for the exploits and bad implications our technologies can have. I was shocked when some users used our API to scrape data for the first time.
A company’s technology stack will be based on the experience and preferences of the first technical person in that company.
When a company is formed, the first technical person has almost infinite decision capabilities on the technology stack the company will use for the foreseeable future. Some companies I worked at, implemented everything in PHP because the tech founder was a PHP fan.
The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years.
Migration projects take 10x time the amount we estimate them to take. They are mostly useless to the company’s business, and make developers quit the company out of boredom and frustration. Yet, the entire tech industry is always looking for the next shiny tech, instead of trying to fix the current tech stack.
Every major technology is going to be followed by a movement to eradicate that technology because it’s going to ruin us.
People fear change, and even more than that, change that they do not understand. Every new major technology is going to provoke people to eradicate it, as if it’s going to drive the end of the world. All technologies are a tool and are only bad if put into bad use by people (see A technology that was built for good will eventually be used for bad.)
A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers.
Tech companies over index on the capabilities of the individual. Most productive teams I worked for had the magic of being communicative and collaborative, rather than genius prima donnas.
Left alone, a product team will optimize to the closest and easiest goal.
Product teams are composed of smart, ambitious, and generally good people. They do however often miss the big picture and focus on a local goal of their feature, or product and not on the grand goal of the company, or benefit of humanity. Focusing on a local target, such as engagement or retention, sometimes drives product teams to do things that hurt the company and its users.
Some aspects of tech are pseudo theological — talking about “tabs vs spaces” will probably start a holy war.
People outside tech think that engineers are super smart and rational people that judge things on their merits and logical benefits. Little do they know that the same type of debates such as which coffee shop is best in Seattle, or which football team is best in Argentina, happens all the time in tech. Developers can fight furiously for hours about the favorite text editor, programing language, and open source project.
When you hire someone from another company, you take some of that company’s DNA into your own company.
I have seen it many times. Hire 5 people from Salesforce and all of a sudden, your company feels like Salesforce, hire five Googlers and you get some of Google in your company. I am part Google, part Microsoft, part Slack, part Amazon.
This is not a problem as long as you do not hire everyone from the same company. You want to build a culture of your own, so make sure you get a diverse set of candidates.
Everyone celebrates version 1.0.0 — but it is version 1.0.3 that actually brings customer value.
Tech companies are optimized to celebrate launches. Most of these launches are rushed out the door, following external pressures like arbitrary timelines. It is not until version 1.0.3 where the product stabilizes and becomes useful for its customers.
Someone in 10 years is going to call your shiny new software “old crap” and will wonder who the hell designed such a bad product.
In tech, we tend to look at software that was developed 5–10 years ago as ancient. We tend to ask ourselves “who the hell thought it was a good design? Who thought of this horrible architecture?”
Remember that someone, in 10 years, if you are super lucky and successful, will look at your product, and say the same.