Staying Out of the Weeds: Demystifying Engineering Strategy for the Rest of the Business | GLOW 2024

All right, welcome back. Hope you got a break, stretched your legs, um, enjoyed the bumper music. Frankly, the music between the things is phenomenal. I've never, I've never worked at a place with better musical taste, I will say. Um, so hope you've been enjoying the tunes and the conversation. It's great to have you all back here. I'm super excited to be having this conversation. We're going to talk for a little bit with Jalal Takhalla of Kinaxis. He is the Executive Vice President of Engineering. Yeah, why don't you say hi, tell us who you are and what you do and what's—

Hey, look, hey everyone. Yes, I'm Jalal Takhalla. I work for Kinaxis. Kinaxis is a software company, enterprise software company that's been around for a while. Um, I still like to think of ourselves as startup, but really we're established company operating, uh, in the supply chain management space. So we build software that helps, um, help companies, Fortune 100 companies, manage their supply chains. And as you would imagine, supply chain is a very popular a term, especially for the last 2-3 years. Um, I've been with Kinaxis for 24 and a half years, but who's counting. Started as a developer many years ago, right? Wrote lots of, lots of code, and then moved into, into management, and, and I'm enjoying that.

Do you write much code these days?

I know, I think I stopped writing C++ a while back, JavaScript and Java more recently. But I do a lot of experimentation with, with our, our, you know, creation tools. We have a platform that allows you to create all kinds of resources— dashboards, workbooks, scorecards, all kinds of visualizations. So I, I do play a little bit, but I'm, I'm now— I'm dangerous. So developers are telling me that I'm dangerous every time I I crossed the code. I have about 500 or so people that I have to, I have to lead. So there's enough, enough on that side.

Right? You've got enough to do that you don't have to go looking for trouble. All right. Awesome. Very cool. Yeah. So folks, we're gonna be talking about engineering strategy, demystifying it, talking to people who are not engineers about it. Probably not everybody watching this is a CTO or VP of engineering. They may not actually have spent a lot of time thinking about engineering strategy. But to jump in and frame this out, what do we want to talk about here? What is engineering strategy? Is it the thing we're making? Is it how we make it? Is it the tools? When you think engineering strategy, what's the area that you're concerned with?

It's a good start. As I said, My experience and my perspective is always going to be through that kind of lens of an enterprise software, well-established enterprise software company. That said, I do believe that the startup could always use kind of more rigor and aspire to excellence in both strategy and execution. So if you don't do that, you know, you end up into that random acts of engineering, which is very, very damaging. Anyway, at a very high level, if you think about it, when talking about product strategy, you are thinking and talking about problems that you're trying to solve, more or less the why and the what, you know, if you like. Whereas the engineering strategy is more about the solutions to those problems that we're trying to solve. It's the how, you know, this technology versus that technology, and the who, you know, is it— do you build it in-house, do you buy it, do you partner? So, so that's kind of the difference. Now, in my opinion, it's best if those two strategies have multiple touchpoints and almost kind of overlap and kind of smash together and fuse together, especially when it, when it comes to the when, which is the strategy, the priority and the timelines. Right. So, so the two groups working together and contributing to each other's strategies is what I find is most, most, most useful. Now, talking outside the engineering and product realm could be, could be challenging, you know, depending on the executive leadership team that you are working with. I've been blessed at Kinaxis to, to have great, great peers in my organization, in my leadership team. Great people that contribute in many ways to, to what we're doing in engineering. It's again what I find useful time and again is to have everyone around the table align on the company strategy, of which the product and engineering strategies are part of, and the goals that you establish. So if you have that alignment, then it's easier to talk about, you know, these groups or that group strategy. Including engineering. Um, of course, it's important the language you use in that conversation. Um, you cannot geek out with, uh, with, with those people. You cannot just talk only about technology. It is try to always answer that kind of, um, you know, eternal questions coming from the other side— what's in it for me, or, or so what, right? So I think that's, that's the key. At the end of the day.

Yeah, right. Talking about we're excited about the new language, the new framework, the new whatever. It's not a super exciting discussion maybe for everybody.

