Engineering resources are immensely valuable. But too often, they’re misused. One instance of how? Tasking engineers to write custom code for internal workflows.
Like, for example, when engineering is asked to write code to connect your platform with Salesforce so that new trial signups trigger new leads, or to write code for marketing to make language changes in your product’s UI. If you’re wasting your engineers’ time in this way, you’re making a mistake.
Here’s why — along with what you should do to manage internal workflows instead.
Which is what your engineers very much need to be focused on.
Your engineers’ time is best spent developing, fine-tuning, and building your company’s core product. That’s where their expertise and energy translates most directly into value and competitive differentiation. Any time taken away from that is time effectively lost. And contrary to what you might think, writing custom code for internal workflows is neither a trivial or one-time expense.
If you’re wasting your engineers’ time in this way, you’re making a mistake.
Among other things, it creates an immense amount of technical and operational debt that only your engineers are equipped to alleviate. (They’ll be the only folks internally with either the requisite knowledge or technical ability.) And this is debt that will continue to be a drain on engineering’s time, because internal workflows need to be manually updated anytime the process in question changes — say, when sales changes the way new trials are signed up. These workflows never end at V1.
Essentially, every internal workflow engineering is asked to write custom code for is an internal workflow that engineering will need to be responsible for — and mindful of — for years to come.
That’s a lot of development time that could have otherwise been spent optimizing your core products.
When engineers write internal custom code, it should only ever be to create structures that can enable the business. Internal workflows hard coded in the product end up being blockers for the business. Whenever changes or improvements to the implicated workflows need to be made, engineering is the only team who can make them.
Such bottlenecks slow down not only engineering — who have to drop what they’re working on on the product side — but literally everyone else, who themselves have to wait for the changes, updates, or improvements to go through.
Leaning on developers to write workflows pertinent to sales or marketing processes results in development and business teams each beholden to each other for the wrong reasons. Which isn’t what you want. What you do want is for engineering to be able to focus on the technical aspects of your product, and for the business to own all business aspects. You want to get out of their way.
The more code that engineering writes, the more bugs they’ll need to fix. This is as true of code written for internal workflows as it is code written for your core product. But unlike fixing bugs related to code written for your core product, fixing bugs born from internal workflows does not translate into increased value or decreased technical debt. It’s but a time-suck that maintains your inefficient status quo.
There’s also the issue of hand-offs; what happens when the engineer who wrote the code for a mission-critical internal workflow leaves? Her knowledge — which is integral to maintaining the workflow — becomes lost.
Okay, so we know writing custom code for internal workflows — and in turn forcing engineers to be responsible for maintaining and updating those workflows forevermore — is unproductive. The question is: what to do instead?
APIs exist to integrate products with external systems, such as Salesforce. The reason that companies don’t utilize them to facilitate internal workflows is they require technical literacy to use. Moreover, even when someone on the marketing team, for example, is so technically literate, engineering doesn’t like just handing over the keys to the code base and losing visibility into what’s being done to it — for obvious reasons.
Unlike fixing bugs related to code written for your core product, fixing bugs born from internal workflows does not translate into increased value or decreased technical debt.
Tonkean solves for that problem — and in effect empowers business teams to consume internal APIs to easily build and maintain their own processes and workflows without code.
How, exactly? Well, first, Tonkean is a truly no-code platform connects with all sorts of data sources, including 3rd party or custom APIs. That access and functionality allows non-technical teams to interact with and consume any type of application. With a few drags and drops of the mouse, non-technical teams can use Tonkean to plug into whatever APIs are available to them and design complex, stateful business logic to orchestrate any process they like — all without bugging your developers or affecting the underlying code, and in a manner consistent with the governing rules of the API in question.
What this allows is for engineering to create an internal API or message bus that allows business teams to interact with the core product in a safe manner — only making available the data and actions that business teams should have access to. Then, via Tonkean’s no-code interface, business teams can be the ones to define the logic for their internal processes.
At the end of the day, using Tonkean for this purpose gives your non-technical teams far greater freedom and functionality. It eliminates bottlenecks that limit both their effectiveness and the effectiveness of your engineers — while keeping your codebase clean. It allows engineering to clear its backload of technical debt, so they can spend far more energy on tasks that truly create value.
Ultimately, that proves a means of not only making the most of engineerings’ time and expertise — but of everyone’s.
Want to learn more about how Tonkean can help your IT team? Click here.
