Tech Lead — 7 Damaging Myths
In a recent podcast episode, a veteran in the industry has given a lot of advice and definitions that didn’t make sense to me.
Most revolved around the Tech Lead, who is a functional expert with no people management responsibility.
“The primary goal is to reduce tech debt and keep the codebase clean”
As we know, if we over-index on reducing tech debt, we make less business progress, which can be detrimental.
Paying tech debt for areas of the code that are rarely touched just to pay tech debt without any business case is missing the point.
I think the primary goal is driving the business through technology, solving customer problems and bringing business value in a sustainable way. Tech debt is taken into consideration, but it is not the primary goal.
Another important goal of the Tech Lead is to train others and make them better.
“Work in places where you feel appreciated”
This advice made sense in the beginning, but then this veteran admitted she had had 27 jobs in 30 years, and she often felt unappreciated. This made me wonder whether she worked on unimportant things (e.g., diligently paying tech debt).
She either did not get useful feedback, misunderstood it or ignored it, continuing to do what she honestly believed was best.
I do agree you should be appreciated. For this, you need to get candid and timely feedback, which is sometimes not the case.
“Only the Tech Lead writes documentation”
No question that we need good documentation that is up-to-date. It’s used by our customers, integrators, support, own team members and for onboarding.
Why should only the Tech Lead write it? Why advise having a bottleneck and not allowing others to do it, update it and get better at writing? Why gatekeeping?
“Estimate tickets together”
The advice was that the Tech Lead should not estimate story points of tasks or stories in a Scrum team alone because they would do them faster. This advice is very agreeable, but
First, it’s about relative effort or complexity, not time to finish.
Second, the estimation is not personal. We don’t know who would pick the task. If the “sprint” is planned per person (who does which tasks) this is not really a team anymore.
Third, it implies that all teams are estimating tickets, which is simply not true. For example, Kanban doesn’t have this notion and not everyone is using Scrum.
The Scrum guide doesn’t have anything to do with estimations, story points or velocity.
“Preventing incidents is the ultimate goal”
Yes, incidents are bad for business, reputation, NPS and morale. But incidents will happen, so it’s better to focus on shortening the time to recover (MTTR) rather than take time-consuming extreme and expensive measures and processes, gates and bureaucratic sign-offs to prevent any possible scenario, causing delays on most daily work types. When incidents do happen, after fixing, retrospect and address the root cause to prevent the same thing from occurring again.
Trying to always play it safe will slow us down, and our competitors will run many more experiments per time period and eventually put us out of business.
For example, if the company’s goals for the quarter include growth at all costs, investing in resilience breaches the strategy.
“From time to time, manually check the disk space”
The expert suggests that we should put manual effort into checking arbitrary metrics (also in a cloud environment). Luckily the industry has progressed and we now have observability best practices and tooling — monitoring and alerting upon reaching some state or value.
Moreover, business observability, e.g. number of requests, searches or orders is more meaningful than the memory or CPU level of a machine, which can be easily autoscaled in the cloud or with kubernetes.
“Heavily invest in standardization”
Having standards helps us to move quickly, know what to expect, and not re-invent things or quarrel over minor details like styling.
Some teams are completely different in technologies they use, tools and methodologies, and such standardization will slow things down and shift the focus from bringing value to making sure all are adhering to the documentation, especially when done in an “ivory tower”. Is it even a problem or worth fixing?
Instead of wasting engineering time in reviewing style in pull requests, start with some default linters for code, decide on common ground rules for teams and ways of working for each team and encourage the most effective ones and allow for evolution.
