A practitioner's perspective on the importance of interdisciplinary communication and steps to improve it
All too often, engineering teams and the operators running their software might as well be on different planets, because they do not always communicate. Solutions engineering teams may push out unwanted software, or operations might not advocate for what they really need. And the businesses they support suffer.
I’ve witnessed this oversight many times during my career managing endpoints for large corporations. In the long run, the lack of communication creates silos and in some cases divisions between the two teams. At best, solutions engineering feels like they can move on to their next problem once they’ve selected a new solution for operations. In these cases, their work is rarely done, because operations will either come back with requests for improvements, changes, or worse, they won’t use what they’ve been given.
This becomes an even bigger problem if operations decide to rely on outdated software, which typically runs slower, and lacks automation, and API integrations. Legacy technologies can’t keep up in our modern digital world. Using older software is like building a house with hand tools – you’ll need more people and more time than you would if using power tools.
A lose-lose scenario
While communication problems may seem innocuous, the impact can be catastrophic, even exposing the entire company to more risk and vulnerabilities. In my experience managing endpoints for very large organizations, I have seen the direct consequence this can have on both the productivity of employees and the security risks they are exposed to.
When there is poor communication (or none at all) regarding recommended products and processes worker productivity suffers. The company’s bottom line suffers when engineers spend time and money pushing out solutions that operations won’t use or that require wholesale changes.
Boosting worker productivity and lowering costs are two main reasons engineering teams get asked to select and implement new solutions in the first place. Ideally, they provide operations with the optimal software for the tasks they want to perform. When they don’t, it’s often because no one checks with users or support staff for input or feedback during planning.
Ineffective engineering and implementation strategies can result in vulnerabilities that could be exploited before you can apply remediations, which has grave effects on security.
The good news is that these problems are solvable.
Ask what’s needed
Engineering managers should be sure to ask their operations counterparts a lot of questions. What will help them do their job better? What doesn’t work about what they’re using now? How do they like the solutions engineering is working on for them?
Not soliciting operations’ feedback means missing the opportunity to make a difference in their productivity and your company’s success and security. On the operations side, people should proactively involve themselves in the engineering planning that affects operations to avoid frustration later on.
The communication conundrum: Five fixes
The need for good communication between solutions engineers and operations may seem obvious. But the reasons why may not be.
Engineers tend to be self-starters and work independently. They aren’t the ones studying customer data to chart the course for new projects: they’re told what the need is and then they try to fulfill it. Reaching out to operations may not even occur to them.
Ideally, these two groups work together to help achieve business objectives – continually and consistently. But if your company culture doesn’t already support this kind of collaboration, you’ll have to take the lead.
Here are five ways engineering teams can improve communication and coordination with operations:
1. Have a segmented, separate space for testing new products – and trying out new features – before you hand them over to operations.
A virtual sandbox in which you can play – trying scenarios and options, making changes, testing what you’ve decided to run – matters not just for you, but for users of the solutions. For one thing, a safe lab environment makes it easier to try new features your operations people might request.
An added benefit: this kind of environment lets you fully document your process and the results of the tests you perform. Being able to present reliable documentation showing that what you’re implementing really works in your company’s environment. It helps improve trust not only with your operations team but with managers on every level.
On the other hand, without a safe testing ground to find and fix problems proactively, you’ll often find yourselves in reaction mode, with various members of both teams – operations and engineering – trying to figure out what’s wrong with what you’ve decided to implement and how to correct it. To avoid this waste of time, use your sandbox to thoroughly test before deployment.
2. Involve operations in your processes early and often.
It’s always a good time for feedback from your operations team – but if you’re waiting until the documentation stage to get their input, you may be communicating ineffectively.
Preventing a problem is easier than finding a solution after the fact. This is why we practice preventive maintenance on our cars – changing the oil, and so forth.
Engineering needs to ask operations early in the process – in the planning stage, if possible – for input into the software and solutions that will work best for them. And you need to include team members regularly so you’re in sync along every step.
The best time to open the lines of communication is as soon as engineering knows that operations have a need. Then you can propose an overall plan to fill that need and make adjustments using operations’ input.
3. Invite operations to peer-review the documentation of the software you’ve selected.
If there isn't time or opportunity to connect before documentation then make sure you do before changes are made, so that the operations team understands your process and what they can expect in new or revised software.
As you’re testing and implementing, document every step. That way, if key IT people leave, operations will have reference materials showing how the solution should operate so they can more easily resolve issues that might crop up later. Providing documentation is engineering’s responsibility.
At one company where I worked, I would ask operations staff to conduct peer reviews of my documentation on projects that involved them.
We upgraded our Configuration Manager environment regularly and refreshed the documentation with each upgrade. On the day before operational implementation, I’d turn over the documentation for operations review. That way, they could provide their input and ask questions, and we could go to development for answers if need be.
This step let me make sure they understood the documentation. If I’d used a term they didn’t understand, we could collaborate to find language that made sense to them. Otherwise, if I left the company and they had problems with what I’d sourced, they might be as much in the dark as if I’d never given them documentation in the first place.
4. Create a “living,” step-by-step plan with benchmarks together.
Roadmaps can help ensure that your program is really going somewhere and that everyone is on the same path. Your “map” could be a chart or series of charts or lists that offer different perspectives: by quarter, by project, or by overall organizational goals.
You might note, for instance, that your vulnerability management system has become outdated, and schedule it for an upgrade at a certain time of the year. Or perhaps you’re planning to migrate to a new hardware platform. Isn’t it best if operations know about these projects from the get-go?
And given the pace of change today, make sure to review and update your roadmaps at least quarterly.
5. Host engineering roundtables that include people from operations.
I hosted monthly engineering meetings to discuss upcoming projects and invited representatives from other functions including operations to join.
For instance, you might call a roundtable series to discuss server administration or endpoint management, maybe announce a patch management project, invite ideas and suggestions, perhaps present your roadmap for a project and solicit participation. This approach gives you a liaison with the operations team and provides its members with information and opportunities to contribute their expertise, as well.
In the fast-paced engineering environment, every moment counts. This particularly rings true for teams under pressure to identify, test, and push out products and updates to stay ahead of the competition.
Working as fast as you can, you may feel tempted to skip these steps of coordinating and collaborating with operations: the more people involved in a project, the more time it will take to complete.
But, omitting your cross-functional coworkers from the process won’t serve anyone in the end – not your engineers, not your operations teams, and certainly not your enterprise. If any of the above rings true for you, it is well past time to open these communication lines. I assure you, it will only benefit you in the long run.
This is the latest entry in our new Adaptiva Practitioner Blog Series. In these blog posts, we share what we know about managing endpoints. Stop by to hear from our own in-house subject matter experts. We are excited to discuss best practices, technical how-tos, and other topics we think you'll find valuable. Our solution architects, product experts, and own IT practitioners have seen and done it all. We are adding new content regularly and are happy to have you here.
