How to Change Your Organization’s Culture

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

How do we change the culture around here?
During a Q&A session this week, after a presentation containing touch points of a future vision, a team member asked me the culture change question. “How do we enact cultural changes here?” The question implied an agreement with the future vision, but acknowledged the challenges cultural changes require to move away from old habits.

I love the question because it gets at the heart of attitudes, customer service, brand, and leadership within a business. It’s gets to the challenge of winning the hearts and minds of the people. Changing a culture is no easy matter. Shawn Parr of Fast Company describes why Culture Eats Strategy and just how culture is a pillar of an entire organization. The greatest strategies in the world will fail if they don’t influence the right cultural mindset of the employees of the organization. cultural change

People will change if they see the value and benefit.
My answer to the question centered around value. It’s the same concept as sales. A sales transaction takes place when both parties see a value in what they are receiving. In an organization, people will rarely change behaviors if they don’t see, understand, and desire the benefit it will bring.

Expressing value is part of leadership. If people get your vision they will want to follow. One of the roles of executive management is to create the context within which the culture of the organization is built. It’s a people thing.

But we are talking about values, assumptions, and behaviors.
No one gets up in the morning with a goal to not do their job and not provide service to their customers. But there are many factors which affect our ability, willingness, and desire to deliver superior service. It’s not easy. This Wall Street Journal article discusses a more systematic and incremental approach to change an organizations culture. If you have read any of my other writings, you’ll know I’m a big proponent of incremental changes to reach a goal.

The bottom line is we are talking about people. People make the culture. The processes, beliefs, values, etc. are a means to the goal. But the culture of an organization lives in the minds and hearts of the people. If they believe in the culture that management wants then they will execute it. So the “how” is not so much about changing organizational layout, processes, and managers. It’s about winning the hearts of the people by showing the value and reaching the heart level.

(photo credit: www.stage2planning.com)

Fighting the headwinds and riding the tailwinds of business

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

Yesterday I ran my first half marathon race. The temperature was in the low 40s with winds 10-15 mph. The course layout was a four lane divided highway. We ran half the race length and then turned around and ran back up the other side. As luck would have it, the first half of the race was into the wind and second half was with the wind at my back. So you can imagine how happy I was to turn the corner and head back in the opposite direction. It was a big sling shot effect. Run The Reagan Half Marathon

I didn’t wear a music device during the race, so it was me and my thoughts. The headwinds I faced in the first half of the race had me at about a 8 minute per mile pace.  The struggle against the wind made me think of business headwinds that impede progress. In my career experience headwinds have been caused by market factors and the backside of a product life cycle that lead to year-over-year declining volumes. This type of headwind pressure erodes units and revenue so businesses must innovate to create new products or solutions.

Business has only two basic functions: marketing and innovation.” Because the purpose of business is to create something of value — that’s innovation — and then to share it with the world and inspire customers to buy it — that’s marketing. – Peter Drucker

Innovation isn’t easy, but when we get it right and can market a product or solution with success that becomes our tailwind. When I turned the corner in my half marathon race yesterday my pace quickened aided by the push of the wind. I finished the race with a per minute pace well below the 8 minute per mile pace I had in the first half. In business, when we have a market opportunities that give us success (tailwinds) we have to make sure to stride appropriately to take advantage of the situation. That may mean making adjustments to processes, organizational layouts, suppliers, or equipment to take advantage of the tailwind.

Oh by the way, my time was 1:45:49. Better than I expected!

2 Server Patching Approaches

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

Server patching is one of those infrastructure tasks that most business owners and infrastructure managers don’t link to the eCommerce portfolio. Operating system patches, virus scanner updates, database patches, etc. are all system level software not directly related to the code line of the eCommerce team. Infrastructure managers can certainly create a patching strategy independent of the eCommerce development process, but I like two methods that keep the current version of eCommerce code in the forefront to help minimize risk and make the patching process more efficient.

1. Follow code line promotions

The premise behind this approach is to install and promote server patches in same sequence of non-production environments as the code line increments. So for example a shop might have an environment sequence for code something like this:

Development ⇒ QA ⇒ Beta ⇒ Production

Let say there is a code release version 2.2 that is currently in development. Then as version 2.2 is deployed in sequence to each environment the infrastructure manager would additionally apply all new patches.

The advantage to this approach is that as the code line is tested in each environment the patches are part of that testing. This prevents the team from having a duplicate testing event just for patch validation and should provide a more thorough set of testing before production deployment. Testing patches for potential system incompatibility is always the biggest risk to production deployments. So this approach tries to mitigate the risk by having it tested by various groups in different environments.

