The Scope of Global Engineering
May 15, 2020
Innovation That Matters® – it’s what Mercury Systems is all about. With a commitment to its customers’ missions, a goal to always develop new technologies, and a drive to be innovative, the engineering group at Mercury has experienced rapid growth in recent years. Listen to Jim Gallagher, Global VP of Engineering, as he discusses how his team is working to build a single, cohesive team across business units with a shared vision of the future for Mercury and its customers.
Read the transcript
Hello and welcome to Mercury Now podcast series, brought to you by Mercury Systems. I am your host, Ralph Guevarez. Today's topic: the scope of global engineering as Mercury stands firmly behind its innovation that matters purpose and continues to deliver trusted, secure, mission-critical solutions to the defense industry. Joining me is Jim Gallagher, Global Vice President of Engineering for Mercury Systems. Jim, good day and welcome.
Hi Ralph. Thanks for having me today.
So Jim, before we dive into what's happening with global engineering, could you please give our listeners a brief background on your current role at Mercury?
Sure. I'm the Global Vice President of Engineering for Mercury, and I've been in this role for almost two years. I joined Mercury in 2016 as part of the Microsemi acquisition, and for the first two years of that, I led the secure processing solutions engineering teams, which was really quite similar to my role in Microsemi for my six years there. Prior to that, spent 22 years in the automotive industry in a variety of software and systems engineering assignments. And let me tell you, after all those experiences, I'm quite happy to be part of the Mercury team.
Jim, I'd like to paint a picture for our listeners by reading a quote from an article you wrote in our Mercury Rising newsletter that states, "We recognize that we cannot operate as separate engineering teams but rather must be one engineering community, so to facilitate cohesion within our diverse geographically separated team, we created engineering playbooks that describe our shared vision, common tools, processes, methodologies, and metrics to be used across all sites in each of our engineering disciplines." So my question for you, Jim, is what is the first thing that comes to mind when you think about engineering at Mercury?
First thing I think of is innovation. Our engineering philosophy is truly centered on delivering innovation that matters to our customers. It's really what Mercury is all about. Our people are really committed to our customers' missions and drive to be innovative, truly bringing out the best in our engineers. We're always striving to develop new technologies, and it's not only to solve existing problems, but to be proactive in the plan for what would be required in the future. But collaborating across business units, our engineers are developing game changing ways of delivering interesting, compelling, important technologies at a pace that's just not possible in a traditional defense contractor.
I agree, and with the amount of growth that we've seen just in the past two years, I'd say the pace is pretty rapid.
I joined the company four years ago as part of the acquisition for Microsemi, and at that time, our company had just over 500 total employees. Today, we've got over 600 engineers in a company that's rapidly approaching 2,000 employees total. That's amazing growth. And the diversity of skill sets that we've built is just incredible. 600 engineers at 15 sites. Think about that. I've got RF engineers developing secure RF microwave, millimeter wave and miniaturized fixed signal processing products. We've got software engineers and firmware engineers developing anti-tamper and crypto solutions. We've got talented multi-discipline engineers, developing secure processing solutions and storage solutions. Just the sheer breadth and depth of our engineering skill set's amazing, and it's particularly so for a company our size.
And even through all that and while we've experienced all that growth, we've really still been able to focus on driving towards the commonization of our engineering approach. Obviously that just doesn't happen by accident. It's been a purposely managed activity, and we have an unbelievably strong global engineering leadership team consisting of the engineering leaders from each of the business units. Our engineering leadership team embraces the Mercury culture with a focus on collaboration and trust. It's a team that thinks across Mercury and not just what is best for their own particular business unit, and that's so important. We've got to think cross Mercury,
Thank you for that update. I agree on the commitment to sharing technology and resources across sites and divisions. It's truly inspiring to see. So what has the global engineering team been up to? Please give us an update.
Well, we're striving to build a single cohesive engineering team across Mercury. That's how I want to think about engineering, that we have a single team across Mercury. We've got, as I mentioned before, the 15 different sites. Many of those sites are very small, so it's important that the people at each of these sites know the people at other sites and what they do because that's how we can take advantage of and leverage different opportunities that exist.
It doesn't really stop there though. We're always growing, we're always in acquisition mode, so we have to be planning for whatever comes next in terms of our acquisition strategy. To do this, having a shared vision is critical for our engineering team. We're always actively looking for more ways to promote collaboration because the more we share, whether it's resources, technology, or IP, that's where we're going to be stronger. And our customers not only want, really they expect to see one Mercury. They don't want to look at us and deal with separate entities. They want to see a single one Mercury approach.
Everything we do from global engineering is geared to support the business units in order to help make them more efficient. Well, you mentioned it earlier, Ralph, much of this is happening through the implementation of our global engineering playbooks.
I'm sure that there was a great amount of effort that went into creating such valued documentation. Could you please elaborate?
When I think about it, how we created these playbooks, I think it's just as important as what's in the playbooks, and I think that's partially the reason for our successful implementation. We didn't have a small group go off and create each of these playbooks in isolation. We didn't mandate them top down. Instead, we communicated through all levels of engineering management what we were planning to do and we set expectations for the implementation. We identified the leader for each of the playbook teams, ensuring that the leadership was dispersed around our geographical locations. We didn't want each site, a single site, to be owning all of the playbooks. We wanted this to be diverse.
We identified participants from each discipline from each site to ensure representation, and then we empowered those teams to identify what were the critical elements of their discipline. What had to be in the playbook? What needed to be common? We let those teams identify the tools to use.
Now this was not the quickest approach. It certainly took us longer to develop the playbooks this way, but it was a necessary step. It fostered the buy in that's required for a process program like this to be effective, over the long haul anyway. And ultimately this makes it possible for our engineers in one location to be able to support different business units or different geographical locations within their business unit without them having to sit back and go, "Wait a minute. How do they do things in this business unit?" It's the same, and that provides both a stronger enterprise and a lot more flexibility for employees.
Could you please describe how we work as a matrix organization? I've heard the term used around corporate and would like our listeners to know what is the matrix and also how is the matrix working within our current situation with COVID-19?
Well, the matrix confuses some, but it really shouldn't. Part of that confusion may be because the matrix can manifest itself in many different ways depending on the role each of us play within an organization. I like to think of the matrix as a combined organization responsible for supporting a function. It's the intersection of process, tools and structure with the day-to-day execution. Left side of the matrix is focused on process, tools and commonization while the top side is focused on day-to-day execution.
But in the engineering organization, we're really trying to blur those bounds. We want our global engineering leadership team to hold a shared vision. So maybe it's best I give a couple of examples about what we're doing in the matrix. I'll start with what's clearly my favorite example, and it's the firmware playbook team. And remember, as we talked about, these playbook teams have representatives from across the different business units in Mercury.
Well, the firmware playbook team saw inconsistencies in how firmware builds were taking place. They saw subscale build infrastructures at the different sites, and they recognized that by establishing a single Linux server farm with a common process, we could be more efficient. So working with IT, that team developed and deployed a new server farm and approach, and Ralph, the results have been far beyond what we had hoped. With this server farm, we're typically seeing build time reductions of 50%. We've seen it as high as 90%. That's shaving hours off of each build. Plus people can run multiple jobs concurrently. Plus we save on license costs. That's just outstanding work by this team, and that's the matrix in action.
We talk about acquisitions, and we love acquisitions. They make our engineering team stronger, but there are certainly challenges that come with integrating acquisitions. So to drive consistent and efficient integration of acquired companies and their respective engineering organizations, we created an engineering specific acquisition integration playbook, and this playbook contains a description of our integration philosophy and lessons learned as well as a set of checklist to guide the integration. These checklists are being used now and will be used with potential future acquisitions. That's another example of the matrix.
You touched on COVID-19. You asked about that. Well, coordination with IT is another area that we lean heavily on the matrix. Most of us are working from home, and when this team activity first started, our matrix structure really played a big role in sharing the best practices on how to set up our home networks to deliver the performance required so that we could continue to work with virtually no interruption. We work with IT on tool commonization across sites. The license cost reduction alone has been huge, but just as important, we're eliminating ongoing redundant support work, and we continue to see the matrix working to help with any number of IT issues, some related to COVID, some just part of daily activities. That's the matrix.
And I'll give one final example on the matrix. Each year we hold events like the engineering leadership conference and the engineering technology conference to promote shared technology across Mercury. That's the matrix in action. An analogy I like to use for the matrix is from football, big football fan, but at a football game, you don't want to realize the officials are there. Officials at a football game are at their best when no one realizes they're calling the game. Well, similarly in some ways, maybe the matrix is working best when you don't realize it's there.
Thank you for clarifying the matrix, Jim. You referenced the engineering leadership conference and engineering technology conference. I understand those events were canceled, but you held a virtual event last week. Could you please tell our listeners about it?
Yeah, last week we held an engineering technology review. We had planned to have our engineering technology conference live in Phoenix. I look forward to these events every year, but obviously we weren't able to hold that event due to the COVID crisis. We had a great conference last year, and I'm certain we would have had an even better event this year. Our agenda just looked fantastic.
These type of events are critical for to be one Mercury. They allow us to share some of the best technologies, products, and capabilities within Mercury while also promoting interaction by technical experts and leaders from all the sites. So while I'm happy we could do the technology review virtually last week, we benefit so much more from the live event when the innovators can interact.
That being said, the event last week was fantastic. We were able to highlight five different technologies being worked across Mercury. We had a great overview of our custom micro electronics business. This is a new business unit that I hope is featured in one of your upcoming discussions. We talked about artificial intelligence, architecture design reuse, software licenses. The presenters did a great job, and we had nearly 100 people from across all of our different sites participating.
Presentations were just outstanding. The quality of the topics generated so much cross site discussion. I was really happy with the scope and depth of the questions. You can tell how a presentation is going based on the quality of the questions that come back and we got some great questions, and I'm very confident that the ongoing discussions that started from this event are going to be worthwhile. I've already seen a ton of email exchanges back and forth on the AI topic in particular, so that worked out great.
Events like this give our engineers a forum to share their technology innovations. They get to show off their work with people who can look for opportunities to apply them in other parts of the enterprise. Our people put a tremendous amount of effort into their work, and it's great that they can share it with their peers and maybe more importantly, make some new connections across Mercury.
Secondly, these events allow others to learn about technology being developed across the company. Maybe they're working on a complimentary technology that can be paired with it. Maybe they have an idea to enhance the technology. This is something we really need to take advantage of. We have experts across all of our sites, and forums like this give us the chance to share some of the high profile technologies that as a group we can potentially enhance. It's the power of Mercury.
And then finally, these events give our technologists a defined forum to interact. We're always encouraging our teams to reach out across sites, across business units, to involve others in that white paper review, to involve others in a technical proposal review, to review that mechanical design. Fresh eyes from other technical experts are so valuable. That's some of the power of the diverse set of teams we have across Mercury. We're really building a tight knit group of engineers, even if we are located at different sites, supporting different business units. We're coming together.
Well, congratulations on a successful event, Jim. It sounds like the outcome was certainly worth the effort, and being a trade show manager myself, I understand completely how gratifying an event like this could be for an organization as a whole, so again, congratulations to you and the entire team. Now with FY21 fast approaching, what are some of the things that we have to look forward to from global engineering?
Ralph, we have so much more to do. The list of things we want to do is endless. We're already talking about and working on round two of the playbooks, adding details, specifically Agile Scrum. That's so exciting. Looking at that for software to drive more consistency and scale, adding more agility to our processes. We have an opportunity for greater depth of checklists and process and mechanical engineering, a group that's done really well with consistency.
Well, let's go one layer deeper. We'll be working with our systems playbook teams. How do we implement the more effective requirements management process? We'll also have a heavy emphasis on implementing more digital engineering methodologies, such as model-based systems engineering. This is an area where we recognized a shortfall and have added some key talent to help guide us going forward. We're working with IT to adopt new tools to simplify or automate tasks. We want to eliminate manual steps wherever possible.
And I'm really enthusiastic about our next generation of product life cycle management. We've aligned all our teams on one PLM tool to enable consistent configuration management, to ensure that we process change orders and handle release process the same way across all our sites.
So while we're thrilled with the progress made this far at Mercury, there's always more to do. I'm excited that our engineering leadership team is committed to simplifying cross site interaction and employing common practices and tools. I know we have the people, processes and tools in place to be successful working together. I think we can all look forward to an exciting, eventful and productive FY21.
Well, it certainly sounds like the engineering leadership team has a firm grip on direction moving forward, and I am eager to help market that innovation to the industry, so thank you for joining me today, Jim. I wish you safety and good health.
This has been another edition of Mercury Now, a podcast series brought to you by Mercury Systems. I am your host, Ralph Guevarez, signing off.