Dan Clark
Daniel Clark
Senior Director of Communication, Navigation and Surveillance Engineering
Rockwell Collins

Professional background: Dan Clark has spent the bulk of his career at Rockwell Collins, initially as a hardware design engineer working on an enhanced passenger entertainment system controller, and then moved into product engineering with responsibility for budgeting, scheduling, and quality. Two years later, Clark became a group manager and followed three years later with his first department manager position, responsible for a group of about 80 to 100 employees. Today, Clark oversees 440 employees, about 330 of whom are engineers and the rest support staff. He is responsible for the requirements, design, development, and manufacturability of complex avionic systems and subsystems.

Education: Bachelor’s degree in electrical engineering from California State Polytechnic University, Pomona.

Personal passions: Being a great spouse and a great dad, cycling, competing in triathlons, landscaping.


By Daniel Clark, Senior Director of Communication, Navigation and Surveillance Engineering, Rockwell Collins

If you’ve ever led a tough development project with tight deadlines and high expectations, then chances are you’ve set up a hotline and given your engineers explicit directions to call immediately should they hit any barriers. Then you’ve waited for the phone to ring, ready to spring into action and help save the day.

Imagine how surprised you’d be if nobody ever called and your “Bat Phone” (Commissioner Gordon’s secure line to Batman) sat silent, day after day, months on end. I know the feeling firsthand.

Direct Line to Action

In the fall of 2013, I had the notion of launching an internal development project. Historically, we had commissioned design and development to an external firm. But for this project the procurement cost was substantial — more than what we believed we’d spend internally.

This type of design and development project would normally run anywhere from 18 months to two years — way too much time for my purposes. I needed to get this program done really fast, so I gathered together a core team of five direct reports — four engineers and a technical project manager — and said, “Guys, I’d like you to do this in 90 days.”

While I fully expected them to tell me my plan was ludicrous, none of them did. I knew completion in 90 days was undoable, as did they, but we all wanted to strive and push ourselves nonetheless. And we thought, “If not 90 days, what about 120 days?” Even in that time frame, or slightly longer, we’d still be extremely successful.

So that became our aim, and hence the reason I felt I needed to set up a Bat Phone. In order to meet such an aggressive development plan, my team members were going to have to obtain special allowances on established processes and procedures used throughout Rockwell Collins. I anticipated some head butting as they crossed organizational boundaries, and I wanted them to be able to reach me at any time. I figured I’d get quite a few calls saying, “I need your help making this happen.”

But those calls never came — if not exactly a blow to my ego as a leader, still a great surprise. In fact, it was very satisfying to see my engineers reach out to others in different parts of the company, explain the urgency with which they needed things done, and achieve their desired results. I loved seeing them take ownership and not come scurrying back to me saying, “Dan, here’s something slowing me down. Go fix it for me.”

Don’t Let Process Get in the Way of Progress

As we worked at speeding our development time, we took the opportunity to identify and document anything my engineers encountered along the way that either slowed them down or potentially could have. As part of that initiative, for example, my product engineering team needed to run lab tests on the weekends. However, those workflows were interrupted by automated software updates IT routinely ran during off hours. So the engineers had to approach IT and say, “Look, we know this is hard because it’s an automated process, but here’s the value that our work is going to bring to the company.” Once IT understood the potential business impact, it willingly helped us out and made it possible for us to work over the weekend without interruption.

Likewise, we were able to expedite a request from one of my engineers who needed multiple screens in order to do his work more effectively. IT delivered the right tools quickly.

The same goes for help we got in expediting procurement. Our company has a process for procurement. Sometimes, as was the case with this project, this can significantly slow down the development process. We were able to show the procurement organization that we would be using the best quality, highest performing parts and that our vendor selections did not affect the company’s overall strategies for reducing procurement costs. Procurement understood our methodology, tailored its process for our purpose, and got us the parts we needed faster than would have been possible through traditional processes.

In the end, thanks in large part to that cross-organizational effort, we were able to crunch a typical 18- to 24-month development cycle down to six months.  We hit our first milestone in November 2013 and completed the project in April 2014. So we didn’t hit the 90-day mark, or the 120 — but we absolutely got it right as fast as we could.  It  was an incredible effort by everybody.

The rapid-fast development didn’t go unnoticed by the higher-ups, either. My boss, who is the vice president of engineering, shared our accomplishment with the COO. As he told me, he thought that what we did was significant enough to warrant a look by corporate leadership — and the COO agreed. If other parts of the organization could see what things were slowing down development, and why that mattered for the overall good, he reasoned, then the company — and its customers — would benefit.

