Category: Engineering Leadership

How to Manage Technical Debt in 2023: A Guide for Leadership

How to Manage Technical Debt in 2023: A Guide for Leadership

In this article, I will summarise effective strategies and best practices to tackle tech debt head-on.

Technical debt is an inevitable reality in software development. But, it can be leveraged just like a financial loan/debt can help you achieve your goals, if managed properly.
It can be used to drive competitive advantage by allowing companies to launch new products and features faster, experiment with new technologies, and improve the scalability and performance of their systems. However, like all loans, it need to be “Repaid” properly and at the right time, failing on it will create a downward spiral.

If you’re not careful, technical debt can quickly become a major burden that slows down development and makes it difficult to add new features or even fix bugs in a timely manner.

We will discuss how to identify technical debt and the signs of poorly managed debt, and then provide a strategy for reducing it. We will also discuss what a healthy level of technical debt looks like and how leaders can use it to their advantage.

Good Tech Debt Vs Bad Tech Debt

Robert Kiyosaki, the author of Rich Dad Poor Dad, famously said:

Bad debt takes money out of your pocket, while good debt puts money in your pocket.

– Robert Kiyosaki

The same is true of tech debt.

Technical debt is the cost of not doing things the right way the first time. Good technical debt is accrued when you make trade-offs to meet deadlines or deliver new features quickly. Bad technical debt is accrued when you make poor decisions or cut corners.

Bad tech debt will probably make your PMs, Sales and CEO happy for a quarter or two. But after that, they will be asking why everything is behind schedule and dealing with customer complaints because things aren’t working properly.

Now that I have presented the obvious in a familiar “Quadrant”, you can actually skip the terminologies and definitions part of this article! 😀

For my verbal brethren, Which is the Tech Debt you’d need to ruthlessly hunt down to extinction? Obviously, it is the untracked, undocumented ones. And the ones which are dragging your team on a downward spiral (immaterial of whether it is tracked or not)

Why does your Tech Debt keep accumulating?

Before we can think about building a strategy to solve tech debt, we need to understand how it gets out of control in the first place.

It’s called “impact visibility”.

Fixing code debt issues is impossible if:

1, You’ve no record of what technical debt issues you have

2, You’ve got a backlog, but you can’t see which issues are related to what code

In both cases, you can’t prioritise tech debt over shipping new features.

We need to get more granular about what impacts these two tech debt cases above.

  • Issue invisibility — There’s no source of shared knowledge. Codebase health info is locked in (few) engineers’ heads.
  • No code quality culture — Shipping fast, whatever the cost, like it’s going out of fashion.
  • Poor process — Tech debt work sucks. Nobody likes creating Jira tickets. “Jira” has become a dirty word.
  • Low-time investment — Justifying the time to fix tech debt or to refactor is a constant uphill battle. After a point, engineers become silent!

Lack of context — Issues in Jira are a world away from the hard reality of the codebase. They’re not related in any way.

So what’s the source of this? Let’s talk strategy.

Spoiler… It’s about changing organisational culture and developer behaviour to track issues properly.

Creating a strategy to reduce technical debt

Track. Issues. Properly.

Good tech debt management starts with team-wide excellence at tracking issues.

You can’t have a tech debt strategy without tracking.

The engineering leader’s job is to make that “issue tracking” easy for your team. There is supposed to be a software for that – Jira, Asana, Rally or something of that sort.

The problem is, I’ve never believed they really get to the bottom of the problem, and after speaking with scores of engineers and leaders about it, they usually don’t either. My personal belief is most companies suffer on the velocity after their Jira rollout! It is a bit like,

No two countries that both have a McDonald’s have ever fought a war against each other.

Thomas L. Friedman – in The Lexus and the Olive Tree!

As a leader, You need to find a way to…

  • Show engineers when they’re working on code with tech debt, without them having to jump thru 3 hoops.
  • Make it really easy for team members to report tech debt.
  • Create a natural way to discuss codebase issues.
  • Integrate tech debt work into your workflows and involve PMs if required.

There are multiple ways to achieve this, the easiest is to not address it. Ie: not address it intentionally, just tweak your existing pipeline. This can be done by,

  • A very robust linting & integration to the IDE
  • Tighter Git rules for commits
  • SAST which runs on the pipeline
  • and can feed into the IDE

Prioritising impactful tech debt

At this point, it should be obvious, but prioritising the right issues is only possible if you’re tracking the impact of these “issues” and it could be direct or indirect (Dependency, Sequencing, Rework avoidance etc) .

Once you’ve got them, you should regularly and consistently use them to decide what to address. This usually happens during the backlog grooming or sprint planning sessions. But, this decision-making process needs to be strategic. Not at all tactical, ie: DO NOT delegate it to the whims and whimsicals of your TL/PM or even EM.

You or someone with a context of the organisation and position on sales, clients, revenue etc., should be doing this.

A good way to start is by choosing a theme each time you prioritise issues. For example, you could prioritise issues that…

  • Are impacting a specific feature you need to work on in the next quarter
  • Are impacting the customer’s UX
  • Are affecting efficiency/morale on the team
  • Are impacting the security posture

This is often straightforward if you’ve got high-quality issues that traceable to code and tagged as such.

Most people wonder how to get the time for these “Tasks”. I have two recommendations.

  • Take an entire sprint every quarter to repay the tech debt (Will need high-level buy-in, It is slightly harder to align your CXOs)
  • Allocate 15-20% of bandwidth in every sprint. (Easier to achieve buy-in from CXOs, harder to drive with engineers)

Engineers generally won’t prioritise tech debt work by themselves because of the conflict of interest/pressure of shipping fast. This was evident from multiple high velocity/impact software engineering teams including ones at AirBnb, Netflix and Spotify. A commitment to code refactoring and maintenance work should be endorsed and supported from the top and reinforced regularly.

How much Tech Debt can you take on?

Managing technical debt is like managing financial debt. You can use it to your advantage, but you need to be careful not to let it get out of control.

Your technical debt budget is the amount of technical debt that you are willing to take on in order to achieve your business goals. You should not try to solve all of your technical debt at once, but instead focus on the most important items.

Prudent technical debt is debt that you take on deliberately and knowingly, in order to achieve a specific goal. For example, you might take on technical debt to launch a new product quickly, or to add a new feature that is in high demand by your customers.

If you manage your technical debt properly, it can be a powerful tool for gaining a competitive advantage. However, if you let your technical debt get out of control, it can lead to serious problems, such as increased costs, delays, and security vulnerabilities.

Concluding remarks:

Technical debt is one of the most neglected areas of software development. It is often only given priority when it is too late and has already caused serious problems.

However, when leaders work together and develop a consistent and process-driven strategy, technical debt can be effectively managed.

The best engineering teams are constantly thinking about how to use their technical debt budget to their advantage.

References and Further Reading:

No McKinsey, You got it all wrong about developer productivity!

No McKinsey, You got it all wrong about developer productivity!

Disclaimer: I have been an enormous proponent of Developer Productivity and have tried to implement automated metrics collection in 3 orgs with varied success. In my Mentoring sessions with early-stage startup leaders as well, I (re)enforce the importance of being aware of Dev Productivity. So much so, that I have written a 2-part article on the same here, here and here. I have also been a huge fan of McKinsey and how they seem to get answers which eluded the attention and resources of mega-corporations or governments alike. However, this article is written to communicate an entirely different perspective. In my opinion, McKinsey has got this entire “framework” thing about “dev productivity” wrong.

Introduction:

About a month back, McKinsey published an article claiming that they have developed a framework to measure productivity. They also acknowledged the fact that they were simply rehashing some of the existing metrics (like DORA and SPACE), which were used by Engineering Leaders and have simplified it (without the context) and are pitching it to their traditional buyers, the C-Suite executives in Mega corporations. Actually, some of these metrics can be useful tools if used correctly -One example is Hand-offs. But, the main reason I have chosen to write this article is their central focus seems to be “Coders should code”. It also appears to have A) missed the context of every metric, OR B) Omitted the context so as not to burden their target audience.

