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.

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. 

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.

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.

Getting Change Done

I am responsible for helping set strategy and direction. When I change current direction, the change may be a little. Or, it may be a lot. The greater the change, the greater potential for angst among the people impacted.

No executive wants to cause her team additional stress. On the other hand, no executive wants to maintain status quo and allow his business to fold. Navigating this tension is difficult. Here are a few things I’ve learned along the way to ease (but not eliminate) this tension.

Start doing, stop talking
Once you know the direction you want to go, start walking. Planning is needed, but not at the expense of learning. You seldom know how things will turn out, so begin to execute and make adjustments. Plan enough to get you started and to share the general direction and goals with key team members. That may mean a few hours or a few weeks – that depends on the scope and magnitude of the strategy to execute. Here are some recommendations:

• Encourage key team members to find the quickest items to start executing, as well as defer everything that doesn’t need to be known immediately.
• Reinforce to them you aren’t looking for perfection and you expect adjustments to be made continually along the way.
• Lay out significant milestones and ask for a plan to achieve them. They own the plan (how); you own the results (what).
  

Stay focused on the storyline, not the sentences
I recently worked with my team to deploy a new (to us) suite of development tools. Do I agree with every configuration and option the team selected? In honesty, I can’t answer the question because I don’t know every configuration and option the team selected. I am pretty sure if I reviewed every choice, there are things I would do differently.

That doesn’t matter.

What matters is that the tools are deployed effectively to increase the efficiency of the development team. In other words, allow the team to determine how the change is implemented. The message to the team is twofold: I trust you to make good enough (not perfect) decisions and I trust you to make course corrections as needed.

Acknowledge the team’s discomfort
It is normal (and part of being human) to feel anxiety and excitement simultaneously during changes of direction. Knowing that feeling frustrated and anxious is normal won’t stop the pain, but it is enough for most people to help them get through the change.

• Be there to help them work through the initial angst. When the first set of people emerge “on the other side”, enlist them to help bring others across.
• Remain firm that the direction is not negotiable (keep in mind if you really blew it, then of course redirect – for now assume your direction is appropriate). Some people may continue to resist, but strangely, knowing that you are committed is reassuring to them.

In the end, How much is too hard to push? If you are moving people out of their comfort zone, then aren’t you making them uncomfortable? And is that bad?

These questions have been buzzing around in my head for years. I’m not sure there is a right answer. More than likely, there isn’t.