No, not really. You only go that far with that.

Yeah, yeah. You mentioned timeline alignment, which makes sense because it impacts the business. It could impact sales or capabilities and other sorts of things. I mean, we all know that software development is impossible to predict, right? Predicting the future is hard. It's done when it's done, somebody told me. How do you present strategy and conversation about timelines credibly? Like, what do you use to drive that conversation?

Yeah, so, so as I said earlier, our software helps companies, uh, deal with, um, with their supply chain operations. And, and businesses, they, they see lots of volatility and disruptions every single day. And what's interesting though lately is that the technology is evolving at such a fast pace, and it's not only the business that you see that disruption and volatility, it's the actual technology landscape. So you need to be prepared to review and adjust previous plans on a regular basis, right? You don't want to do it too often though, because as it's the case with individuals, an engineering organization needs some time to get into the kind of the zone. Right? And then so, you know, to get that momentum on the topic before you kind of switch to the next shiny, uh, shiny, uh, thing. And, and I'm telling you, like, there is always something out there that, that's going to be that temptation, um, to kind of jump into something else. So, so you need, you need to be able to, uh, to adjust and review plans and strategies and execution, but at the same time you know, you have to be— to, to try to stay in that kind of consistency as much as possible. So in our case, what we have is we have quarterly investment councils, which are, which are vehicles for us to— for product and engineering to present the progress on existing investments. So usually there's 3 types of outcomes and recommendation out of those reviews, you know: accelerate this program, slow it down or pause it, and stop it altogether. I've seen all those three recommendations being executed on. And then on the flip side, or in a balance, you know, you also want to talk about new investments, right, including trade-offs that are required. So that's kind of how you do it. Now, For all these conversations, it's best if you have measurable data to, to accompany your recommendations or your, your updates, right? Things like market research, buying purchase intents, adoption rates, uh, you know, forecasts versus actuals, um, attach rates for, for new SKUs, uh, costing information, um, for building or operating a product capability. So all those All those, uh, provide you the, uh, the foundation for that good quarterly investment review and informs the decisions that you make with the executive team.

Yeah. Do you find, like, how does quarterly feel for you as a cadence? Because things move fast, things change a lot. Or you do feel like, do you need to call an audible mid-quarter, or is it just sort of confirming that you're on track for the year?

It's a good question. So we have them scheduled quarterly, but we could, we could have an out-of-bound meeting. So there could be a case where something needs to be acted on, like pronto, right? Like, like now. So we, we don't have an issue to, to gather together and, and do, and do that review. But we, we tried, we tried to have it quarterly. But we will have some impromptu ad hoc. Yes.

Yeah, right now when you're talking about the engineering part of the strategy, right, which is part of the product and the whole thing altogether at these meetings, what, um, what are you looking to get back from your peers on this stuff? Like you present a thing and they say, that sounds great, go build it, or, you know, different types of feedback. What are, what are you looking to get out of those conversations?

Yeah, so, so I go back to that common understanding of of the company strategy and the goals, right? And think about it, let's start with sales. Like, they, they have metrics like annual or quarter revenue targets, new name account acquisition, uh, expanding into existing customer base, you know. On the other hand, finance is all about top and bottom line. Customer service care about customer health, value at risk, renewals, uh, you know. Marketing will always want to have a a solid pipeline of things to amplify in the market, right? So, so if you, if you talk about a new feature, you must relate and translate to those metrics, right, that are important for your audience. Um, you know, again, I mentioned earlier, what's in it for me, right? So if you tell your head of sales that this new feature is kind of on 80% of your customers' purchase intention, you know, they will listen. Right, or that, you know, the user adoption rate will double, uh, you know, the customer service leader will kind of do the happy dancing. So, so, you know, your product is sticky, so customer satisfaction will follow, renewal is no more a question. So ultimately you need to get, um, the buy-in and support to deliver on each aspect of your strategy, uh, you know, from a feature to any kind of renovation, I call it, project that you might want to execute on your technology stack, right? So it, it, it's, it's one of those, um, bi-directional, uh, conversation. And I find often my peers in the executive leadership team often come with questions or we come with perspectives that are really, really good. And, and that's what I said earlier. I'm really lucky because those, those colleagues of mine are, are great contributors to the strategy.

