In one of our usual catchups, I was having a chat with one of our engineering leads, casually explaining a feature request we had received from our sales organization. As a team, most of our clients are internal, and we are always happy to receive such feedback. It came in as a mild shock when the response was we wouldn’t be implementing this feature. I knew it wasn’t a matter of time; we had processes to handle long term as well as delight features. So why the no?
In the same casual tone, he went on to explain a viable scenario where with the feature implemented, the interaction between sales and finance systems would grind to a halt, and we would then need to push an Android update. In short, the feature delivered nothing more than delight value but had the potential to stop the entire business!
I moved on from this conversation with even more respect for this individual; this truly is the mark of great leadership.
In this entry, I will be discussing a bit more about risk and how you can relate to it within your engineering organization.
Be clear
Risk is such an ambiguous concept. You can’t see, touch, smell, hear or taste it. Even intellectually grasping it is a hard endeavor.
It is easy to ignore such things. After all, do you really want to be the Grimm at the project kick-off party?
Still, it’s essential to enumerate your risks and the likelihood the risk will materialize. It doesn’t need to be a long or formal document. Frankly, even if you drop the likelihood calculation, just the fact that the possibilities are on top of your mind is well worth the effort.
If you already do this, pat yourself on the back. Now, to the more difficult task. How do you know the risk has materialized?
Suppose in your risk register, you had “Developer leaves team” and “Vendor X stops supporting Y library.” You may say, well, of course, we will know when these risks have materialized. Once you dig a bit deeper, you will see how this belief is flawed in an insidious way.
Let’s take the first case. Most organizations have a reasonable notice period before you can leave, for an engineering manager, this is cheap comfort. When a team member has decided to move on from your business, all sense of initiative goes out of the window. What you now have is not the whole brained, energetic, committed dev you used to know, rather a by the book, can’t wait till 5pm, does minimum work to get it done lad. In short, your ambitious schedule is f*ckd!
Have a contingency plan
If you have a risk register and have not thought through how you will handle the risks, then in essence what you have is a glorified worry list.
I have come to see risk as having a fascinating characteristic. Once it becomes obvious, a risk will transition then what you need to do becomes obvious but mitigating it, if at all possible can only be done at a high cost. Before a risk is obvious, what you need to do is less obvious, but it can be done much more cheaply.
To illustrate the point, think of an app that failed in production because it runs out of memory. In this case, once it becomes manifest the event is happening, there is little else you can do if you are stuck in a VM type of architecture, scale it, and the application quickly eats through the new RAM. In short, what you need to do is visible but very expensive. If you had thought about this problem when the app was still in Greenfield, you then wouldn’t know if the risk would ever materialize, but solving it would have been as easy as say, choosing a different programming language, or going cloud-native.
You obviously can’t plan for all risks, but if you can select the risks with the most significant impact and the chance of happening. You maximize your chances of being able to sail through the worst of the storm or better yet, avoiding it altogether.
Did it happen to your peers
In Swahili, there is a saying
“Ukiona mwenzio ananyolewa, zako tia maji”.
Roughly translated, if you see your neighbor getting shaved, you better start wetting your own hair.
The point here is if other smart people have tried to solve the problem you are now embarking on without success, and you can not clearly articulate why they failed, there is probably an underlying structural issue.
An example here is the Kenyan cashless markets. Almost all international players come in with a firm intention only to accept online payments via credit cards, soon this softens to Mpesa, and for those that thrive, cash makes its way back into their model. I am not saying I understand why pure cashless doesn’t work or that it will not work, maybe even sooner than we think. What I am saying is, if you are entering the market now, you are well advised to consider lessons of your predecessors.
To get started, you can think of some of these risks, almost every leader in a tech organization I know has had to face some variant of.
- Developer leaves your team
- An essential vendor/library drops support suddenly
- The client gets new ideas as the project starts shaping up
How do you manage risk in your own organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchexv
