Blog News and events about Polaris Solutions!

95% Reduction in Deployment Costs with Octopus

by Joshua King on January 08, 2018


A national airport offsite parking company was outgrowing their build and deploy process. Deploying software to each location manually was proving costly and time consuming. Each deployment was taking over 40 hours to configure and deploy, followed by 20+ hours of follow-on work. They needed a new solution that would supplant the capabilities of their existing solution as well as scale with the expected growth of the organization, while still providing detailed information about the success or failure of deployments to every location.


Polaris Solutions worked with key stakeholders to identify the problem, determine the capabilities required from the build and deploy tooling as well as the reporting granularity that was necessary. Based on the familiarity and robustness of the existing build tool, it was decided that this tool would continue to work, with a few configuration changes and enhancements. The deployment tool was replaced with Octopus, an industry leading automation platform that provided the deployment metrics, granularity of control, multi-tenant abilities, and scalability that was needed. The new solution greatly reduced the time and cost of each deployment while increasing the success rate of all builds and deployments.


With the implementation of Octopus to manage deployments, the organization saved an estimated 85% annually on deployments, and as much as 80% on configuration and maintenance of the deployment process. Configuration time required by the teams to perform a deployment decreased by over 95%, and drove more consistency in implementations. Configuration of each new facility for deployments reduced by over 90%, an estimated annual savings of nearly $80,000 per facility generating an ROI of 530%. Instead of taking days to deploy code, or implement a new facility, this new process takes minutes, allowing them to deploy more often and stand up new facilities more quickly.


1,2,3…NOT IT!

by Joshua King on December 18, 2017

"If only the team would take ownership, we wouldn’t be in this mess. I need someone to be accountable for this project!"

As a leader, how many times have you thought about the idea of accountability, and wished your team would take accountability for things? How many times have you thought about the issues you have and wondered why you’re not getting the engagement you want? Have you ever googled “getting people to be accountable”?

Odds are good if you’ve asked any of these questions, you’re the only one (or few) that’s owning things. It’s also likely that you’re sick of being the only one to do so. It’s equally likely that you don’t realize the reason people aren’t taking ownership is because of how you and other leaders act.

The unfortunate truth is that you cannot ‘make’ someone take accountability for something. You can cajole. You can incent. You can even make their bonus contingent upon it, but at that point, what are you trying to achieve?

You need to ask yourself, “how have I created a culture where people don’t want to own things or be accountable?”, “how have I acted when people took accountability and things weren’t perfect?”. It is possible that there are a couple of people that don’t innately take ownership of things, but to have a whole team, or  organization perform like that points to a bigger issue, an issue within the system, the system being the organization and culture.

So how do I get more engagement? How do I get my team to want to take accountability? The first step is realizing that the team’s lack of engagement falls squarely on the shoulders of the leadership and the culture that you’re creating. Think about the last time you had someone from the team take on something and decide to own it. If it didn’t go well, how did you act in that moment? Did you assign blame? Did you seek to understand and move forward? Was punishment on your mind? This moment, this tiny space is your opportunity to create, or crush, accountability within your organization. If you touch the stove and burn yourself, you’re not going to be as likely to touch that stove again in the future, this is the same kind of situation! You need to reward the behavior you want, and discourage what you don’t. If your default mode when things go wrong is to look for someone to blame or punish, you’re encouraging the kind of behavior that leads to no one taking accountability.

So next time things don’t go exactly as planned, take that opportunity to approach the situation with curiosity, understand everyone is doing their best with what they have, and coach the person/team on how things could have gone better. Most of the time, you can’t be any harder on people than they already are on themselves, so help them move forward and be more successful next time. This kind of behavior will encourage people to take ownership, take risks, be innovative, and help push your organization forward.


DEV LUNCH: Modernizing Legacy Applications

by Clint Edmonson on December 14, 2017

Application modernization is the practice of re-writing or porting existing software to newer frameworks and platforms to align it more closely with current business needs and realize more value.

Modernization of a critical enterprise application is often a large, multi-year high risk journey. It benefits greatly from a proper strategy to incrementally improve upon and modernize while ensuring it remains fully functional throughout the transformation.

This interactive session featuring a panel of senior Polaris consultants will explore trends and strategies to consider when embarking on an application modernization effort.

Key topics will include:

  • Driving forces
  • Web based application frameworks
  • Domain and microservices
  • Data storage
  • CI/CD Pipeline
  • Cloud services (functions, fabrics, containers, AI, and more)
  • Stages in the journey
  • Building a roadmap

Complimentary lunch will be provided. Seating is limited.

Tue,  Jan 23    11:30 AM - 1:00 PM      St. Louis, MO              REGISTER NOW!

Tue,  Feb  6     11:30 AM - 1:00 PM      Downer's Grove, IL    REGISTER NOW!



