Showing posts with label Growth. Show all posts
Showing posts with label Growth. Show all posts

Monday, January 26, 2026

The Awareness Words On Growth And Promotion

 

I wish, I had seniors who said me about growth and promotions when I began my software testing career.  Could be my seniors did not know how important it is to share this with juniors who have started their career.  

Nevertheless, I want to share it here.  So that, it can be the words of awareness.  

These words of awareness related to promotions and growth is not limited to below sharing.  It is more and beyond.

The below are quick reminders to myself.  It can serve you as well.


  • The good work delivered does not mean good money and benefits.
  • The promotion and growth is not all about the good work done and delivered.
    • It is about my identity, professional identity, visibility, communication, persuasion, influencing, the kind of problems I'm solving, the value and money I bring to the business.
  • Me skilled in the tech stacks and capable to build, test and deliver is not the only priority factors for the growth, promotion and benefits, each time.
  • The 1:1's and meeting with stakeholders should have a goal and way to evaluate the same periodically and consistently.
    • It should be quantifiable and visible in the business.
  • A manager's job is not to worry about my growth and promotions.
  • A manager's job is to ensure the delivery is going good and meeting the business goals.
  • A manager's job is to solve and enable the business on priority, most of the times.
  • A manager can be of help in my growth and promotion to a certain role maybe until the senior engineer role.
    • Beyond that, it is me and how I'm seen by my peers for what I'm and what I do.
  • A manager is not responsible for my learning and upskilling.
    • It is my responsibility and accountability.
  • The manager might forget me after a release.
    • She or he will remember me
      • When I'm needed in the meeting.
      • When a data is needed from me.
      • When someone else need data of me.
  • It is me who has to keep the manager engaged with my value and impacts delivered.
    • The data has to be presented.
    • The data should be quantifiable.
  • The one whose work bring money to business and the one who sits in the role for making decisions that brings money to business, get identified and promoted usually.
    • In other way, how close is my work to bring the money and impact to business and its growth?
      • This is a preliminary equation which one has to have and solve before going to ask promotion, growth and benefits in a business place.
    • How to keep myself here while I deliver an excellent work and value to the business?
    • If you see, in a way this is politics.
      • The office politics is not bad!  Everything runs on politics.
        • It is the people and management dynamics, and that is how a system functions inherently.  This is my observation and interpretation.
      • One should be able to play her or his role in the office politics.
        • If ignored or keeping oneself away from the office politics, it projects one as muted with a label tagged -- he or she can be updated later and the job will get done and no need to be here.
      • One's office politics is her or his identity, visibility, positioning and influencing

The manager is in the organization not to promote her or his team members.
  • But, to ensure the business goals are being met.  
  • Taking care of her or his team members in a defined scope is one of the responsibilities for a manager; it is not the only responsibility and not the number one priority responsibility.

Business goals do not have my promotions and growth as their priority goals.  It should be my goals.

Yet, the managers go and fight in a closed room for her or his team members growth, hike and promotion until a role.  You see, not all get promoted in a cycle.  That challenging is the advocacy in that closed room, tables and meetings for the managers.  Give the quantified data to your manager.

Underestimating self and letting that to be used by others in the floor can be lethal to the growth.  



To end here, my growth, hike, promotion and the benefits I need to get is my advocacy and visibility for first.  The manager and peers can be a catalyst here.



Sunday, September 21, 2025

Who Talks About Your Work?


You talking about your work is stronger than the work talking about it.  Why?

I see, the work speaks in terms of change it brings -- the feeling and emotion of other people.  In the change, people do not see you.  The people see themselves and it is not wrong.  People see how your work made them feel; not what you feel for giving that delivering work.

How you are feeling, what you are feeling and what is that you are expecting for doing the work -- you should make it explicit and talk about it.  I see this is fair ask, be it at home or at business.  

In business, you are paid for the work.  That is how the business looks at it.  Probably nothing more than that.  If not you, someone else will come in to do that work.  But, then what is the difference in you doing and someone else coming in and doing it?  How do you put this across and persuade with an influence?  This is, you talking about your work and presence.  This matters!