Finally, there is a mix-max of things to track, metrics to monitor and Opportunities to Focus, which looks like

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was reckless!

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was Stupid!

The Legendary Kent Beck has written a deep 2-part piece on countering the conjectures presented by McKinsey and elaborating on the gaps that engineering orgs are traditionally bound to manifest. It is very well written and covers almost everything. There are also a bunch of other eminent Software Engineers who have written on this and I have tried to give a quick lot at the bottom of this article.

What Was I concerned about?

Focus On Activities

I was primarily concerned about the lack of focus on Outcomes and Impact and a focus on the “Activities” in the proposed framework!

Any engineering leader or manager will tell you that Code Review Velocity and Deployment Frequency have nothing to do with measuring outcomes. While I will not discount Cycle Time or MTTR (I take pride in building multiple teams with one of the lowest MTTR and Cycle times in the ecosystem). They are indicators of some process elements/activities that could lead to outcomes. If we want to measure something, it should be Outcomes, not activities!

Focus on Optimisation of Irrelevant Metrics

Code Review Velocity:

If you want to time-motion the code review process in the entire stream map, you’ll find that async code review is killing your productivity. Pairing improves that dramatically. Instead of trying to sub-optimize for code review, measure the thing we actually want to improve. Which will be “Cycel Time”.

Story Points Completed:

Let’s agree on a basic fact. A “story point” is a made-up number. It was conceived as yet another way to obfuscate estimates for thought work that is difficult to estimate. As originally conceived, it represented the number of mythical “ideal days” of effort. There’s so much time wasted on getting better at “story pointing,” arguing about the Fibonacci sequence, “planning poker,” and other story point nonsense. Frankly, it is one of the “Bad” elements of Scrum! As a leader, you should find and remove handoffs and wait times. Story points are useless for anything and even more useless for this goal. Track throughput instead. 

Handoffs:

This is a good one. Good job, McKinsey. You got something right. Stop using testing teams, use pairing instead of code review, operate what you build, and don’t have any people doing anything manual to the right of development.

Contribution Analysis and Opportunities focus

In the other focus areas, they have listed metrics at the individual level that can be useful unless you measure “developer satisfaction,” “retention,” and “interruptions” at the individual level. These should only be measured in aggregates to prevent any cognitive bias. IMO, Things start getting really toxic in the “Opportunities focus” section, though.

I have been part of organisations and processes where there was a focus on tracking and measuring the outcomes of individuals. It did not play out well, ever. My Conclusion after reading the article for the second time is that McKinsey thinks their intended audience (CEOs and CFOs) cannot understand “systems thinking.” Now, If you roll out this or a similar framework and announce this and what do you think will happen?

You have a group of people all working on the same backlog but not acting as a team. Code review suffers, mentoring sufferers, pairing is hard, work breakdown suffers, etc. Anything that requires more than one person to conduct/conclude, including helping someone get unstuck, will get deprioritised!

Overall, The inferences seem to be based on hard facts, but the conjectures are all flawed.

Why This Now?

At this point, I want to highlight what “Triggered” me to write this, read the following.,

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

McKinsey’s Article on the purported Framework

Wow. I pray for that company.

So, I believe after McKinsey pointed to the fact, that developers are involved in irrelevant things like design, architecture etc. They created separate towers of responsibility for design. In that case, I am puzzled about who will be responsible for the minor things like dependency management, prerequisites, versioning, capacity planning, concurrency, scalability etc.

Did they get anything Right?

Yes. There are tonnes, but they are buried at the bottom. Their focus on Hand-offs and cycle times are really worth tracking in any engineering org. To the authors’ credit, they have also identified some of the core issues with measuring Developer Productivity. But, someone higher in the firm seem to have suggested to soften the blow. So, they have diluted and buried those sections. I will share 2 gems here.

To truly benefit from measuring productivity, leaders and developers alike need to move past the outdated notion that leaders “cannot” understand the intricacies of software engineering, or that engineering is too complex to measure.

The real problem is that in many large organisations, “The Management” doesn’t understand the work they manage. Management can understand the intricacies of software engineering if they become leaders and study the work they manage. In a large behemoth, not all managers are leaders. They want a framework and will enforce it with an iron fist. Now, McKinsey has delivered them a framework!

Learn the basics. All C-suite leaders who are not engineers or who have been in management for a long time will need a primer on the software development process and how it is evolving.

This one Nailed it! The primary reason “Management” finds it difficult to measure the right thing is because they sometimes do not understand the work they want to measure. Leaders who understand do measure the right things. My primary concern with this framework is, in trying to solve this, McKinsey has made the problem worse!

Just google “McKinsey developer productivity” and you’ll find more articles on how this framework is flawed than the original article link!

Anto’s Response to the Article and the purported Framework.

References & Further Reading/Watching:

1, Mc.Kinsey Article – https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
2, Kent Beck’s rebuttal – https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
3, Redidit – https://www.reddit.com/r/programming/comments/1650595/measuring_developer_productivity_a_response_to/
4, Level Up Coding – https://levelup.gitconnected.com/the-developers-productivity-can-t-be-measured-in-mckinsey-s-way-an-analysis-4d81924279ae
5, Measuring Developers Productivity… McKinsey what’s the point? – https://www.youtube.com/watch?v=wjQn8nnkXTs
6, Can We Measure Developer Productivity? A Reaction to McKinsey’s Article – https://www.youtube.com/watch?v=ETa24ErdcwQ
7, HOW TO MEASURE ENGINEERING PRODUCTIVITY? – https://nocturnalknight.co/2022/11/how-to-measure-engineering-productivity/
8, Business Value delivery by Engineering Teams in StartUps – Part 1 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-1/#comment-773
9, Business Value Delivery by Engineering Teams in StartUps – Part 2 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-2/
10, Space Metrics – https://www.harness.io/blog/space-metrics-get-started
11, DORA Metrics – https://www.leanix.net/en/wiki/vsm/dora-metrics
12, Dave Farley’s Response To The NONSENSE McKinsey Article On Developer Productivity – https://www.youtube.com/watch?v=yuUBZ1pByzM

Is the myth of a “10X Developer” Real?

Is the myth of a “10X Developer” Real?

If you’re a software engineer, manager or leader, I am sure you have heard the term ‘10x developer’ used in discussions. It refers to developers who are purportedly 10 times more productive, or capable, than their peers, while it is a hotly contested category. Some refer to it very liberally, others deny that it even exists. In the last 40+ years, the ‘10X developer` has become a ‘Loch Ness` of the tech world, fueled by the hype associated with Silicon Valley.

I’m not about to delude myself into thinking that writing a blog on it to pass my verdict will put these theories to rest, but the question has gained enough traction that it deserves a little articulation. 

Do 10x developers really exist, and if so, how would we distinguish them?

Framing the Issue

All of us can acknowledge that the range of skills in most human activities can be extensive. A marathon runner can cover roughly 10 times the distance that an untrained person could, while a professional chef can cook a 5-course meal in 1/5th the time it takes an average person to do a 2-course meal.

Coding, which is a hugely complex field unencumbered by physical limitations, should naturally show differences in the skill that vary by orders of magnitude. Thus, if by 10x developer we simply mean a person whose skill level is in a different league compared to someone else, then clearly they exist. 

How could anyone argue otherwise?

Here’s the rub though, in the data-driven and lexically precise world of modern tech, that’s not what 10x developer means. Instead, a 10x developer is supposed to be someone who genuinely outperforms others by 10 times or more on some quantifiable scale. That ‘quantifiable scale’ is where the problems start.

Where did the term actually come from? Enter Coding War Games.

Coding War Games

Tom DeMarco and Tim Lister have conducted the “Coding War Games” since 1977. This is a public productivity survey in which teams of software implementors from different organizations compete to complete a series of benchmarks in minimal time with minimal defects. They’ve had over 600 developers participate. Its results are publicly available and is very informative, to say the least. Jeff Lester published a wonderful piece on the origins of the 10X developer here