As an organization, we called the initiative “What  Slows Us Down.” We ended up with several items, ranging from how we procured products and managed IT processes, as noted above, to the ways we worked on third-party intellectual property licensing and how we certified products for compliance with Federal Aviation Administration regulations.

Based on that list, we formed a cross-organizational leadership team and began working together on process improvements. Having the COO’s backing really helped energize and drive the leaders to take the necessary actions within their respective organizations to improve cycle times for engineering development.

Figure Out What Motivates Your Team

As difficult as this challenge was for my core team members, I was confident they’d be successful. That’s because I believe in them unquestionably — that’s an imperative. Let’s face it, as leaders we’re not the ones doing the work. The people on the front line of any development project are the ones who get the job done. My fundamental belief, a philosophy of leadership, is that the better care you show your people, the better job they’re going to do.

I’m 100% confident that when you have engaged, motivated employees, they will find a way to get the job done. And let me tell you, when you have engaged, motivated employees who are passionate about what they’re doing, your job as a leader gets easier.

The trick, of course, is figuring out how to engage employees. A much-used statistic is that, at maximum, only about 30% of a company’s employees consider themselves engaged at work (I’ve seen numbers ranging from 20% to 40%, depending on the industry.) So if I can take that 30% of engaged workers and make it 40%, I’m going to be better than all my competitors. And if I can take that 30% and make it 60%? Well then I’ll be screamin’ down the road with much better products, at lower cost, and with a customer satisfaction rating that goes through the roof.

I’m working toward this at Rockwell Collins.

As a company, we conduct an annual employee survey that includes about a half dozen questions related to engagement. That’s great to get the data that shows how people feel, but my personal feeling is that we as a management team need to be doing more than looking at the data we collect. I want to be doing things close to the employee, watching their responses, and using that as a measurement of engagement. To me, employee engagement and quality are of the same ilk — that is, you can’t always measure either, but you can sure tell when you don’t have it.

I don’t have any expertise or advice on how to engage employees that you can’t find in any number of leadership guides, but I absolutely do know that you have to take the time to figure out what motivates an employee on a personal level. If you find out what’s important to an individual, your job as a leader gets easier, because you’ll know how to reward him or her in a way that engages and motivates.

Some employees appreciate gift cards and feel like valued contributors when they receive one. Others aren’t interested in financial rewards whatsoever and instead find motivation in personal interactions, new career opportunities, or extra time off. I always try to express my thanks to anybody who does something well. For some, that simple acknowledgement is enough of a motivator. Others feel valued when thanked, but not engaged. As a leader, it’s my responsibility to listen and hear what employees want. I’ve found that when you take the time and put in the effort, the answers become clear fairly quickly.

Obviously I can’t go to that level of personalized attention with each of the 440 employees in my organization. So I start with my directors and champion the engagement ideal with them. I meet with my leadership team, which comprises seven direct reports plus two remote CTOs, once a week as a group and in one on ones during which we talk not only about professional projects but also anything pertinent on a personal level.

My expectation is that these leaders use the same approach with their direct reports, and so on down the line. And I’m happy to hear when managers take the initiative to recognize employees’ efforts. For example, I loved that one manager recently gave each person in his department a certificate for a HoneyBaked ham with a handwritten thank you note for working so hard.

That kind of gesture can be so simple, but we as leaders don’t do this sort of thing nearly enough. It’s too easy to get out of the practice. You get too busy with your day. The hottest project is in trouble, and so you’re focused on that and you forget to go around and say thank you to the people who are working so hard. I think we’ve lost the art of saying thank you, and we need a reminder to do so every so often.

Maybe what we really need are Bat Phones for saying thanks, not asking for help!

Originally published in CTO Straight Talk, No. 2

The Takeaways

In trying to achieve a stretch goal — an ambitious project or a tight deadline, for instance — you might find that established routines and processes are getting in the way. Document the obstacles and then approach the owners of those processes to explain how deviating from routine in some circumstances can benefit the entire organization.

Engaged, motivated employees will rise to even the toughest challenges. The trick is figuring out what engages people. For some, it’s tangible rewards; for others, it’s words of thanks and professional opportunities. Collecting data from employees is a good first step, but you’ll learn even more, and be able to tailor incentives, through personal interactions and observations.