At the bottom, everything has calculations -- at home or at work.  One has to talk about her or his work, presence, and value.  This is a useful lesson for family members at home and peers in work place or community -- which is not spoken or taught in school and home.

It happens that, people talk about you and not about your work.  Then who will talk about your work?  You talk on your work.


To open you up to talk about your work, 

  1. To talk about your work, work and know your work
  2. There is a thin line between bragging and talking about your work
    • When I say talk, it is communicate -- communication
    • How do you communicate about you and your work?
  3. Talk about your work with,
    • Data that can be correlated with change and growth
      • Quantify it
        • Change and growth is well received when it is quantified
        • Illustrate this with data which is evident and interpretable
          • I said, evident and not logical; logical does not resonate always
    • Change, Impact, Consistency, Influence, Trust, Value
      • Highlight the trust and its consistency from your work
    • Reliability
    • Challenges remaining
    • Gains and loss
      • Talk about loss which are competent gain
    • Changed and unchanged
    • Continuity -- how and why
  4. Your gain and loss is not just your work, it is also what you talk about your work
  5. Know your ego when you talk about your work and others work
  6. Before talking about others work, know your work and talk about it
  7. In short, talking about others work is -- What you are not doing!

If you do not talk about your work, neither your work nor others talk about it.  Never!

Talk about your work!



Monday, September 15, 2025

Software Design Principles in Communication of an Engineer

 

As a reporting manager, anytime did you say this to one of your team members?

  • You did not deliver what the organization expected.
  • You did not deliver what the business expected.
  • You should also deliver what the company needs; but, you did not.

If you hear any of these from someone in the team other than manager, it is more likely, the story is narrated in the team, and you are hearing it now.  How to avoid ending up here?



Reporting Manager and Communication

When I'm in the role of a reporting manager, I want to avoid the below mistakes and keep my team well aware and informed.

I see, most of the skilled engineers are put to a corner because of not good communication from the reporting managers.  And, not all engineers are aware of politics and to move politically.

I listen and converse to such engineers. They are not well communicated and aware of -- what is expected by business, company and stakeholders.  It is not communicated in precise and straight.  

But, it is expected from one to deliver. Failing to do so, the message narrated to the floor is -- she or he did not deliver what is expected.

When I work in the role of Engineering Manager or Director of Engineering or its above roles,

  • One of primary responsibilities is to be better in communication day-by-day and follow the KISS - Keep It Simple and Straight.
  • Yes, you read it right, it is KISS.

How are you communicating in the role of Engineering Manager and Director of Engineering?  How effective, simple, precise and straight it is?



Software Design Principles and Communication

Communicate with your engineers in the teams.

Help your engineers to understand the expectations.  Practice the software design principles in your communication.  Give it a try!

If a software engineer can identify and implement the design principles in the software she or he builds, then, she or he can identify it in your communication and the expectations you have.

These software design principles should be in our communication day-on-day,

  1. KISS
  2. DRY
  3. YAGNI
  4. TDA
  5. SOLID
Do not have these design principles just in the interview rounds and sometimes in the code review.  It should be in our communication and day-to-day decision execution.

Do you have these in your communication?
Or, just in the interview you take and the system you build?

Ask your team member if she or he knows your expectations.  Ask, how well you have communicated it.



To sum up and summarize,

  1. The team or a team member is skilled but failed to deliver the expectation is more likely when the expectations are not well communicated by her or his reporting manager or the skip manager. 
    • The other case is, the engineer is lousy and not stepping up.  But, most times it is not well communicated.
  2. The Software Design Principles as KISS, DRY, and YAGNI are not just for the software we build.  
    • It is also a must practice in our day-to-day communication and engineering's decision execution.  
    • If it cannot be practiced in our communication, I doubt, if a team or org practices these design principles in the software system it builds and ships.
  3. The reporting manager role is underrated and not understood well enough.  
    • It is one of the critical roles in the business and org.  
    • Any of us can be a reporting manager in role. But, hardly a few have the lasting legacy of being the effective and efficient reporting managers.
  4. Communicate it straight and in simple, so that, each in a team knows her or his objectives and how it will align to business's goals and objectives with an impact.
  5. Learning to deal with one's ego is a underrated and unspoken skill.
    • Foster and build culture where one approaches you with questions to seek clarity.  
    • When you demonstrate how well you are handling the ego, the other can spot it and will manage her or his ego.  If not, still you will master your ego!
  6. Like, how a child's growth behavior is reflection of people around it, an engineers growth and behavior is a reflection of you and people in the business and org.
    • The reporting manager's persona, communication and character will leave the marks on team members and org.


Happy Engineers Day!


Tuesday, January 7, 2025

Is Software Testing a Cost to Business?


How quick one gets to have the awareness of the cost and value in the trade, it will be of help.  I consistently exercise the below questions in my practice.

  • What are the Values added from my work to the business?
    • How do I benefit from this?
  • What are the Values removed from my work to the business?
    • What does it bring to me?
  • Who is not getting benefited from the Values I'm adding and why?
    • What are the loses and its impact?
    • What are the benefits and gains we are losing?
  • Who is getting benefitted from the Values I'm adding and why?
    • What are the benefits and gains we are making?
  • What are the Costs added from my work to the business?
    • What are the impacts?
    • How does it impact me?
    • How does it benefit me?
  • What are the Costs removed from my work to the business?
    • How does it benefit me and what do I gain?
    • How does it benefit the business and others?  What do they gain?
  • Who are all experiencing the Costs from my work and why?
    • What are the pains from these costs?
  • Who are not having any Costs from my work and why?
    • Do they need anything from my work and its value add?

This exercise will help me to know the expectations of stakeholders and business. I align myself to deliver the expectations as I exercise these questions.  

The cost and value from my software test engineering work will have impact and influences my growth with the benefits that I will make.



Is Software Testing a Cost to Business?


I witness the discussion which says testing is a cost in software engineering business.  But, I do not hear the same statement on development.  This made me to think, why?

Here are my understanding on thinking over it for now.
  1. Software development is not about just programming.
    1. When said development it includes every teams and their work.
    2. Programming and Testing are parallel activities in the software engineering which helps each other.
    3. If testing is a cost, then for sure, programming is also a cost!  It is an associated activity.
  2. In business, every activity and investment on them is a cost in multiple ways.
    1. These are evaluated costs and being taken for a purpose in expectation of returns.
  3. Have I come across anyone saying Automation in Testing is a cost, like I hear for testing?
    1. It is seen as investment and necessity. Why?
      1. May be, because, in a belief if [once] automated, that is sufficient enough it goes on for itself without human intervention.
      2. If this is the thought, do you think we are doing it wrong?
  4. Have I seen the discussion and statements which concludes testing for performance and security is cost?
    1. If yes, how?
    2. If no, why these two are not seen as cost?
  5. Serving and well maintained engineering system is a trade-off
    1. I see, we engineers and business choose what to trade-off
      1. This decision can be on logical and non-logical basis; but, there will be a trade-off
      2. Each trade-off has costs and values
      3. What should I trade-off in the software test engineering and why?
      4. What should I trade-off in the software engineering that we are doing as a business?  Why?
  6. When one is offered a offer letter from a business, there is a CTC mention.
    1. CTC means Cost to Business
      1. Programmer has a CTC
      2. Tester has a CTC
      3. Every others in different teams have a CTC including the CxOs
      4. We all [and our job] are cost to a business, who can add value and get the high returns


To end for now, I learn, everything and anything business picks up is a cost.  Because, there is an investment on it.  If there is no investment, is there anything happening or progressing and changing?

I do not want to get into discussions which says software testing is a cost.  I see such discussion is lacking in understanding the software engineering and intrinsic for first.  Software Development is not all about programming; the programming is one small part of it.

There are different teams that work together in collaboration to develop and consistently delivering the usable software systems.  In this process, everything in software engineering business is an invested and evaluated cost in the interest of returns and values that are expected.

It is time to know and ask "What way of testing and its outcome is a cost?" than saying and listening to -- 'testing is a cost', which is nonsensical.  This holds good for any activity in software engineering.  

Any serving engineering marvel is a calculated and evaluated trade-off.