Yes. Nice. I should mention for folks watching, there are some questions and if you have them as well, and there's a Q&A section and there's a chat section, so feel free to pop up if you have questions. We'll try to leave some time for that as we go. Yeah, so in that conversation, I'm wondering, is there sort of a fundamental shared understanding of how engineering works? Do people have a framing of like, is it going well? How do we know? How do we know if Jell-O's doing a good job or if the engineering teams are doing a good job or are we on track? What is the shared vocabulary that you find is helpful to talk about and what do you kind of not bother?

Yeah, so I mean, Pretty much everyone knows, uh, you know, everyone in the software industry, uh, will attest to this, is that projects do tend to slip, right? You tend to get delayed or for, for various reasons. Now the rule number one for me is transparency, right? So if I, if I have transparency, that breeds trust, and if you have trust, then any kind of problems, you always find the path forward, no matter, right? And so, so show your numbers, right? I think you— that's your language, um, when you, when you talk about progress, when you, when you update someone, uh, on the schedule, you know, talk about the numbers, show, demonstrate that you tried everything before, before, uh, you know, any any, any delays are shared with the, with the, with the leadership team. Um, you know, you have to show that evidence that you, you kind of working the right way, you have the right people, that you have a plan to recover. Those are aspects that everyone then can get behind, and then they can adjust their plans on their respective organizations to, uh, to, to align with the reality. Right? There's also an opportunity to discuss aspects related to the support you need from your, from your peers, right? Like oftentimes, you know, I would need an introduction to a customer that is willing to be an early adopter, for example, to a new capability. What best than your sales colleague to do that, or someone that is interested to validate some, some of your assumptions early on, so an alpha or a beta, you see. So there's never a a good idea to just put your head down and, you know, code until you're done, right? Early and often feedback is the key to build a successful product. Um, I, I mentioned measurements, right? Numbers. So, so maybe, maybe we can touch a little bit on that.

Yeah.

And, and probably could spend a full day talking about, uh, about that topic, right? The full session. But I'll give you my short version, right? We should and must measure everything we can, and there's many reasons why we want to do that. Because if you— and I might be controversial here, I know I have colleagues in the industry that, that are, are not too happy about measuring engineering organizations. They say it's difficult or impossible. I agree, it's not easy, but, but there's so much you can get out of even attempting to do that, right? You inform the budget planning exercise in investment in R&D. You inform an investment decision, you know, funding Project 1 versus Project 2. Obviously, you manage performance, underperformance, overachievers, and often informs the career development and growth opportunities and options for an individual. So for that reason, I'm sold, right? Now, Now there's, there's some things you have to be careful about, you know, and this is something that I read, um, out there. There's, there's kind of two types of measurements. You have the metrics, that kind of the good old metrics with goals, and you know, you should have several of those so that you reduce the risk of system gaming. Ideally, data is automatically collected You know, you don't weaponize those metrics and you make the distinction between measurable and exactness, right? Like, I think that's, that's where some people get into the weeds. It's like, oh no, if it's not accurate to the second decimal place, then it's not good. No. Yeah, I disagree. I think it has to be measurable and then you can look at trends and you can look at ways to make it better.

Yeah, I totally share that, like a baseline of what it is today. And if we change something on our teams or our tools or our process, did it get better? Did it get worse? There's something there, right?

And if it gets better, how do you replicate that with others? And if it gets worse, what do you learn from that so that others cannot fall into the same mistake, right? And so you have the metrics and then the other types of measurements are in my mind, are the type of measurement is, is what someone very aptly call it check engine lights, right?

Sure.

So you're looking more for symptoms, for trends versus goals and targets. You know, it's more about monitoring, understanding, correcting, and acting. And then you have all the different frameworks for measurements, DORA, SPACE, DevEx, and all that. But for me, there's 4 aspects that I care about. Financial, operational, quality, and innovation. Those are the 4 quadrants that I use, and I have metrics in each of those. And those are the numbers that I go back and talk about when, when it's about progress and, and decisions on, on project, on projects.

