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

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.