Twiga tech team currently has 25 members, the business in whole has 400+ employees and rapidly growing. This means for every techie we have 16-20 colleagues in other departments. Even more importantly, Twiga is a Tech enabled business, that is, the tech team plays a supporting role. Working well with other groups is not a luxury for the team, it’s a necessity.
As you can expect, there is bound to be some friction when operations and tech have to work closely together for business success.
As a tech team, we have great appreciation and respect for our operations colleagues. It is not easy to sell to over 2,000 vendors daily from a rapidly growing customer base of 6,000 customers and a network of over 13,000 farmers. Clearly, there are a lot of people doing a lot of things right.
In my experience, I have come to find out the areas of friction originate from two major areas:
- How the departments interact with the business
- How the people within the company interact with each other
Interaction with the company
Twiga is in the business of aggregating retail demand in African cities to provide low-cost access to better quality food.
To this end, Ops(Operations) and Tech(Technology) contribute in fundamentally different ways.
Imagine if you will, a company-wide meeting has been held, and all teams are reporting their numbers. Ops goes first. The crew talks about 100 tonnes moved from farm gate to vendor, 10 million Shillings in revenue and perhaps 4 million shillings in operating costs. Now, as the person accountable from tech, would you follow that up with, we delivered 100 story points? Even worse, 10KLOC (Thousands of Lines of Code)?
In these cases, you should use different approaches. For starters, try to identify simple to understand metrics. For example, our system uptime was 99% is more useful than our Apdex score was 98%. It doesn’t matter that the latter metric communicates more information. You can make it better if you can find business-oriented metrics, for example, we processed 10,000 orders and 9,000 deliveries without a single failure. Or 100% crash free users.
Given the flexible nature of the work, you must compensate by aggressively marketing what you plan to do, why you plan to do it, and when it will be done. Once it’s done, show don’t tell. Fairly regular tech demos where you invite your colleagues from other departments should help.
The moment a new business process is introduced, you can be positive pressure will immediately mount to have it reflected on the system. Know that businesses processes take time to mature, what seems set in stone right now will likely evolve into something barely recognizable once it hits the actual reality of operations. You want to give the process time. Otherwise, you will end up scrambling to rework your architecture every time the process bumps on a wall.
Interaction with people
Ops move fast! Almost all stock brought in is out within 48 hours with the notable exception of bananas which requires ripening.
Tech, on the other end, moves in two weeks sprints. There is progress in the middle of the sprint of course, but before you show this out, take a long look at an incomplete building or a car out at the garage. If the owner is nearby, their horror as the mechanic hammers, pulls and twists the various parts is palpable. Better to only share what is at least understandable.
Given this reality, I suggest you do far more planning than I would usually advocate for a tech team. You want your colleagues to co-create with you. Invite them to all brainstorms, you will be pleasantly surprised at the insights the non-techies can provide. The joint sessions will also allow them to peek into how you work, hopefully, in the process, they will also learn to appreciate the complexity of building a modern application.
Take the time to educate your colleagues. What you consider common may register as jargon to your colleagues. Don’t for a moment take the statement
“I am not a techie, I don’t understand this thing you guys are the geniuses”
or any of its variants. When it’s said, don’t take it as a statement of your superior cognitive status, interpret it for what it really is,
“You are a cost center who I am still not sure why I need.”
Make a great effort to understand your colleagues, get them to know how what you are doing will benefit them.
Finally, you want to be running an efficient support function. Most issues which will come to tech will likely be transactional in nature. For example, I can’t log in, I can’t see my records, etc. Transactional issues have an exciting asymmetry, they are usually easy to solve yet cause a lot of pain for the person experiencing them. This means you can create a whole world of value just by quickly handling them.