So you want to be a VP?

I am periodically asked about becoming a VP.  That is the wrong question. An appropriate question is, "How do I increase my organizational, customer, or industry influence?" Recognize that our interests are not what drive other departments.  They want to execute and grow a business.  For them, technology is a means to an end.  To influence them, seek to understand their world.   

I recommend three groups with whom you develop relationships. 

Customers

Find ways to visit customers, attend customer events, or join calls with customers.  Set aside time to learn about your industry (in my case, healthcare).  The more you understand your customer's business and industry, the better partner you become.  It will improve your product decisions, as you will have context for how your customers use your product and the problems they are trying to solve.

Business partners

Your business partners include departments like sales, support, services, and marketing.  Take time to learn how they do what they do.  For example, learn how a salesperson gets quota credit (you do know what quota credit is, right?) or when and how your services team recognizes revenue (you do know what revenue is, right?)  Once you learn these concepts, you will have a better appreciation for why June 30 is significantly more than one business day away from July 1.

 

Finance and accounting

Learn how the money works in your organization.  There are critical concepts like capitalization, R&D Tax Credits, and so on that impact your company financial statements.  These in turn impact your ability to hire or to buy software. Financial management is as much a software development executive function as is shaping engineering practices and technology choices. 

I have never met a customer or business partner that refused to teach me.  They greatly appreciate your interest.  In turn, you will be surprised at how much you teach them about product development.  Spend your time here, and the question of "How do I become a VP" will take care of itself. 

Argue your way to good decisions

If you observed my Friday afternoon leadership team meetings, you might think we are the most argumentative bunch of folks on the planet. And with good reason.

We are.

You might further think we constantly fight, back stab, and never agree to anything.

You'd be wrong.

Respectful disagreements
From the time I interviewed and recruited the team, we've interacted with respect. During interviews, I challenged their beliefs. I wanted to know how they handle a differing opinion by someone "in authority." Could they defend their position without becoming defensive? Could they acknowledge a counterpoint even if they didn't agree?

I didn't ask the "Tell me about a time when you disagreed with your boss" question. I wanted to disagree with them and see how they reacted. If you are going to do behavioral interviews, then you might as well elicit behaviors.

One important point. Even in heated discussions involving critical decisions, we maintain respect. We don't throw things; we don't shout; we don't name call.

High Standards
Every member of my leadership team is excellent at what they do. They have selected each other as much as they've selected me. We expect the best from each other and push each other. We don't want to let each other down.

Keep this in mind when you recruit. I've found that if you hire wrong, the team descends to the lowest common denominator. Hire well and your team rises to levels of achievement unreachable individually.

Confidence
What type of person is better equipped to be wrong and make a change? One with low self-esteem or one with high self-esteem?

Correct - high self-esteem. If we felt that our self-worth was tied to being correct, we would never get to problem resolution. We would be too busy defending our self-esteem.

So what does all this lead to (other than ending a sentence with a preposition)?

Freedom.

Freedom to acknowledge a better idea. Freedom to ask for help. Freedom to admit a mistake. Freedom to learn from each other.

What matters is that we arrive at a good decision. Equally important, it is a decision that has been argued, ripped apart, challenged, and extensively reviewed. When I walk out of the room, I'm confident a good decision has been made.

That is why I love leading this group of argumentative folks.

Coding a Mile in Someone Else's Market

It is easy to look at legacy software systems written by others and criticize the design and implementation. I'm not proud to admit it, but I've done this myself through the years. Time and experience have allowed me to appreciate the difficulties inherent in building software in an ever changing world.

Consider 10 years ago.

What technology were you using? We had just come out of the Y2K scare, the web was still about "eyeballs", and Silverlight and the iPhone were years away. You had Java as your main option for writing web applications (which I'm not sure were called web applications).

Were the applications written then bad because they aren't using Entity Frameworks and Service Composition? Of course not. Smart people were using the latest and greatest patterns (Gang of Four, anyone?) and practices (eXtreme Programming).

It is interesting to approach "legacy" applications from a historical perspective. What was the state of technology when they were written? What was the state of the market they were serving? How has that market changed over time?

You may find it interesting that these are the same questions you ought to be asking about technology, your application, and your market today.

The bottom line is this: It's hard to write software. Period. You have to handle today's problem. You have to anticipate what the market may need in the future. And more often than not, you are tied to customers who are using your current product.

Instead of re-writing an application, consider extending it by adopting newer technologies for new features. You may have to write some adapter code, but that may be easier than re-writing a bunch of functionality that works fine today. For example, I managed a project that integrated C# WinForms into a Delphi application. We extended integration and other processing by surrounding the core Delphi engine with .NET web services. We saved a lot of time not re-writing and regressing testing code that worked.

I'm not saying don't rewrite applications. What I am saying is that you should make sure you are doing it for sound business reasons, not just to move to newer technology for the sake of new technology.

Keep this in mind: That hot Silverlight application you are writing today will be someone else's legacy application in five years.

Maturity

Over the past several months, I've noticed an alarming trend in the way I answer questions. When asked about a product feature or a particular nuance regarding a release schedule, I find myself responding with a shrug of the shoulders and a simple "I don't know. I'll have to ask my team."

This trend forced me to examine my role. As a manager and to a large degree, as a director, I had command of each issue, task, and aspect of a software release.

When our customer support team would urgently inquire "What is the status of issue ABC?", my immediate response would be "It's being coded today, tested tomorrow, and a patch is shipping to three customers Friday".

Those days are gone. What changed?

Have I lost mental ability? Have I risen to the infamous level of incompetency? Am I slipping?

I think I finally figured out the answer. I matured.

Laugh if you will, but I am 100% serious. You see, 15 months into this Vice President role, I am beginning to act like, well, a Vice President. I'm not talking about the Dilbert pointy haired boss stereotype. You know, the one who is essentially an idiot, unable to inspire or generally function as an adult. No - I'm talking about beginning to think holistically about the business. In other words, contributing to my company's financial health (not just budgets and headcount, but sales, revenue, and margin), culture (not just organization charts, but how we think about each ourselves, the broader company, our markets, and our customers), and operations (not just product development, but marketing, support, services, customers, and so on).

It's not about losing my mental capacity or becoming incompetent. It's about me letting go of details.

I simply can't know everything going on anymore. As my responsibilities grow, I can't be everywhere. We all try to stay in our comfort zones. When I was promoted to Vice President, I fell into the same trap I did when I became a first time manager years ago. I kept doing what I did before, and assumed that the "new" part of my job would settle down once I learned it.

I continued to attend meetings that I should have let my managers run without me. I continued hanging around developers and designers making tweaks to the product (when I should have worked with my team on my vision for the application).

By clinging to what I had done well in the past, I eventually started to hate being a Vice President. I subconsciously yearned for the comfort of knowing everything going on. Fortunately, somewhere along the way, I realized that I have a team to build software. My job is to build team identity, product vision, and grow my managers to eventually take my current job. Their job is to deliver "results".

This realization has given me a new found understanding of what being a Vice President means.

In a future post, I'm going to be joined by friend and colleague Igor Vershynin. Igor and I will further explore our thoughts on what it means to be a senior leader. For now, please take a moment to share your experiences regarding when you first realized you had to let go of details. I am eager to find out if I'm indeed "normal" or "crazy".