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. 

Customer involvement to reduce time to satisfaction

In my previous post, I discussed time to customer satisfaction. Much has been written elsewhere about customer involvement as part of a user experience program.  Prototypes, wireframes, and other techniques are well documented. As such, I'll avoid these topics. There are, however, two items that don't receive the same level of attention (or at least I haven't seen them frequently). They are the focus of this post.

Early involvement via sprint demos

Agile advocates that stakeholders (or proxies in the form of product owners) be part of the team.  This is an admirable goal, but I've yet to see it occur in practice.  This may be due to my experience in product development companies, where the "customer" is a market, not specific people.  While I've not had the opportunity to embed customers in my teams, there are ways to integrate them in your process.

Make each product owner responsible for cultivating a cadre of users.  These users are people heavily involved in the operational workflows for which the product is intended to be used.  Beginning with the first storyboards, this collection of users participates in sprint demonstrations.  They are made aware of the user stories delivered and the user stories being considered for the next iteration.  As the product is demonstrated, they can immediately confirm or correct workflow and visual designs.  I've even witnessed users helping each other understand how to use the product, thereby eliminating feature requests entirely.

This group also is a sounding board for questions or ideas that come up during the development process.  It is not unusual for product owners to have multiple user contacts through an iteration.

Advisory boards

While iteration demonstrations are tactical, advisory boards are strategic.  Look for people with industry breadth and understanding of operations within their organizations.  Advisory boards are critical to ensuring appropriate major product features and workflows.  Instead of focusing on iteration deliverables, this group guides you to determine priorities of competing major features, high level workflows across features, and your standing relative to competitors (within ethical and legal constraints).  

You will want 8-12 people representing multiple dimensions of your product. For example, a product for physicians would have an advisory board comprised of multiple specialties, geographies, and EHR usage. I encourage you to have non-customers represented, as well. They are highly likely to provide you completely new ways of thinking about problems, since they don't "know" your product or its workflows.

Most importantly, you want this group to tell you where your strategic mistakes are - before the market does.


These two groups can tremendously impact your ability to deliver a highly acceptable product to the market. They help refine workflows and visual designs, thereby decreasing the time to customer satisfaction. Equally important, the people involved throughout take a high degree of ownership. They become product advocates, since it is their product design.

Customer satisfaction & technical debt

Time to market is a key concept for product delivery.  Reducing time to market can preempt competition, show responsiveness to customer requests, and generate revenue sooner.  It is the basis for commitments to sales, to customers, and to the market.

Without ignoring time to market, I propose you plan, design, and deliver software with an additional concept in mind: Time to customer satisfaction.  

Bringing a product to market and having satisfied customers are not the same thing.  Time to market is straightforward.  It is when the product is released to sales and to customers.  Time to customer satisfaction is difficult to measure. It is a subjective combination of a customer's willingness to purchase, deploy, and use the software.

With an ideal product delivery process, the gap between time to market and time to satisfied customers is zero.  Alas, we don't live in ideal worlds.  Periodically, the gap is significant. When this occurs, the development team incurs a subtle of technical debt.

Let me step back for a moment.  Generally, plans expect version "X" to go to market with little or no additional work.  Reported defects are handled by a maintenance or customer support team. Requested enhancements are considered for a future release.  All is good.  

But, what happens when the feature itself is rejected?

Regardless of the reason for the rejection, you are forced to repair fundamental flaws immediately. These require depth that only your development team has.

The challenge is that your development team is executing plans and commitments for version "X+1."  Those have been communicated to sales and customers.  Product delivery commitments are commitments for revenue.

Oops.

You have a few options:

• Replan and change commitments.
• Overwork your team to repair version "X" and maintain delivery of version "X+1" simultaneously.
• Cut corners on version "X+1" as much as possible without impacting revenue and customer satisfaction.

The right option depends on your business.  For example, a small start-up needing cash is going to go for the latter two choices.  Whether or not the choices are sound business decisions is irrelevant.  What matters is that they feed on themselves to increase the likelihood of a future delay in version "X+1" time to customer satisfaction.

You might say at this point, "Adjust the plan and change the commitments." That is the engineer talking, not the business person.  Changing commitments can not be taken lightly.  The consequences range from lost credibility to severe financial harm (lost contracts, stock price, etc.).  

Your goal as a development leader is to reduce the risk of a gap in time to customer satisfaction.  Now that I've introduced the concept, I'll stop here. My next post will focus on things you control (or, at least influence) to decrease time to customer satisfaction.

When opportunity knocks

Last week, I resigned my position to pursue a new opportunity.  I will dearly miss my current team, product, and customers.  But, you know what is said about opportunity knocking. 

Turns out that a combination of family and professional factors lined up.  It was truly "too good to pass up."   In the course of the many goodbyes, one individual wrote that it takes a lot of the right kind of work to find these things.  He then asked if I had any recommendations. 

My reply was, "No."

Followed promptly by my recommendation.

Know what matters to you.  You are the only one that can figure that out.  Maybe it's money, maybe it's family, maybe it is title and prestige.  Then go a little deeper.  For example, what does money represent to you?  Security?  Freedom?  Is money the only way to achieve these goals?

The things that matter most to you are a filter for opportunities that come your way.  Technology comes and goes (unless mastery of a particular technology matter most to you).  Commutes can be altered.  And yes, cities can be left for new ones.

In the end, know yourself, use that to measure things that come your way, and seek out people that share your goals (since they will likely be connected to others that also share your goals).

Maybe it is less about finding opportunities and more about recognizing them when they appear.

Teach, don't solve

New or inexperienced managers tend to fall into the trap of solving problems for their team.  This frequently occurs when an engineer asks for validation of a technical solution. Given normal delivery pressure, you want to quickly get the problem corrected or solution implemented.  The perceived easy path typically goes something like one of the following two ways:

1. It's good.  Make this tweak and go for it.  Let me know when you are done.
2. You really missed it.  Here is how you need to do this. (You then return to your office where you solve the problem and the engineer watches you)

Either may be efficient in the short term, but neither is a teaching moment. Watching someone else do something is a poor substitute for engaging the person in the learning experience. To increase learning, engage your engineer in the solution process. 

Regardless of whether the solution is right or wrong (as if it is ever that black and white), ask the following questions:

• What are the aspects of the problem that lead you to this solution?  What are the downsides to this solution?
• What alternatives did you consider?  What is your rationale for rejecting those?
• How will this solution impact…? Insert what is appropriate, such as implementation, maintenance, upgrading to a future version, workflow.
• Now that we've discussed this a bit, what parts of the solution will you change? Why?

Your goal as a manager is to promote independence and critical thinking skills. Solving the problem on behalf of the engineer builds neither.

Learning

In my last post, I introduced Challaboration as a core team value.  A second core value is learning. Within this are two elements: being adaptable and courage.

Requirements, technology, business environments all change.  A person (and by extension, a team) will have limited success solving new problems only using past solutions.  If you are unwilling to adapt and don't have the courage to find help from others, you will not expand your set of tools to solve problems.

Adaptable

When you explore new approaches and tools, you learn.  For example, around 2011, my company made a reasoned decision to shift some of its product stack from .NET to Java.  Quite a bit of our team (who we hired as .NET  developers) were faced with a choice: continue as .NET experts or become novice Java/HTML/JavaScript programmers.  Every developer made the transition.

It would have been easy to leave.  After all .NET is the dominate programming platform in Nashville. Because they chose to adapt, they expanded their toolkit (learning a new language and front end technology).  It was a tough road. In the beginning, we wrote a lot of C# code masquerading as Java.  Over time, the team grew into first-class Java developers.

By adapting, the developers learned a valuable lesson:  Their excellence is based on their critical thinking and design skills, not language competency.  More importantly, they

not to define themselves by the technologies they know.

Courage

Our team is a mix of veteran and junior developers.  We have experienced healthcare providers and seasoned QA who have never provided direct patient care.  You would think the knowledge flows from the "older" to "younger" generation.  That is far from the case.  Junior developers show veterans how some of the new technology stack functions.  In turn, veterans share hard-fought learnings from years of production software.

What our team has in common is not knowledge or skill level.  It is their courage to say, "I need help" or "I don't know."  This simple acknowledgement creates the possibility for learning. 

The dynamics of healthcare IT demand constant learning. A willingness to adapt and the courage to ask for help creates an environment where everyone learns from each other.  As a team, we adapt to changing demands and have the courage to rely on each other to learn how to solve problems. In other words, we win and lose as a team. 

Bad idea filtering

Some teams seem to consistently end up with better decisions.

While not downplaying individual contributions, I believe the way the team brings ideas to life (or kills them) matters most. It isn't about starting with more good ideas.  It's about creating a culture where good ideas are refined and bad ones are eliminated quickly.  In other words, they have a better Bad Idea Filter, and the means to make mediocre ideas good (or great).

I've found two factors to influence idea quality: challenge and collaborate.  They are blended; so much that my team coined the phrase Challaboration.

We challenge practically everything.  If you propose an idea, you will defend it against technical, business, workflow, and visual design critiques.   One person is unable to consider a variety of consequences, barriers, and alternative solutions.  A team of people with varied experiences can. If the idea cannot be defended, then it doesn't survive - even if it is mine.

With multiple solution paths explored, the resulting decision is more resilient.  It draws from improvements to address previously unforeseen aspects of the problem, while minimizing weaknesses (or at least making them known).

If challenging is behavior, then collaboration is motivation. Team members receive and provide critiques to the idea, not the person.  This isn't about scoring points; the desire must be to reach the best decision the team can make.  When I challenge a design, I do so to make it excellent. I want the other person and the team to be successful.  Thus, I challenge.

The motivation for the critique matters.  If the motivation is to increase quality results, better ideas emerge.  If the motivation is to show personal intelligence or to score points, bad decisions slip through.  Worse yet, idea generation itself shuts down. 

Your team gains confidence as they struggle with criticisms and pursue alternatives.  When external groups and customers provide input, frequently it has been considered in depth.  Your team is prepared to acknowledge inputs and explain how they were considered, enhanced, or rejected.   In turn, your team's confidence provides confidence to the customer.

Challaboration is a core value of our team.  Each person has a responsibility to assist in crafting a better solution.  They also have an obligation to identify weak ideas and prevent them from harming the team, product, and customers.  These are key, since our team doesn't start with more good ideas than most teams.  It just has a pretty darn good Bad Idea Filter.