SamB

I started as an electrical engineer. My first job was designing pump motor sets, instrumentation, and control panels for water supply and treatment systems in power plants and industrial townships. The work was physical: specifications, tolerances, load calculations, and the hard reality that a pump either moves water or it doesn't. There is no "sort of works" in electrical infrastructure. Systems either meet spec or they fail, and failure is observable. That shaped how I think about everything that came after.

​

From there I moved into engineering sales for products like DG sets and control panels to the real estate market in West Bengal. Techno-commercial quotations, government tendering, negotiating orders, ensuring payment.

 

Then into MEP project engineering for two years: designing, planning, and executing electrical, mechanical, and plumbing systems across residential, commercial, and retail projects. HT and LT cabling, HVAC, procurement, vendor negotiations, scheduling, coordinating across civil, electrical, and accounts teams. During that period, I built an MIS system from scratch, my first instinct that operational visibility required deliberate structure, not just effort. I completed a postgraduate program in business analytics alongside this work. Statistical inference, regression, time series, segmentation, forecasting, neural networks. It gave me formal grounding in the quantitative methods I had been using intuitively as an engineer.

 

Then a pivot. I moved from physical engineering into data analytics, working with British Petroleum's global procurement team on reporting and analytics for management decision-making. The tools changed to Oracle SQL, SAP BO, Tableau, R, Salesforce but the underlying problem was identical to what I had seen in electrical systems: measure what is actually happening, represent it accurately, surface deviations before they become failures. The tools changed. The physics didn't.

 

Then into software. A year as a business analyst in IT services: requirements gathering, agile boards, user stories, wireframes, process improvement. I was learning firsthand that the gap between what a client says they want and what actually needs to be built is where most projects fail. That decomposition discipline, breaking a vague ask into its irreducible logical components is the seed of what eventually became my approach to systems thinking.

 

Then I co-founded a SaaS startup. A cloud-based product for the hospitality industry: property management, restaurant management, cross-functional team across BA, development, HR, and marketing. I built the product idea, the logic, the process, the team. The company struggled financially and I had to leave. That failure taught me something no success could have. Building a good product is not enough if your operations - your cash flow, your resource allocation, your process discipline, your ability to see where you actually are versus where you think you are - they are not systemically sound. I carried that lesson forward into everything.

 

Then Unified Infotech, for the last nine years. I joined and grew into running and leading operations across engineering, finance, HR, sales, marketing, and compliance for a 130-person IT services company. During that period, my teams delivered approximately $16 million in software services across hundreds of projects. I conducted over a thousand interviews. I wrote over 150 operational documents covering process definitions, checklists, trackers, templates, agreements, guidelines, frameworks that became the company's working nervous system. Those documents were not written to theorise. They were written because something was broken and needed fixing, or because something worked and needed to be repeatable.

​

I am, by disposition, someone who does not stop at the boundary of his own domain. I read AI research papers and translate them into operational implications — not as an academic exercise but because I see direct relevance to how organisations govern themselves. I study mathematics not to publish but to verify: when I claim that queueing theory governs service delivery, it is because I have checked the formulas against real delivery data. I follow developments in machine learning, systems design, and organisational theory because the boundaries between these fields are artificial. The patterns that govern how a neural network learns, how a delivery pipeline flows, and how a team self-organises are not three different subjects. They are the same subject viewed from different elevations.

​

I maintain a creative practice in visual art, photography, music that runs parallel to the analytical work. This is not a biographical aside. The creative practice matters because it exercises the same faculty: pattern recognition across unlike domains. A photograph composes disparate visual elements into a coherent frame. A musical arrangement balances independent voices into a unified structure. These are not metaphors for organisational design. They are the same cognitive act.

​

The ability to see that a sprint retrospective and a quarterly performance review are structurally identical or that an electrical load calculation and a software scoping exercise follow the same decomposition logic that comes from the same place as the ability to see that a photograph and a musical arrangement are both acts of composition under constraint.