The top findings from these are,

1, Get your working environment Right

The overriding observation from this study is that quiet, private, dedicated working space with fewer interruptions led to groups that performed significantly better.

2, Remove the Net Negative Producing Programmer

Some developers are “net negative producing programmers” (NNPP), that is they produce so many defects that removing them from the team increases productivity. This is the opposite of a 10X developer, these people are the ones that make the team productivity go from bad to worse.

The Problem with Measuring ‘Skill’

Even where skill can vary wildly, differences will not necessarily be quantifiable. A talented artist may know how to create a painting that teleports you to a whole other world compared to an average artiste who can transport you to the scene.

But the question is, can you attach numbers to that painting’s beauty?

The work of a developer isn’t nearly as abstract, but not all of it can be reduced to metrics either, and definitely not the programming skill itself.

A less glamorous approach may be to judge a 10x dev not in terms of skill but in terms of productivity. Someone who can write 500 lines of code when it takes others to write 50 would then fall in that category.

If you know anything about programming, however, you’ve probably already spotted the problem with this line of thinking. Longer code isn’t necessarily more efficient, and for most people there tends to be a positive correlation between how quickly one works and how many bugs one creates.

This is not to say that programmers can’t produce bug-free code much faster than their peers. Where this statement proves fallacious though, is in trying to peg that difference to a single metric. There are myriad factors at play that will affect a developer’s productivity outside of their skill, including their team and the environment they find themselves. In fact, depending on the situation, the 10x tag may be inaccurate because a developer could be programming well over 10 times as much as another and still produce 1/10th of the ‘Outcomes’!

What should be our conclusion? There can be no doubt that the field of programming has its own Mozarts and Vincent Van Goghs, and few would object if these people were described as being ‘orders of magnitude’ better than the rest. But it is important to recognize that this is only a figure of speech, and not something meant to be used according to its precise quantitative meaning.

I can’t presume to speak for the tech industry as a whole, but I for one have noticed a worrying tendency to read the expression ‘10x developer’ literally.

Ultimately this does more harm than good, as it spreads the myth that there is some universal metric whereby every programmer’s value can always be quantified. 

Important qualities like creativity, client focus and teamwork are entirely omitted in this way of thinking, which is why my final suggestion is to stop worrying about lofty 10x developers and whether you are, aren’t, or may or not become one. 

Simply focus on being the best developer you can be. That will always be enough.

References & Further Reading

Origin of a 10X developer

https://medium.com/ingeniouslysimple/the-origins-of-the-10x-developer-2e0177ecef60 

https://gwern.net/doc/cs/algorithm/2001-demarco-peopleware-whymeasureperformance.pdf

https://news.ycombinator.com/item?id=22349531

Is NoOps the End of DevOps?

Is NoOps the End of DevOps?

Some say that NoOps is the end of DevOps. Is that really true? If you need to answer this question, you must first understand NoOps better.

Things are moving at warp speed in the field of software development. You can subscribe to almost anything “as a service” be it storage, network, computing, or security. Cloud providers are also increasingly investing in their automation ecosystem. This leads us to NoOps, where you wouldn’t require an operations team to manage the lifecycle of your apps, because everything would be automated.

Picture Courtesy: GitHub Blog

You can use automation templates to provision your app components and automate component management, including provisioning, orchestration, deployments, maintenance, upgradation, patching and anything in between meaning significantly less overhead for you and minimal to no human interference. Does this sound wonderful? 

But is this a wise choice, and what are some advantages and challenges to implementing it?

Find out the answers to these questions, including whether NoOps is DevOps’s end in this article.

NoOps — Is It a Wise Choice?

You already know that DevOps aims to make app deployments faster and smoother, focusing on continuous improvement. NoOps — no operations — a term coined by Mike Gualtieri at Forrester, has the same goal at its core but without operations professionals!

In an ideal NoOps scenario, a developer never has to collaborate with a member of the operations team. Instead, NoOps uses serverless and PaaS to get the resources they need when they need them. This means that you can use a set of services and tools to securely deploy the required cloud components (including the infrastructure and code). Additionally, NoOps leverages a CI/CD pipeline for deployment. What is more, Ops teams are incredibly effective with data-related tasks, seeing data collection, analysis, and storage as a crucial part of their functions. However, keep in mind that you can automate most of your data collection tasks, but you can’t always get the same level of insights from automating this analysis.

Essentially, NoOps can act as a self-service model where a cloud provider becomes your ops department, automating the underlying infrastructure layer and removing the need for a team to manage it.

Many argue that a completely automated IT environment requiring zero human involvement — true NoOps — is unwise, or even impossible.

Maybe people are afraid of Skynet becoming self-aware!

NoOps vs. DevOps — Pros and Cons

DevOps emphasizes the collaboration between developers and the operations team, while NoOps emphasizes complete automation. Yet, they both try to achieve the same thing — accelerated GTM and a better software deployment process. However, there are both advantages and challenges when considering a DevOps vs. a true NoOps approach.

Pros

More automation, less maintenance

By automating everything using code, NoOps aims to eliminate the additional effort required to support your code’s ecosystem. This means that there will be no need for manual intervention, and every component will be more maintainable in the long run because it’ll be deployed as part of the code. But does this affect DevOps jobs?

Uses the full power of the cloud

There are a lot of new technologies that support extreme automation, including Container as a Service (CaaS) or Function as a Service (FaaS) as opposed to just Serverless, so most big cloud service providers can help you kickstart NoOps adoption. This is excellent news because Ops can ramp up cloud resources as much as necessary, leading to higher capacity, performance & availability planning compared to DevOps (where Dev and Ops work together to decide where the app can run).

Rapid Deployment Cycles

NoOps focuses on business outcomes by shifting focus to priority tasks that deliver value to customers and eliminating the dependency on the operations team, further reducing time-to-market.

Cons

You still need Ops!

In theory, not relying on an operations team to take care of your underlying infrastructure can sound like a dream. Practically, you may need them to monitor outcomes or take care of exceptions. Expecting developers to handle these responsibilities exclusively would take their focus away from delivering business outcomes and wouldn’t be advantageous considering NoOps benefits.

It also wouldn’t be in your best interest to rely solely on developers, as their skill sets don’t necessarily include addressing operational issues. Plus, you don’t want to further overwhelm devs with even more tasks.

Security, Compliance, Privacy

You could abide by security best practices and align them with automatic deployments all you want, but that won’t completely eliminate the need for you to take delicate care of security. Attack methods evolve and change each day, therefore, so should your cloud security controls.

For example, you could introduce the wrong rules for your AI or automate flawed processes, inviting errors in your automation or creating flawed scripts for hundreds or thousands of infrastructure components or servers. If you completely remove your Ops team, you may want to consider investing additional funds into a security team to ensure you’re instilling the best security and compliance methods for your environments.

Consider your environment

Considering NoOps uses serverless and PaaS to get resources, this could become a limiting factor for you, especially during a refactor or transformation. Automation is still possible with legacy infrastructures and hybrid deployments, but you can’t entirely eliminate human intervention in these cases. So remember that not all environments can transition to NoOps, therefore, you must carefully evaluate the pros and cons of switching.

So Is NoOps Really the End of DevOps?

TL:DR: NO!

Detail: NoOps is not a Panacea. It is limited to apps that fit into existing #serverless and #PaaS solutions. As someone who builds B2B SaaS applications for a living, I know that most enterprises still run on monolithic legacy apps and even some of the new-gen Unicorns are in the middle of Refactoring/Migration which will require total rewrites or massive updates to work in a PaaS environment, you’d still need someone to take care of operations even if there’s a single legacy system left behind.

In this sense, NoOps is still a way away from handling long-running apps that run specialized processes or production environments with demanding applications. Conversely, operations occur before production, so, with DevOps, operations work happens before code goes to production. Releases include monitoring, testing, bug fixes, security and policy checks on every commit, etc.

