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. 

Solve the problem class, not the instance

Failure reports are specific occurrences of end users experiencing unexpected results.  These typically occur when the system is not designed to handle unexpected user input.  There are really two underlying defects causing the failure.  The first is the workflow and visual design allowing the unexpected input to be entered.  The second is the unexpected result - the failure itself.

When correcting either defect, it is typical to update the system to handle the unexpected user input.  This is where most people stop.   Since systems are built using patterns and models, a defect in one part of the system has likely been introduced elsewhere.  Generally, solutions to reported failures miss opportunities to identify and resolve the underlying class of defects.  

When faced with a failure report from the field (or internal QA), go deeper.  While more an art than a science, there are several questions to ask that may reveal additional latent defects:

• Where else is this programming model used? (E.g., the pattern is used in all our repositories)
• How can the specific user input be generalized? (E.g., a screen blows up because one piece of information was made inactive by the system administrator, but other types of information can also be made elsewhere)
• Where else can these type data be entered? (E.g., Dates prior to today can be entered in many places)

Cultivate this perspective by starting with these questions and extending them to your environment.  Encourage people on your team to generalize every failure reported.  The goal is to get past the specific instance of the failure and to consider the class to which the failure belongs.  You may elect to only repair this instance due to time or money.  At least you will be doing so consciously.  Alternatively, you may find that you identify and avoid serious field failures.

You may elect to only repair this instance due to time or money.  At least you will do so consciously.  Alternatively, you may find that you identify and avoid serious field failures.

Fallacy of a shippable product

The agile literature generally advocates a potentially shippable product at the end of each sprint.  I find this assertion problematic.  It is disconnected from the larger discipline of product development and somewhat naïve.

The fallacy lies in the fatal (and unstated) assumption that the product is programming, testing, and documentation.  It isn't.  While these are the basis for the end user experience, they do not represent the totality of the experience.

For example, the customer may need help and call support.  Or, the customer may need help implementing the software and require training and services.  You may not even have a customer, and therefore require someone to market and sell the software.  All the coding, testing, and documentation in the world isn't going to solve these challenges.

Here are some of the other groups needed to make a product shippable.

• Sales requires knowledge of the problems the software solves in order to position it to the buyer.  They need assistance learning how to demonstrate it effectively.  They will also need to determine the price of the software.

• Marketing must understand the features, what they do, the problems they solve, and the benefits they provide to the customer.  They may need testimonials or other endorsements. They also typically develop collateral, press releases, and other material that can be "left behind" by sales or used at trade shows.

• Support must be trained on the use and troubleshooting of new features. They may also need to learn new issue escalation paths to development for issues that exceed their skills or knowledge.

• Services will need to learn how to install, upgrade, and configure the software.  They may also be the group that trains users, as well as consults on best practices for using the software efficiently.  They will need to develop end user training and consulting guides.

• Legal will need to draft contracts that can be used when the software is purchased or licensed.

This is a significant list of deliverables required to ship a product to an end user. Are you really going to have your organization do this in conjunction with the end of every sprint?   The cost associated with these type activities is best spent once, when the release is stabilizing towards the end of the remaining sprints.

Continue to strive for fully coded, tested, and documented software at the end of each sprint.  But let's mature our view of product development and recognize it is much more than just the ones and zeros.

Letting your team find their own path

I recently spent a week on the road.  As luck would have it, several key meetings were scheduled in the office for the same week.  I selected different members of my team to represent me at each.  They did a fantastic job representing themselves and our team.  They helped good decisions be made for our company and for our customers.

I'm proud of them, and in full disclosure, I also take pride in my role helping them be successful. But that is not the point of this post.  What I'd like to share are the lessons from a conversation prior to one of the meetings. For ease of reading, let me refer to the person with whom I talked as Chuck.
 
In preparation, Chuck and I talked about the intent of the meeting, who should attend from our team, how we thought the session would go, and our goals for the outcomes.  As we talked, I caught myself doing more dictating than coaching.  I was (not so) subtly guiding Chuck down a path of how I would have approached the meeting based on my role, my understanding of the background and attendees, and my knowledge of the situation.

Chuck stopped the conversations and said, "I need to do this my way.  I can't be you."  And Chuck was absolutely right.  We took a step back and looked at things from his perspective.  From there, Chuck led the approach with me in the better role of coach.  I challenged his assumptions when necessary and added context when needed.  In the end, we agreed that he would do much better as a confident Chuck than a pretend Neal.

Chuck went to the meeting and knocked it out of the park.  When asked how Chuck did, a peer executive texted me, "Very good.  [He] was strong."  I could end the story here, but there are two lessons I'd like to share.

First, without trust, Chuck wouldn't have advocated for himself.  I've written elsewhere about the need to build this culture.  This is a terrific example of why this matters.  If Chuck hadn't believed he could challenge anyone on the team - including me - he would have performed less effectively at the meeting.  Given the stakes, the results would have harmed the team and the business.

Second, it reminded me to let my leaders find their own way.  I try hard to not over manage, and yet it is easy to do so.  Only through constant self-awareness can I pull back and give my team the space to find their own solutions and style.  Each leader on my team has a unique way of approaching problems.  For them to grow, they need my guidance and trust.  And they need the confidence that comes from knowing that if they choose a path different than one I might have chosen, I will support them.

In the end, what matters is that we achieve good results.  To get good results, fall back to the basics of trust among the team and freedom to explore different paths to success.

Creating product evangelists

I've been spending time recently with sales, education, and other teams talking about new products.  A challenge these teams face is their distance from the original product design decisions (and the discussions surrounding them).  This can put them at a disadvantage with customers.  Without a deeper appreciation for the design intent, they may struggle to adapt beyond feature/function.  This can lead to missed opportunities or an overreliance on product development.

 

Here a two tips for creating product evangelists from within your teams of colleagues.

 

Invite other teams to product design sessions

Members of other teams bring valuable perspectives.  This alone is a great contribution.  Equally important is the insight they receive to the assumptions, alternatives, and choices made during the design process.  These insights provide knowledge and confidence during future customer interactions.  For example, when a customer makes a recommendation for an alternative, they might reply, "Great comment.  We considered that during design and here were our thoughts…"

Teach more than features

When you interact with a colleague, take a few moments to go beyond a simple "how-to" explanation of a feature.  After you explain it, review why the feature exists.  What user problem is being solved?  How does it make them more efficient? Effective?  What alternatives were considered and rejected? Why were they rejected?
 

Recognize that product development has the deepest understanding of the intention for the product.  We literally are with it from conception to delivery.  We must use every interaction with others to infuse them with the knowledge, hopes, and aspirations we have for the product.   That, in turn, makes the other teams significantly more effective.