All right. You share all 4 of those with your kind of non-engineering partners, like at your quarterly meetings, things like that?

I mean, we are at, uh, at Jellyfish's conference, so, and not that I have to do any plugins But, but we do use Jellyfish for collecting those many of those metrics. And as I said, the beauty of it is that they're automatically collected as people use their systems every day, you know, GitHub or, or Jira or, or Confluence or any other systems. Data gets collected and now you can see some aspects. And of course we have some some other measurements that we collect directly ourselves, and then we combine that. I have a dashboard that anyone can see it inside engineering, outside. It's easy to understand, easy to, to, uh, discuss when you have that.

Yeah, somebody mentioned the chat, so financial, operational, quality, and what was the fourth one?

Oh, the last one was innovation. Which for a software company, it's, it's, it's a really, really important one. Yeah.

How do you measure innovation? What does that look like?

Ah, that's a, that's a good, good question. So in my mind, innovation, it's— you, you evaluate your insatiable appetite to innovate, right? That's, that's how I think about it. And so for us, uh, things like patents, you know, how many patents we filed, how many were awarded, uh, how many, um, ideas have been processed or are in the pipeline for, for the architecture board. So we have a, we have a body that kind of reviews architectural decisions and proposals. How many SKUs do you release? You know, we have a hackathon program like every year. We tools down for a week and then we kind of just that's what we do the whole week. We just build, build all kind of crazy ideas. So how many hackathon projects do you have? We do lots of what I call spikes or proof of concepts. Oftentimes you have a lot of technology uncertainties. So for us, I like to understand how many of those do we do, because if we don't have enough, it means we're not pushing the envelope, right? Like everything is safe, everything is clear. So we're probably not innovating at the state, at this, at the rate that we should. So those are some examples of, of metrics that I care about when it comes to innovation.

That's very cool. So you're thinking about not just so like the things you ship for sure and patent and put a SKU on, but also the idea generation up front of that. Like, are we generating enough ideas to get good ones through?

Exactly. I mean, on the, on the, you know, operation, operational part, I, I care all about velocity and flow and throughput and, you know, collaborations and commitments and, you know, all the developer experience, you know, with tools and frameworks and processes. And, you know, I also care about the organizational maturity. Like, I have a nice histogram by level and years of service, nutrition, and others because I want to understand how is the organization, um, kind of adjusting and moving as we hire people, as people kind of grow or depart. That's always a good one.

Yeah, no, that's very cool. I like the innovation idea, the generation of ideas up front, right? Like you have to do a lot of them in order to get the best stuff through as well and mixing that with operations. When you talk about this with your larger group there, and do you have sort of a shared sense of, you know, a certain amount of our energy should be going towards exploring new stuff, making stuff up, hacking, whatever, versus kind of known safe bets? How are you, how are you strategizing through that and talking about it?

Yeah, so this will depend from company to company, I'm sure. But also for us, for Kinaxis, we go through different cycles. So there are times where the investment on what I called earlier maintenance projects is probably more significant. Then, but there's always, in my mind, there's always a portion of your capacity has to be dedicated to that kind of innovation, forward-looking, you know, always be on top of what are the technology trends, what's happening out there, how can you, how can you adopt that technology to solve problems. We, we definitely, uh, we are not building or, or innovating for the sake of innovation. We always start with the use We always look at how can I solve it in a faster, better, cheaper, simpler way, right? And, and that's, you know, so if you look at our investment over the years, no matter where in that cycle we are, uh, the, the innovation portion is always there. So we never, we never have a case where, uh, we're like, no, we're not looking at that. Nice.

That's very cool. When you've got your sort of plan and you've met and you've got your yearly plan or your quarterly plan and you're checking in on that stuff in progress, obviously you can see like projects are done or they're not done or they're on time or they're not on time. How are you, how often are you communicating those changes? Like how do you talk about, there's lots of reasons, technical, personal, planning, unknown unknowns, right? Scope creep, whatever. How are you communicating out like process on, higher-level initiatives that like your senior leaders are going to be the most invested in?

