The Software Factory
Season 1: The Making of a Systems Builder
Season 1: The Making of a Systems Builder
Surendra Reddy10 min read
By the time my ITC journey moved into the Software Technology Park, the nature of the work had changed again. The factory had shown me how software entered the pressure of real operations, and Singapore had widened that lesson into public infrastructure, where systems had to work for strangers moving through a city. The next challenge was different from both. We now had to build the capability to keep building serious systems, and that was the real work of the Software Technology Park in Bangalore.
I never saw it as just a lab. It felt more like a formative institution, though we may not have used that language at the time. India was still early in its emergence as a serious global technology destination. The talent was present, the ambition was real, and Bangalore was beginning to develop its own technology identity, while capability had to be built deliberately rather than assumed. We were doing far more than writing code. We were building a software organization, and that distinction mattered. A software organization needs infrastructure, standards, tools, process discipline, technical leadership, customer confidence, quality practices, delivery habits, and a culture where people can learn faster than the market changes. Those ideas may sound familiar now. At the time, they had to be learned, practiced, and made real.
Access to serious computing infrastructure itself was a major event. We were working with hardware many of us had not seen before, since AS/400 systems and other advanced platforms were not casually available. They had to be secured, installed, protected, understood, and turned into working capability, and the lab became a place where people could experience modern technology directly rather than only read about it or hear about it from abroad. That changed the energy of the place. When new hardware arrived, it was never just equipment. It expanded what we could imagine, and it forced us to think about system administration, security, access, training, uptime, and operational discipline, because enthusiasm alone could not run a serious technology environment. The infrastructure had to be managed properly if it was going to become useful.
Communication infrastructure was just as important. A software technology park could not be isolated, so if we were going to serve customers, learn from the wider world, and compete in an emerging technology landscape, connectivity had to be treated as a foundation, and building that connectivity in Bangalore at that time required persistence. This was no plug-and-play environment. Networks had to be planned, links had to be made reliable, and people had to understand what communication infrastructure made possible and what it demanded in return. That was another step in my understanding of infrastructure. In the factory it supported operations, in Singapore it supported public movement, and in the Software Technology Park it supported capability-building, creating the environment in which people could learn, collaborate, deliver, and compete. That became very important to me, because a serious software organization cannot depend on individual brilliance alone. Brilliant individuals matter, and they cannot carry a growing institution by themselves. The organization needs shared practices, repeatable methods, reviews, training, quality systems, and a path for young engineers to grow into responsibility without the whole enterprise depending on heroic effort.
The early work was basic in some ways and never easy. We had to hire people, train them, expose them to platforms and practices that were still new in the Indian software environment, and build teams that could deliver for serious customers. We were never trying to create a place where people merely experimented with interesting technology. We were trying to build a center that could compete.
I still remember the energy of that period. There was a sense that India was standing at the edge of something larger, with Bangalore becoming a technology city in real time, companies learning from one another, and people trying to understand what global software delivery would require. There was competition, naturally, alongside a strong learning culture, and many of us were figuring things out in parallel. I was fortunate to be actively involved with other companies in Bangalore during that period, learning together around software quality, design practices, engineering discipline, and delivery standards. That exposure mattered because capability never develops in isolation. The ecosystem teaches you, and so do peers, customers, competitors, standards, and finally the market itself, which teaches you whenever internal confidence runs ahead of reality.
Quality becomes an organizational discipline
This was where software quality became central to my thinking. In the factory, quality meant that the system had to reflect real operations. In Singapore, quality meant public reliability. In the Software Technology Park, quality became an organizational discipline. We were among the first to achieve ISO 9000 certification, and that was far more than a badge for the wall. It forced rigor: documenting practices, defining processes, creating verification and validation methods, and bringing more consistency into how software was built, tested, delivered, and improved. Process can become bureaucratic when handled badly, and I knew that even then. In that environment, process was never bureaucracy. It was a way to make trust repeatable. A customer cannot depend on your intention, a growing team cannot depend on memory alone, and a young engineer cannot learn from a process that exists only in someone’s head. If the organization is going to scale, knowledge has to become shareable, quality has to become visible, work has to become reviewable, defects have to be caught earlier, and delivery has to depend less on luck.
Verification and validation gave us a useful discipline.
That distinction stayed with me, because a team can produce technically correct software and still miss the customer’s real need, meet a specification that was incomplete, or pass tests and still fail in use. The discipline is to keep both questions alive throughout the work rather than only at the end. The factory had introduced this lesson in a practical way, and the Software Technology Park gave it organizational form. It also made clear that quality begins much earlier than testing, starting in how a requirement is understood and continuing through design, code, review, integration, testing, deployment, and customer feedback. Waiting until the end to think about quality is too late. Quality has to become part of the rhythm of work.
Leadership as architecture
That was also a leadership lesson. As the team grew, the important question was no longer whether I could personally solve a problem. The real question was whether the organization could learn how to solve problems repeatedly, and that required a different kind of attention. Hiring had to look beyond technical familiarity toward curiosity, discipline, and adaptability. Training had to give people structured exposure to technologies, tools, standards, and customer expectations. Design discipline kept software from becoming fragile, reviews helped the organization see more clearly, documentation gave a growing organization memory, and customer communication taught technical teams how to listen, clarify, commit, and deliver. Leadership mattered most of all, because a young organization studies what leaders tolerate. Tolerate shortcuts and shortcuts become normal, reward speed without care for quality and problems hide until later, ignore learning and mistakes repeat, treat process as punishment and people stop telling the truth about the work.
I learned many of these lessons imperfectly. We were young, the industry was young, and the environment was changing quickly, so we did not have the luxury of waiting for perfect maturity. We had to build while learning how to build, and that may have been the best education possible. The Software Technology Park carried ambition and demanded humility in equal measure: every new platform reminded us how much we still had to learn, every customer expectation raised the bar, every quality practice exposed gaps in our assumptions, and every new engineer brought potential along with the need for guidance, structure, and patience.
This was where I began to understand that leadership is also a form of architecture. The structure of a team shapes how people think, the process shapes how work moves, the quality system shapes what people notice, the communication rhythm determines which problems surface early and which remain hidden, and the culture decides whether people are willing to tell the truth before failure becomes expensive. Building a software organization was never separate from building software. It was the deeper system that made software possible, and that realization stayed with me. Later, when I built and led teams across startups, public companies, research institutions, and global enterprises, I would return to these lessons often. A serious technical organization needs more than talent. It needs operating cadence, standards, shared language, and a way to absorb new complexity without losing discipline. At the Software Technology Park, I began learning that directly.
India proving itself
The experience also changed how I viewed India’s role in technology. At the time, the country was still proving itself to the global market, and it was not automatically assumed that Indian teams could deliver complex software at high quality. Confidence had to be earned through capability, process, reliability, and customer trust, and that gave the work a larger meaning. We were participating in the early formation of India’s software capability, learning how to compete globally while building the foundations locally, and that required pride alongside restraint: pride in the talent, the effort, and the possibility, restrained by the discipline of knowing the market would never reward intention. It would reward delivery.
The ISO 9000 work mattered in that context. It signaled seriousness, showing that we were treating software as a disciplined capability that could be examined, trusted, and improved rather than informal craft alone. It also gave people inside the organization confidence. Young engineers could see they were part of something structured and ambitious, customers could see a method behind the work, and leaders could see that software delivery rested on practices that could scale rather than individual effort alone. A two-person beginning became a 100-person organization through repeated acts of formation: hiring, training, mentoring, setting standards, building infrastructure, learning from peers, absorbing new technologies, and creating a culture that wanted to be taken seriously.
I do not want to make it sound smoother than it was. There were gaps, mistakes, and delays, moments when we were learning technology almost as fast as we were expected to use it, and times when process felt heavy, infrastructure was difficult, and the gap between ambition and capability was plainly visible. That is how institutions are built, though, never by already having the answers, and always by creating a place where answers can be discovered, taught, repeated, and improved.
The first architecture of a career
The Software Technology Park completed the first major arc of my career, and each chapter had given something different.
| Chapter | What it gave |
|---|---|
| The factory | The discipline of work: software had to enter the reality of materials, schedules, inventory, machines, planners, supervisors, exceptions, and the practical knowledge carried by people closest to the floor |
| Singapore | A wider sense of responsibility: infrastructure is most powerful when people can depend on it without thinking about it, and public reliability is a matter of trust as much as engineering |
| The Software Technology Park | The organizational lesson: hardware, networks, platforms, and tools were never enough; we also had to build talent, process, quality practices, verification and validation discipline, customer confidence, and an organization that could keep learning |
Together, those years gave me the first real architecture of my career, and it was the architecture of becoming a systems builder rather than the architecture of any one system. I had learned to move from code to operations, from operations to public infrastructure, and from infrastructure to organization-building. I had learned that software was never isolated from the people and institutions it served, that quality was a habit rather than a testing phase, and that trust had to be earned in use, under pressure, with real consequences. By the time I was ready for the next chapter, I was no longer only a young engineer fascinated by technology. I had begun to understand that serious systems live inside larger systems: a factory is a system of work, a city is a system of movement and trust, and a software organization is a system for creating capability.
That understanding prepared me for the next doorway, AT&T Bell Labs. Bell Labs would take me into a very different world, where the scale would be larger, the systems more abstract, and telecommunications would bring its own discipline, rigor, and expectations of reliability, moving the work deeper into networks, transaction systems, enterprise software, and the infrastructure that allowed people and organizations to communicate at scale. I did not enter that world empty-handed. ITC had already taught me to respect reality, listen to the people who live with the system, and think across hardware, software, networks, process, quality, customer expectations, and organizational capability. Bell Labs would give me a new arena for those lessons. The systems would change while the question stayed the same: can we build technology that institutions can trust?