Thank you!

Early in his career, Neil Lustig faced a choice: continue his fast ascent as one of IBM’s most promising engineers in a satellite office or take an entry-level sales position in its larger New York City location. His boss told him the move would end his career, within the company and industry. But his mentor argued the opposite. He said he’d hit a ceiling without exposure to both the technical and commercial sides of the business — and that he’d never lead without experiencing all the moving parts. The mentor, once a former engineer, oversaw a team of 7,000 people at the time.

Lustig transferred to New York — and thrived in sales. He found that his engineering chops enabled him to explain technology in a way that moved people to action. He closed million dollar deals with clients like Citibank, and reached his annual quota in six months. Over the years, Lustig rose through the ranks to eventually lead IBM’s e-commerce solutions division when Lou Gerstner was at the helm. Every team he joined thereafter he earned more responsibility: as the GM at Ariba — where he helped shift the company to the cloud — to CEO and President at Vendavo to leading cross-channel experience management platform Sailthru.

In this exclusive interview, Lustig shares how his management code came from his days coding —and how by drawing from that expertise, he’s grown into a more effective manager. He outlines everyday engineering practices that not only have helped him strategically direct companies, but develop the ‘soft skills’ needed to lead.

Decompose in order to direct

Products, like teams and companies, are systems that address complex problems. This was an important realization for Lustig when he first made the jump from an individual contributor to a manager. To tackle his new set of challenges, he leaned on decomposition or factoring, which breaks complex systems into components that are more manageable to process, tackle and address. For Lustig, this doubled as strong management philosophy.

When Lustig began his first global role at Ariba, he transitioned from leading sales in New York to being responsible for finance, sales, marketing, professional services and support across Europe. “I had no idea what I was doing. Leading teams in 10 countries — that all spoke different languages — was overwhelming,” he says. “I fell back on the team based software development approach I used as an engineer: You don’t write a new system in a continuous stream. You break it down as deeply as you can into subproblems and solve each one in a sequence. Being CEO is exactly the same. In this case, I mapped it out and started with customer satisfaction because product direction and maintaining our growth rate hinged on that being understood. That opened up the challenge — and our ability to focus and coordinate our efforts to address it across the organization.”

Factoring is most successful not only when systems are broken into parts, but when those parts are modular and can be maintained. In the case of leaders, that means each component — in this case, team leader — is competent and can act independently. When he oversaw Europe for Ariba, Lustig spent his first weeks in London digging into the challenges each team faced and uncovering why. “Your first job is to understand the problem holistically. Then, start the factoring. Dig into each facet of the problem by asking your team open-ended questions, such a ‘Why did we lose this deal?’ or ‘Why is this customer unhappy?’ because they encourage and generate full, authentic answers. My favorite question to ask was ‘How do you know — what data or insight drove your decision?’” he says. “As a leader, it’s tempting to just ask the questions that return the answers you have predisposed in your mind. That’s why it’s critical to push into areas outside your expertise — not only to return to a learner’s mind, but to identify just how independent your functional leaders must be. In my case, I learned with all the variations by country, I needed the Finance head to be able to direct on her own. Those discoveries from decomposition help leaders better prioritize and allocate resources.”

Randomly test — and deliver — via cold calls

The experience of getting randomly chosen to answer a question in class can make even the most capable students anxious. But what if you cold-called to offer answers instead of ask for them? “I learned a lot from former IBM CEO Lou Gerstner and his executive team. One tactic that I still employ to this day is their practice of personally calling individual contributors throughout the company,” says Lustig. “Once Jerry York — IBM’s then-CFO — called me. It was early on in my time at IBM. He asked what was getting in my way. I told him I was struggling to close a customer in the global account program. He literally said ‘Okay, I’m on it’ — and hung up the phone. The bottleneck was internal and the conversation between him and me helped illuminate and fix the hold-up.”

Senior leadership can get so disconnected from the frontlines, especially as startups scale into larger organizations. For Lustig, this habit of cold calling was akin to the random testing in software development. “It’s a common software testing approach where one generates random and independent inputs to test programs. It helps ensure the integrity of the system and starts to weatherproof it for when it’s ‘out in the wild,’” says Lustig. “It’s critical for leaders to do this, as they can get so quickly disconnected from the real world. In fact, just communicating within the C-Suite is akin to only testing your app in San Francisco. It narrows your vision. The IBM execs always talked to the troops. People in the trenches have a different and important perspective.”

When you get promoted, talk half as much and listen twice as much. You’ll connect faster and further with your ears.

In companies even a tenth the size of IBM, senior leaders could randomly cold-call daily, and not connect with everyone in a year. When Lustig joined Vendavo, he scaled this method by organizing cross-functional teams of 6-10 people, so he could meet all 150 members in-person. “The objective was to decrease the perception of hierarchies and friction. That started with purposely not meeting with people with their immediate teams, but instead in functionally diverse groups. No team would have a manager or manager from their team in a group with them — it made it easier for them to be members of Vendavo than a specific role in engineering or sales,” says Lustig.

“Now, as a CEO, I don’t expect one serious sit-down conversation to be a silver bullet establishing open lines of dialogue from here on out — but you’d be surprised how far a conversation like that goes,” says Lustig. “Something about a small group, casual chat not only made me more human — and not just the CEO the board brought on to make changes — but also served as a precedent that each person could reference. Throughout my seven years with the company, I’d estimate 30% of the team reached out to me proactively or really opened up when we’d meet. That’s a significant portion of a good-sized company.”

Neil Lustig with members of the Sailthru team

Invest in languages — become a polyglot.

