The digital news landscape has changed dramatically over recent years. Previously, increased interest on the part of readers allowed sites like BuzzFeed and Huffington Post to thrive, as demand for their content made creating more profitable. Social media played a massive role in the success of digital news media, as the sharing of articles and posts by readers enhanced a company’s visibility, often for much less money than traditional advertising mechanisms.
However, the landscape has shifted dramatically. Everything from Facebook’s pledge to focus more on posts from friends and family to rising interest in other mechanisms, like video, is playing a role. Buzzfeed ultimately decided to lay off around 15 percent of their staff as they prepare to adjust their model.
The Rise of the Online Video Star
Sites like Facebook, Instagram, and YouTube have made posting videos about as easy as possible. As a result, nearly anyone could potentially try their hand at being a star. Plus, the masses were becoming increasingly enamored with video, often favoring it over other mechanisms, like written posts and static images.
As a result, many companies began to pivot, looking for ways to profit in the video category while shifting away from other approaches. This was especially true once the digital news sections of many companies began to become less profitable, decreasing their cost-effectiveness from a business perspective.
Facebook as a Publisher
Many digital news organizations relied on social media to gain readership. Facebook was often a preferred platform, but a variety of revelations – including the Cambridge Analytica data scandal and presence of Russian fake news sites – lead many users to doubt the validity of what was being posted. Additionally, Facebook itself was forced to pivot in response, altering what forms of content could be promoted by digital news organizations, limiting organic reach, and changing what users would see on their feeds.
Further, some users began to pull away from platforms like Facebook. They began to doubt the social media giant on a primal level, and that impacted how many people would be exposed to posts from digital news organizations. Others started to question the validity of nearly all digital news sources, as uncertainty about who is fake became an increasing concern.
The changes on Facebook’s side made digital news less profitable, and some digital news organizations ultimately did not survive. Skeptical readers also began pulling away, further harming readership numbers and impacting profits.
Is Digital News in Trouble?
In reality, digital news likely is not in trouble across the board. However, that does not mean companies will not need to change to survive in the shifting landscape, and those who refuse may disappear, either voluntarily or when readership dwindles to a point that they are no longer viable.
Those who change and adapt will likely remain, at least for the next few years. In the end, it is not unlike any other business segment where those who refuse to keep up with the times fade into obscurity while those who embrace the need for change have a chance to remain strong.
If you would like to learn more, the team at The Armada Group can help. Contact us with questions today and see how our expertise can benefit you.
IT professionals are often trusted with a significant amount of power in any organization. They have access to critical systems and data, some of which is not directly related to their positions.
Employees in any department may participate in some questionable activities, and IT workers are no exception. While some occasional lighthearted actions can be beneficial to morale, when certain lines are crossed, a serious problem exists.
To help you identify these issues and address unruly IT employee behavior, here are some common areas of concern and how to handle them.
IT employees are uniquely positioned when it comes to practical jokes. They can do anything from changing a person’s password to adjusting computer wallpaper, often remotely.
While some of these actions may seem harmless, they can easily become bothersome. For example, another employee’s work may be disrupted by a practical joke, hurting productivity. In more severe scenarios, such as changing a worker’s desktop background to something inappropriate, a staff member may become offended, or worse.
To prevent these activities, you need strong policies in place that define how credentials can be used as well as any consequences that are associated with these breaches of trust. Using alerts that inform the manager when specific actions are taken can also be effective deterrents, as all activities are automatically broadcast to their supervisor.
Accessing Confidential Information
Most IT professionals have administrator credentials that allow them to access a range of systems. While this is necessary for the work, it can cause problems when they abuse the privilege, using their credentials to access confidential or sensitive information not related to their positions.
Further, they often have the ability to delete or alter logs, giving them a chance to cover their tracks.
Setting up alerts can help spot this kind of activity, as well as a robust ticketing system that can help determine which actions are legitimate and which may be illicit in nature.
Since IT often controls what can be accessed over the internet and which activities are logged, the potential for abuse is significant. A worker could give themselves the ability to access entertainment related sites that would otherwise be blocked, giving them the opportunity to slack off while they are on the clock.
While taking a moment to relax isn’t inherently a problem, if they begin spending more than a reasonable amount of time on non-work-related activities, productivity is going to decline. Further, if they access inappropriate content using company resources, you could have a bigger problem.
To help lower the risk associated with such actions, it’s imperative that all employees be subject to the same restrictions based on actionable policies and that any attempts to circumvent certain blocks be appropriately logged and alerted. This helps deter IT professionals from taking advantage of their position, lessening the likelihood that someone will do so.
Ultimately, most IT employees are standup workers and wouldn’t abuse their power. However, it is crucial that the proper policies and monitoring mechanisms are in place to ensure that such activities don’t take place.
If you are interested in learning more or are looking to hire a new IT worker, the team at The Armada Group can help. Contact us today to see how our services can work for you.
Being promoted into your first leadership position is an exciting time, but it can also be a challenging one. Often, it comes with a series of nuances you have yet to experience. Add to that the desire to make a strong first impression, and it can be almost anxiety inducing.
While everything may not go perfectly regardless of your efforts, there are steps you can take to help you prepare for your first day as a leader in a company. To help you on your journey, here are some tips to make the beginning of this segment of your career as successful as possible.
An internal promotion into a leadership position means you are working with people who remember when you were a member of their ranks. Regardless of your skills or abilities, the change in the dynamic can lead to some awkward encounters. You may be unsure about your authority, and former coworkers might not know if the relationship has effectively shifted as you assume your new role. In some cases, you may even run into individuals who are blatantly resistant, guaranteeing some uncomfortable moments.
While you may not handle every one of these moments perfectly, understanding that they will occur helps ensure you aren’t caught off guard. Just remember, it can take time for a change to sink in and become the norm and make sure you handle every situation with a mixture of confidence and grace.
To Err is Human
When you start a new position, you are going to make the occasional mistake. And transitioning into a leadership role is no exception. Acknowledge that errors will be made and take ownership of them when they do. Then, treat them as learning opportunities and strive to avoid that mistake in the future.
Just because you have worked at the company for a while, that doesn’t mean you will automatically know everything there is to know about being a leader in the organization. Be prepared for some missteps, make necessary corrections, learn from the experience, and then move on to the next challenge.
Popularity and Leadership Don’t Always Go Hand-in-Hand
Sometimes you will have to make a choice, and it isn’t always going to make you popular even if it is the right move. Understand that not everyone will like your decision but, if it was made based on an appropriate amount of analysis and experience, don’t be afraid to stand by it.
It can take time for employees to trust new leaders. As you continue in the position, you may see the amount of resistance lessen, though it might never disappear. Just make sure to listen to legitimate concerns or potentially valuable input and then act accordingly. If it turns out you made a mistake, refer back to the point above.
If you are interested in more advice regarding working in a leadership position, The Armada Group has the expertise to help you on your way. Contact us today and see what our recruitment professionals have to offer.
When corporate leaders think of protecting corporate data, they usually think in terms of protecting it against cyberattacks. But in reality – even if a company is fully protected against external threats – those aren't the biggest issues companies face with respect to their data.
Storage devices have high reliability, but they aren't fail proof. Companies need their storage plans to account for failures. This means using clustering, mirrored disks, and replication to ensure that data is available on another device.
Most companies have automated backups, but the backup plans often aren't reviewed and updated. This means it's easy to miss new devices and omit them from the procedure. Backups also need to be monitored, to make sure the automated scripts work properly. Lastly, companies rarely test restoring from backup, but this should be done in order to verify the procedure and understand how long it will take.
People make mistakes that expose corporate data. Phishing campaigns have convinced users to provide corporate bank accounts. But it doesn't take a phishing campaign. Users often send sensitive data through unencrypted email. They share passwords because getting set up properly takes too long. They mistype a command and the system doesn't require confirmation before executing it. Issues like these can largely be addressed through better training or redesigning systems.
The biggest data issue companies face, though, is corrupt data. When incorrect data feeds into other corporate processes, the company's decision making is inevitably adversely affected. Corrupt data entry is often caused by poorly designed applications; it can also occur when data is force-fit into legacy systems because creating a new application with appropriately named data fields would take too long. At the same time, migrating data from legacy fields to new applications introduces possibilities for error when fields are mapped wrong. In many businesses, the same data is entered into multiple systems, with chances of incorrect or inconsistent values.
Data is at the heart of business operations, and it's unquestionably important for companies to protect it. Doing so effectively requires taking a broad view of the data at rest, in transit, and when it's accessed by both man and machine.
Small companies often partner with bigger companies to work together on projects. The small companies gain access to opportunities they can't win on their own; the bigger companies get the smaller firms' specialized expertise, dynamism, and creativity. For these partnerships to succeed, the responsibilities and obligations of both firms need to be spelled out clearly in the contract. These are some of the aspects contracts should address:
The most basic aspect of the contract will be the price to be paid for services. Neither side should agree to the contract if the financial terms are unsatisfactory. However, even if the contract's financial terms are acceptable, other contract points may need to be negotiated.
Indemnification clauses state that one of the parties to the contract will be held harmless, in case a third party sues over a specified matter. Typical contracts dictate that the larger firm will not be liable for matters related to new technology introduced by the smaller firm. Because the smaller firm cannot rely on the resources of the larger company to support it in case of a lawsuit, indemnification insurance may be necessary for both parties to be adequately protected.
• Non-infringement of intellectual property
These clauses state that the smaller firm represents that its intellectual property is its own, and not infringing any existing patents. Agreeing to this clause can be difficult for firms that use emerging technologies where patents have been applied for but not yet granted. This contract clause may therefore require negotiation and flexibility on the part of both parties to reach agreeable wording.
• Filing for patents
If the partnership between the two firms will generate patentable ideas, the contract should specify where patents will be applied for and which party will pay for the applications. Big firms may have global reach and require patent coverage around the world, while the smaller firm may not have resources to apply for patents in every market. Frequently, contracts specify that the larger firm will pay the fees in certain markets or split the cost of filing fees with the smaller firm.
• Limitation of liability
Limitation of liability clauses cap the damages that can be owed due to breach of contract. Agreements between large businesses often cap damages to a low multiple of the prior year's fees. However, small firms may be heavily dependent on a single contract, and financially devastated if the contract is breached. Negotiating the limit to an appropriate value is one of the critical points to be addressed when large and small firms need to do business together.
When software moves from test to production release, making sure it runs properly is the job of the site reliability engineering team. Sometimes the production environment is different from the development and test environment, so the application doesn't have the same performance it had during test. Sometimes there are more users than anticipated, and the application doesn't scale up. Sometimes real-world data causes problems that test data didn't uncover. Whatever the issue in production, site reliability engineers need to figure out the cause of the problem and put the necessary changes into place to make the application successful.
At some companies, the SRE function is called DevOps, because it's all about moving applications out of development and keeping them operational.
Monitoring and Planning Ahead
A lot of the site reliability engineer's role is about keeping an eye on the system and planning for issues. For an SRE, the "system" means the entire system, including the application, third-party software, the hardware, and the network. The SRE team monitors the system to make sure it meets availability and responsiveness requirements.
The team also looks to the future of the system. They make sure any planned changes, to any component, minimize impact to users. They review capacity and come up with plans for expansion. They also have the responsibility for dealing with unplanned downtime and planning for disaster recovery.
Site Reliability Engineer Skills
Site reliability engineers need solid software engineering skills. They need to understand how software works and how different software products interoperate. SREs often write complex scripts to automate operational tasks. But they also need to bring a broader perspective than just application software development, and understand networks and system administration.
Site reliability engineers need to be creative thinkers and problem solvers, who can work under pressure to figure out a system problem and create a solid solution for bringing things back under control quickly. They need to be analytical, to review data about system usage and system problems, in order to develop plans for the future of the application.
Communication skills are important; SREs need to be able to ask questions of other technical teams to figure out the problem and also to explain to management both the problem and the solution. SREs are part of a team and need to be able to work with a variety of colleagues.
Site Reliability Engineer Career Path
In some cases, SREs choose to strengthen their software engineering skills and move to the software engineering team to create the future of the application. Other SREs choose to develop their system engineering skills and continue to work within site reliability engineering. For those who are interested in management, success as an SRE can lead to firm-wide responsibility for managing infrastructure and shaping the future of the enterprise.
You may think the transition of an application from development to production happens at the end of the software lifecycle, but achieving a successful transition requires thinking about it all the way back at the start of the development process. Here are 10 things you can do during development to make it easier for the operations team to take responsibility for the app in production:
1. Make it easy to gather metrics. A key part of the operations team's job is monitoring what the application is doing and how it's doing it. That's a lot easier when the application gathers basic information and provides hooks for ops to check other performance numbers.
2. Document system dependencies. No system runs in isolation, but if the ops team doesn't know your application depends on some obscure package, that package may end up getting deleted to free up space. Put together a list of all the necessary components to make sure they get installed and stay installed to keep your app running.
3. Degrade gracefully. Don't write an application that falls apart when there's any sort of problem. Applications should flag problems and alert the support team, but continue functioning as fully as possible. This means applications shouldn't fail to come up just because the log file system is full.
4. Keep compatibility in mind. If your application can run with past and future versions of third-party products, the DevOps team will have a much easier time deploying your application and managing it, especially if it runs in a shared environment where other applications may want different versions of those components.
5. Make it easy to change configuration settings. A key responsibility of the DevOps team is keeping applications running when the environment around them is shifting. Building connection strings and other configuration settings into compiled code makes it impossible for DevOps to do that.
6. Provide configurations settings and flags for as much as possible. If a feature isn't configurable or can't be turned off and on, the DevOps team has no way to control it and manage the impact in production.
7. Build with scalability in mind. If you're lucky, your application will be wildly successful and have to grow to support more users. A well-designed application will let DevOps handle this by running the app on more nodes. If you don't design the application well, it may need to go back to the development team for a rewrite before the user base can expand.
8. Think about support scripts. The support team would love to automate as much of their job as possible. This means making sure application functionality can be invoked from a command line, rather than only by clicks within a GUI.
9. Provide a regression test suite. DevOps wants the application to keep running when the environment around it changes. A robust regression test suite lets them verify the system will still work after they make changes.
10. Document. Document. Document. There's a ton of critical information that exists only in the developers' heads. Writing it down means the DevOps team won't need to call developers in the middle of the night to find out where to change a configuration setting.