DEV Community: Sufyian

Engineering onboarding is not black and white

Sufyian — Fri, 21 Apr 2023 12:01:46 +0000

Onboarding, by definition, is the process of socializing new employees and enabling them to integrate into the organization.

Different companies have implemented different mechanisms for this purpose, but in almost all cases, I have observed that companies are trying to onboard different people with the same approach.

Based on different researches we know that humans are diverse ,they come from different cultures ,are full of emotions and humans exhibit biases in their thinking.

If we take these researches into consideration then this raises the question that,

Is there one solution which can onboard everyone ?

In my upcoming blog post, I will endeavor to elucidate the distinction between onboarding processes that are guided by checklists versus those that are centered around a clear purpose or goal.

See the leaders of the dysfunctional team

Sufyian — Mon, 30 Jan 2023 19:28:17 +0000

Episode #3 of Revisiting Product Engineering - Co creation

Sufyian — Mon, 19 Dec 2022 20:30:21 +0000

When two or more multiple people work together to a common problem I refer to this as co creation. In this blog I will try to evaluate this practice from multiple dimensions. This is based on my experience,observations and failures so far which can change in future based on my new learning.
I see this way of working from these dimensions.

Creating value individually or together.
Changing habits and building new ones.
System which empowers this style of working.
Group productivity or individual productivity.
Culture as everyone's responsibility.
Different skills level in the team.
Granularity of accountability.
Tactical empathy and team happiness.
The trap of single person knowledge.
Different styles of co creation.
Knowledge transfers in the team.

Culture as everyone's responsibility

For quite a long time product engineering community has been following the notion of concepts likebest practices. I think this has effected us so much that it is very easy to fall victim of the notion thatsome work should be done some way. It is the habits which are formed over the period of time. Our reflexes are built this way which we have to fight against. I would propose to call itcontext driven decisions. This enables us to have an understanding that whatever practices we choose is because of the context of we are in. If we change the context the practices might change. This idea gives us an understanding even the style of working is context dependent. What is important is context driven decisions which are agreed upon by the team. What I want to highlight here is that culture is not an individual's job. Do we have culture managers or culture owners ? It is everyone's responsibility to put effort and come to decisions based on the culture that we wish to have in the team. This is like gardening. Its not a one time effort. Its a continuous effort made by every member of the team to put effort for the garden they wish to have. Without the collective effort and team agreed upon context driven decisions any practice or any idea will not be able to succeed. Also like gardening is a continuous effort else the plants will die similarly the context is always changing. Culture is an evolving phenomenon which is a side effect of team's effort. This is the survey which reflects the impact of culture on people. I would leave this to you to think who is the culture owner ? Is it any individual in any role or is it the team as a whole ?

Episode #2 of Revisiting Product Engineering - Decision making

Sufyian — Mon, 30 May 2022 22:45:00 +0000

All of us are making decisions all the time and no one deliberately wants to make poor decisions for the product we care for. It is the notion of time and circumstances that are acting upon which concludes the health of those decisions.
Not all decisions are same, a problem has to be solved before Christmas because there is an opportunity cost, if the problem is solved after the Christmas it will loose its value , some decisions are strategic and can wait , for example we have to optimize the development cost , some decisions are hard to change for example choice of a programming language to solve problem and some decisions are easy to change.
We as humans have biases and as group we have group biases too,on the other side we are socially influenced through social media , our friends in technology talking about new shiny technologies , someone talking about a technology in some conference and we fall for these temptations and form preferences and opinions. We should not forget as mentioned in the purpose that our purpose is to solve problems. I have seen many times that decisions made by engineers are based on preferences and opinions for example a practice is better then some other practice , we should do that. What we are missing many times are realities , yes every one of us wants that shiny straight surface with everything smooth but realities are far from straight road. The purpose of decision is to move forward. So how do we take decision ?