Engineers can debate how many programming languages are needed to be a proficient developer, but knowing more than one has its immediate benefits. As is true with linguists, being aware of at least two languages can show the strengths and limitations of each of the languages by comparison. Even if you don’t fully achieve comprehension, you obtain a greater appreciation of other languages.

Lustig learned this phenomenon soon after he transferred from engineering to sales at IBM. “On my first day in sales, my manager gave me a challenge: Show you know more about the person, than the software,” says Lustig. “As an engineer, this was hard, as I knew a ton about the software. He told me that I needed to communicate in a way that people would walk away saying: ‘This guy gets it. I want to work with him.’”

Resonate before you educate. That doesn’t mean dumbing it down, but focus on dialing in first.

Every role — in engineering, sales, marketing — that Lustig has had has made him a better executive and CEO. “My fluency is my biggest strength as a leader. If you can adapt your tone, cadence and diction based on people’s expertise and what excites them, you’re on your way,” Lustig says. “What’s important to your customer success team and what drives them emotionally is fundamentally different than what motivates your sales team.”

Take how Lustig pitched the impact of Sailthru’s new elasticsearch feature — a capability to adapt marketing campaigns in real-time — to his engineering, sales and customer success teams:

Fluency in multiple languages doesn’t mean communication is all about talk. Action will resonate more quickly with some teams. For example, when Lustig worked at Ariba, every year they awarded the company’s top salesperson a year lease on a Porsche. “Rolling a Porsche onto the floor and giving the winner the keys was a sight,” he says. “The rest of the sales team said to themselves: ‘That’s me. I’m getting the keys next’ and spent the year going after it. Sales is competitive and visceral, which makes a visible status symbol enticing. But that same reward wouldn’t work for your engineering team, and definitely not finance. Every profile has its prize.”

Open source your strategic roadmap

When most leaders talk about alignment, it remains this mysterious — nearly mythical state — where teams are synchronized while scaling. They neglect to mention how much autonomy is necessary to make it work. “If alignment is a process, you can control the foundation more than you can the long-term outcome. So for example, like many companies, Sailthru’s teams meet periodically — we do it monthly — to review our roadmap and dig into how each department is performing to hit our goals,” says Lustig. “We make sure to create the space for these sessions — and while we look at metrics, we frame them as conversations, asking: ‘Are we on track? Do we need to adjust?’ We discuss, instead of just do a read-out and report-in.”

It may seem commonplace these days, but Neil Lustig remembers the advent of the Open Source Initiative in the late 90s. “Whether you were for it or against the idea of open-source software, it changed how we approached programming. Anyone could learn, change and distribute software to anyone for any reason,” says Lustig. “For me, the power of that is the abiding philosophy of developing in a collaborative public way. When startups share their roadmaps, they should share all of it. That’s the foundation for alignment: a habit of convening and exchanging information. The cadence and common platform keeps everyone in step — not giving everyone marching orders.”

Here’s what Sailthru covers in each of its monthly roadmap meetings:

Sailthru’s practice of monthly roadmap meetings has generated results. “In a recent engagement survey, 90% of our employees said that they understand how their daily work contributes to the company’s goals. A through line from daily, individual work to overall company goals is so critical to me. I love that we are never more than 30 days away from checking in on it,” says Lustig.

Lastly, open sourcing your strategic roadmap entails allowing others to know — and own — more of it. “I see so many CEOs and founders of early-stage companies struggle with this. When you’re 20 people, you touch everything: You know every customer. You make every software decision. If you’re still doing that when you’re 50 people, you become the bottleneck. Your involvement slows the entire company down,” says Lustig. “When I joined Vendavo, the CEO and founder asserted that the three of us were most experienced and should close every deal. My ambition was different: We had 20 salespeople. If they all pulled us in, we’d be stuck at $15 million in annual sales. This inflection point happens in every function: engineers turned engineering managers, marketers turned VPs of marketing. You have to trust the team you’ve got — and that starts with an open sourcing the plan.”

Victory for a leader is not being a part of every decision.

Keep lean and learning

Over the decades, Lustig has seen many tide shifts in technology. It’s taught him that nothing he did last year is going to work this year — and especially not next year. “My first program was written on a paper tape. My next was on punch cards. Eventually, my dad brought home the Apple II,” he says. “What you did last year is no longer relevant. There’s never good enough. There’s only better.”

Here are a few areas where Lustig keeps an adaptable mindset in management, just as he did as an engineer and technologist:

Leadership is fixating on what ships, but more on the ship itself: the organization. That’s engineering at scale.

Bringing it All Together

When software engineers make the jump from owning lines of code to business lines, they should lean on their developer’s skill set to help guide the way. First, organizations, like software systems, are complex — use decomposition or factoring to break them down into manageable, modular units. Randomly test the integrity and health of your system by cold-calling employees. This will help you calibrate your understanding of progress — roll up your sleeves to help with specific challenges as thanks. Developers should be proficient in at least one dynamic programming language, but are upleveled when they know more — the same goes with leaders who are “conversant” in all the functional areas in their organization. Open source your roadmap, clean up management debt and broaden how you benchmark your abilities.

“That boss who said I’d end my career if I jumped from engineering to sales wasn’t thinking big enough — and I’m not talking about my career. Because in that way he was right — I never truly returned to software development,” says Lustig. “What he neglected was what might happen to others’ careers — and entire company — if I transferred. As an engineer, I could’ve continued to build products sequentially or equip myself to experience firsthand how teams fit together to achieve exponential growth. If I had any advice for my fellow engineers early in their careers, it’d be this: Truly being ‘full-stack’ involves stepping outside of software development at some point. Take the leap, because here’s the thing: you’ve already got the foundation to get you there.”

Photography by Christos Xidias.

Recommended Articles
First Round TalentAccess exclusive opportunities at the startups in our community