You must have everyone on the team (including key stakeholders) involved from the beginning to enable fast feedback and ensure automated controls and tasks are effective and correct. Continuous learning and improvement (a pillar of DevOps teams) shouldn’t only happen when things go wrong; instead, members must work together and collaboratively to problem-solve and improve systems and processes.

The Upside

Thankfully, NoOps fits within some DevOps ways. It’s focused on learning and improvement, uses new tools, ideas, and techniques developed through continuous and open collaboration, and NoOps solutions remove friction to increase the flow of valuable features through the pipeline. This means that NoOps is a successful extension of DevOps.

In other words, DevOps is forever, and NoOps is just the beginning of the innovations that can take place together with DevOps, so to say that NoOps is the end of DevOps would mean that there isn’t anything new to learn or improve.

Destination: NoOps

There’s quite a lot of groundwork involved for true NoOps — you need to choose between serverless or PaaS, and take configuration, component management, and security controls into consideration to get started. Even then, you may still have some loose ends — like legacy systems — that would take more time to transition (or that you can’t transition at all).

One thing is certain, though, DevOps isn’t going anywhere and automation won’t make Ops obsolete. However, as serverless automation evolves, you may have to consider a new approach for development and operations at some point. Thankfully, you have a lot of help, like automation tools and EaaS, to make your transition easier should you choose to switch.

How to measure Engineering Productivity?

How to measure Engineering Productivity?

The fact that you clicked on this article tells me that you are leading/heading a Team, group or an entire Engineering function and most likely a fast-paced startup. Assume the following,

It was a regular weekday, and your CEO/CTO asked the most intriguing question.

Do we measure Engineering Productivity? How do we fare? What can we do to improve it?

Well, if your boss’s name is not Elon Musk or if you do not work for Twitter, you can still be saved. Go on and read through. I know it is a long read.

What is Engineering Productivity?

As with anything you’re trying to improve, it starts with measuring the right data. So, you can actually track the right metrics. This data will form the basis of your analysis and baseline. I strongly recommend you don’t change anything about your current engineering process before you can collect sex weeks’ worth of data about your processes. If you start working on processes, you could end up with a Survivorship Basis.

You should have sufficient historical data to make comparisons. On top of that, most teams work in sprints of two weeks, so six weeks of data allows you to collect data for at least three different sprints. This will give you the allowances for any spikes and eliminate any unusual stress or slack on the execution.

Next, you should make gradual changes to the engineering process to see what improves or impedes the value delivery. It’s ideal to only implement one change at a time, so you can see the effect of each change, with all other things being equal. (it never is :D)

For example, if your engineering squads suffer from significant technical debt, you may want to build an additional stub related to feature completion. Every time an engineer completes a new feature, they must document the new feature. This could mean describing the feature, how is it built, what are the outcomes, how it interacts with other functions and the reasoning behind the design decisions.

By continuously measuring engineering productivity metrics, you can determine if this change has positively impacted the developers’ productivity.

How Is Engineering Productivity Measured?

There are potentially 100s of metrics you can measure for an Engineering Org. Here are four key metrics that will help you to get started with measuring engineering productivity. And I have consciously excluded the Sprint Velocity.

4 Prime Directives of Engineering Metrics

1. The One Metrics to rule them all metrics – Cycle Time 

Software development cycle time measures the amount of time from work started to work delivered. It is a metric “borrowed” from lean manufacturing, and it is one of the most important metrics for software development teams. In plain speak, cycle time measures the amount of time from the first commit to production release.

2. The Oracle of an Engineering Leader – Release Frequency 

You should measure how often you deploy new changes to your customers (production). In addition, you can track deployments to various branches/instances, such as feature branches, hotfix branches, or QA branches. This data would show you how long it takes for a feature/fix to move through the different development stages. In addition, the Release Frequency reflects the throughput of your team. It’s a good stand-in replacement for Agile Velocity, so you don’t spook your Engineers and you are not blind as well.

3. The Guardrail – Number of Bugs

You should definitely track the number of bugs that your team has to resolve within 2 sprints of releasing a feature. This metric helps you to understand the quality of your code better. Higher-quality code should display fewer bugs after feature deployment.

While there are derivative and more evolved metrics like Defect Density, Mean Time to Detect (MTtD), Mean Time to Resolve (MTrR) and Code coverage, those onces makes sense after you’ve taken stock of and address the prime metric “ No: of Bugs” first.

If you want a more detailed list, methodology of QA metrics, refer the links given below. 

4. What is your “Blocker” – Review to Merge Time (RTMT)

This may look like a zoom-in on “Cycle time” metric we discussed earlier. But, in fact it is very different. In fact, it is an interesting metric suggested by GitLab’s development handbook. 

You should measure the time between asking for a pull request (PR) review and merging the PR. Ideally, you want to reduce the time a feature spends in the review state (or pending review state). A high RTMT prevents developers from progressing while they wait for feedback and encourages context-switching between different issues/features.

Arguably, Context-Switching is the highest productivity killer and should be avoided as much as possible

So, why would you measure all these engineering productivity metrics?

Why Is Measuring Engineering Productivity Important?

When you’re a “fast-growing startup”, it’s important to keep an eye on engineering productivity. It happens that these startups favour growth through feature delivery at the cost of effectively scaling the engineering team and ensuring the team’s efficiency.

I hear your question.

But, why does my CEO/VP/MD not understand?

Answer is simple

Assume you have to manage multiple VP’s expectations and outcomes (Sales, Marketing, Support etc), Company’s OKRs, and investors (or) board, will you have more time to dedicate to Engineering Productivity?

In these cases, technical debt can quickly grow, which will slowly kill your team’s productivity. Technical debt can have many negative consequences:

  • More bugs for your team to fix
  • Lower code quality—not only bugs but also worse code design
  • Harder to debug code
  • Scalability issues
  • A decline in overall happiness and job satisfaction

To avoid all of these scenarios, you should measure the engineering team’s efficiency and avoid technical debt buildup. Avoiding these problems before they occur is an excellent Occam’s razor.  But addressing them head-on will have a significant impact on your organisation, both materially and culturally. 

In addition to preventing your team’s productivity from going down, the engineering productivity approach allows you to experiment with various approaches to try and improve throughput & efficiency. 

So, the goal is to improve the engineering process itself. For example, introducing new tools or applying new techniques. Next, you can measure the impact of these changes on your team’s productivity.

In the next part, I will write down on how can measurement improve engineering productivity, Stay Tuned!

References:

  1. Survivorship Bias. 
    1. https://www.masterclass.com/articles/survivorship-bias
    2. https://en.wikipedia.org/wiki/Survivorship_bias 
  2. Cycle Time
    1. https://tulip.co/blog/cycle-vs-lead-vs-takt
  3. Release Frequency
    1. https://community.atlassian.com/t5/DevOps-articles/Why-should-we-start-measuring-the-Release-Frequency/ba-p/1786430 
  4. Detailed QA Metrics to ponder (in addition to No: of bugs)
    1. https://reqtest.com/agile-blog/agile-testing-metrics/ 
  5. Review to Merge Time
    1. https://about.gitlab.com/handbook/engineering/development/performance-indicators/#review-to-merge-time-rtmt 
  6. Context Switching 
    1. https://pacohq.com/blog/guide/the-high-price-of-context-switching-for-developers/ 
Why Engineers Hate your “Boiler Plate” Job Descriptions?

Why Engineers Hate your “Boiler Plate” Job Descriptions?

How to Attract the most relevant applicants with great job postings

One of the main problems in SaaS/Software engineering hiring is the way job descriptions are written. While I knew this for some time (read years) The problem is, I was too lazy to change anything about it! That is until recently, one of the candidates I was interviewing for an Engineering Manager Role said this in our introductory call,

Me: Hope you’ve had a discussion with Ms.ABC (our HR) regarding the Roles and Responsibilities. If there are questions on it I can answer them, or we can get into the agenda.

Candidate: Yes I had a discussion with Ms. ABC. But, quite frankly it was your boilerplate JD. I’d actually want to understand what exactly I’d be doing. What will I be in charge of? What will I move?

