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. 

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.

Development Partner Due Diligence

Recently, over tea, I was asked about offshore partners.  During the course of the conversation, I shared my thoughts about selecting a partner.  While not an exhaustive list, nor in a particular order, here are some thoughts I believe represent significant consideration.

Demonstrated technical competence

In what technologies does the partner claim expertise?  Regardless of whether you have a technical stack in mind or are deferring to the partner, you want confidence the partner has skill and competence. 

The strongest evidence is successful completion of projects using the proposed technologies.  Your partner ought to provide examples of other projects, including how the technologies were used, the extent to which they were used, and the results.  You want to know the projects were roughly comparable in terms of complexity (scope and team size).  If not, then you want a clear picture of how the partner can scale their experience to meet the demands of your needs.

Second, ask for corporate credentials or relationships that indicate expertise with the given technologies.  For example, if the partner claims extensive .NET experience, ask them to elaborate on their relationship with Microsoft.  I'm not talking about getting a certification for buying a bunch of Microsoft stuff.  I'm talking about actually engaging the Microsoft developer tools and technology program teams. Have they participated in any Microsoft ISV programs?  Have they been in a TAP? While not perfect, this can give you a sense that they have invested additional effort in mastering one or more technologies.

As a concrete example, a partner I work with has the largest absolute (and as a percentage of staff) number of HL7 certified developers on staff of any company I know on the planet.  This is a strong signal of their deep organizational commitment to healthcare interoperability.

Reference customers

Your partner should have a set of customers willing to talk to you.  I like to ask for 5-6 customers.  Some in related fields and some not.  Then I pick some (or all) and call them.  Here are some of the questions I typically explore:

• How does the partner handle the contracting process?  What about changes? I want to know if the contractor views this as a transaction or a relationship.
• Are the people on the team the same as the people that were introduced during the sales process?  I want to know if I can trust the partner, or is this going to be bait-and-switch.
• How is the quality of the deliverables (not just the software)? How are quality problems addressed?  I want to know if the partner takes pride in what they produce.
• How is the interaction with the partner's leadership team?  How would you describe their character?  Organizations take on the characteristics of their leaders.
• If you have visited their location, describe the physical environment (including hardware and equipment they have) and work conditions.  Is it a sweat shop or do the employees appear well cared for?  This impacts turnover, and consequently, the overall productivity of the team.
• Have you awarded the partner additional business since you begin the relationship with them?  Yes or no, why?  You can finesse the other answers, but where you put your money says a lot.
• If possible, describe briefly your project.  Ask the reference if they would recommend the partner based on your description.  Arguably, it might be little to go on, but you would be surprised.  You may describe a highly technical research project and find that the partner is better suited at a well defined line of business application.

The team

Ask for resumes or biographies of the key team leaders that will be assigned to your project.  Don't accept "representative" overviews.  Get the details of the specific people that will be assigned.  And be sure to interview them to verify their credentials and background.  You should treat these key leaders no differently than if you were going to hire them onto your team directly - because that is what you are doing.

In addition to the team itself, ask about their training program.  Elements you should look for include:

• New hire orientation programs
• Domain specific training (e.g, Healthcare, Banking, etc.)
• Function specific ladders with associated expected skills (e.g., Junior Developer through to Developer Team Lead)
• If appropriate, language and communication skills training

The best partners I've seen (and therefore, do business with) are able to tell me, "When you hire a Senior Java developer, you are assured they have these skills, each at this level, and will receive the following training in the coming year."

Again, this is not an exhaustive list.  But it should get you thinking about more than just cost rates.  Leave some of your questions or other items as comments.  I'd love to hear what you think.

Big rewrites: Summing things up

My last several posts dealt with migrating technologies, people, and skills considerations. Certainly, a few posts can't do justice to something as complex as a system technology refresh.  On the other hand, there are a few principles that can be helpful guides as you navigate the the complexity.

• Iterate
  If possible, break the rewrite into smaller chunks.  Determine the smallest amount of business value you can deliver and start there.   This allows you to stay focused on software delivery fundamentals and to use the new technology in the real world.  Release management, branching and merging, and patching are just a few of the processes I've seen atrophy after years of rewriting software without a delivery.
• People
  A blended team of existing folks and new hires is desired, but comes with issues that require supportive, yet firm, management. The technology transition is going to happen - that is where you must remain firm.    It is not reasonable to expect your existing team to learn a new technology stack in the context of significant business implications.  You will have acquire skills and that will cause friction.  These new folks have to be integrated into a new, combined team.
• Skills
  The existing team members are a key to success due to expertise of the system, customers, and industry.  Your commitment to their education, skills, and to be blunt - employment, is the supportive aspect. Show them how they will participate in the transition itself, as well as their contribution in the new world after the change.  Provide them a picture of their role after the new technology is in place to assure them that they aren't helping the "new folks" build the system that is putting them out of a job.

These principles provide you a start at identifying the core issues you will face regardless of technology or industry.  For example, iteration is simple in theory.  In practice you have to address factors such as, "What is the least meaningful value I can ship to the market?", "How can I deliver 'less than everything' alongside existing software?", and "How long do I really have in the market with the existing product?"