A disadvantage to this approach is that the need for server patching may arise independent of the release schedule. Emergency vulnerability patches may arise due to a hacker exploit or some other industry event.

2. Snapshot and test

The idea of this approach is to make a copy of the environment that you will patch and then install the patches to the copied environment. The test team will then validate that there are no code incompatibilities by testing against the new environment. Once approved, the infrastructure manager can promote the patched environment to production or patch the original production environment.

The advantage to this approach is that it can run at intervals independent of code releases. That could be useful if there is an emergency vulnerability patch and the next code release isn’t scheduled for production deployment for another four weeks.

The disadvantage to this approach is that it requires more administrative overhead and management. Depending on how it’s executed you could duplicate tasks. Additionally it creates a separate testing event for the validation team that is independent of the normal test validation associated with code installs.

In practice, it may be best to use both approaches. Following code line promotions is a risk mitigation approach that doesn’t duplicate testing efforts and would work for a routine patch update schedule. The snapshot and test approach works for off-cycle patches that have a more urgent requirement for deployment.

Crossing departmental boundaries with your eCommerce team

This is my 300th blog post!

So much is written about the strained relationship between IT and other business departments such as Marketing or Sales. Both departments want to achieve the same goal of creating a service for the customer.  Both departments want to be predictable in their service delivery. But they define predictability differently which is the basis for friction and a strained relationship.

For an eCommerce team the boundaries between departments are often strained because of estimated work effort, estimated costs, volume of work produced, and the velocity of work produced. Unfortunately all of these take the focus of the relationship away from the true goal to produce working software that provides a valuable solution to the customer (one in which the company should make money).boundarycrossing

Here are a few techniques that I have found to be valuable when approaching relationships with other departments in the business. Remember to always turn the conversation back to the ultimate goal.

Deliver smaller work units according to a regular cadence.
Build confidence by showing incremental progress towards solution delivery. The big bang approach to software delivery keeps the internal customers in the dark about how the final solution is progressing and creates a longer period of time before the customer can begin to use any of the solution.

I hear IT people say that it is tough to get business people involved in the process defining requirements. So I advise breaking the work into smaller units of work or a subset of the larger group of features. Show progress towards the goal and transform the discussion with the business owner to one of results rather than waiting. Business stakeholders are more open to conversations and supportive when they see progress along the way.

IT won’t be able to solve all the incoming requests.
Somewhere along the course of time the business units developed an expectation that anything they request will be completed and IT, or a smaller group like eCommerc, automatically assumes they must complete every request. But let’s face it, there are always more requests and ideas than the eCommerce team can implement. This is what leads to product roadmaps and backlogs.

Many people view IT as a large cost center to the business. Technology capital and labor is expensive. So shouldn’t the business want make sure that the team is working on items that will provide a return?  Let’s be real. Sales and Marketing are not able to solve all requests they get either, and many cases work with customers for work-arounds and alternative solutions.

Get agreement to this concept from department heads so that expectations are clear. Then get the department heads to be involved in the process of what work has the best forecast to move everyone towards the goal of returning investment back to the business. Mutual involvement, risk taking, and reward sharing is key.

When possible visit them in-person.
Strong Relationships are built in-person. When I want to discuss the priorities, schedule, or work-in-progress of the team I try to pay the business contact a personal visit. Yes, that means getting up and walking away from desk. It means not trying to live my business life completely in email. My experience is that the spoken word helps to achieve cohesion and unity with the business contact. It creates more of a bond and a feeling that you are solving the puzzle together.

Conflicts can be unlocked by finding your common goal.
Conflicts and differences of opinion are inevitable. There are many ways to solve conflicts but to create a good cross collaborative approach we need to focus on the common goal. For eCommerce teams and business owners that is to produce working software that provides a return on the investment (make money!).

I like the evaporating cloud technique for solving conflict. Answer these questions:

1. What do I want? What do they want? (precisely verbalize the conflict)
2. What need do I have that causes me to insist on that want? What need do they have that causes them to insist on their want?
3. What is the common objective?

Example:
The Conflict

  • Business – Get valid estimates upfront
  • eCommerce Team – Give valid estimates after all requirements are given

The need

  • Business – Give the customer feedback when the request can be completed and for what cost
  • eCommerce Team – Provide the best quality by knowing all of the requirements upfront

The common goal

  • Produce working software that provides a solution to the customer and return to the business.

Then challenge the assumptions in the middle and find ways invalidate the assumptions which will produce ways to break the conflict.  From my example, does the customer expect that the full project will be delivered in one piece? Can the customer take delivery in multiple pieces? For the eCommerce team does the customer know fully what they want and can they articulate it upfront?

At some point in the process an assumption may be proved false which will provide a way to unlock the conflict.