A software executive who teaches people to say no has chosen a curious line of work. Clients arrive with deadlines. Engineers arrive with possibilities. Somewhere between the two, someone must explain that the requested miracle will take longer than Thursday. Edward V. Szofer has spent years arguing that this conversation belongs near the beginning of a project. The ability to listen, then disagree usefully, is part of the job.
That conviction gives his career an interesting shape. Szofer is president, chief executive officer and co-founder of SenecaGlobal, a software development and technical advisory business established in 2007. His responsibilities cover strategy, management and operations. Yet the recurring subject in his public remarks is the person doing the work: what that person understands, what they can communicate, and whether they have a reason to stay.
The opportunity his parents insisted he notice
Szofer grew up on Chicago’s West Side, the son of Polish immigrants who had endured forced labor during the Second World War. His father arrived in 1949 and worked for Chicago’s transit system; his mother followed two years later and cleaned Archdiocese offices at night. Their message was that he had opportunities they had lacked. He should use them.
He describes himself with humor as well as gratitude. Asked how friends would characterize him, he offered honesty, sarcasm and self-deprecation. He also recalled serving for 15 years on the board of St. Patrick High School in Chicago. Giving other students a chance made the family lesson practical.
Before the dinner, a public company
His business education included a bachelor’s degree in business administration at Loyola University Chicago. He began his career at Arthur Andersen & Co. Later, at Whittman-Hart, he served as president, chief operating officer and a director, helping take the technology consulting business public. During a four-year period, the firm reached nearly $500 million in revenue and more than 5,000 employees worldwide.
Those figures describe a particular period at Whittman-Hart. They also establish the scale of the organizations Szofer had helped manage before starting SenecaGlobal. A company with thousands of employees poses a very different management problem from a handful of founders. Distance grows. Reporting becomes necessary. The original understanding between colleagues has to survive being translated into systems.
His subsequent career included senior roles at divine and Alliance Consulting. These were operating jobs, the sort in which a strategy eventually meets a staffing decision, a budget and a delivery date. By 2007, he was bringing experience from larger organizations to a new company with two partners.
A company begins with dinner
The founding story has the welcome advantage of involving an actual meal. Szofer and Rao Tummalapalli met for dinner in Chicago to discuss an IT services business. They wanted to combine software development and advisory expertise with a culture that paid attention to employees. Swaminathan Mani joined them. SenecaGlobal began in 2007, just before the market conditions of 2007 and 2008 made starting a business a less comfortable proposition.
At its 15th anniversary, the founders described two connected purposes: supplying technical skills to middle-market businesses and creating careers for the people supplying them. Those aims impose useful pressure on each other. A client wants continuity. An employee wants a future. A services company has to make both promises credible while still finishing the work.
Two countries, one company
Szofer has been careful about the language used for SenecaGlobal’s international operations. In a 2022 conversation, he explained that the Indian operation was wholly owned by the same company as the U.S. business. Senior people in the United States worked with clients and with dedicated teams in India. His reason for choosing India was straightforward: his partners were there, he had long experience doing business there, and there was a substantial technical workforce.
That explanation strips some romance out of the word global, usefully. A cross-border company still needs named colleagues who know one another’s work. Ownership, client understanding and the daily exchange between teams matter more than the sweep of a line drawn across a map.
Business requirements
Software engineering
One company. Shared delivery responsibility.
In 2017, he also described a blended staffing model that hired locally in the United States and India without using H-1B visas. His argument favored making opportunities available where people already lived. It was a specific operating choice, made within a broader debate about technology labor, rather than a claim that every company should organize itself identically.
The expensive habit of agreeing
Ask Szofer about missing skills and he starts with listening. Engineers can be so eager to demonstrate a solution that they move before fully understanding the requirement. An impressive answer to the wrong question remains the wrong answer. It may even be more expensive because everybody admires it for a while.
His second concern is the ability to refuse an unrealistic request and help develop a workable plan. In 2017, he described formal training in communication and dedicated English-language instructors at overseas locations. Advancement into management was tied to developing these abilities alongside technical competence. Communication had a place in the career structure, with time and teaching attached.
“In one word: training.”
Ed Szofer, on developing stronger skills across IT teams, 2017
The management implication is plain. If a company rewards only technical output, it gives employees little reason to practice the difficult conversation. Szofer’s approach makes that conversation part of professional progress. A programmer who understands an objection can prevent wasted work before anyone needs to explain the invoice.
What the client is really buying
SenecaGlobal’s earlier descriptions of its work make the commercial logic clear. In 2015, Szofer discussed clients whose local technical advisers could act as a CTO, helping decide questions of architecture, scalability, security and mobile strategy. For a business trying to bring a product to market, those choices arrive together. Hiring someone to write code does not automatically resolve them.
By 2016, the company was describing its service as SmartSourcing. Experienced U.S.-based technology leaders helped establish requirements and guide distributed development and testing. The offering extended across the software lifecycle, including maintenance, integration and modernization. The premise was that clients needed judgment as well as capacity.
A 2018 account offers a small example: an independent software vendor needed to expand an online review-monitoring product on a limited budget. SenecaGlobal developed a solution that gathered reviews from multiple sites in one place. The usefulness lay in the customer’s task becoming easier. The architecture could remain backstage, where architecture generally has better manners.
The plumbing beneath the screen
In January 2018, SenecaGlobal formalized an enterprise cloud and managed services practice. Its approach covered advisory work, architecture, transformation and migration, and ongoing management. Eric Crump was appointed to lead the practice, based in a new Atlanta-area office. The sequence recognized that moving a system requires decisions before migration and attention afterward.
By 2022, Szofer was using a house analogy to explain technical debt. A pleasing front end can conceal aging systems underneath, much as an attractive facade can conceal troublesome plumbing. Maintenance becomes harder; the people who know the old systems become harder to find. Delaying a change has a cost of its own.
There is something characteristically practical about choosing plumbing as an explanation for digital transformation. It makes an abstract investment legible. The customer can see the screen; the business has to live with everything behind it. Good management keeps both in view, including the parts nobody applauds at a product demonstration.
The test plan returns
Szofer’s newer public posts apply a similar standard to generative AI. One concerns testing. He acknowledges having disliked writing test plans earlier in his career, then argues that AI makes evaluation more demanding. He points to hallucinations, bias and changes in performance as things teams must examine. His position puts a familiar engineering discipline inside a newer technical problem.
Another post focuses on accountability: who approves an AI use case, who monitors its outputs, who can stop it and who owns the result. These questions reach beyond whether a demonstration works. They ask how a business will manage a system after people begin relying on it.
He has also questioned the ease with which polished AI-generated strategic advice can sound convincing. His suggested uses include generating options and testing assumptions, with people retaining responsibility for consequential trade-offs. Read together, these comments suggest a consistent preference: introduce the technology, then insist that someone can explain the work.
That preference gives the long career its continuity. Software changes. Delivery models change. A new tool can produce an answer faster than a meeting can agree on the question. Szofer keeps coming back to the duties around the answer: listen carefully, develop people, test what has been built, and know who is responsible when it reaches a customer. There is still a place for someone willing to say Thursday is too soon.