As an expert application architect and engineer, I’ve spent the past seven years designing and implementing agent-facing technical solutions across Discover call centers. In that time, I’ve run into a common problem: Teams often focus on technology as simply delivering and building new features and fail to factor in the underlying costs of infrastructure when building out product plans.
In the interest of producing a good or service, you must strike a balance between the needs of the business to determine and design propositions for value, and the software technologists who build the tangible products and services to deliver on those designs.
My hunch is that this communication gap is a frequent problem at most companies with a substantial software technology department, so I wanted to share my observations about when you might see this polarity and how to overcome it so you can deliver the best products, quickly.
The new feature
Let's look at an example scenario. The customer service department at a big generic bank has analyzed its customer base and concluded that its younger customers prefer contacting the bank via text chat as opposed to calling over the phone. They determine that offering text message servicing will significantly trim costs from their call center.
So, the business analysts sit down with their technological counterparts and discuss the strategy. The technology team does their initial research into what work is required for such a feature and then estimates a timeline. They consider the technical work needed to build the feature (APIs, databases, services, and protocols that need to be stood up) and the business considers the budget, brand risks, planning work, design, key resulting metrics and who will be involved in the feature's pilot test.
This should all sound familiar to anyone who has worked on either side of such a hypothetical situation. It seems straightforward enough: Start with an idea, factor risks vs. value, and then determine how long it will take and how much money it will cost. All that is left, then, is to build and deliver the product in a reasonable time.
Except that isn't how it typically goes, right?
After a few weeks, maybe problems come up at the status meeting. The underlying tech stack the team wanted to build on is too old and needs enhancements. A major security flaw is discovered in the wild that causes the team to shift priorities in the technology department to update vulnerable software. A sibling team in the department reminds the team of a long-running contract with a licensed vendor that is expiring soon and requires migration from their systems promptly.
None of this is a surprise. It happens all the time, and yet it didn't play a part in our planning and priority discussion. When the business and technology teams meet again to discuss how to adjust the time to fix these things, the technology team's budget and time will be brought into question.
So, what is the initial mistake here? Where did things truly go wrong? What changes could have prevented this common tale from playing out?
The invisible party
In this scenario, the team made a critical misassumption: That prioritization of necessities like the infrastructure, security, and long-term strategy for business technology should fit into the tech side of the 50/50 business split.
Instead, the technology part of the equation should be split into its two actual parts:
-
The architecture and engineering of technical solutions.
-
The maintenance and enhancement journey of complex infrastructure.
This split highlights that there are three parties sitting at the table, and they should have equally distributed their prioritization.
If you've worked in a business technology department before, this may be an unusual way to look at it, but it's a familiar concept nonetheless. Large technological systems have base needs that need to be met regularly to continue to function and to continue to stay relevant as time goes on.
When you purchase a home, you consider aspects of the cost beyond its sticker price. Budgeting for the home while ignoring closing costs, taxes, mortgage insurance, HOA dues, and maintenance fees would lead to a rude awakening come bill-paying time.
Furthermore, once you own the house, if you choose to make upgrades, you will, inevitably, run into unforeseen costs. After all, what would a home makeover show be without the inevitable mold, unexpected load bearing wall and leaky pipes lurking just behind the drywall?
So, why don't we make the same considerations for the multi-million-dollar technical infrastructure upon which we rely so heavily to provide new solutions to our customers?
Clear and distinguishable value
How do we explain this third newcomer at our priority table to our business partner? How do we help them differentiate from what to them must seem like identical twins claiming to be unique and important members of the team? When will I stop asking questions and start answering them?
The business team responsible for determining the needs of the product and the infrastructure development team sit a Grand Canyon apart as none of their work directly affects the other on a day-to-day basis.
It's difficult to explain to the user that wants their interface to show more than 30 days of information that the underlying systems only keep 30 days and cold stores anything older. To show more than 30 days would require huge, fundamental changes to the platform.
The user, understandably, just wants more than 30 days on the screen.
Looking in the other direction, it's hard to translate to your business partner the need to migrate from an outdated version of your software to a much newer, safer one that is NOT backwards compatible. It's hard to explain why it's going to take months of coding work, data migration, and training, and that putting it off longer will only exacerbate this already "unreasonable" timeline.
Learn to communicate
One of the single greatest barriers to teams working together is that they can’t communicate in a common language. Just like Sacagawea helped break down linguistic barriers for Meriweather Lewis and William Clark on their infamous westward journey, we need a common translator to bridge the cultural and linguistic barriers between teams.
Because language is complex, there are words or phrases with no direct translation because they require context and colloquial knowledge. To be truly successful, both business and technology teams need more than direct translation. They need to be willing to learn more about each other.
I'm not saying I expect business partners to learn to code or for software engineers to get MBAs, but some tangential experiences and mutual shadowing are vital.
Seeking to understand
Let's recap the situation. There are three parties seated at the table:
- Business partners with business goals
- A technical build team ready to construct solutions
- A technical infrastructure team eager to maintain and improve the dependability of their underlying systems
Since the infrastructure and business teams are the furthest from one another in similarities and common ground, the technical build team would be an excellent mediator and translator for both. This, at the very least, would allow some level of improved communication.
Furthermore, the business partner and the infrastructure teams could benefit from learning each other's perspective on how they manage priorities and the importance of the work. Often, people learn they have more in common than in opposition once they take the time to discuss their similarities.
The business teams would benefit greatly if they understood the compound value that faster, more efficient underlying architecture provides. Faster turnaround of new features, fewer errors and back-outs, A/B and canary testing, and up-to-the-minute health checks offer tangible value to all parties involved. If you're a business user and wish to understand the technical wizardry behind the scenes more clearly, start small. Learn what APIs are and the basics of how they work. Learn what horizontal scaling vs. vertical scaling is and its costs, pros, and cons. Learn about virtualization and containerization versus bare-metal infrastructure.
Likewise, the infrastructure team would be able to better plan and prioritize their work if they had a further out plan of what their business partners wanted to see over the next 2-5 years instead of simply the next quarter. Often, this would help clear the way to more predictable estimations in the future. If you're an infrastructure architect, learn more about the direction your business partner is taking in the long term. Learn about their "north star" goals and the metrics they use to measure success. Learn about the end customer or user so you have contextual awareness and even empathy for the products built on your infrastructure.
Conclusion
Do all the above and you will notice a difference in the air of prioritization meetings. Treat the room as having three participants and your thought process around priority will improve. Recognizing and admitting we have a problem is the first step in tackling it.
Will this solve mankind's fundamental inability to estimate work hours? Honestly, probably not. But will it enhance your communication and understanding of what to focus on, why it's important, and what it affects? Most certainly.