Yeah, like I, you know, sometimes the language you use, the prep work you're doing could give you, you know, an outcome that you desire, or maybe you weren't expecting. So have I ever presented something that was not well received? Of course I did. I've done that many times. What was the mistake? I think mostly didn't lead with the what's in it for me, right? With that kind of answer to that question. So I assume people around the table will be super excited about that new library or that module that we want to build because the technology is superior to the current one. But then so what? Like, so what, right? The hardest part, you know, I find, is to convince your peers about any technical debt that needs to be done, right? That to me is the, uh, the, the one where, um, you know, they first, they don't really understand the concept. Second, you have not told them anything that translates into value for their organization, right? So, so my approach is often to to package that technical debt with the feature that they understand its benefits, right?

Yeah.

And then they care about that. And, and, you know, at times you talk about it as maybe a tax of doing business because it's a, it's an extra effort or an extra time that you add to the, to the, to the delivery date. But But something that would be like that would be much easier to accept in most cases when it comes to technical debt.

Yeah, yeah. Maybe one last one. Not seeing any questions from folks. Feel free to ask questions in here, guys. We got a couple minutes left if anyone has any. If you were bringing in a new, you know, a new executive joins your team tomorrow and maybe they're from a less technical company or a different type of work in the background? What's the, what's the thing you feel like you want to work with them the most? Or what's the thing you really kind of hope they understand? Maybe you don't have the history with them of having done this before. How do you, how do you sort of onboard them into how you're thinking about it?

Yeah, yeah, yeah. So, so I, we have one thing at Kinaxis, it's called a buddy system. So every new employee actually doesn't matter if it's an executive or an individual contributor. They are assigned a buddy, right? And so I've been there, I've been the buddy for many, many of our executives, and I find everyone wants to learn. In a software company, obviously the product and engineering is, is the driving force in many ways, right? Obviously have to have sales, but, but if you don't have a product, it's going to be hard to sell. Something. So I do spend time going through, you know, describing, describing the, the organization, the DNA of our engineering organization. I talk about the product because, you know, I, I took— I was part of building it, right, early on. So I, you know, I'm never tired of talking about product. And, and as I said earlier, though, I often get those new leaders or those new people that are joining the company, uh, they always have that kind of ignorance is bliss advantage, right? And they will always come up with a question that, that's like, oh, that's an interesting way of putting it.

And, and I love those interactions, like fresh eyes and new questions, because you're just used to—

wonderful.

Yeah, yeah, yeah.

I think we have a question Yeah, we've got one from Jesse.

Uh, when you're talking about investment in projects, are you thinking in terms of percentage of engineering as a whole, like number of engineers, financial investment? How do you think about or communicate about how you're invested in projects?

Yeah, it's a very, very good question. So we, we do, uh, execute— our execution model is kind of using squads, so a bit of a cross-functional, and it, it, um, it, it pretty much uses the, uh, kind of numbers of, of individuals that will be contributing to that project. And then there is the financial aspect, as I said earlier, like we have some projections that we would like to see in terms of how many customers do we expect to, uh, to use that, how— what's the, what's the revenue associated with. So we use those different, different perspectives to make to make investment decisions ultimately. And, uh, the number, the number of, of people, the capacity we allocate to that project, uh, would, would fluctuate. We know we'll start smaller, we'll grow, we'll probably go through some ups and downs depending on the phase we are with that project and, and, you know, the market reaction. Oftentimes we had where, you know, the V2 of a feature, like, we double down because it was that, it was that successful. So we want to, to catch the momentum and, and basically deliver value for our customers.

So, right, so you might actually shift more energy into that to, to get more value from that, from that experiment or whatever.

Awesome.

Well, thanks so much. We're right on time here. Thanks everyone for, uh, for coming and hanging out with us. It's been super fun to talk to you and prepping for this and having this conversation. Thank you for taking the time with us today.

Same here. Thanks, Luke. And, uh, Everyone, have a good day.

All right, thanks, folks.

Bye.