The questions that follow from the principles are the real power.  Conversations surrounding the questions and their answers will do more to increase project success than all the project management during the project itself.  After all, if you don't have the right skills, your team is demoralized, and the project is a multi-year science project, your project status reports are going to be the least of your worries.

System migration and people: Part 2

Technologists often align themselves to the skills they possess.  You see it in job titles: Senior .NET developer; Java architect, and so on.  In the midst of a migration to a new technology stack, you are changing more than a person's business card.  You are changing who they perceive themselves to be.

This presents a fundamental challenge to large-scale technology migration. And one of the greatest ironies. 

Possession of the required new skills is the least important contribution from your existing team.  Yes - you read that right.  During this transition, what makes your existing team so valuable is not their technical skills.  So what does?

• Domain knowledge
  No matter your business, there is specialized domain knowledge.  Mine is healthcare.  That means deep understanding of patient registration, ordering medications, patient care documentation, and scores of other complex workflows.  These don't change with new technology.  Your team has spent years learning these and the interplay among them.
• Customer understanding
  Your team understands how your customers operate at the intersection of the current product and the domain.  You can't do a migration without some consideration for your customer base.  Your team has customer relationships and trust (hopefully) to increase the chances of the transition going smoothly.
• Organizational knowledge
  As I wrote last time, you may supplement your team with expertise in the new technology. These folks aren't going to have a clue about anything related to the items above.  Your team can help them navigate the challenges of finding information about the existing system and processes - or even who knows the answer in the first place.

Returning to the challenge - changing who a person perceives themselves to be.  Your goal is to shift that perception.  You have to state (and restate) that technology is fleeting - and that it can be learned.  The emphasis for the existing team is on their knowledge of domain, customer, and organization.  That can't be extinguished by Java 8, HTML 5, or any other technology.

System migration and people: Part 1

My last post discussed migrating to a new technology stack as part of extending the life of a software system.  Next, I'll explore people considerations.  The first topic is skills related to the technology stack.  My next post will discuss the role of domain experience.  Finally, I'll attempt to tie it all together with a summary post.

Chances are your current team possesses skills to evolve and maintain the existing system. Unfortunately, these may not be the technical skills needed by the new technology stack. This may be a source of fear among the team. While there are no easy solutions, here are some thoughts:

• Get expertise in the new technology stack
  The most effective way I've seen this done is to hire additional people to supplement the team.   Find people who know the new technology well and have demonstrated its use in bringing to market solutions that have some matching characteristics to your product.
  
  You need people with experience, otherwise you will end up with the old solution implemented in new technology - not at all what you intend.Your goal is to quickly apply best practices with the new technology.  Consultants have their place, but in this situation I find that nothing beats employees who are fully dedicated to the project.

• Commit to trainingFor those who want to, provide training in the new technology. It's OK if some want to stay with the older stack.  it will be around for a while and you will need to maintain it.  However, show people that you are willing to invest in their future and they will be more likely to stay with you through the transition.
  In addition to training, integrate new employees with existing teams to increase the pace of learning.  This will create one team, demonstrate by example how to apply the new tech stack, and allow new employees exposure to existing rationale, business rules, and architecture.

Understand that for some, they will equate their value to their existing skills.  My next post will address this directly.

Migrating technology

I've been thinking a lot about extending the life of a software system.   There are several hard problems to solve.  The first problem I want to discuss is migrating to a new technology stack.  I'm skipping the discussions that take place before the decision to transition to a different technical stack are made.  Whether that decision is good or bad, if it has been made it is your job to get it done.

Consideration #0 - Don't do it all at once

Big rewrites are very likely to fail. So don't try them.  Learn from our collective Agile experience and establish a backlog for your migration.  You will learn a lot from planning the backlog, such as business and sales pain points, architecture dependencies, and areas that don't require immediate attention.  This gives you the advantage of putting new technology into the market faster, further accelerating your learning feedback cycle.

Consideration #1 - Build new features in the new technical stack

While straightforward to understand, this is perhaps the most difficult to implement.  Your end user work flows have to be (relatively) seamless.  The existing system was designed to support a collection of end user goals and workflows.  If the new feature is presented is a jarring manner, you risk putting your users off.

A few years back, my team was challenged to move from Delphi to .NET.  We found ways to render .NET screens inside Delphi containers.  Although we used different component libraries, an end user had to be extremely astute to notice subtle control rendering variations.  A more recent experience involving more disparate technologies has required some visual redesign of the existing application to reduce the perception gap.

Regardless of your technologies, you have to make the user experience transition as seamless as possible.  

Consideration #2 - Rewrite parts of the existing system when appropriate

As your existing system requires modifications, determine if the feature to modify is a good candidate for being rewritten.  Again going back a few years, we were faced with a major overhaul to government reimbursement for Home Health services.

Instead of modifying the existing (tried and true Delphi) payment system, we left it alone.  We wrote the new billing engine in .NET.  This allowed us to guarantee no regression to existing billing and to add significant capability in the new system.