The Agile Transformation Trough of Despair - How to Avoid It!

by Joshua King on December 08, 2017

Agile transformations can be undertaken for a myriad of reasons, but the fact is, no matter the reason, the changes that are required to transform the organization are largely the same. There are organizational changes, roles to be created, incentive plans to be reworked, financial planning re-evaluated, leadership, and then finally, the teams.

Most organizations start with the teams and decide that a top-down supported bottom-up transformation will work, but this is a fallacy. If you want a transformation to work, the entire leadership team needs to be bought in, from the board of directors down. This is no mere way of changing the way teams work, this is changing the way the whole organization operates. The teams are the easy part, but the change within the teams is going to highlight the problems that they encounter on a daily basis, and it’s going to require a lot of hard work by the people at the very top. If they’re not bought-in to an agile mindset, you’re going to have a bad time.

Let’s look at the way most organizations start a transformation. The original plan may have been put together by a middle manager that’s been tasked with the transformation, but not empowered or understanding of what they’ve been asked to do. For that matter, the people at the top that want the 35% increase in productivity don’t really understand how that’s achieved. They’re going to start planning it like they would any other project, build out an MS Project plan in excruciating detail from start to finish. The plan will have a lot of goals that may or may not be at all achievable. They’re going to start working with teams and having some degree of success, but they’re also going to uncover a lot of the built-in problems that the organization hasn’t been acknowledging over the years. These problems are going to have to be dealt with, they’re going to have to be resolved if the teams are going to continue to move forward. As these problems aren’t resolved, teams will start to be discouraged, and morale will drop significantly. People will stop reporting problems because they know nothing will be done about them. It’s back to business as usual and teams will revert to what they’re used to, and the previous success will be long forgotten. Management will look at the situation and determine that the fault lies within agile and not necessarily their organization. They’ll put the agile transformation in the pile of failed management initiatives.


Now let’s look at what could be possible If the leadership does embody an agile mindset from the beginning. Start at the very top of the organization by helping them adjust their leadership style to embrace agile values of empowerment, psychological safety, safety to fail, optimizing the whole, intent-driven leadership, etc.; these changes alone will reap benefits for the organization. They’ll start creating company and product visions that will excite their teams, make them want to come to work because they have a purpose. The leaders will start to see the problems that are inherent in the organization, and start solving them. They’ll see how their structure is built to maximize efficiency in any one area, at the expense of making it more difficult to get things done overall. They’ll see the cost of centralizing command and not pushing decisions to the place where the information is. They’ll see that there is no chance of innovation without psychological safety and freedom to fail. They’ll also recognize that by setting intent instead of directives, they are embracing the creativity of the entire organization rather than relying on 1 or 2 people to come up with all the ideas. Some of these problems are BIG and will take a while to resolve, but will provide immense benefit to the organization when they are.


This is where we start pushing it down into the levels of middle management and the teams. They’ll see their leaders acting in this new way, and they’ll be more receptive to changing how they’re thinking and behaving. The teams will see this new space they’re given to start deciding how they’re going to solve issues, and as they see the changes, they’ll start stepping into this new ownership over their experience.

By starting at the top of the organization and their mindset, we’ve avoided the trough of despair and pushed enlightenment forward. Expectations will be more realistic, and teams will fully embrace and buy the change that they’re seeing at all levels above them. This will create a sustainable change within the organization, and reap the benefits of agile for the organization that goes far beyond productivity. This will create an engaged workforce that’s willing to try new ideas, push the envelope of what’s possible, and teams that will go the extra mile willingly when necessary.


Announcing the Polaris Innovation Repository

by Clint Edmonson on December 04, 2017

One of our core values is inventiveness and one of the great perks of working at Polaris is the dedicated time we are given to follow our intellectual pursuits. Our Innovation Days benefit gives every consultant full autonomy to spend 3 days working on a technology project of their choice.

These ideas are not vetted by management, subject to anyone's approval, or directed by leadership in any way. We want our consultants to have the chance to work on something they're truly passionate about. The only requirement is that the results are demonstrated to leadership to allow us to leverage and showcase great innovations to our customers.

This week we're proud to announce we have created the official Polaris Innovation repository on We've chosen this platform to demonstrate our inventiveness and show it off in a concrete manner. Visitors can see our ideas, the actual code, and the application created as opposed to simply having marketing text claiming that "we're innovative too!"

Our first innovation project is a real-time Emotion Detector. It was built by our very own Jacob Maki using WPF and Microsoft Cognitive Services API to graph emotions in near real time. The UI supports tracking emotions via a webcam and screen scraping the primary monitor, enabling the user to track emotions across multiple video conferencing applications if desired.


Please stop by our Polaris Innovation repository and check it out. And check back regularly for more exciting projects to come.