Decompose in order to direct
Products, like teams and companies, are systems that address complex problems. … 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.
“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. …
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. … “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. “…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. …”
Randomly test — and deliver — via cold calls
“… One tactic that I still employ to this day is their practice of personally calling individual contributors throughout the company.”
…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 … In fact, just communicating within the C-Suite is akin to only testing your app in San Francisco. It narrows your vision. … People in the trenches have a different and important perspective.”
“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.”
When you get promoted, talk half as much and listen twice as much. You’ll connect faster and further with your ears.
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.
“On my first day in sales, my manager gave me a challenge: Show you know more about the person, than 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.’”
“… If you can adapt your tone, cadence and diction based on people’s expertise and what excites them, you’re on your way…”
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. …"
Here’s what Sailthru covers in each of its monthly roadmap meetings:
-review of corporate goals and how we're tracking
-review of new business closed
-review of key renewals
-ad-hoc presentations, such as internal engagement survey data reviews, updates on go-to-market–campaigns or key product enhancements
-shout-outs where anyone can recognize individual contributors for work that they've done that's above-and-beyond
-open floor, where any topic can be raised and discussed
Victory for a leader is not being a part of every decision.
Keep lean and learning
Mind your management debt. In the same way engineers revisit and refine their codebase, managers should periodically reassess their management. … You built your team for last year’s business. This is this year’s business.”
Broaden your benchmarking.
…Currently, Lustig serves on two boards: … One is an Fortune 500, pubic industrial company generating about $7 billion a year and the other is 20-person startup in San Francisco. That pulls my head — and how I benchmark success — in two different directions every month.”
Share jobs not just information.
…They started picking off all these little requests that were meaningful to customers, but just quick fixes from a technical point of view. They just needed to see and hear it firsthand.
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.