Needless to say, I spent the next ~30 minutes walking through the current team structure, where he’d come in, what will he own, what the growth trajectory looks like etc. Ultimately, we did 2 more calls before both of us were satisfied that there are mutual synergies and went ahead. It made me reevaluate all of our Job Descriptions over the weekend and rewrote almost half of them to include factual details on projects, outcomes expected, tools available, glimpse of growth among other things.

After this, I asked the HR to send this “revised” JD to the candidates once again.

 And the result was visible from Monday!

Either candidates that the HR thought super suited started dropping voluntarily from the process or candidates started expressing interest, doing more research on our stack, infra, product proposition and competitor benchmarking, before the call. Some even did a cold reach-out on Linkedin.

So, I wanted to share the small titbit here.

Why General Descriptions Don’t work? 

Most Job descriptions barely resemble “specifications” at all, but feel more like generic stubs. Sort of like the equivalent of shopping for a car with as much details as “red and goes fast” or “black and built to last.”

 It leaves too much open to the imagination for it to be a successful criterion to enable fitment. With criteria as broad as this you’ll end up spending an inordinate amount of time executing the search, since so many things appear to be a match. For me, Red and goes fast is always a 1971 Ford Mustang, for you it could be a 1998 Ferrari 365.

The truth is that statements like the above — or its equivalent in engineering hiring — “Get me a backed dev with OOPS in Python/Java/Go with 5 years experience” — guarantee a similarly frustrating shopping experience. You’ve made it needlessly difficult for yourself and your HR/TA team to identify the specific talent you want. In this trite example you’ve indicated that you’re looking for a mid-level engineer that knows OOPS, but that basically includes everyone that ever graduated with a CS degree in the past 5 (to 10?) years. Surprisingly, many job “specifications” we see contain rarely any more info. These are the “Boiler Plate” Job Descriptions.

How did we find ourselves in this mess?

I understand why hiring managers do this. Sometimes they’re not exactly sure what they want — after all, it takes real time and effort to work out the specific vision for the role. But instead of acknowledging this and then solving the real problem (their own laziness), they delegate the JD writing to their Team/HR and it turns into generic tech JD. But the hiring manager is unfazed — “I’ll know the right candidate when I see them,” they say. Really? It could be true in some instances. Sometimes, we start with a Backend developer, then we come across a candidate with experience in building a full pipeline or a payment system. Then we expand the role to cover wider scope and evaluate against it. But generally,  How will they know the right candidate if they can’t write down specifically what the candidate looks like?

Another reason for generic job specs is because a hiring manager is recruiting in a talent-constrained market (sound familiar?), and it feels like a smart move to cast as wide of a net as possible. Theoretically, one should be able to get more candidates into the top of the funnel this way, right?

Perhaps. Theoretically. But in my experience, this approach usually, and utterly, backfires. Here’s why:

Boiler Plate Job Descriptionsaren’t designed to appeal to any engineer in particular

In the current job market, engineers are faced with a wide variety of options from some amazing established companies and lots of seemingly “sexy” startups. (after “the great resignation”)

You need to take your opportunityto stand out! The more specific you are about the challenges a specific engineer will get to work in a specific role, the more traction you’ll get with (the right) candidates.

The idea is to make an engineer excited when you describe what they will “Get to do” in the first 12-15 months in the role. 

Be very specific, 

  • Talk about the product/modules they will own/drive/be part of, 
  • Talk about the outcomes and metrics they will own and drive,
  • Talk about the toolchains & frameworks they’ll use (or get to choose), 
  • Talk about What’s hard/challenging about the role, How are they a great fit. 
  • The more details you can squeeze into the spec to help them visualize their role and the projects they’ll be working on the better.

Boiler Plate Job Descriptions don’t arm others to help you

Another bad thing about generic JD is that they don’t help others help you. Think of how much reach could you get by using everyone in your network as a recruiter. But in today’s scenario, “everyone else” is already asking them if they know any Python Engineers or React Developers or Go Engineers. Why would they help you? Because you’ve taken the time to get specific about what you want? Maybe. 

Take a look at the following Job Description. Anyone in software engineering who had some deployment, infra-planning & communication seems to be a candidate for the role. 

I recently got a request from a founder friend of mine to refer a Sr.Tech Lead/Engineering Manager for an early-stage startup. When I saw the JD, it was so generic it did not even have the primary stack on it. Assume sharing it from your handle. I politely declined to share it and asked for some more information and said will come back once he shares. (I believe he is very busy and hence hasn’t come back) 

The bottomline is, Make them want to help you — give them a JD that’s so amazing, well-written, specific, (even entertaining)  — that they can’t help but pass it on, post it, tell their friends about it, etc. If you make it stand out — you’ll get more attention from the folks that can help because you’ll arm them with something interesting & effective that they can use to reach out to their network.

Boiler Plate Job Descriptions don’t enable you to know what success looks like

This is a very simple point — see above — if you can’t explain what the ideal candidate looks like, how will you know when you’ve found them? The JD shared by my friend looks as vague as this.

Typical Boiler Plate JD

Actually, his company was looking for a guy who could not just do Infrastructure Architecture. They wanted someone who has architected/built a cloud native SaaS application. His team has built the application and has no idea how to convert it to truly cloud native format to scale without breaking the bank!

The main idea here is about not being willing to settle for less. I realise the market is tough right now, and maybe you’ll need to make compromises. But do you want to start at the wrong end of the pool? When you go out the door with a generic description, you preemptively give up the battle. If you need to settle — fine! — but know exactly what points you’re compromising on.

The larger problem is that if you don’t know what the best candidate really looks like then the other people involved in making a decision likely don’t know what s/he looks like either. A well-defined, specific description of the role enables everyone involved in the interviewing and hiring process to be on the same proverbial page.

Now go get started!

Fixing your job descriptions will take some work(as I found out). To get to specifics, you’ll need to dig in and make additional efforts. You might also need to do some retraining in your organization and teach others these principles, too.

But when you get through the hard work, your postings will turn into valuable weapons that will,

 a.) appeal to the engineers you want to reach,

 b.) enable others to help you expand your outreach, and 

c.) get your hiring team on the same page to quickly come to the right decision.

If you’re curious to see what roles we currently hire for, we have a lot of openings in Product, Design and Engineering:

It ranges from Kubernetes Architect, React Native Mobile Dev, Sr.Backend Dev, Tech Lead-Mobile Technologies, Engineering Managers, Associate Product managers, Product Managers etc.

More details can be had at https://angel.co/company/itilite-1/jobs or you can ping me 🙂  

Do you really need a Product Manager for a successful Product?

Do you really need a Product Manager for a successful Product?

This post is a summary of a series of “Mentoring” and “Advisory”  calls I did with some early stage startups, over the past 6 months. Most of the time, one of the founder ideates, one builds/leads the build. But, they want to go fast and think they need a Product Manager. Unfortunately, most of them don’t need a Product Manager. If you are at a similar juncture, read on to find out more.. 

The title is a controversial question, I know! 

The State of Product Management:

Off lately, Product Managers have to wear too many hats, leaving the role vague and blurring the boundaries of their area of responsibility. This ultimately leads to diminishing the value of the product manager’s core functions. Product Management is a strategic, cross-functional, front-line role that brings great value to the product and business.

But, it commonly gets abused by many fast-paced organisations expecting product managers to fill in the gaps in various disciplines. This may be process, pricing, unit-economics, partnerships, product-marketing to name a few. They can definitely do that due to their broad professional background.

Admittedly, product managers do have a broad background, otherwise they would have a hard time to be able to effectively collaborate with the stakeholders, lead the product and make the informed decisions. But this definitely should not end up with the product managers becoming de-facto “deciders” or “doers” originally intended to be done by other roles in other functions.

How do you decide if you need a Product Manager or Not?

Like any problem, there are two approaches, if an intellectual debate is more to your taste, continue reading on. If it is more of a rational “doer” approach, head straight down to it. 

Intellectual Approach

Ask yourselves some questions:

If you are a founder or a  leader or a decision maker,  before hiring a Product Manager, question yourself as to your expectations from the product manager. 

Think hard on what you want them to do:

  1. What do you want your new product manager to change/fix in your organization? What is it that you are unable to do?
  2. Do you not already have the in-house expertise that would help you address the current issues?

If you are still unsure about whether or not you need a product manager “in the house”, 

I recommend that you go through this checklist and answer Yes/No to each of its questions:

  1. Do you have a vision for your product? Do you believe it is aligned with the market needs?
  2. Are you sure you are building the right product — the one that delivers value to your target audience?
  3. Do you have a direction for your product? A long-term and a short-term roadmap?
  4. Till now, have you been able to execute your roadmap without major distractions?
  5. Are you capable of maintaining the strategic focus across all levels of the organization?
  6. Do you know your competitors and what they have on the game? Proposition, not features.
  7. Do you have an established feedback loop with your clients? (Not the feature request types)
  8. Do you mostly base your decisions on evidence/data?
  9. Do you find it easy to say “No” to various stakeholders from various functions while hearing their “suggestions” and “inputs” and explain them why what they think is not the “most” right thing?

If you answered “No” to more than 4 questions, you probably need a Product Manager, No doubt in that. 

But the reality is, that hiring a highly capable Product Manager won’t magically change the DNA of your organisation. I have seen multiple orgs regress into a worser situation than before. Because, the person responsibl has delegated the product decisions to that Product manager with a shiny belt, without enabling/empowering him/her. 

The result 

Rational Approach

If you’re a CEO, founder, or senior leader considering hiring a PM, check this list and see if you need one. Lets play a guess and eliminate game. 

If you can see your organisation is reflected in this article, don’t bother hiring a PM — save some money and hire a cheaper role. You would also spare a PM some misery.

Don’t bother hiring a PM…

If you have a fixed idea of what to build

You already know what you want to build, you just need somebody to build it. You’ve hired some engineers. You need somebody to gather the requirements from you and the team, and maybe manage the back-and-forth of different requirements from many stakeholders. This person then passes the requirements along to the engineers and makes sure they deliver on time.

You need a Project Manager, not a Product Manager.

If your Sales team or clients are dictating what to build

You have a handful of big clients and you’re ready to bend over backwards to deliver what they need, including building custom features. Your Sales team knows best what to build, surely, as they’re the ones talking to the customers all the time. Now it’s just a matter of writing the stories and prioritising them.

You need a Delivery Manager, not a Product Manager

If they won’t have access to your customers

You have some very-important-people as customers and their time is precious. You don’t want the new person you just hired to talk to them directly — may be they will say something untoward?

I don’t know what you need, but you certainly don’t need a Product Manager. 

If you’re not ready to delegate authority

You know that product managers should be given a problem to solve, not a feature to build. Heck, you were probably a Product person yourself, who has now set up your own startup. You have the vision and the strategy and you know exactly how to get there…

What’s left for the Product Managers to do, then? Maybe hire an Engineering Manager or a Tech Lead?

If you see technology as a support function

An easy way to assess this: How much of your company budget is dedicated for product/technology/innovation? If you’re not willing to invest significant resources to staff the product/technology team properly, they’ll be left firefighting all year long. 

Don’t hire a Product Manager — yet. Assess how you see technology plays a role in your company’s vision. Set aside a proper budget, hire a strong CTO or CPO, and let them build their team. Only do that if you’re willing to listen to them though — or don’t bother doing it at all.

In Sum and summary, Hire a Product Manager only if you believe you can delegate authority, and can come to a rational decision based on data. If not, hire a Project Manager, Engineering Manager or any of the other roles.

A Tech Lead writing code is a disservice to the company.

A Tech Lead writing code is a disservice to the company.

You have been coding your whole life or at least most of your professional life. Recently, you have been promoted/designated or as a Lead Engineer or a Tech Lead. Does anything change for you?

Should you stop coding?

People generally say, hell no!

Hell No!

And why should you now?

  • You like it; 
  • You enjoy it and probably 
  • really good at it too. 

But then you start leading a team, which means that everything should change or at the minimum, something should change Or shouldn’t?

It’s an eternal question for every engineering manager. I have tried to answer it all along my career and 

The hardest thing is to understand that you are not “just a” developer anymore.

I know, the above statement is controversial with multiple of my readers.

Most of you are now in a role with,

  • different responsibilities, 
  • different daily schedules, and 
  • tasks that involve different mental processes.

And you are most likely trying to combine two things at this time.

  • You’re trying to be a good developer (that you used to be).
  • You’re also trying to act as a “Coordinator” “Communicator” and also “Manage” things

I know, your designation/title says Tech “Lead” or “Lead” Engineer and not Engineering Manager.  But, in most organisations, a TL is looked upon as an EM in waiting (For more insight on career tracks for a TL – Check out my previous article on Engineering Leadership on Startups )

And working two jobs may often lead to early burning out and, frankly, not being any good in either of them.

I will take two very probable examples here.

Case 1: You are a Lead and you want to own a particular piece of code rewrite, which is giving a lot of concurrency nightmares to both the product support and your on-call teams. Most design/debug and development tasks require high concentration and focus, which contradicts the very nature of the team leader’s work. Multiple planned meetings, calls, messages — a lead needs to be on alert. It’s tough to consider all the edge cases when your slack/hangout/teams is buzzing all the time.

Another essential element is most of these buzzing & pinging can be controlled if your team is good at Asynchronous Communication. (I will write more about it in a future article)

Case 2: You are a Lead, driving a new subscription module for your latest product. There are simply so many stakeholders, your PM, Payments team, external partner/vendor, Infra team etc. It will be hard to be prepared to answer your teammates’ or vendors or customers’ questions if all you can think about is the efficiency of that function you just wrote.

Time Share:

Another thing is that spending a lot of time on development gives you little time to do your actual job as a lead/manager. And your job is managing other people. Though you will probably make time for your primary duties — assigning tasks, making estimations, validating designs, communicating with the stakeholder — you will miss out on all the other “noncrucial” parts of your job.

You can get so invested in a feature that you will miss some critical signs of your employees becoming demotivated to do their work, tired, or less happy. And, as you are busy, you become less innovative. Who will come up with a new architecture for the 3-year-old service? Most certainly not you, since you are too deep in the code.

Anti-Growth

Minefields you’d inadvertently trigger are either the Martyr Effect or the Hero Syndrome (Think Bruce Wayne or Tony Stark). On the first & second one, You’d always take the toughest part of the code or the most interesting part of the code, respectively. Either way, you’d be creating a team who’d be ill-prepared to take up challenges on their own or ill-equipped.

But what if I do not want to give up coding?

It may so happen that plain management isn’t your path. So, from here on, you may not enjoy what the role has to offer. Being a Team Lead/EM is all about people; being a Principal Engineer (or staff engineer or architect) is about code. If programming is critical for you and brings you more joy, you may be more suited for a Technical Leader role. So choose wisely.

But as a Team Lead, you are still most welcome to join code reviews and help your teammates with challenging coding problems if you want to.

Consult. Guide. Assist. Communicate

This is going to be your Motto.

And of course, You should definitely continue to code in other “Non-paying” parts of your job. Start automating your units, create boiler plates, write smaller, niche, critical elements of your system.

What Does It Take To Become a “Senior” Software Engineer.

What Does It Take To Become a “Senior” Software Engineer.

This article is a result of a discussion with one of our ” Ninja-neer”. He was interested in “Delivering Business Value” but not interested to take up People Management or other responsibilities. Do I have any pointers for people like him? Of course. So, we started discussing on ways he can contribute at a different level. In the end we talked for about 90+ minutes. This is an extract & summary of that discussion.

In the late 2000s, it was a trend for companies to hire developers based on the programming language they had experience with, frameworks, tech stack, and such. (I still remember the disappointing gaze I got when I told the interviewer that I have only worked with CVS and Mercurial and not in SVN, which the team I was interviewing for was using)

