How to work with engineers: A cheat sheet for finance leaders

Just because engineers and managers think differently, doesn’t mean that they can’t work together

You’ve spent your career working with numbers, perhaps by specializing in FP&A or accounts receivable. You might have been asked to stretch to other financial domains, like helping to raise funds or to run with a strategic finance project.

If you’re like most finance leaders, you’ve also found yourself increasingly being asked to design financial systems and work with engineering teams. And that can be tricky because engineers and financial leaders think very differently. It can seem like each party is speaking different languages.

And so as a finance leader, it falls to you to understand their short answers, programming jargon and tech-savvy ways while simultaneously putting key business and financial objectives into a language that they can understand.

That’s easier said than done, but the good news is that this post is going to teach you everything you need to know. Let’s get started.

Working with engineers to bring ideas to life

Engineers are great at distilling large ideas into small building blocks, but they’ll need a little support along the way. With your guidance on user needs and solution goals, you can help them to combine the blocks in such a way that they lay the foundation for a fast and scalable solution.

Unfortunately, it’s not quite as easy as simply telling the engineer what you want and leaving them to crack on with it. Simply telling them that you need a new financial system or reporting dashboard isn’t enough.

The good news is that convincing an engineer becomes much, much easier if you know how to collaborate with them. Here are a few tips on how to do that effectively.

1. Understand engineering constraints

As finance leaders, it’s easy to get excited about a potential solution and to go ahead and purchase it without consulting your engineering team. We’re like magpies seeing something shiny. Don’t go through the heartache of falling in love with a tool that’s too difficult to integrate. You have enough on your plate already without wasting time pushing for solutions that can’t actually be used.

It should be pretty obvious why this is a bad idea. Given that your engineers will be the ones responsible for implementing the solution, it’s important to get their buy-in from the outset. They’ll also have a better grasp of any constraints that you might face, such as whether there are decent APIs or integrations with your other systems. Even if there are pre-built integrations and no engineering effort is needed, there are sometimes data requirements or architectural prerequisites that warrant their consultation.

For example, some tax engines require a full customer address on every transaction in order for them to run smoothly. Without a full address, the transaction is rejected by the tax engine, meaning that your billing systems won’t match it and you’ll face all sorts of headaches and out-of-pocket payments when it comes to reconciliation and remittance.

It’s much better to create a list of the high-level requirements and data points that you need and to ask an engineer about the technicalities behind collecting and storing that information if you don’t do so already.

Oh, and did we mention that Anrok works even if you only have the customer zip code? We’ve got you covered.

2. Use diagrams to illustrate money flows

An important part of getting buy-in from engineers is saving them time. Note that we’re not talking about you doing their job for them, but rather about putting in the effort to give them a proper brief that covers where the money flows so that they don’t waste time building a system that they then need to rebuild again.

You’re an expert when it comes to the invoicing process, and your engineers aren’t. That’s why you can add a lot of value by creating diagrams that outline the different checkpoints in the process and how the money flows at any given stage.

It’s also a good idea to define the terms. For example, make sure that they know what the “total amount due” includes and what the difference is between “receivables” and “disbursements”.

If the system is in flux and some of the vendors or processes might change, let the engineers know as early as possible so that they can build the platform out with that in mind. Nothing annoys an engineer more than sprinting towards a solution only to find that the goalposts have moved.

With that said, engineers are used to iterating and throwing code away, and they know that revisions are a natural part of the process. That doesn’t mean that you can waste their time, though. Make sure that they know which parts are still exploratory and which parts are fixed so that they can design a solution that’s modular and flexible.

3. Plan, plan, plan

Building on from the last point, the single best way to win an engineer over is with comprehensive planning. They live in an ordered world where everything has a place and a process, and planning up front means that you’ll give them the best possible base to go ahead and build on.

And so if you want to impress your engineers, you should try putting on your product management hat and rolling up your planning sleeves. Write a document that outlines the background and the problem, as well as the impact that you’re hoping their solution will have. Don’t forget to include what’s needed and when.

If you have specific user stories or user profiles, include those as well. Remember that a user isn’t necessarily a customer. They can also be internal users, such as members of your ops team. You might even need a solution that’s used both internally and externally.

Going above and beyond

Once you’ve wrapped your head around what we’ve talked about so far, you’re ready to take things a step further. The tips so far have all been to help you to cover the basics, but if you really want to shine and to turn your working relationship into a partnership, you can tackle these optional extras:

• Sequencing: Identify whether there’s an ideal order in which you’d like to roll the solution out. Then see whether you can help to prioritize any parts of the project that are more important than others.

• Errors: Instead of waiting for problems to happen before you deal with them, be proactive and identify where you’re most worried about things going wrong. See whether your engineers can anticipate those error states and try to find ways to resolve them.

• Users: Whenever you’re working on an engineering project, you should consider the end user and see whether you can create personas for the different types of user that will interact with the system. Figure out what each persona’s unique needs are and what they’ll do with the information that they access.

The goal of all of this should be to make your engineering team feel as though you’re leaning in and working on the project as a team, rather than just dumping it onto them on top of their existing responsibilities.

Engineers tend to be busy people (aren’t we all?), and if you can meet them in the middle and give them a decent briefing, they’re sure to appreciate it. Better still, it will have an impact on the end result and lead to a piece of software that’s much more likely to get the job done. ⊞