Subject Matter Experts Don’t Grow on Trees
An all too common story
James is a principal energy analyst who’s been with Acme Energy company for 10 years. He is not only an expert on energy markets, but also knows every nook and cranny of the company’s market trading processes, having tinkered with and hacked together many of the systems currently in use. One day, his higher ups in management decide that their in-house market trading system needs an uplift and hires an outside development team to build one. As the resident market trading guru, James is assigned as the subject matter expert (SME) for the project. He still has his normal day-to-day tasks to do, but now has to carve out some additional time to guide the dev team.
Unfortunately, while the developers have a lot of experience building complex IT systems, they have practically zero exposure to the energy industry. James spends many hours writing detailed requirements and patiently providing explanations on how the trading system and energy markets work. The dev team members are clever people and pick things up quickly, but they need more constant supervision to get things done right. One time, James encounters results that look off, but he can’t quite figure out why. After some back and forth with the dev team, he finds out that some generator bids had negative quantities, but the developers didn’t realise what seemed like common sense to him was a material problem (given that bid prices could legitimately be negative). Another time, a whole module had to be re-worked after the dev team made some naïve assumptions and misinterpreted the requirements while James was away on leave.
In the end, the new system is delivered, but 4 months late and over budget. James also put in a significant number of extra hours to ensure that the development team delivered an end product that was useable.
SMEs don’t grow on trees
While the story above is completely fictional, surprisingly, we often see versions of this play out in other company’s projects. The fate of a technology project frequently hinges on the level of engagement provided by the SMEs.
Beyond possessing niche technical skills, SMEs also tend to have a unique understanding of their business and how it fits in within the broader industry. But SMEs are also busy people and typically don’t have the time to upskill, train and provide handholding supervision to development teams. They usually have other critical business tasks that they can’t outsource, so they are at best, part-time resources to the technology project. Moreover, SMEs are hard to replicate since it can take years of experience to understand the business at a deep level.
The value of domain expertise in development teams
It may seem innocuous, but we firmly believe that there is real value in having domain expertise within the dev team. It is a tacit understanding of the domain that allows the dev team to make the right assumptions and design decisions without necessarily needing SME input, to ask the right questions or know when something feels wrong.
James’ story above could have also had a far worse ending. If James wasn’t engaged or was too busy with his day-to-day work, the dev team could have been left to their own devices, tasked with building a system that they don’t fully comprehend. We’ve seen this scenario firsthand, for example in an energy platform project that was languishing for months because the dev team had no guidance. We were able to get the project back on track, however this is a scenario that should have been avoided in the first place.
The value of domain expertise may be hard to measure in real-time as it is largely intangible, but it ultimately results in successful projects that are delivered on time and on budget.