Month: July 2021

Data-driven, Metric-driven

Some say they are the same – metrics are computed on data. So, I must be data driven if I am already metric driven.

I claim that they are different. Agile combines them together in a nice way.

You would be metrics-driven to achieve a goal. Goal coaches insist that goals should be SMART (Specific, Measurable, Attainable, Realistic/Relevant, and Time bound). E.g., I want to be an millionaire in one year is a SMART goal, that can be measured along the way (lead metrics) and once an year has elapsed (lag metrics). The lead metrics tell you whether you are on the right path to achieve the goal, while the lag metrics tells you whether you have achieved or how well you have achieved the goal.

You would be data-driven when you have to deal with ambiguities. Data coaches insist that good quality data must be captured continuously to seek insights that can be converted to knowledge and actions. E.g., I want to drive academic excellence for my child this year. This statement does not tick all the boxes of SMART. It does not say that my child should score A+ in mathematics. There is inherent ambiguity in the statement and choice of words (“excellence”). In such situations, you collect data from tests, teachers feedback, and your own observations. Based on the data, you get insights – the child is great at arts, excellent at mathematics, and needs improvement in language. You then focus on sustaining the strengths (arts, mathematics), and focus on development needs to improve academic excellence. Being data-driven is all about seeking actionable insights. You may make a decision to not take any action to improve language skills and let the child excel in her strengths, but that’s still a data-driven decision.

Agile helps with the cone of uncertainty with the levels of agility. E.g., In a software development context, the team may look at lead metrics like flow velocity and team happiness to determine whether we are on the right track to reach the outcome measured by the lag metrics. However, the team will also look at data (new features, technical debt, customer feedback) to derive whether a change of course is required. So, you get the benefit of both being iterative. Being iterative, and taking small chunks of work to do (stories with 8 story points), you can be metric-driven (SMART) to measure say/do as a lag-metric. Also, grooming the product backlog with insights from data, you will be data-driven.

Technical Career and Competencies

Some people plan their careers. Others don’t and let it happen. Which one is better?

A great career coach will talk to you and advice to either plan or to flow. A good career coach will always ask you to plan. A mediocre career coach will ask you to flow.

Expertise is a necessary attribute for a great career, but not sufficient. A performance track record is another necessary attribute for a great career, but not sufficient. Presidential communication and influencing skills is yet another necessary attribute for a great career, but not sufficient.

It’s easy to list down the ingredients of a great recipe (methods for a great career), but different cooks with the same recipe have different results. So, there is also some luck and practice involved.

For this blog post, lets focus on EXPERTISE. Early technical careers are measured by the depth of technical competencies. Technical competencies define late career choices as well. My advice has always been to develop 1-2 competencies in early career to build depth. Some broad technical competencies are:

Web (Cloud Scale) Software
Enterprise Software
Device (Mobile) Software
Device (Embedded) Software
Security and Privacy
Artificial Intelligence (BI/ML)
Data Engineering
DevOps
Test Automation
Robotic Process Automation
Operations Research
Agile

The list is not comprehensive, but is a classification of the type of software problems that software engineers & architects solve today for the market. The engineers have to build different mindset and skills for each class of problems.

E.g., As a Web Software Engineer, you would need to have the mindset of building for scale, and skills to debug programs that may fail at scale. As a Device (Embedded) Software Engineer, you would need to have the mindset of building for scarcity (memory, cpu), and skills to debug programs with concurrency related failures. As a Enterprise Software Engineer, you would need to have the mindset of integration, and skills to debug programs with integration/messaging problems with other systems. As a Data Engineer, you would need to have the mindset of processing data in batches, and skills to find anomalies and patterns in data. As an Agile/DevOps Engineer, you would need to have the mindset of continuous improvement, and skills to automate workflows.

Best bet – early in the career, if you know your natural mindset, you can choose a competency that fits you. Later, choose a competency that challenges you.

Don’t choose a competency that claims to maximize your cash flow. So, work to strengthen your strengths, and later work on your development opportunities.

Summary: Once you plan you need to let it happen, and measure your happiness. If you are not satisfied with the flow, you need to plan a change. Rinse-repeat until you are settled and happy. If you are content, plan to change.