When I was a junior engineer, I thought that it’s my manager’s job to manage me. It even says so in the name: manage-r. I just do my work, and my manager manages me.

In reality, the reporting relationship is a two-way street, no different from any of your personal relationships. It requires effort from both sides. As a reportee, you manage up:

Understand your team’s goals, which are the same as the manager’s goals. Then, understand what you need to do for the team to achieve its goals. Ask your manager explicitly, “What do you need from me for the team to achieve its overall goals?” Asking explicitly is good because managers rarely communicate it so directly [1]. In addition to the what, the how, which is the overall context, is also important. For example, if the goal is to launch an MVP ASAP with a low quality, and you take a lot of time to deliver something polished, you’re not fitting in to the overall plan. …


First, seek to understand before being understood. This is an area I need to improve in, too: I should listen to what the other person is saying, without looking for an opportunity to get my point in. Or to use what he’s saying as a jumping-off point to making my own point. Which superficially sounds like building on the other person’s point, but is actually not, so it’s in a way dishonest. When listening, you can ask clarifying questions to understand, or to probe areas he may not have thought about to figure out if he has a view there, but not disagree. …


Most blockchain applications are useless [1], built by people who have no clue what they’re doing, and funded by people who have no clue what they’re funding.

There are a few reasons for this:

First, a blockchain does away with the need for a central authority, but such an authority is often helpful. For example, someone proposed an Uber-like site that’s operated on a blockchain rather than having one company control the platform. But I want a minimum standard that I can expect from a taxi, and I want a central party to enforce it. If I have a problem, I want to be able to contact someone who can take care of it. If a driver repeatedly mistreats passengers, I want him booted off the platform. Some naive techies think that middlemen are always bad. But a trusted authority often helps. …


Many services in India are designed for the top of the pyramid, the disporportionate few who fly regularly, own cars, have airconditioned houses, and have broadband at home. If you think everyone has broadband at home, do.

A few years back there was a recognition that startups should build products for everyone, just not the elites. This was dubbed as building for Bharat, as opposed to for India.

But we don’t hear much about building for Bharat any more. This hype train has passed us by, and good riddance:

For a company to make a profit (and therefore stay in business), customers should pay more than what it costs to make and sell the product. This requires discretionary income, money left over after buying essentials, that can be spent on a new product or service. But people of Bharat can’t afford this. …


A shared with me a fascinating management philosophy, which I’m not going to implement as is, but is worth considering:

In his company, managers can also persuade, but each person has ultimate authority over what they choose to work on, and how, and they can ignore what their manager is telling them. Managers can enforce their view only in the following cases:

  • Ethical matters.
  • Things that require coordination like having a meeting, which can’t happen if different people want to meet at different times.
  • Decisions that have a long-term implication.

But if someone is making a decision that has only short-term implications, managers can’t overrule them. …


If you’re a manger, you have to be in different mindsets at different times:

Doer: As a doer, you work in an individual capacity: If you’re an engineering manager, code. If you’re a design manager, design something. If you’re a sales manager, make some sales calls. Unless you’re down in the trenches doing the day-to-day work at least one day a week, you can’t manage well, and will become a pointy-haired boss.

Coach: As a coach, you observe what people are doing, identify problems, and suggest how they can do better. …


I won’t work at a company that’s focused on enterprise customers. Say companies paying $50,000 or more each.

Why?

First, with enterprise, the focus shifts to checkbox-ticking, like “we have all eight features in this matrix, while others have only 4 or 5”. Of course, the company will pick features so that they tick all of them. This is a bad way to evaluate a product. It reminds me of the idiots who, when the iPhone was new, sent me forwards with a long checklist of features the iPhone didn’t have, like: Java ❌ Flash ❌ Physical keyboard ❌ Removable battery ❌ MMS ❌ Use mp3 file as ringtone ❌. When selling to the enterprise, a team of salespeople fly in and make a fancy PowerPoint presentation, which is a dumb way to evaluate a product. …


If I were looking for an analytics service, I would not use Firebase Analytics. It has too much cognitive overhead, too many surprises, too many things you have to do manually that it should have done by itself. (I would use Firebase’s BaaS tools, and perhaps use Firebase Analytics in that context, but not by itself, if I were just looking for an analytics service.)

⦿ Firebase Analytics does not distinguish between production and development versions of your product. As you develop your app, you’ll run it locally, and as you do this, analytics data from your local runs will get mixed with production data, corrupting it. To fix these, you need to detect such builds and call setAnalyticsCollectionEnabled(false). There are multiple kinds of builds to detect: running from Xcode or Android studio, running on the simulator, debug mode builds, and testing production builds before launch using TestFlight or other similar tool. …


On mobile, native apps have a lot of benefits over web apps. But, to avail of these benefits, native apps throw away a lot of benefits of web apps:

  • You have to install native apps.
  • You have to keep them updated.
  • They take up space on your phone.
  • They add yet another icon to your home screen or launcher.
  • To do something, you have to stop and think, “Which app is this part of?” For example, to order groceries from Amazon, I open the Amazon app, but don’t find it. I later realise that I should have remembered to open the Prime Now app, not the Amazon app. To join a Meet call, I open the Gmail app. This is counter-intuitive. The web doesn’t have these rigid boundaries. You keep navigating smoothly from one web page to another without regard to which app they’re part of. It’s like driving down the road, not like crossing a border. …

The iPhone, when it launched, didn’t even have basic features like copy and paste or multitasking. What it did have was very polished, and the first one iPhone bought, the 3GS, met a bar I didn’t know existed. Over the years, Apple added these and a lot more missing features, while maintaining a minimum level of polish.

By contrast, Android had features like multitasking from the very beginning, and added features faster than the iPhone in its first few years, always remaining ahead in this regard. It was a crappy user experience, built with no attention to detail. Over the years, Google polished it, to the extent that it’s a very similar product as the iPhone, as of today. Both have a polished UX, both are responsive, have good battery life, are more extensible than most people need, have all the apps you need, have great screens, and more. …

About

Kartick Vaddadi

CTO, Squadcast. Earlier: IIT | Google | Founder | Advisor.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store