Optimizing for Engineering Efficiency

In my observations across the industry, I observe a lot of inefficiencies from engineers in the practice of solving problems, and there are simple ways to optimize for efficiency.

1. Optimizing for the vision and mission

For engineers – Every time you are making a decision, think about the end goal, whether this decision would help towards achieving the end goal, and whether there are any alternate solutions which would help us to achieve the end goal more efficiently.
All the other things are secondary, and when you are highly motivated towards the mission, those shouldn’t get in the way of efficiency.
Too often, engineers prioritize ‘the other things’ over the primary goal.
Do not prematurely optimize. Do not build things that MAY be helpful in some years in the future.
Too often, over-engineering is highly inefficient, always be aware. And remember, “Perfectionism is suboptimal”

2. Individual Ownership

For engineering managers – Get highly motivated, efficient engineers and empower them by giving individual ownership, responsibilities, autonomy, and trust, and try to make sure that each individual can function independently (very loose coupling)
Cut out the middleman, whenever it is possible.
There is an illusion that the middleman is “needed”, but most of such alluring “need” is rooted in the inefficient engineers.
I believe that it is engineer’s responsibility to communicate, understand the problem and context, propose and design a solution, deliver and evangelize it.
(Esp. the case of product managers – this is the kind of illusion of need, whose role mostly comprise of filling the gap between stakeholders and inefficient engineers, which is a highly irrelevant role in the case of efficient engineers)
To achieve this, a cross-pollination across different domains and teams in the organization is MUST.
Let the engineers sit together with the stakeholders, in person, and let them figure out things.

3. Do Not Repeat

Try to reduce the number of times which the documentation of context and business logic is repeated.
Although I agree with each level of documentation as the part of software engineering serves its own purpose, we should be able to modify those according to our need.
Always think about the COST OF DOCUMENTATION –
Here, Documentation includes all the requirements and design documents, the source code, the comments and the different levels of tests, and user manuals, etc — EVERYTHING is a document.
The Cost of Documentation is – every single document that we create, repeats the context and business logic of the application.
As we know it, software and its engineering is inherently agile. And every single change requires a change reflected across ALL the levels at which documents are created!
So, when you are creating a document, always think about this cost!
One should write what is ABSOLUTELY NECESSARY for achieving the goal / solving problem!

4. It’s about time!

As Leonard Bernstein once said, “To achieve great things, two things are needed; a plan, and not quite enough time.”
In my observation, the root cause of the problems mentioned in (1),(2),(3) is that having ‘too much’ time at hand! Planning is indispensable. So the autonomy for engineers. In my observation, motivated engineers are highly efficient when they work in constrained time-frames.
Especially it is highly effective for the inefficiency inducing problems like over-engineering and premature optimization.
A few months back, I published a post focusing engineering operations and deeply technical and infrastructural aspects to optimize for efficiency, and as I have made further observations, I believe the solutions and practices mentioned above solve the root cause, and those technical/infrastructural aspects can be augmented on top of these to improve the efficiency further.