June 21, 2023
The State of Engineering Management Research found that 91% of engineering leaders must provide financial reporting to their finance teams. The successful integration between finance, operations, and engineering (called DevFinOps) will be critical to the future of business leadership, but too few companies are discussing how these should collaborate with one another. At GLOW 2023, we tackled this topic directly, calling in two veteran Finance and Engineering leaders who accel in this collaboration process.
This post will continue the discussion from last week with David O’Leary and Joanne Cheng to discuss the line to draw when leveraging financial data for strategic decision-making as an executive engineering leader. To watch the full presentation, visit jellyfish.co/resources/glow-maximizing-engineering-impact-on-demand.
How does issue-level financial data and the ability to extrapolate the costs of certain issues factor into project prioritization? From a product delivery leadership standpoint, how are you factoring financial information into how you make your decisions and how you prioritize your team’s time?
David O’Leary:
A lot of that depends on what the product investment is and what an overrun might look like on that. I wouldn’t hastily make decisions based on investment at an issue level, but I would certainly be interested in seeing when something is overrunning. When we make a product investment, we really need to think about how this is going to move the needle for us and what value we think this is going to return. It would be very unlikely to see something overrun the expected return of a project, but it’s worth understanding the total spend on a given project in the context of others.
It sounds like the consensus is that you wouldn’t give a go or no-go decision based solely on financial data, but ithe data gives helpful context when it comes to speaking with your Finance counterparts about long-term strategy.
DO:
Definitely. It’s also just a useful tool for me as someone who doesn’t have a financial background. I can’t speak to language of product management or engineering to them necessarily, so I have to think about it in a different way. This data really equips me quite well to frame engineering team decisions in a conversation with my FNA colleagues.
Joanne Cheng:
Many people watching (or reading) this discussion will not have Jellyfish, and that’s okay. Every company I’ve been at prior did not have Jellyfish, and it is possible to get this financial data, but it’s a lot of work.
I was at a company where I worked with the engineering manager, and I downloaded every Jira ticket and we tagged them all. We asked ourselves, “How much is it going to cost us to build this new product?” We were trying to figure that out, and we would use our historical data to figure out the development of a new product. It’s important to measure things financially with engineering data, and you can do it.
Engineering is not the black box everyone says it is, but you need to do that exercise with discipline and consistency to make good decisions for the company.
DO: I remember being a college graduate in IBM, and my senior colleagues having such despair knowing they were going to have to do that year’s tax documentation. And I’ve been in a world where we’ve done this through Excel!
Those methods are significantly less accurate, slower, and full of guesswork. To really get anywhere, you needed hour tracking or apportioning for effort. You have to invent all these complicated things that really a tool like Jellyfish just does better. And I really, really trust the model that Jellyfish uses more than I would hour tracking because they’’re really looking at signals from multiple sources for where your engineers are spending time. I know personally if I was to do hour tracking, I would just fill in at the end of the week and say 40 hours.
If we’re working on this initiative, and it’s behind schedule, someone inevitably will ask if throwing more resources at the problem will help. From your perspective, can you speak to how you support those initiatives that are falling behind?
DO: The idea of throwing engineers at something and making it go faster is naive, but I certainly think tools that can help you understand when something is slipping on the critical path and then have realistic conversations with your team around scoping. There could be a way to support, help, or unblock an issue that arises.
Throwing engineers at things is a potential solution, if they’re up to speed enough on the project and have the programming language skills for the specific area needed. I think issue-level detail should really be more of a way to understand when we should stop and say, “Okay, something is moving on the critical path of something that really matters to us, and it’s not going as we expected. We should talk about it, we should do something about it.” Having a way to see that intuitively and start those conversations is valuable.
What are the future applications for leveraging financial data for engineering and product decisions?
JC:
Having a good view of historical information is really important to making future decisions, but accurately consolidating data, is very challenging. Accuracy is what makes that data useful.
Understanding where you were at, how long things took, and forecasting the future is dependent on your historical attainment and achievements. Having the ability to get that information in an easy way is the first battle.
DO: To avoid the sunk-cost fallacy, regular collaboration has to start earlier, and we have to have more particular thoughts about our investments and what we commit to. We must all have better information about what major investments, or “big bets,” we should be making.
Doing sunk cost analyses is an interesting idea, especially on a micro level, where it’s much easier to have that conversation. If you’re talking about, let’s say there’s a P4 bug that someone spent a million years on, it’s safe to assume that that’s probably not a good use of time. But I hope that the investments that leaders are making macro-wise will not always be dependent on that level of data.
Regarding process, what are some good ways that finance and engineering teams should check in with each other? Do you swoop in on a team meeting every now and then? Are there good things to know for finance teams to better understand engineering teams or vice-versa? How has that interaction looked, and what would you like to see?
JC: Generally, it starts with relationship building. It’s always important to build the right relationship between Finance and Engineering. The FP&A team is your friend, they want to model out different things such as what drives engineering hiring, what drives engineering costs, hosting costs, or other software costs. But in general, they want to have a good line of communication to understand the drivers of costs, and then drivers of achieving deadlines and deliverables.
