BUSINESS STRATEGY
In my experience as a Technical Lead , I found it rather surprising that people encompassed about 50 % of the challenges and technology accounted for the remaining 50 %. Conversely , as a Sales Engineer , I found that 90 % of my problems came down to people , leaving only 10 % as technical issues . Even as a developer , the human element cannot be evaded , with an estimated 20 – 30 % of challenges being people-related . but competent team , we were overwhelmed with the demands of the many teams and stakeholders who wanted their data to be on the data lake or wanted to consume from it . In trying to make the data available and conform to consistent formats despite the inevitable , seemingly endless variations and problems , we could not take the time to understand the context of the data , its usage and the nuances of its business rules .
Gabriel Eisenberg , Senior Data Engineer at Synthesis Software Technologies
While one might assume that presenting a robust technical solution would result in easy acceptance and progression in the building process , it ’ s not that straightforward . There ’ s a continual need to convince others of the solution ’ s validity , align perspectives , address miscommunication openly , build both relationships and trust over time and collaborate closely with the client and team members .
People play a pivotal role in these processes
Given the time , engaging with the business stakeholders and individuals would allow for a better understanding of their requirements . It helps to understand what problem we are solving by building a particular system and what it means for the business itself . The ‘ why ’ is critical . Understanding this and the monetary impact will underly the decisions being made regarding the system and can also be used to frame design decisions and arguments .
Seeing it from others ’ perspectives
So , is the solution to avoid people entirely ? While tempting for the stereotypical introverted engineer , it ’ s likely impractical and would lead to isolation . Moreover , the most intriguing and challenging technical problems and solutions often emerge from collaboration .
Where people matter in business
What are the motivations of people you are working with and why do they need to achieve the tasks they ’ re putting forward to you ? By empathising and understanding where they are coming from , you can obtain context about the broader business and stressors .
Open and regular communication
As a consultant , one will always be interacting with a client , both at the stakeholder level and at the user level . One needs to be considerate of who one is speaking to . From the broader business context to the nuanced dynamics of interpersonal communication . Each facet plays a role in shaping successful outcomes for projects .
Business context
I have been reading a fantastic book by Joe Reis and Matt Housley called , Fundamentals of Data Engineering . While the following extract is framed for data engineers , I believe that it generalises for technologists working across industries : “ Without a framework for managing data , data engineers are simply technicians operating in a vacuum . Data engineers need a broader perspective of data ’ s utility across the organisation , from the source systems to the C-suite , and everywhere in between .”
Upon reading these two sentences , what struck me was how this related to my experience working in a platform team responsible for the development of an enterprise scale data lake . As a relatively small
Open and regular communication or feedback will ensure opportunities for earlier intervention , if needed , and will help manage the expectations of stakeholders . Managing expectations can make or break a project . This is one of the biggest lessons I have learnt . Being upfront with your stakeholders builds personal trust and manages expectations .
Engagement protocol and establishing boundaries
It is important to set boundaries and lay out terms of engagement . This protocol will prevent you and your team from being overwhelmed by ad-hoc requests and will help prioritise requirements and manage client expectations .
Meet them where they are
The reality is that you don ’ t necessarily know the context of the people you are talking to . Job titles can be misleading and force assumptions into interactions . It helps to first understand if the person you are speaking to is technical or not . Secondly , what level of information do they need to know given the situation .
26 www . intelligentcxo . com