Upset the Apple Cart

Good engineers are obsessive problem solvers. They want to solve hard problems. Harder the problem, greater the high they get.

Good engineers care deeply about the quality of their work. This often translates to caring about the quality of their teammates’ work.

Good engineers challenge the status quo. They also like to be challenged.

Good engineers want to work with other good engineers. They feed on each other’s positive energy and a vibrant environment is created where ideas are debated and knowledge is shared.

Good engineers choose to work and stay in companies whose vision aligns with their interests. They like to continue at a workplace where they don’t have the anxiety of getting stagnated.

Because they know that all of the above factors finally help them grow and succeed in their careers. Good engineers are therefore driven by rational self interest.

And that is good!

Every tech company needs at its core a critical mass of good engineers. They are the ones who build products that customers find engaging, scale backend systems, write high quality API documentation, debate technical decisions freely and openly, plan sprints, stretch as much or as little as is required to complete the tasks they have committed to, manage releases, communicate proactively when something breaks, fix bugs and inefficiencies without being asked to, and publish RCAs voluntarily.

In order to achieve these goals they will figure out the right set of tools and processes and convince Engineering Managers and Product Managers to align with those. They treat EMs and PMs as their peers, as facilitators. They do not elevate them to the status of “leaders” or “visionaries” who will solve their problems and guide them all the way; nor do they relegate them to the role of “glorified coordinators” whose job it becomes to run around brokering deals across multiple tech teams, breaking logjams, micromanage, and relentlessly follow up. They seek clarifications, challenge assumptions, contribute product ideas, and get on to customer calls to get a first hand understanding of a use case. All in all, they consider product building a collaborative effort. They help EMs and PMs do their jobs effectively which primarily comprises: giving all the relevant context and information to build a product; setting clear business goals and success criteria; helping in planning and prioritization; shielding engineers from constant external turmoil.

This is because good engineers are secure and confident; they set high standards for themselves. They are assertive. They seek a certain level of autonomy that suits them. They discuss their growth path openly with their peers and managers. Their primary accountability is to themselves and none other. They understand implicitly that doing all of this is in their own interest.

They do of course understand that their work benefits the company, which in turn benefits them. But they are not doing this out of a misguided sense of loyalty or by notions around what this company means to them or has done for them. In other words, they would do the same were they working elsewhere. Because in their worldview, this is the right thing to do.

Lot of tech companies do manage to build a core of good engineers when they start out. And as a startup grows into a bigger company this core is supposed to expand, which doesn’t always happen. Most such companies go through a period where they have a nontrivial number of (formerly good) engineers who have grown to be either cynical or jaded. They are neither inspired nor infuriated by the company’s vision or lack thereof any longer. At times they start becoming insecure, bitter even.

And the company’s leadership doesn’t seem to be able to influence significant change however hard they try. They bring in seemingly better, more rigorous processes in hopes of digging deeper and finding out the source of the rot. Structured accountability metrics, OKRs, and other frameworks come in. All of these are necessary — make no mistake — especially as a company grows. It’s important to measure things. It’s important to bring discipline across functions.

But this top down approach — while necessary is hardly sufficient. Further, it only seems to have superficial influence. In fact, at times, in the hands of cynical employees processes can becomes veils behind which they can hide their inadequacies. Engineers who are unmotivated start feeling productive by measuring it through the number of tickets closed or items ticked off. There is no noticeable qualitative impact. Product and tech start suffering.

On the other side, processes start getting used as a stick by management to “hold people more accountable”, to penalize them. This probably helps in slowing down the rot in the short term, but hardly paves a path for the future. The remaining set of good engineers, which is already a dwindling minority by the way, start perceiving this as a lack of vision on the part of tech leadership, and get turned off. They might even start leaving.

Most companies that survive and hit the growth phase go through this phase where they become heavily dependent on a large number of long serving and loyal but uninspired and/or entitled engineers. They seem to be holding the fort, guarding it jealously. It need not be this way at all, of course. The early team brings in a lot of context, a lot of value. They can easily play much bigger, more strategic perchance, role by being open to change, and getting out of the way sometimes. They can be thought leaders and facilitators. But as it happens often, they are entrenched. It appears like there’s no way in to it for anybody new or out of it for the old ones.

Regardless, leaders must think beyond the short term. They must be prepared to make some sacrifices to achieve bigger things. Lay a siege to that fort, break down some walls, and let fresh air and sunlight enter.

If all this sounds too lofty that is because building a company from scratch and growing it are indeed lofty goals. Most startups don’t face this problem because most startups don’t reach this stage. They perish much before that. Every startup that has grown enough to become a bigger company needs, nay deserves, to be perturbed out of its local optima from time to time such that it at least stands a chance of fulfilling its promise, of getting closer to the global optima.

So, this is essentially a note to self. Go ahead. Upset that apple cart.