Consideration #3 - Accept that some stuff will remain around for a very long time, maybe forever

This can be hard to accept.  Engineering, and I suppose business, is about choices.  Those choices involve what you do and what you don't do.  There are parts of your system that work, are reliable, and aren't causing you lost sales.  Before you rewrite those pieces, have a compelling reason to do so.

In general, your goal is to devise a scheme to migrate to the new technology over a reasonable period of time, incrementally, with little impact to your end users.  I know this is hard.  But it is possible.  The alternative - a massive all-or-nothing rewrite - has proven again and again to lead to failure.

Understand old solutions to solve new problems

In my last post, I ended with a comment about the importance of understanding solutions in order to solve a broader range of problems.  Problems have an essence.  If you understand the essence of a problem, you can draw from solutions for that class of problems.

Consider the problem of managing vaccination history for a patient.  Take a moment to enumerate the essential characteristics of this problem. Can you think of systems you have seen or used that address problems with similar characteristics?

What would you say if I told you that tracking vaccinations is a very similar problem to your vehicle’s recommended maintenance schedule?  If you don’t believe me, next time you get your oil changed, ask to take a look at the screen the service manager uses to upsell you on a new air filter.  Replace each recommended service with a vaccination and you should see what I mean.

Experience with and exposure to varied solutions is important.  However, it is not enough.  You must internalize the relationship to the problems they solve and the essence of those problems.

Here is an approach that may help:

1. When you use tools (physical or software), identify the problem the tool solves.  Ignore the features – focus on the problems.  For example, don’t think of a hammer as something to “Drive a nail into a wall.”  Think “Deliver force to an object.”  
2. When solving a problem, tease out its essence.  Find solutions that solve problems sharing essential characteristics.  For example, replacing the lid on a paint can requires the use of directed force to seal the canister.

Go out and build an inventory of solutions and the problems they solve.  The larger your solution inventory, the broader the range of problems you will be able to solve.

Drive

I recently received an e-mail relating how certain programming constructs look elegant, but turn out to be grossly inefficient.  That got thinking about abstraction frameworks and how they increase perceived development speed, yet can have unintended consequences (performance being a big one).  That, in turn, got me thinking about why the guys on the thread could immediately spot the underlying inefficiency through visual inspection.

Are they inherently smarter? Maybe.

Did they screw up a similar project and learn? Possibly.

Are they driven to understand how things work at a fundamental level? Check.

What separates these guys from the huddled masses is an innate drive to understand their world (in this case, software engineering) down to the ones and zeros.  I’ve sat next to both of them while they code.  They have debuggers, output windows, browsers inspectors, and SQL execution plans running well after typical developers would have committed the code.

They have a drive to know their code is correct, fast, and readable.  They dissect it, improve it, and test it.  If someone is going to break their code, it will damn sure be them, not someone else.
But you protest.  Surely, they must not understand deadlines!  Clearly, they take longer!

You protest in vain.  These guys are among the most productive guys I’ve worked with.  Their code is clean before they release it.  There is rarely rework.  Because they have spent so much time understanding their tools, they avoid mistakes made by developers who focus on getting it done and checked-in.

Their breadth of understanding allows them to quickly select appropriate constructs and patterns based on the problem.  Contrast this with developers forced to solve problems based on what they know versus the nature of the problem itself.  More importantly, their depth of knowledge allows them to know why their solution will work and what its limitations are.  Most developers won’t fully understand why their solution works. Or what problems it can’t solve.

I’ll leave things here.  I plan to return to this last paragraph in a future post.

Free to be crazy

I’ve been thinking about why I am comfortable throwing out crazy ideas to my team. I don’t think it is solely my lack of concern about appearing foolish (although there is an element of that).

I’ve repeatedly told my team – everyone, not just managers – that one of their most important jobs is to keep me from making bad decisions. I need to know that I am going to get honest feedback from everyone. This gives me freedom to come up with crazy ideas without fear they will be accepted simply because they came from me.

How do you get the team to a point where everyone believes they can safely share feedback with you?

• Reinforce the need to know the truth from your staff. Encourage people to challenge you. They may not do this initially. After all, you are the boss.
• When you propose an idea, actively solicit input in public settings: “What do you think?” “Is there something I am missing?” “What would you do?” It will take time. If you keep asking, people will start to use their voice.
• Once people find their voice, listen. The ensuing dialogue is the reinforcement needed to move your team into a positive feedback cycle. Use this time to explore your idea, tear it apart, defend it (without being defensive), and find viable alternatives.

I have found that most of the time there are only a few outcomes (in descending order of occurrence):

• I realize I am crazy and I’m grateful that we didn’t act on my idea.
• A kernel of goodness is contained in my idea and the interaction results in a much better idea.
• I actually had a pretty good idea after all.

Remember, you aren’t trying to be right. You are trying to get to the best decision for the situation. Your job isn’t to be right – it is to make sure the right decisions are made by the team.

One last consideration. If you never accept the feedback, then you have two problems. Number one, your team will stop offering it. And two, you aren’t really interested in hearing it – which is why number one happens.

So go out and be crazy. Something good is sure to happen.

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.