It is preferable to hire engineers skilled with a particular stack, it is not crucial. After all, great software developers should be able to learn and ramp up quickly with the massive knowledge available on the internet.

With that being the absolute baseline, companies started to value developers with great complimentary soft skills, as their technical expertise is now baseline to work in the industry, setting the bar even higher for people starting a career right out of college.

The Three Fundamental Traits

After almost 12 years of managing/leading Software Engineering teams as a Technical Lead, PM, Engineering Manager, Director etc.,  I have observed the skills that tech organisations generally value the most. I believe I have identified a pattern that generally falls into three different categories:

1. Technical expertise and craftsmanship

Understanding the fundamental concepts of computing is the baseline to becoming a software engineer. Even though this looks like common sense, this science is vast and is continuously evolving. Gone are the days when knowing some data structures, array transformations and basic algorithms will get you over the ledge. Also, the organisational/product context is very important as well. For example, my peers at Paypal prided in getting sub 500ms latency for all the “processes” they wrote, while my colleagues in Hinduja Tech focussed on ensuring “zero-packet loss” from the telematics devices.

It really boils down to what is your company’s key priorities are. It can be quicker release cycles/velocity, resilience/ fault-tolerance or efficient memory management. Whatever it is, you need to first understand the “value” and then follow it in your implementations.

2. Scope and autonomy

We do not live in a world where working alone and implementing specifications from LLD/UML diagrams is sufficient anymore. For that matter, in the last 18+ years, I have met exactly two people who were able to pull it off and one was a 62-year-old Ingres developer, who was single-handedly managing the 40year old databases of PA. Those who know how to navigate complexity requiring minimum supervision are now extremely valuable professionals. Actively communicating and ensuring alignment is more important in these times of high-velocity organisations.

3. Communication and influence

Even though nobody expects you to be a skilled public speaker, we are long past the era where programmers were introverts that spoke an unintelligible alien language. Knowing how to work with people and interact with non-technical partners is a valued skill in the market.

I had a very first-hand experience of why clarity in communication is so important as you grow up the ladder in your tech org. 

I was (hastily) called to a meeting, where my boss (VP) was explaining to our CEO, of why we should not be building the next generation of BRTS for Congo, Senegal and Ghanna on Desfire EV1. The primary concern was around security and privacy. There were major concerns around its security and was exposed just before the London Olympics. (It had taken me 3 meetings over 2 weeks to convince my Boss to go with EV2) I still do not know why he thought I might be able to do it in 10 minutes and that too in front of the CEO!! But the important thing was, My boss was willing to give me a chance to try it and in the process, he was giving me visibility to the inner workings on the 11th floor (C-Suite).   

How do I convince my CEO to opt for a solution with almost 20% additional initial cost? 

