Friday afternoon, my team and I hit on what we thought was a serious data issue that might have had a big impact on our sales team. The data coming into one end of a business process didn’t seem to be coming out the other as we expected.
It turned out that we were mistaken about what we were looking at – it actually took us a few hours to figure out why the data seemed so anomalous. We had mis-diagnosed the situation, and without sober practices for working through the problem, acting incorrectly on that mistake could have cost us a lot in terms of time, energy, money and lost opportunities.
Six months ago when I came to the company, we might have acted quickly and aggressively at the first sign something was wrong. Even three months ago in the middle of Chapter 11 restructuring, we had our hands in so many moving parts we were working to stabilize, we could have made the poor decision.
I am super-proud of my team for the discipline they showed last Friday. Actually, I was probably the one chomping at the bit the most – I’ll confess that one of the things that helped me maintain discipline was that I didn’t want to cave in to bad practices in front of them. While I’d like to think I would have remained disciplined if I were alone with DBA access to the data, I’m also glad I don’t get a do-over to find out in this case.
It would have been SOOOO easy to just write the query that simulated the process transform, just to get it through to the sales folks who would have loved to have the information. We didn’t, and in fact our apps and processes were functioning as intended… as it turns out, better than our intuition at the time.
It felt natural to write a memo to tell everyone what we had found, as soon as we found it – even though we couldn’t explain why it was happening, what it meant or what anyone should do about it. We didn’t, and we saved everyone even more time, energy and money (not to mention, stress) because we didn’t misinform.
As proud as I am of my team, I am keenly aware of my temptations to fix things quickly and with finality. I often get caught thinking I know what’s going on, inside and out, when maybe I’m missing some key piece of information.
Human knowledge is always matter of framing and storytelling – our history, our culture, our education, our capacities to notice and observe, and our relative power to act frame what we know – and ultimately we tell ourselves stories that fit our situation and describe to us what is real and meaningful.
For so much of my career, my story has been about having the answer and knowing how to act. With teams, however, I’m open to the possibility there are many other actions to take than the one I want. In this case, that really saved us a lot of pain.
Reflecting on that, it seems to me that a culture of autonomy, trust and professional growth – both as individuals and as a team – is necessary to rely on the expert help of others. Without any of those, a team can only do what tasks its manager requires, and I hate to think what that would have produced in our situation Friday evening.
In writing software and perhaps other disciplines, standard practices, principles and ethics may support autonomy, trust and professional growth. In the same way, with every high-stakes exception that surfaces, it is prudent to define and [later] refine practices, principles and ethics so a team can act with trust and autonomy during recovery of the situation.
Choosing your casualty ethics before the situation occurs reduces the stress of making some decisions when catastrophe strikes. I remember in the Navy how our first actions when faced with fire or flooding were written out well in advance and drilled into our heads. First stabilize the situation, then make assessments and plan the recovery without all the panic… do all that you can to make recovery deterministic and controlled.
And if, like me, you want to act quickly and decisively, look at situations like my last Friday as opportunities to practice discipline.