Posted on

How Do You Turn Around A Team Not Performing Well?

The first thing needed is an assessment of what’s wrong. My advice is to meet with each member of the team individually, make your own assessment of the information you are receiving. A few key dimensions to collect and assess are team structure, individual assignments and roles (whether the team has the right skill sets, are they motivated in their roles and are there any prevalent bad attitudes), and leadership style within the team. Also note the current success and failures  of the team.

What has worked well for me in the past is to define a mission statement for the team – what are we trying to do and why? Each member of the team should be able to state and defend the mission and why its critical. A shared understanding and buy in is critical for the team to rally around and cooperate. Remember the Star Trek Enterprise episodes always started with their mission statement – “Space, the final frontier. These are the voyages of the starship Enterprise. Its 5-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no man has gone before.”

Define SMART (first defined at GE) and Stretch goals. Smart goals are specific, measurable, achievable, realistic and timeline based. Stretch on the other hand may appear to be more than possible, but are the ones that spark remarkable innovations.

Setup team norms that ensure psychological safety (Charles Duhigg – Smarter, Faster, Better – The Transformative Power of Real Productivity). The following is an excerpt from the book that describes this concept and some of the other critical building blocks for a high performing team:  A team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.

1. Teams need to believe that their work is important.

2. Teams need to feel their work is personally meaningful.

3. Teams need clear goals and defined roles.

4. Team members need to know they can depend on one another.

5. But, most important, teams need psychological safety.

Where “Psychological safety” is a shared belief, held by members of a team, that the group is a safe place for taking risks. It is a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up.

Next address the tactical issues of failures and risks. Secure stakeholder agreements to ensure that targets are achievable. Reassign or repurpose team members with bad attitudes.

Some general principles that have helped me throughout my career are as follows –

  • Keep criticism private
  • Roll up your sleeves and get in the trenches
  • Achieve short term wins; Praise achievements and celebrate
  • Inspire and motivate – “We can and We will”

Finally measure what you value and put it in a cycle for continuous improvement.

For example, for an IT team, the metrics to measure may be the following:

  • Cadence of delivery
  • Delivery throughput
  • Quality of code delivered
  • Stability of the application/platform/system
  • Scalability
  • Usability measure
  • Business continuity
  • TCO – total cost of ownership

While for a product team, you may want to measure and improve these:

  • Effective product lifecycle management
  • Product market position
  • Rate of new / modified products being introduced
  • Success rate for new / modified products
  • Ability to deco/sunset loss making products

Or for an Operations team, the following may be relevant measures:

  • Cost per unit work
  • Quality per unit work and rework %
  • Risk mitigation/avoidance and quality tolerance
  • Average turnover in the team and morale

As always, feedback is always welcome…

Posted on

How To Measure Delivery Effectiveness For An IT Team

Common measures that should drive an application or application development team’s metrics collection and measurement:

  • Cadence – how frequent and regular is the release cycle
    • the number of releases per year
    • the probability of keeping a periodic release
  • Delivery throughput – how much content (functionality) is released every release
    • measures such as jira counts weighted by complexity or size
  • Quality – number of defects per cycle
    • defect counts from a defect management system such as ALM or quality center
    • change requests raised post dev commencement
  • Stability – Crashes/ breakage/incidents around the application
    • Crashes
    • Functionality not working
    • Application unavailable
    • Each of the above could be measured via tickets from an incident management system like Service Now
  • Scalability – how easily does the application expand and contract based on usage
    • measure application usage variability across time periods – for e.g. we planned for usage to double for Rx fulfillment at mail order pharmacies during Thanksgiving and Christmas  holidays than normal weeks
    • application scaling around peak usage + a comfortable variance allowance
    • shrinkage back to adjust to non peak usage to effectively manage TCO  and use capacity on demand techniques
  • Usability – how well and easily can your users access or work the application
  • Business Continuity
    • ability to recover in the event of a disaster
    • time to restore service in a continuity scenario

In my opinion, some key pre-requisites that drive good metrics are –

  • Good design and architecture
  • Code reviews and design conformance
  • Scalability isn’t an after thought
  • Usability is designed before the software is written
  • Automated regression and functional testing

I have implemented versions of delivery effectiveness for my teams at both Morgan Stanley and Medco and contrary to most practitioners beliefs, its not that hard to do.  Please reach out if you want a deeper how to discussion.

Posted on

Difference in motivating your team – healthcare vs. finance

You may need different techniques for motivating your team in healthcare and finance domains. Here’s some experience from the field.

In the Healthcare domain, when I was running projects in the field – we were able to connect the project outcomes to a patient’s health. For e.g. on a project where we were automating information collection (using a tablet coupled with a workflow tool – filenet) for a nurse visit for a patient infusion – we could correlate the accuracy of the data collection and the subsequent real time interventions we predicted to a reduction in ADE (Adverse Drug Events). It was certainly very motivating for the team to link the project outcomes to better patient health and the ability to save a life.

On another project “Therapeutic Resource Centers (TRC)” – this was similar to organizing our pharmacy and call center staff in a cluster of different cells specializing in a certain disease condition like cardiovascular or diabetes or neuro-psych or specialty. We were able to use a patient’s prescription history and medical claims to stratify them to a TRC. Once we achieved this, for any inbound contact from the patient for either a prescription or a phone call, we were able to route them to our appropriate therapeutic resource center cell. This resulted in a much more meaningful conversation with the patient regarding their health including conversations about adherence and gaps in therapy that had a direct impact on patient health. We were then able to use actuarial studies to prove the value of this model and introduced innovative products in the market to drive mail order dispensing at a much higher rate within our drug benefit plans to employers and health plans while promising for an overall reduction in healthcare spend and patient health.

In the finance domain its a lot harder to connect the outcomes of your projects to a fulfilling objective like patient health. Instead I have used a couple of different techniques to motivate my teams –

Close engagement with the business working with the regulators to understand the impact of their work. For example when we ran the risk ranking project, what motivated the team was their working very closely with the business in being able to visualize our regulatory rules and to be able to easily explain why we arrived at the result we had. What was motivating was also the fact that my team had come up with a way of visualizing the rules, that the business had not experienced before. We also were able to provide a complete audit history of how the risk ranking had changed over time by using a bi-temporal model to store our evaluation results and reason codes and the change in which client characteristics led to our evaluation of a different risk metric for the client. The business was a lot more comfortable in our annual sign offs after this visualization of the rules and audit records being available when ever we needed them for a regulatory audit.

A second way that I have used for motivating my team is being able to tie in the flexibility of our systems to the rapid changes in the regulatory landscape. Once we have a good design in place – that was able to extract our business rules out of the bowels of a program, these became a lot more accessible to change outside of the usual code release window. We were able to change our rules using a separate change cycle as opposed to our regular monthly or quarterly code release cycle – and be able to change things like high risk jurisdiction countries at a much faster pace (as needed and approved by the business). Being able to tie in our design to reduction of capital needed for our projects and also having to avoid the rapid code changes into production for every rule change definitely helped team morale as they were not constantly supporting emergency changes related to a rapidly changing regulatory landscape.