Is it with NXPs’ security from relay attack or with 16KB vs 4KB of usable memory or something else? Then it struck me if the topline is something my CEO was interested in he could definitely understand the bottom line!  I fumbled something around potential “Revenue loss” and did a whiteboard tabulation of some numbers. (Desfire

Surprisingly, my CEO got it despite my ramblings and corrected my statement, It is a potential Revenue Leakage, not a loss!

That one meeting changed almost every communication I did after it.

Becoming a Senior IC – Sr.Engineer, Staff Engineer, Principal Engineer, Architect (or any of the other dozen designations)

Again, this article is aimed to give some clarity on what are the options for rising up the ranks as an Indivudual Contributor. The Tech Ladder in most Startups are similar with slight deviations. After you become a Sr. Engineer you have 2 tracks – Technical Excellence leading to Staff Engineer and Principal Engineer. The other track involves People and Budget management leading to Tech Lead, Engineering Manager and Director, VP etc.

 I’d like to help you understand important aspects that can place you at higher levels based upon the expectations set on each level of proficiency grouped into the following tiers: Beginner, Intermediate and Advanced.

ExpertiseScope & AutonomyInfluence
BeginnerLearningFeature & GuidedCollobrators
IntermediateProficencyProduct, Performance & TacticalTeam(s) Wide
AdvancedExpertiseDomain, Industry & StrategicTeams & Function wide

This grid above depicts the career trajectory of software engineers in a super-simplified way. It is generally more complex than that, but it still serves as a good guideline to identify career points of inflection. Note that I did not use the so popular “associate,” “mid-level,” and “senior” on the different levels. This is more of a grouping of related circles of roles.

Starting a Career as a Software Engineer

As a beginner in this new and adventurous area, there are lots of low-hanging fruits you can learn from. In fact, learning should be your focus. You should acquire as much knowledge as you can from being exposed to a variety of problems.

Up until a point, you will work on “very specific” problems or small features or bug fixes until you ramp up and have a good understanding of the lay of the land (product or system) you are helping to develop.

You will pair with more experienced engineers and learn from code reviews and feedback from your partners. Engineers at this level spend a reasonable amount of time learning until they get proficient with tools and acquire more domain knowledge. You’ll learn a lot of Tricks and Tools from your senior peers and you will also find the kind of problems you’re proficient in solving. Which will result in similar problems, fixes or features you’re assigned with.

The trick is to emrace the “Streotype” and make it your “Niche”, while also diversifing enough to get a hang of other things and continue to learn.

Working as a Proficient Developer

At this point, you would have gotten your hands dirty for a few years and developed mastery of computer science including algorithm design, data structures, design patterns, and the tools and frameworks you work with. You have very deep experience with at least one or two part of the technology stack you work with.

It is now taken for granted you will be able to deliver complex pieces of software with very little supervision. In fact, there is also the expectation you can help less experienced engineers to grow and guide them to execute the tactical plan you created. You help people to review their code as well as solve problems and develop new features.

One thing to remember is, “Code Review is a Bidirectional Learning exercise” – The proficient ones understand/learn new approaches from the beginner, the beginner

It is the time in your career that you start getting the opportunity to lead small projects and time-bound initiatives and likely start to get more exposure to cross-functional partners and some non-technical stakeholders. Most software engineers stay at this level for many years.

The Non-Comissioned Officers are called as the backbone of an Army. Similarly, Sr.Developer is the backbone of any product/Engineering Team. As this is the most visible and “on-the-ground” leadership.

The Making of a Senior Software Engineer

At this level, Coding in general starts to become less important as you are now a visible voice for your team and across the organization. You now understand how to make difficult trade-offs in the architectural level of your application across the entire domain.

As a domain expert, you own a substantial part of your company’s codebase, supervise its evolution and work from other engineers, as well as advise other teams on how to better approach or integrate with your services and applications.

As an advisor, your contribution is clear and visible across multiple teams. You are highly influential and your advice is constantly sought from other engineers and cross-functional partners.

This is the inflection point where you start considering a transition to leadership roles. It usually takes some years to land at this level. The next step for you is growing the impact of your work across teams, organizations, companies, and industry-wide.

Even though colleges prepare you to develop software, as you grow in your career that skill starts to become less important and other soft skills turn out to be more relevant. I hope i was able to nake justification to the topic of growing as an indivudual contributor and make higher impact and inspire you to reflect on your own trajectory and how to proceed with the next steps.

The 5 ways to Fail as Engineering Managers in Startups

The 5 ways to Fail as Engineering Managers in Startups

This article is a compilation of multiple years of my experience being an Engineering Manager and subsequently running the Tech Org and managing multiple Engineering Managers. I have tried to summarise and condense them.

Having a good manager can make you feel supported, can boost your career growth (and sometimes personal), and help make your team and company a happy place. On the other hand, having a bad manager can make your work-life miserable and could hinder your growth and drain you.

Engineering Managers have a huge impact on their team’s, morale, outcomes, timelines and most importantly the professional growth and help them carve a career path. But, you may have seen, heard or felt that some or most Engineering Managers are anything but the above description, right? Do you want to know the root cause of the problem?

It is the practice of making a high-performing Individual Contributor/Engineer the Tech Lead and thence to an EM!

Trust me when I say this, I have seen it multiple times. I have seen many good Engineers burn out as soon as they have people management responsibilities. An Engineer may be okay to mentor some junior devs and help them get the right design etc. But, S/he needs to have a people-first mindset to become an Effective Engineering Manager (or any of the myriad titles with the job function).

The 5 ways to Fail as an Engineering Manager!

So, assume an Engineer is looking to move into Engineering Management, the following are the pitfalls S/he should be aware of as these are the most common ways EMs fail.

1, Too much Solutioning, not enough listening.

Interestingly, this can happen both when you’re not confident as a leader and when you are too confident. We tend to focus on solutions too much instead of supporting/empowering others or listening for more context. Sometimes people only need someone to vent to and are not looking for solutions immediately. Even when they are, we can act as coaches and guide them to the solutions, helping them grow in the process so that next time they will be able to solve on their own. Even when they need an immediate solution, we might fail to get the whole context by not authentically listening to them.

Such leaders usually jump to solutions right after hearing about an issue, and even when they ask for more details and input, they are not listening authentically. They might get impatient when the discussion drags on.

There are two critical Skills to practice to overcome this pitfall. Effective Listening and asking more Leading Questions.

2. The silver bullet or the Golden Rule Fallacy

We might not be very conscious about it, but we all have a natural, default style when it comes to management. This is sculpted by our general personality, our experiences, our bosses and how they treated us and things we’ve learned along the way. As managers, we unconsciously rely on this style, and without guidance, we tend to use that style with every direct report. Even when it becomes conscious, we justify this with ‘this is who I am’ and sometimes even with core values and our self-image

Don’t “Treat others as you wish to be treated”

The above statement could be borderline Blasphemy to many people in many aspects (including cultural or religious). How could it be untrue? If most major religions/cultures preach it?

The reason for this paradox is simple, we all assume we want to be treated fair. But, fairness to me may be unfair to you and the other way around.

For example, I tend to react very well to negative stimuli, i.e: critical remarks. I use them to better myself and continuously improvise (most times, at least) whereas some other person may feel it draining, for them, the Positive Reinforcement techniques may work well.

While having strong core values is vital to being a successful leader, using a single management style just simply won’t work with all your Team Members over the years. Doing this way WILL HARM some of the Team Members (and of course hinder your performance as an engineering manager, too). The Golden Rule managers often talk about the one true way to do things. They get overprotective/defensive about their style as they face more and more challenges. They often see the failure to be with the team members who don’t respond well to their style instead of adapting to theirs. This is especially important as more and more of you’re team members tend to be Millenials.

The most obvious display of the Golden-Rule/One-Trick Managers is hiring #minimes. They hire a team full of similar styled team members. You may have recognised certain trends over the years, a very hands-on manager will not only hire, but also treasure a very hands-on problem solver by empowering them. On the other hand, a Process-oriented manager will hire their lieutenants to be fully process-driven ones.

The problem with the first example is, you’ll have an army of Debuggers, Fixers and Solvers but very few(if any) to think & execute in a scalable & sustainable way.

The problem with the second example is, you’ll have an entire team quoting the “Rule-book” to each other in no time and meanwhile, the company may be bleeding.

There is only one approach here, As managers, it’s our core job to form a good working relationship with our team members. This will require us to adapt our style or adopt new styles.

3, Low self-confidence

Yes. I meant it. I have known multiple awesome engineers in my career who started having Low Self-Confidence after they became managers.

Honestly, I have gone through it myself at various points, before climbing up the rope. The reason is also quite obvious, when I was an IC/Sr.Dev I know what was the outcome and what was the timeline and quality of deliverables was something I prided in. So, nothing was ever out of control for me (except maybe twice).

And if something exceptional happened, I can “Report” it and either get the “Scope” or “Timeline” modified and my self-worth was left unchanged. Now, as the first-time manager, I realised that I am that “Exception Handler”. Sure, I can go to my Delivery Director or Group Program Manager etc, but I am supposed to be the first line of defence from exceptions affecting the Business! This is the no: 1 cause for low self-confidence.

But, it is by no means the only one. The second most cause according to me is delayed feedback and low observability of Business Value delivered. It’s usually really hard to see our work’s positive effect, feedback loops are just too long, and cause-and-effect relations aren’t always easy to see or quantify.

People with low self-confidence usually have a hard time saying “I don’t know”, which is essential as an engineering manager. We cling to the thought that we have to know answers to everything that comes up; otherwise, we’re just not good enough.

I’ve seen some insecure managers trying to do team members’ jobs. They do this not because they don’t trust their team, but they need something they’re proficient with to feel more secure and confident. Another way for such managers to feel that they are still worth something is to be too nitpicky, for example, in code reviews or simply when giving feedback.

Among many things, all this can lead to the engineers feeling that their engineering manager is competing against them in a way. This is THE worst feeling you can give to your team and a sure way to fail as a Manager.

Be the force multiplier to the team, not another grunt.

There are proven ways to come out of this zone. Discuss with your peers (other EMs/TLs) and your Manager, open up your insecurities & fears. You will realise that this is much more common and also learn from them.

4, People or Business Attitude (as opposed to People for Business)

There are two most common styles of management, Too much Business Focus and Too Much People Focus.

There are Managers and Leaders who are only into Business and view upon their team as only “Resources”. They are driven by Goals, deadlines, KPIs and Metrics. They seemingly don’t care about their team’s wellbeing.

There are Leaders who are only into the people part of their team. They create a virtual haven for their team. They shield and protect their teams from the other parts of the company and the world at large. They seemingly don’t care about business outcomes or performance that much.

Needless to say, these two styles are diametrically opposed.

Fortunately, I have seen and worked with organisations with both styles of Management and Managers. (And believe I did pick some elements from both). In the StartUp eco-system, Boot-Strapped and bootstrap influenced organisations tend to be slightly tilted toward the People First management philosophy. And generally, organisations that are VC funded and with an aggressive growth appetite will be tilted toward the Business First management philosophy.

But universally, all leaders I have worked with accept/agree that the key to success is balancing the two approaches.

Too much focus on the business in a leader will sometimes result in that leader prioritizing short-term wins over long-term ones. Such managers will talk a lot about holding people accountable. They are generally okay in abandoning the team members who don’t fall in-line in terms of Team Commitments and Performance, instead of coaching or aligning. The cost here could be enormous. People will get burnt out quick and will leave, The company culture suffers.

Too much focus on people without the consideration that your team is responsible for the company successful can be even worse. Such leaders will position themselves as the “Gatekeepers of hell” with their team. They will defend their team no matter what and will view every discussion/motion as “the Battle of Thermopylae”!

In the end, is is not as much as balancing these views. Its actually building synergies between these two seemingly conflicting ideals. You as a leader and manager will have to find ways for your teams to grow and be successful in tandem with the business goals.

5 – Not Delegating Enough.

The most common mistakes for leaders and managers are usually focused around delegation; either a manager is delegating too much or not enough. This is especially common for an Engineering Manager. Most Engineering Managers think of themselves as a “Specalist” Engineer than a Manager, especially applicable to an EM at the early part of his career. Any manager who fails to delegate will become overloaded and fail to move the business forward. A manager who over delegates with no explanation as to why could lose the respect of their team. The key rules to live by as a manager when it comes to delegating are:

  • Only ask someone to do something you would be happy to do yourself if you had the time
  • Only delegate a task to someone who is happy to take on the task
  • Only delegate to someone is capable of completing it to a level you would be happy with yourself or can get there with quick review comments

The trick is to know when to Cascade, Delegate & Escalate!

Concluding Remark

Obviously, this list is not-exhaustive and there are other significant issues causing to failures of Engineering Managers. But, this is a Ranked list from my personal experience.

I was extremely fortunate to work with some of the best leaders and managers and each one of them has shaped my skill, style and everything in between. While mentioning my “managers”, “My Teams” over the last 8-10 years have played an equally important role in this transformation.

Also, If you’re looking forward to learn how can you be a manager/leader your team will not run away, check out this short course by Laurie Ruttimann – https://www.linkedin.com/learning/be-the-manager-people-won-t-leave/be-someone-people-trust-no-matter-what

Bitnami