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. 

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.

History: Its there for a reason

I recently had discussions with several senior engineers about “modern” software architectures. The conversation turned to service-oriented architecture. While discussing the merits of SOA principles, I was struck by their consistency with principles developed 30 years ago or more. For example, fundamentals such as information hiding, modularity, and coupling. These are time-tested principles that have been the foundation of major evolutions in software architecture since the 1970’s (and perhaps earlier).

Don’t get me wrong – I’m not suggesting that SOA is merely a new name for old concepts. The SOA discussion was merely a trigger for me to consider how we, as practitioners of our discipline, learn from and incorporate lessons from our past. My observations have led me to believe few development folks spend much time seeking and learning from the past. For example, how many members of your team have heard of Fred Brooks, Jerry Weinberg, Tom DeMarco, Dave Parnas, Barry Boehm, Watts Humphreys, and many others who paved the trail for large system software development and managing teams? Of those that have heard of these people, how many can articulate the key concepts and contributions these folks have brought?

Let me fast forward to my point, or more accurately, my question to you. What are you doing to know the history of software development, and what are you doing to encourage your team members to do the same?

You may ask why I seem concerned with lessons that are in some cases 35+ years old. I would tell you that the variety and depth of reading/learning I’ve done has served me well.

New technology doesn’t appear as “new”. Process innovation looks more like a natural evolution of what I know, versus, well – innovation. I view emerging technology and practices with a critical eye of “how is this like what I know” and “to what degree does it differ”, as opposed to “wow – I have to learn a whole new (insert your favorite thing that will be obsolete in 5-10 years).”

By learning about software engineering history, I have at my fingertips some of the best and worst methods that have been learned in the trenches. That gives me a much broader experience base than what I would have if I limited myself to only what I’ve seen firsthand. This in turn, increases the set of responses available to me when faced with “new.”

So next time you are looking for a new book, consider an “oldie-but-goodie”. You might just find that someone has grappled with very similar problems years ago that you are facing today.