Using Portfolio Management to Guide Software and Product Development: Alan Boucher with IDEXX
Alan Boucher is the Director of IT for Software Product and Development and Architecture at IDEXX. IDEXX serves its veterinary customers on two business platforms; diagnostics business and reference lab business. As we unravel how they serve their clients, we see just how complex their platform is, serving the needs of veterinarians, farmers, and other companion animals facilities.
Running a department that deals with such technologies requires lots of organization. Listen to this episode to hear Alan share how his methods of portfolio management make management in his industry possible.
Topics we discuss:
1. Portfolio Management
2. Budgets and Timelines
4. Feedback Loop
7. Evolving Career
8. Veterinary Practices
9. Companion Animals
Carlos: Today we have Alan Boucher on the show. I am very excited about this conversation because Alan has a great breadth of experience when it comes to doing portfolio management. He is actually the director of IT of Software Product and Development and Architecture at IDEXX. You can learn more about IDEXX at idexx.com and the wonderful work that Alan is doing over there.
So this conversation is going to be around portfolio management. How it differs from project management and different techniques and methods that as engineers we should care about especially if you’re an engineering manager or a national senior developer or a non-senior developer. You want to understand how work is prioritized by the organization that you worked at and why it makes a difference.
Anyways, this is going to be a very interesting conversation. We’re going to talk about what portfolio management is, how it impacts future budgets and timelines, ROIs, the feedback loop, different timelines, promises made as expectations and everlasting constant change. So with that said, let’s get started.
Alan, my friend, thank you so much for joining us today. It’s been a couple of weeks coming so I’m very excited to finally have you on the show.
Alan: Hey Carlos. It’s really great to be here. Thank you for having me.
Carlos: I found your profile and the work that you’re doing fascinated me. The breadth of work that you’re involved with in terms of contextually understanding the width of what you guys do as an organization. We’re going to talk about a very interesting topic, which is about this portfolio management, and portfolio management is something that encompasses not just one area of work but in your case, it’s many throughout different areas of the company. Anyways, long story short you’re going through this currently and I think it’s a timely conversation for listeners that are planning their next year. They might get some insight from the lessons you have learned. Anyways, thank you so much for coming on the show.
Alan: Yeah, I hope everybody can take away one or two things from our discussion today that would be great.
Carlos: Yeah, and they can take away some sort of method of how you’re doing things, and that is the evolution of what this podcast has become. In the past, it used to be very biographical and now it’s evolved into this conversation about a method. What I’m super interested about is talking about this as something actionable. Every person can take and learn from your experience because as I said others are going through the same thing. Just hearing it from somebody else is looking at your perspective of how I am different from them, this is what’s valuable.
Before we get started on the topic though, I want to make sure that everybody gets to know you and how impressive the work that you’re doing is. I am alluding to a lot of this width of expertise that you have, this vast amount of context that you have to deal with at an organizational level, so let’s start there. Tell me about yourself and tell me a bit about your career. Where did you come from before you started at IDEXX?
Alan: Sure, so I spent, the majority of my career at Intel. I started out actually as a technologist in the field, working with customers, solving problems, creating solutions, working with computer OEMs and lots and lots of different ISVs and operating system vendors who create value for Intel’s extended customer base. I move from there into their networking division and ultimately into their enterprise solutions division. After, I migrated my way over towards Health Care and Life Sciences. In the early 2000’s that was a majority of my focus. Then Intel actually created their own Health Care and Life Sciences division and I took over both product architecture and product engineering for all of their software products.
I did that up until we decided to send that group out with GE, with a private investment and actually create a startup called Care Innovations. I was there for 3 or 4 years. Left Care Innovations, moved back to the East Coast and took a job at IDEXX about 3½ years ago. I basically started out in their customer-facing software organization as a director running 7 or 8 different products of development areas. And then I had an opportunity to move over to Information Technology for a new core innovative, core platform for running our reference lab or diagnostic labs globally; involves lots and lots of integrations across internal systems and external systems and it’s running on commercial cloud. Frankly, a lot of our stuff runs in commercial cloud and so that was a great opportunity for me to take that and build a team, build an organization which is what I’ve done.
Carlos: Tell me a bit about the company. Tell me a bit about IDEXX. I know that there are tons of things that you guys do around veterinary oriented practice management – software for veterinarians, if I am not mistaken to water testing. Can you give us a bit of understanding about everything that you guys do in terms of say verticals? Then how does that horizontally, cohesively from a horizontal perspective, look? You guys, all of it is kind of in the same family if you would?
Alan: Sure. If you think about companion animals as an industry, and we do every day, people have pets, farmers and ranchers have poultry, dairy, and livestock. We have lots and lots of opportunities to test and maintain water supplies around the world. Everything having to do with really the space around health and wellness of pets and people and the industry as a whole. It is split across a number of different vertical businesses here at IDEXX. The more obvious one, our diagnostics business, which is shaped in a number of ways. We have our reference lab business, which is greater than 70 labs around the world and basically for geographies that create value in diagnostic testing for our customers. Our customers are generally in that space, so either they are larger buying customers who may be ranches and farmers as well as literally tens of thousands of veterinary practices and hospitals and other facilities that serve as companion animals.
This testing is what you might expect, and genetic testing. It’s cytology and histology, pathology, blood chemistry. There are a lot of things happening between the point where you take your pet in for a wellness check or sickness check, and those specimens are captured. And they are ran internally in the veterinary office with IDEXX instrumentation, that we sell through one of our businesses and provide more immediate value. So this might be a veterinarian hospital, or it may have their diagnostics with both processed in-house. What we call in-house, this includes some instruments that we sell to them but also some amounts of reference lab. And so we provide not only all of the leadership in research and development across chemistry and hematology and other sciences for those tests and essays, but on the other side of it we manage the labs and the infrastructure; The software infrastructure that runs the labs and all the master systems, as you might expect, our master data and SAP data, how we actually maintain customer and master data and test directory master data, how we actually do billing, and how we store results and how deliver those results through any number of systems back to our customers who are waiting anxiously to deliver the results to their pet owners. Frankly, if we’re trying to do large herd analysis, say 1,000 head of cattle, it’s a similar process where you’re capturing specimens and actually delivering value back to that rancher and veterinarians that support them.
I think across the business portfolio we’re very role aligned, we’re very focused on our business. Every aspect of our business involves software. A lot of that software is fairly complex. A lot of that software runs in the cloud. It also runs on-premises, depending on where it is. And it’s our job to make sure we build a really high quality, minimizing technical debt and other detriments to the software asset and delivering it a really high value in a highly reliable fashion.
Carlos: And this is, I think, where portfolio management as a topic and sort of a guide to portfolio management. Or Alan’s guide, right? How you are doing it? And tell me a little bit about what’s going on now. Why is this is a timely conversation? Why is this time of the year usually the time that you begin doing these sort of things for the next year?
Alan: Sure, first off, let’s start with the difference between an individual product, a project, and a portfolio. I think organizations mature through that right? I worked in startups. I’ve also worked inside of Intel and even here at IDEXX where we got kind of startup feel to a new product line. You know, small teams, lots of versatility, moving very quickly, making decisions and pivoting. All of that is very focused on building just an MVP or commercially viable product you can get into the marketplace versus a project that says, “Hey, this probably has phases, and we’re going move through Phase 1, maybe a Phase 2, we’ll ship then there is a Phase 3, 4, 5 downstream as we look to improve, and make additional investment perhaps, or enhance and/or expand the product.” Versus a portfolio that says, “Hey we have a group of products and a group of needs and capabilities across a business unit. Now how do we build them and/or what the priorities are?” How they interoperate with each other and what dependencies do they have elsewhere in the organization or outside the organization? So when you start to look at and make decisions that are portfolio driven, well you really have to think about how your resources are being best used? What technology am I choosing? Where am I going to land this? How will I deploy it? How will I build and deploy it, right? Lots of companies including ourselves can’t tolerate massive downtime between upgrades. So you know, how do you build from… How do you build as a new deployment and how do you have zero downtime? So it takes a lot of planning to do that.
So when you start to think about keeping the business running and layering in capabilities, solving challenges, issues, needs but also prioritizing those based on your investments, the intended return on investment or optimization in the business or other. You start to shape the way you think about building innovation and assets differently. That’s your portfolio management. Then there is this concept of in-flight, which means what development do we have in-flight? And then you have to look downstream at your portfolio and say, “What are the things we need to be building, in what priority?” And perhaps a priority change from last year to this year, right? So the things you thought you’re going to be building this year or perhaps next year have some risk to them because other things take.
Portfolio isn’t a thing that you do once a year. You’re constantly shaping it, right? We’re looking at the portfolio every quarter or saying are things still relevant? Do we have the right priorities? Do we have the right focus as a development organization but also as a product organization? So that requires us to work really really closely together.
Carlos: In order to do that planning you have to have a lot of that deep understanding of as you said, how you’re going to deploy. You need to have a lot of that context, that awareness of the entire periphery of all the projects and how they are going to impact the organization. Just to shape this a little bit, what are the typical areas at work? What are the usual bodies of work? Just to give you an example sometimes there are projects that are like architecture projects or a specific system that is going to be built like a web application. Tell me what are the typical bodies of work that encompass the work that you’re doing?
Alan: Well, so first and foremost where we’re on market. That’s another way to say it might keep the lights on, right? Were we on market? We really need to make sure that we’ve got the right level of resources in the portfolio groups focused on doing a good job for our customers and frankly our internal team who might be leveraging the software that we deliver. So it’s really really important that we have a majority of whatever we’re doing on a daily or weekend basis. We focus on the market. Then there’s new products and innovations.
Carlos: In a second, I want to talk about that because we have to figure out like how are you measuring in terms of performance, when usually you’re rewarded by those new things, right? But as you said the most important thing is to keep the lights on.
Alan: Yeah, the most important thing is to be able to run and maintain and sustain the software that you built, right? I mean in many cases lots of companies today, more than we would ever imagine, make long-term investments in a multi-year investment. So at some point, they may be capitalizing their investment for over three to five years. And they incrementally improve that investment and perhaps the defects come along or enhancement request from the field or they build something early on that they would like to change now and that’s the technical debt in one form or another. We try to discourage a bunch of that but at the end of the day, it happens in software platforms. You make decisions to quickly move to the market recognizing that, “Hey, I kept the can down the road on that thing. We’re going to have to deal with it later on.”, so that’s technical debt. And so all of that is a part of keeping the lights on and making sure that the software performs the way you intended on market.
Carlos: How do you guys handle things, like a big example. Let’s say you guys were using and then you’re thinking of implementing a modern sort of front-end engineering platform. You’re building your own design system. How is that going to be implemented in the sense of seeing how creating that will impact rewriting a lot of code in the future. How do you keep a balance between that?
Alan: Yes, so I mean you have to actually look at that and say, there’s a difference in technical debt and say technical investment. So let me clarify that a little bit because you may be on an older technology where you need to have some portion of the team in place to work on the technology, right? But at some point you’re going to make a decision that says the pain of maintaining that older technology is greater than us pivoting into a rewrite; perhaps a refactoring, perhaps frankly an entire. Maybe you want to move something that’s running, let’s say a swing client on-premise to a more spring global pub sub, say an Angular front-end with some data server in a commercial cloud environment. Or you want to do something that’s React and Node-based with maybe Mongo as the database. All of these types of things, you know, you got to pivot into that right? That’s a new investment, that’s a technical investment that could take the place of moving from on-premise infrastructure to cloud. You’ve got the whole security, wrapper, and layer that have to be implemented there. You got to do penetration testing. You got to rewrite the software entirely and the front-end and the back end, and you move to a data service. All of that is a big technical investment, right?
But in the meantime, you have to maintain what’s on market so you can make that migration and make that switch. And so you’ve got to be able to balance that and say, “Okay, at what point do I turn down the dial on developing what’s on market and just sustain it so that I can redirect the team or acquire new resources to actually do the new work.”
Carlos: So if we think of the way that you prioritize this. I am sure ROI is a big factor and as you were mentioning at the beginning is there in a ROI analysis. Tell me a little bit about that. What type of ROI exists and how do you come to those?
Alan: Well, so at the end of the day I mean it depends who you are talking to. If you are talking to a financial team, it’s really a financial ROI. It’s like what and when is my return on investment, what is my net present value, when does my contribution margin target actually. When does it is achieved, when it is reached? You know there is a bunch of different things to take the shape around the financial investment. You know, what is our depreciation target? At what point are we fully depreciated if we did nothing more at some point or we had a minimal investment once we build the platform, and we all know platforms aren’t perfect ever really, you know, software is never done.
But at some point, there is a measurable point in the product lifecycle where you actually have an ROI target and have you achieved it or did not achieve. But there is a whole bunch of others, right? So you might have, if I am building a SaaS platform that’s facing a customer base. What I may be doing is I’m may be looking about non-functionals, things like scalability, reliability, sustainability, uptime. Those kinds of things, right, which are non-functionals but they are important to customers. The other thing might be Net Promoter Score. I might be looking at a customer and saying, “Look, I am going to deliver more features. I am going to deliver better quality. I am going to deliver on a faster platform, better software.” I might want to wrap that in a measurement that is a Net Promoter Score or Net Customer Value Score and be targeting improvements in that. Ultimately, I might be building software that improves the operational efficiency in the company itself, right. So could be a commercial platform that you acquire that enables your sales teams and your marketing teams, your service teams to be able to service our customers faster and better with more visibility into both the data around the customer, right data around the market and what are the things they might need to be doing versus operationally in a lab or factory side of the business; where I want to make a number of improvements in the software that actually reduce the need for some level of redundancy on the line because the software actually does more than the old software where I had to have more employees actually doing the work, right?
So it’s really an optimization discussion on the line on the manufacturing line and the production line that the software is trying to improve, right, so all of these are different forms of return on investment. It really depends on the portfolio in the business and what they are trying to do. If they are trying to improve their contribution margin that’s a target and the portfolio takes a certain shape. If you’re trying to improve your efficiency and processing or in the lab or in a factory that’s a different shape.
Carlos: I have an interesting topic to kind of add this to the budget conversation in turn with ROI in the sense of how do we set expectations of ROI in relation to, also how do you make budget decisions ahead of time before having requirements for a project? You’re still making a promise on ROI or not a promise but you’re trying to set an expectation on an ROI but at the same time, you’re making an uneducated guess at some point about the budget. How do you keep those two things in?
Alan: Yeah, I mean it is complex, right, Carlos. It is really is complex because you have to look at a number of factors. How large is a body of work, right? How many teams you are going to require to do that body of work? Is this a single team? My SCRUM team tends to be 3 or 4 developers, a SCRUM master, and we do a lot of CICD here, Continuous Integration Continuous Delivery and we do a lot of test automation in many of the teams both customer facing and now in IT. And so we are migrating more towards different forms of Agile but the teams are fairly tight and we can measure them pretty finely. So we understand kind of in the case of pure SCRUM, we are looking at capacity and velocity, burn up burn down. In the case of Kanban, we are looking at pulls and cycle time and continuous flow and a number of other things to measure throughput. And velocity and throughput by the way for your audience in my experience, you know, velocity is a classic example where if a business partner or someone on the business side actually gets a hold of velocity they start measuring their investment and their project timelines or portfolio timelines across multi-years based on that velocity and that’s a dangerous thing because velocity is an internal development team measurement. It’s not an external measurement, and so velocity is important because it’s a measurement of the team and how the performing right now. And right now is a window of probably back of a couple of sprints or if we just continuous delivery really don’t have sprints here you’re operating a slightly different model. But basically, it’s what happens in the near term both previously and what do we expect in the near term in the future. And so I just want to caution people around that. Velocity is something that should be held tightly by the development organization.
Ultimately, when you try to figure out portfolio on a program that’s especially multi-year and we have a lot of these, where they are in phases over multi-year it’s just a continuous stream of development. A lot of it is experience based. What are we building? Do we have predicates in the environment that are similar to those, right? And if we do, for instance, do we have any way to measure the difficulty of feature implementations previously. What is the overall value of those features in the equation and how do we measure that value? What throughput from these teams on that previous program? What was the throughput and what’s that throughput? Can we actually use that as a marker or a benchmark or a baseline to go forward on this new program? So part of it is actually, experience based. If we’ve done this before, great. If not then what we have to do is we have to rely on looking at and breaking down, what we happen to use a number of different processes when we break down designs. We don’t do designs upfront. What we will do is block out a design. We will use storyboards and block the design as best as we can and then we will assumptions on the body at work in each one of those blocks. And that’s where we start, right? Recognizing that I don’t have a crystal ball and nobody has a crystal ball. What we can do is we can do enough of the backlog upfront even if it’s Kanban so that we understand what it is we’re going to build over the next 3-4 months. And we might have a delivery phase that’s a year out. And so what we have to is we have to take our best ‘geusstimate’ at hitting that year out day with the features and the needs of the business one they build the portfolio. But if you are asking me to project out three years I can do that but it’s really a discussion of precision without accuracy and that’s a dangerous place to be.
Carlos: The longer that has to be, the more you’re relying really on orders of magnitude versus specific like dollar amount because dollar amount usually equals hours specifically or specific days. Here you are talking more about ranges. Again, orders of magnitude is the way I think about this, at this level at least.
Alan: Absolutely. We just went through that exercise. You know, I have a product that we are building that’s really really complex. It’s based on transaction and genetics core but it integrates with instrumentation that runs our diagnostic labs. But on the front side of it and the back side of it are a number of commercial systems, internal systems that are built that master the data in and out of that system and some of that we’ve done before, right? And some of those systems already exist so it’s a matter of, what is the level of effort to integrate this new platform, this new portfolio platform through that thing that exists. There are other cases where we’re building new platforms to associate with this core transaction platform and so we’ve got to manage those plus also the integration. And so something’s you feel very, very sure about another things are much grayer, right? What you have to do is you have to maintain a risk matrix along with your program, your portfolio, says, “Hey, here are the identifiable risk.” And if you’re using something like an where you’re measuring kind of you know 0 to 5 on the risk, 5 being the highest, what you say is, “Hey, I’m going to measure in a sense of form we’re going to work this risk down as we go over time and we believe that we get it down to 1 or 0.” What you’re trying to do is work through your risk, identify them early, manage through mitigation, you know work your way through your development cycle and deliver. And so that for me is really tough. Nobody is ever going to stand on this podcast and say “I have the answer to a program.”
Carlos: Yeah, it’s a lot of assumption that are set forth I think. Of course, you try to use different techniques so, as we call them methods to try to be within a certain error percentage or within a certain acceptable room but it’s quite impossible to do as an organization, for example, to do fix estimates or fix estimate error. There’s always a sense of we work in Agile way and even our business runs in an Agile way when it comes onto like invoicing for example.
Alan: Absolutely, you know I get this all time from executives, business side executives, it’s like well I have 8 or 9 platforms in a portfolio and every team seems to have a different, one point is a different value for every team. And what you have to look at is what are the technologies the team is using? What is the shape and experience of the team that’s doing the work? How long has the platform been out there so that the team has a really good idea of, hey all these other things we build were 3 or were on 8 or were 13 right, so, therefore, we feel really confident that this too is a 13. Once again it gets back down to experience base and gets down to the software that came before and you know how do you actually build confidence into your estimates and build, more importantly building confidence in your estimate over time.
Carlos: Yeah, and as you mention though there’s still be to be set about keeping the business in the loop. That’s I think the biggest thing we have to do. Because almost we stay close to projects things can go bad quickly and I know that you depend on a group of project managers. But how do you personally keep your finger on the pulse of all these programs that are going on the same time without overwhelming yourself and not doing everything else you have to do? What methods do you personally use to do it?
Alan: Well like you, I’m not a bashful guy and I talk a lot and it works well for me here at IDEXX because one of the values to IDEXX is bringing people along. And bringing people along means really being truthful and honest about where you are in the program, what you need, what’s happening, how’s it going? You know are we meeting our commitments? Are we not going to meet our commitments, right? It’s about truth and transparency. We have lots of opportunity for that. I spend probably a third of my week talking to my business partners, my product partners, my engineering leads to make sure that we understand whenever we’re doing well and celebrate that and you know to make sure the business, and where we have problems equally understand those and make sure the business unit is aware of it.
I have a philosophy and you and I talked about it earlier which was. I actually believe my development teams. I have a set of desks in every single development area that is where my product team is set. To me when I’m running a natural team or some derivative of that or Kanban, it doesn’t matter. If I have a BA (Business Analyst) and a product owner or multiple BA’s and a product owner from the business team they’re going to sit with my engineering team. I want them in every design discussion. I want them in every stand up. I want them to be a part of what it is we’re doing. We win and we lose together.
Carlos: Yeah, they need to breathe the same air, have the same coffee.
Alan: Yeah, absolutely. And so that’s where really important is, so when we actually do go to, at IDEXX we have a lot of stir codes. At Intel, it used to be something called MRCs but we have stirring committees. And stirring committees are really where the top level leadership team gets an update right and those time to happen every 3 or 4 weeks. And you know we’ll sit down there’s a format we used and we kind of go through what our commitments are, where are we now, what’s new, let’s show them a demo, let’s talk about financials if you need to talk about financials. And that’s a formal way to bring people along but it’s also a place to have those difficult discussions if we need to have a difficult discussion.
Carlos: In terms of keeping the business aware or up to date. I would imagine that the things that the business cares is how are you monitoring that ROI and how it’s progressing along let’s say to year and to your projection how close or how far are they, and also how often do they need to know? What sort of checking do you do? How does that work?
Alan: Yes, so it’s your question so we have a strategic model here. We were looking 5 years outright so every year we look 5 years out. I know there’s a lot of folks who will listen to this podcast and say well you know there’s a number of company’s out there that don’t bother to strategic plans anymore and that if you plan of your from out to waste. Not if you’re a larger company, right? Larger companies have shareholder responsibility, board of responsibility, employer responsibility, employee’s family’s right? One of the things we’re looking at is what is the shape of our business look like and what are the systems we need to be building in our portfolio 3 to 5 years from now. We need to be directionally diligent but not necessarily directionally correct, you know. I mean you have to have an opinion. I’ve always subscribed to, your software and your protocol to have an opinion. I believe your strategy had some right. So one of the things we’re always looking at is how does a portfolio take shape and therefore what does the investment look like in around that portfolio. That investment actually drives a number of decisions about what are the things we should be building, what platforms that are under development today could be carried forward versus hey, we’re going to finish it here and then we will move to a different development model on that platform and bring this other platform target up.
And so you have to be constantly having those decisions because the business changes too quickly. If we look back 15 years ago and I recognize that’s hard for some of your audience. You might have been doing this 15 years ago, but you look back 15 years ago it was, you know perfectly rational you could stay on target with your business for a year and a half, two years sometimes with the things you were building you didn’t have to necessarily adjust. Well, that’s much different today. I mean we got lots of competitors, lots of customer needs, lots of cross-industry needs that are coming at us right? New vendors, new capabilities, new technologies you need to evaluate those and figure out how do they enhance the decisions you’re making? How do they perhaps change the decision you’re making and how do they influence you for a long term.
Carlos: That’s the constant thing about today’s sort of businesses. There’s constant change, right? And that’s why we have this sort of techniques that we do in order to be able to mitigate change but not necessarily have to go back to the drawing board every week. Otherwise, we’ll go nuts.
Alan: Absolutely, what you have to do is make your decisions going forward, just like you fail forward. If you have a bad release and you find a defect what you do is you fix it quickly, you test it and get it out the door right. The whole concept is progress right. You should be in a progress forward mode with the way you’re thinking about engineering, the way you’re thinking about innovation, the way you’re trimming on market products, your new product development, your technical debt team and really the decisions you’re making at a business funding level to support those.
Carlos: I would assume that you’ve got some let’s say good luck in a sense that not all business side of the company understand technology cause maybe you guys do. And so in your case again having this good relationship it’s, I don’t want to say easy, but it’s a manageable situation when change is coming to plan all of a sudden here comes Alan and he needs to have expanded budget. How does that happen and how do you mitigate that currently? How does that work within IDEXX and how would it work if the business wasn’t so understanding and if it’s seen as a negative thing on your end right? A lot of people would be afraid of doing that.
Alan: Sure, so it’s a good question. So first off, that’s not always the case right. I mean what happens is you know we’re working within a budget and then your budget is like everybody else’s. And if your budget is been targeted against your portfolio and you’ve got agreement with all the technical leadership teams and also the business teams and the product teams. You’re marching to a commitment and those commitments have, hard commitments built inside the company and outside the company on a set of expectations. Along with that there may be things that arise for up to you and they do where there are new needs to come up that we have to address in one form or another. Could be a compliance thing, could be a GDPR thing from Europe. Recently I know a number of folks on your podcast will appreciate because they just gone through it as well. You know that’s not something you necessarily plan for right? Maybe you did to some extent but then you realize hey the final cut of the GDPR dates and the expectations on companies to comply, of course, that’s to redirect our investment and/or to our outdoor investment no change things. And I’m not saying it did here or not but it’s those kinds of things. It could be that. It could be things you need to do in your network because your volume has just increased you know the number of order and throughputs on the system has increased the level where you need to change infrastructure. There are all kinds of it. And you have a product that hit the market and it’s widely successful and your volume increase, you need to actually deliver a whole bunch of new features and deliver in a new way and perhaps integrate with other third parties. And so how do we make that investments base on the current envelop that we have and the current investments targets we’ve committed to right? So you have to have those hard decisions, try to fit into your investments strategy or we have to make some changes. Or do you write a business case for it so the business teams and our product partners and engineering puts together a cost estimate for that investment and what we can build and what kind of timeframe then that goes before the business to make the decision right? And frankly, both of those have right? I don’t care what company that you’re at. You know that’s the shape of product development.
Carlos: Yes. We near here the end of our conversation. It’s intriguing the thought process that our engineering leaders suggest yourself has to go through not only as in terms of actions that you have to perform but all also how you have to influence others, how you have to work with others. I see influence in a good way. But you have to definitely have that leadership role in order to impact change in the organization. I’m thankful for things that open up and sharing some of these thoughts with us.
I have 3 last questions for you. Before we get into those 3 just to do a bit of a sum up of what we discuss so we talked about what portfolio management is, why it’s important and how you guys do it. We talked about how it impacts future budgets and timelines and how you guys do it. We know that we cannot promise. We don’t have a crystal ball. We can’t promise things to the minute but we got enough experience in order to tell about orders of magnitude of time base in the team and our own past lessons. How ROI plays a role? How we keep in touch with the feedback loops from the teams that are working so that we can keep the business, basically knowing what’s going on because they want to know how they’re investments are doing. Timelines, promises made, managing expectations and most important thing, the thing that the actual constant in life is change. We’re able to hit those a lot more of a data on those topics today. So here’s the last 3 questions I have for you so we’re talking about portfolio management for next year. We’re recording this at the end of 2018, end of Q3 I think or beginning of SQ4. What can you tell us about 2019 for you at IDEXX that is possible for you to talk about at a high level? Any fun over all projects or initiatives?
Alan: Yeah. So I think I can’t get into specific projects but I will tell you that IDEXX is a global company and like any other global companies as we’ve moved into new markets and looking a great value and for now facilities and we just expand our footprint, as you might imagine there’s a lot of demands on information technology and the other engineering organizations to make all that possible right. And so there’s always seems to be more work to do than time, resources or investments to do alright. So that’s a good problem to have by the way we weary set up for self. We’re blessed that it’s a good problem to have. So we are constantly looking at our portfolio and in fact, we do it on a monthly basis internally here in IT to make sure we’ve got the right shape to things, right? And that we’re watching the things that are important. We are making sure we’re moving resources around to optimize our commitments to the rest of IDEXX. And I think that is just absolutely critical to our success long term and so next year is no different and frankly the years after that wouldn’t be different either. So I think once again we feel bless for healthy, everybody’s working hard we are building a strong business for our employees and our shareholders.
Carlos: With that, of course, I’m sure there’s a ton of growth that is required in order to keep that pace going. How can people find you, find IDEXX and what sort of profile say engineers are you guys looking for?
Alan: Say a little more about that, Carlos.
Carlos: So just trying to get an idea of, if people that are listening to show might be interested in learning more about IDEXX and the work that you’re doing what sort of background are you guys looking for in the future for hiring? Question is, are you hiring? And if you are how can people keep in touch? Who are the right types of people?
Carlos: Do you have any books or resources that you might want to share with us or that might be relative to your experience as an engineering leader or even to conversation we had today.
Alan: Lately I’ve been working on a different process and business books related to portfolio. But I think one of the ones that I think is quite interesting I’m just going to bring up the author real quick because I think her book, it’s called Accelerate and I want to make sure I get her name. I think it is Joanna Roften. She wrote a book called Accelerate. That book is really interesting because it talks about the ways software engineering is really being shaped differently in an Agile model. So it’s really about not just the structure of Agile and the ceremonies but really how you looked at CICD delivery, how you looked at pipelines. How do you bring in not just test driven development, behavior-driven development? And by the way, there are excellent books on behavior-driven development if your audience hadn’t read that. I think what we’re really trying to do as an industry now is change the way that we structure teams, the way we value equality inside of the development processes and not just separate entity so you know through over the wall and have QA do the automation, do verification and validation of the software and he design do performance testing outside of the team. All of that has now been brought in as part of the development process right? It’s embedded with the engineering organization and it really talks about that. The other thing I would highly recommend Eric Evans has a book called Domain Driven Design which is a wonderful book that focuses on really how do you build the IO domains in your software by creating down its context and how the context relationships between important layers in your software. So for instance if you have a software that does orders and then that software moves from orders into say some validation sequence or processing sequence and ends up with being sent back to the customer as a result, those are inner related but they are completely separate bound in context is in how do you actually design a chip or software to allow you to build things more efficiently and faster because you’re not overlapping integration in really requirements on those domains right. So it’s a really interesting model like I highly recommend reading that book. You know I think we’re in a really interesting time right, very much so computer science base, data science base. Lots of data analytics going on, lots of companies trying to figure out at how they shape their data to not only influence their business decisions but also drive their sales team in a more efficient manner, so a lot of that going on. It’s really exciting time to be in product development.
Carlos: Yeah and in terms of books, but I read maybe a book or sometimes two a week. It’s not an effort of reading books and usually their business related books of non-fiction usually. But yeah, we live in a nation you can find information about anything and just be amongst people that are, that have different thoughts than you and be able to learn from other people even if you’ve never met the person. We’ll have those books on the show notes. Thank you for sharing those.
Alan, you know this is the end of our show but I want to thank you so much for coming on the show, for accepting my invitation. I know it came out, out of left field out of nowhere. And you’re kind enough to share all these insights about portfolio management and some of your own experience, some of the stuff that you’re working on through right now for 2019. So anyways I want to thank you for the wonderful conversation today and thank you so much for being on the show.
Alan: Thank you for having me, Carlos. For those folks by the way just as an adder, on the Accelerate book, I missed the author, it’s Nicole Forsgren and Jez Humble and Gene Kim. I’m sorry. I just want to make sure that people looking for that book. That is, in fact, the book I find very interesting.
Carlos: Perfect! We’ll have that on the show notes.
Carlos: Alright, Alan, thank you so much and I look forward to hopefully having you on the show in the future again. This is something forward listening. We’re planning on some future panels with a previously interviewed guest. So it might be interesting to have a conversation with you in the future maybe would bring another guest and talk about a similar topic or different topics just kind of have a different point of views with the same topic
Alan: Great! Great, thank you!
Carlos: Well Alan, once again thank you so much for being on the show.