First and foremost data is the key, try to make decisions based on the data.The type of work we are engaged in is effected by multiple variables , and I came across the concept UCurve optimisation in the book Principle of Flow in product development ,and I think it can help in making tradeoffs.
I also think for decisions which are hard to change for example choice of a programming language we should take into account global picture rather then thinking locally .

Even then there is always the case that decision turns out unhealthy, but the learning from that decision should be incorporated for improvising the decision making process for next time.

Episode #1 of Revisiting product Engineering - Purpose

Sufyian — Sun, 29 May 2022 19:52:57 +0000

Some months back I had the opportunity to engage in discussion with @yoavflam who is my colleague ,leader in the organization I work for and a great teacher at the same time. That conversation changed my perspective on how I see technology, the code I write and eventually lead me to study more about product engineering.

I cannot fully remember the question word by word but I remember sharing with him my perspective on types of organizations and wanting to know his perspective. After working for few years in the industry and mostly in those organizations which are operationally complex I got an impression that may be there are different views to see the organization and practices differ from one type of organization to organization, for example technology company with banking license and bank where technology is a department to support the operations. As a naive software engineer I was differentiating between organizations which are very strong advocates of top notch engineering quality in comparison to what I was experiencing. I was curious to know opinion from someone who has seen industry inside out.

He addressed my curiosity with a question "would you like to build something that no one will use ? or would you like to build something that people will use ?"

Of course the later.This question which @yoavflam asked pushed me to think about technology in a very different way and later on my curiosity took me to two phenomenal books that was introduced to me by another colleague.

The Goal by Eliyahu Goldratt
The Principle of Product Development Flow by Donald G. Reinertsen.

I learn with time that goal of the organization is to make money,increase life cycle profits like Jonah teacher of Alex showed him a different perspective of the goal of the manufacturing plant in the book the Goal.Likewise the robots in Alex's manufacturing plant is the technology that we built to solve some customer problem and when that problem is solved it should bring in some value for the organization at the end.

We often hear about organizations which are not profitable and burning cash and for that reason I have mentioned about life cycle profits, even these organizations are burning cash so they can be profitable one day in the economies of scale.

This conversation with @yoavflam ,some book readings and experiences has also helped me to see my role differently in the context of product engineering.I have an opinion that labels and job titles plays some role,something magical happens when you name it right.I don't have any research to prove this hypothesis. I am inclined to call people who build to solve customer problems product engineers. This gives a more clear context on the work they do.

In this series I will try to share my learning from both of the books mentioned above and compliment that with my experience of day to day to work.I will also be using few more books such as Team Topologies by Manuel Pais and Matthew Skelton and The Knowledge Illusion by Steven Sloman and Philip Fernback as references when required.

The reason for this cross reference is because the picture is complete with the customers that you build for, the colleagues that you build with, the ecosystem that you live in and the technology that you use if any to solve the customer problem.

Please feel free to disagree and comment and point out issues.

In the next episode I will be try to present my arguments on the decision making framework in product engineering

Tactical engagement in multiple teams

Sufyian — Sun, 22 May 2022 19:39:25 +0000

I got an opportunity where I was working for two teams at the same time tactically , by tactic engagement I mean at the implementation level.

I have the following observations,

Focus is divided , although you might be able to split your time accordingly but I find it difficult to clear my thoughts from the current context to another context. Even though I was able to switch work accordingly but my brain was still stuck and thinking about the other context.
If I moved from one context A to context B , the context A is not static in nature and thus evolving all the time so the time I keep working on context B I miss the difference of work in context A from the time I switched to context A to the time I switched to context B again.
Because of the lack of focus , quality was suffering in one of the streams and I got into rush unconsciously of just get it done , but it was also not getting done because of lack of focus .
Because of lack of deliverables and late deliverables I got an impression that trust deficit was building as well.

This strategy was adopted because of lack of people and from what I understand it was an attempt to optimize on number of people.I am willing and open to listen how others are solving this problem ?

These opinions are my own and I not in anyway represent any entity in any form