organizations

Quality Is Anti-Fragile

| Jeremy Brien

As the adoption of Scrum continues to grow,  non-technical people begin to fill the role of Scrum Master or Product Owner. This is a great thing, as it helps the business align with Information Technology. The organization’s IT unit isn’t seen as a service any longer; instead, they become business partners. Conversations break through company silos as Developers learn the business lexicon and Line of Business personnel learn how to build better software. Processes form to create quality. Quality software is beautiful.

Quality Systems Are Anti-Fragile

So what’s quality? It’s one of those things we know we need. But, what are we talking about when we say, “bake in the quality?” There’s so many definitions that exist today, but I like to think of quality as “anti-fragile.”

What do I mean by “anti-fragile.” It’s a concept developed by Professor Nissim Nicholas Taleb in his book called Antifragile. He describes “systems,” whether those systems are processes, organizations, software, or even cultures, that can withstand the stresses of the environment which act upon them. Anti-fragile is much more than “resilient,” meaning it stays the same despite what the environment throws at it. In software development, we strive to produce more with less effort. We strive for business agility. We pivot and adjust our processes as the environment throws things at us and we are anti-fragile. We use feedback loops, like retrospectives, Six Sigma, and Continual Integration.

We give developers freedom and autonomy by giving them “what” needs to be done, they tell us the “how.” Antifragile means being adaptive. Selection of the right tools and technology for the right job — versus prescriptive.

Anti-Fragile As An Analogy

Professor Taleb uses a great analogy in his book. He asks you to picture something in your home that you’d consider “anti-fragile.” This might be something like the remote control for your television or even your sofa. Of course they can break, right? But, they’re designed to take a bit of punishment. They’re designed to conform and adapt as they are used — they are serving a function and withstanding inputs from the environment. In fact, your sofa tends to feel more comfortable over time as it conforms to your body.

Now picture something in your home that you’d consider “fragile.” This might be something like your grandmother’s china or an ancient grandfather clock. They’re usually tucked away in the safest part of the house and are rarely touched. Why? Because we’re afraid we’ll break them. They’re designed to be aesthetically pleasing — serving a function and withstanding stresses from the environment were not considered in their design. These objects are fragile and saved for “the special occasion.”

Beauty In The Anti-Fragile

So what approach should we take to software development? Should we design something that’s large and complex but liable to break whenever a code commit is pushed? When there’s a tight schedule, should we spend our effort designing something beautiful to the eye but doesn’t serve our purposes? No, we shouldn’t.

I contend that there’s beauty in software when it just works. There’s beauty in software when it serves our users and solves their problems. There’s beauty in software when it gets better over time — not when it falls apart.

Thanks for taking the time to read. I’d love to hear your thoughts on quality or anti-fragile. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Related Posts

Improving Agile Retrospectives With SMART Goals

 

Top Secret! Successful Program Management In Government

| Jeremy Brien

Case Study Review: Milestones To Efficiency and The Factors That Influence Program Success In U.S. Federal Agencies

Formal project and program management has not been as diligently applied in government agencies relative to their counter-parts in private industry. This is alarming, as a large percentage of organizations, both public and private, are unable to deliver their projects successfully — “nearly 56 percent of strategic initiatives meet their original goals and business intent” (PMI, 2015). As a result, organizations are “losing $99 million for every $1 billion invested in projects and programs” (PMI, 2018). That’s roughly 10 cents per dollar spent on a project initiative. This article is aimed at summarizing the case study performed by the Project Management Institute (PMI) in 2015. The full case study can be found here.

Using Organizational Project Management — OPM

Just over a third of government agencies report that they “fully understand the value of project management” (PMI, 2015) and this case study examines three Federal Agencies to demonstrate what “successful Organizational Project Management (OPM) looks like in government” (PMI, 2015) in the:

  • Social Security Administration (SSA)
  • Bureau of Indian Affairs (BIA)
  • Federal Aviation Administraiton (FAA). 

Success Factors

While the specific mission and goals of each agency are unique — they all strive to effectively manage their budgets and spend tax payers money wisely, serve their constituents, and adopt and realize the benefits of OPM within their respective programs and projects. Below is a list of the success factors all three agencies report as

  1. Strong Leadership Capabilities: Hands on leadership from program managers effectively support project management activities, better engages stakeholders, and “serves to increase camaraderies and confidence within the team (PMI, 2015).”
  2. Commitment to OPM: Each agency had a subject matter expert (SME) available or leading the adoption of OPM; investment in training and certification made “formalizing principles and practices” (PMI, 2015) much easier and the appetite for change outweighed risk & avoidance. 
  3. Executive and Senior Level Support: Executives budgeted for training and were called upon when their influence was needed to remove project impediments — signaling a “strong sign of commitment to lower echelons” (PMI, 2015) of the organization. 
  4. Effective Training Programs, Ongoing Coursework, & Certifications: Training and experience go hand and hand; critical employees were afforded training and certification opportunities to better serve their constituents.

    “For the team involved in the Bureau of Indian Affairs program, to lower violent crime rates, Indian Country police officers received sensitivity training. This familiarized them with Indian cultures and customs, helping officers to avoid cultural missteps. This in turn helped promote acceptance of the program.”

  5. Transparent and Effective Communication: Regular communication, both formal and informal, were highly effective as they fit the needs of stakeholders and the programs, resulting in “identification of problems that could be pre-empted — reducing the likelihood of escalation” (PMI, 2015). 
  6. Team building and Stakeholder Engagement: Coalesced communication, training, and agency buy-in culminates into shared “understanding and respect among parties, which helps avoid resistance and misunderstanding that can lead to delays” (PMI, 2015). 

Common Obstacles

Each agency identified obstacles that were unique to their programs and mission, however, two common obstacles were identified:

  1. Lack of Understanding: Specifically, understanding the value of a project or program management.
  2. Limited Funding: Resources are finite and government agencies must carefully budget and distribute their funds across multiple portfolios, programs, projects, and operating activities. 

Lessons Learned

The Project Management Institute has not performed a study on the adoption of Organizational Program Management in Government Agencies prior to this case study. The case study servers as a baseline for future research and the impetus for other agencies to collectively learn and increase adoption of OPM.

Lessons Learned By Agency

  1. Social Security Administration: “Project and program career development benefits the entire organization” (PMI, 2015).
  2. Bureau of Indian Affairs: “Project and program management practices can be implemented to fight crime and promote better understanding between police and the community, thus creating efficiency and lowering the violent crime rate” (PMI, 2015). 
  3. Federal Aviation Administration: “Greater reliance on standardization of processes transforms program management at the FAA” (PMI, 2015). 

I’d love to hear your thoughts on OPM or any experience you’ve had with program and project management you’ve seen in government. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

 

References

Project Management Institute. (2014). PMIs Pulse of The Profession: The High Cost of Low Performance 2014. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2015). Milestones to Efficiency: Factors That Influence Program Management Success in U.S. Federal Agencies. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2018). PMIs Pulse of The Profession: Success in Disruptive Times. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

The People And Process Balancing Act

| Jeremy Brien

The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools

There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?

Chinks In The Armor

Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the

storm trooper
Scrum Reveals The Chinks in the Armor

new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”

The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.

As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.

People Dependency

Pros

  1. It gives workers satisfaction – employees feel satisfied when they know they are valued
  2. Flexible – employees are empowered to perform work in the way they feel is best
  3. Adaptable – the ability to pivot and make changes is the hallmark of business agility
  4. Efficient – unnecessary steps in a process are avoided
  5. Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job

Cons

  1. Less repeatability – changing processes are not repeatable and leads to waste
  2. Makes customers nervous – customers feel comfortable when there’s visibility on the process
  3. Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
  4. Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
  5. Higher risks – for the reasons listed above

Process Dependecy

Pros

  1. Repeatability – repeatability helps with predictability
  2. Easier to improve – a documented process is easier to improve with less risk to the organization
  3. Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
  4. Predictability – it can be measured objectively and relied on as a lever for control in the organization
  5. Brings new personnel up to speed faster and with less risk of poor performance

Cons

  1. Paperwork can overshadow the task – processes that are overly complex distract from value added work
  2. Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
  3. Someone must own and manage the process
  4. Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste. 

Processes Come First But They Should Not Be Valued

I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.

“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”

— Arthur Quiller-Couch,

On the Art of Writing

vintage scale.jpg
People and Processes Are Not Equal

I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.

Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.

Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Improving Agile Retrospectives With SMART Goals

Six Elements of An Effective Strategy

 

 

 

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum.

| Jeremy Brien

The 5 P Pyramid Model.

I recall my first software development project as both exciting and nerve racking. Luckily, I was paired with an extremely talented Business Process Analyst who’s approach to requirements gathering was both methodical and like watching an artist at work. He introduced me to several ways of thinking about organizations — what I now call the 5 P Pyramid Model. This model has helped me analyze business processes and has been a wonderful tool for change management and exercising business agility. I continue to refine his ideas and accumulate my own knowledge, however, I would like to share his lessons with you by using the Scrum Process as an example.

“When eliciting requirements or attempting to document information from your stakeholders, keep the following items in mind:

The 5 P Pyramid Model
  1. Policies,
  2. Processes,
  3. Procedures,
  4. People, and their
  5. Personalities”

Policy

Policy is about understanding the landscape you operate in and those affected by your decisions. Policies guide decisions and provide rationale for their existence. Well written policies describe the what — they do not describe how an organization will fulfill the requirements of the policy. Generally, you can bucket your policies as external and internal. Internal policies also have two characteristics: De jure and de facto.

  • External policies are the laws and industry standards your organizations must adhere to. These include international, federal, and state laws you must adhere. In the case of Scrum, a government agency has policies regarding purchasing. Here is a great article regarding public-sector purchasing using Agile.
  • Internal policies are the policies related to the organization’s vision, mission, and goals. Whether undergoing business projects or internal IT projects, policies regarding how products and projects are delivered also exist. In the case of Agile, an organization’s policy describes the use of iterative and incremental development techniques vs. gated and sequential development.
    • De jure internal policies: Have been formally evaluated, approved, and adopted by the organization. Usually, they are easily accessible, understandable, and “written in stone.”
    • De facto internal policies: Have been widely adopted and accepted by the organization, however, they are not written and documented — leaving room for interpretation. Finding and documenting these policies can be difficult. At times it can feel like you’re on a journey to find the tribal leaders who can teach you the “song of the tribe.” It becomes increasingly difficult to find the tribal leaders to teach us their “songs” as more people retire and the trend for job hopping continues to grow.

Process

Business processes are the high level activities that an organization accomplishes in order to fulfill policies. They can and should be analyzed at different degrees of resolution. Think about the saying, “Give me the 30,000 foot view” vs. “At the ground level.” They should be assessed and dropped into three different categories:

  1. Operational processes are the processes related to an organization’s value chain. They are the core business activities that organizations engage in to deliver their goods and services. Using the processes that our Scrum teams use, we can see that the Sprint Review and Pushing Code to Production directly add value to our customers because this is where our stakeholders review and accept the code (sprint review) that was developed during the iteration and the delivery team makes it available to for use (delivery of shippable code).
  2. Supporting processes are the secondary functions that exist within the organization. They support the core business processes but do not provide value to the customers directly — Sprint planning and the daily scrum is where our delivery team plans what will be worked on (planning) and discusses the work being done over the past 24 hours to address any impediments to meeting the sprint goals (daily stand up). 
  3. Management processes help coordinate the operations and supporting processes. They drive for business efficiency and success. The sprint retrospective is used by the delivery team to inspect and adapt their daily work to improve efficiency and product backlog grooming is for prioritization, addressing dependencies, and writing effective user stories before the next planning meeting.

 

Scrum Process Diagram
A 30,000ft view of the Scrum Process

Procedures & People

Procedures are the steps that need to occur in each process to reach desired outcomes. They are normally fulfilled by a combination of people & technologies and are sometimes referred to as standard operating procedures. Let’s look at the procedures in our Scrum processes as an example and identify the people involved.

Sprint Planning
  1. Scrum Master: Opens the planning session, sets expectations, announces the agenda, and enforces a “time-box” throughout the planning session.
  2. Product Owner: Presents a prioritized and groomed product backlog to the Delivery Team and states what business objectives the stakeholders want attention during the iteration.
  3. Delivery Team: Examines the high priority user stories, asks clarifying questions with the Product Owner, identifies potential risks & dependencies, and helps refine acceptance criteria.
  4. Scrum Master and Delivery Team: Reviews the velocity from the last few iterations and plans their capacity for the coming sprint.
  5. Delivery Team: Uses relative estimation to size the user stories.
  6. Delivery Team: Uses their past velocity to benchmark how many user stories should be responsibly committed to.
  7. Product Owner and Delivery Team: Finalizes the Sprint Goal together.
Daily Scrum (aka. Daily Stand-up)
  1. Scrum Master: Ensures the meeting occurs, ensures no management interference on the free flow of information and discussion, and enforces a 15-minute “time-box” on the Daily Stand-up.
  2. Delivery Team: Conducts the meeting and discusses the progress towards the Sprint Goal.
  3. Product Owner: When available, attends the meeting to answer questions for the Delivery Team and makes decisions when needed.
  4. Scrum Master: Makes notes of any impediments that the Delivery Team is facing and immediately takes action following the Daily Stand-up to resolve impediments.
Sprint Review
  1. Scrum Master: Opens the Sprint Review, sets expectations, announces the agenda, and enforces a “time-box” throughout the review.
  2. Delivery Team: Presents their work in accordance with the acceptance criteria agreed upon during the planning meeting to both the Product Owner and any stakeholders invited to the meeting.
  3. Product Owner & stakeholders: Once the Delivery Team has finished presenting their work, the Product Owner and stakeholders are invited to ask clarifying questions and interact with what was built.
  4. Product Owner & Delivery Team: Takes notes of any issues, risks, or concerns from the stakeholders related to what was built or will be built in the near future.
  5. Product Owner: Accepts or Rejects each user story the Delivery Team worked on during the sprint.
Delivery of Shippable Code

Teams and organizations have their own way of pushing their code into their production environments. Due to the various best practices that exist, a separate blog post will be posted to address this at a later time. Seriously! This could be a ph.D thesis!

Sprint Retrospective
  1. Scrum Master: Facilitates the meeting, enforces a “time-box” and “sets the stage” –all information shared during the Retrospective stays within the meeting. I call this the “Vegas Rule” because what happens in Retro stays in Retro.
  2. Scrum Master: Starts with an ice-breaker if the Delivery Team is new and reviews past velocity with the team. The Scrum Master may also reminds the team of all the impediments that occurred during the sprint if the Delivery Team faced any during the sprint.
  3. Scrum Master and Delivery Team: The Scrum Master facilitates “Data Gathering” activity and the Delivery Team produces the data.
  4. Scrum Master and Delivery Team: The Scrum Master facilitates an “Insight Creation” activity and the Delivery Team creates the insights.
  5. Scrum Master and Deliver Team: The Scrum Master facilitates a “Prioritization” activity and the Delivery Team prioritizes what they want to improve.
  6. Scrum Master and Delivery Team: Decides how they will improve their own processes (either operating, supporting, or managerial processes) and creates a realistic plan to execute on. Scrum Master may need to coach new Delivery Teams about developing SMART Goals or some other goal setting techniques.
Product Backlog Grooming
  1. Product Owner: Prioritize the Product Backlog based on business objectives.
  2. Product Owner and Scrum Master: Gathers the requirements from stakeholders and writes preliminary User Stories and Acceptance Criteria
    • User Stories: As a <some role or person>, I want to <some procedure>, so I can <achieve a business outcome>.
    • Acceptance Criteria:
      • Functional
      • Non-Functional
      • Performance
      • Security
  3. Product Owner, Delivery Team, Scrum Master and invited stakeholders: Scrum Master and Product Owner facilitates an activity for the stakeholders and Delivery Team to refine the user stories and acceptance criteria.

Personalities

The personalities of our employees influences their effectiveness for their role(s). Selecting the right people with desired personalities ensures that the procedures and processes are completed correctly and in a manner that matches the organizational culture. While I won’t go into the different “types of personalities,” I will speak to the types of characteristics and traits that make an effective Scrum Master, Product Owner, and Delivery Team member.

  • Scrum Master
    • Ability to coach others with empathy.
    • Ability to resolve conflict and communicate with empathy.
    • Deep understanding of Agile and Project Management.
    • Facilitation skills and creativity.
    • Servant Leadership.
    • High level IT skills and knowledge.
    • Business acumen.
  • Product Owner
    • Strong leadership.
    • Ability to prioritize work and competing demands.
    • Ability to make decisions independently.
    • Ability to gather business requirements and elicit information from stakeholders.
    • Understanding of Agile and Project Management.
    • Domain knowledge.
    • Tactful communication skills.
  • Delivery Team Member
    • Ability to work well with others.
    • Openness to coaching.
    • Strong communication skills.
    • Strong technical skills.
    • Ability to analyze and solve problems.
    • Honesty and integrity.
    • Understanding of Agile and Project Management.

I’d love to hear your thoughts on the 5 P Pyramid Model in the comments below or if you’d like to have a discussion about Business Process Analysis, please contact or connect with me on social media!

Photo Credit: Flickr

Related Posts
For more on:

 

 

Agile Leaders Understand Customer Service And Culture

| Jeremy Brien

Transforming A Culture Is No Easy Task

Developing a strategic plan to promote internal and external customer service is no easy task. The role of organizational culture, the forces effecting the culture, understanding who the internal and external customers are, and identifying the key objectives required for effective customer service will help an organization meet specific goals: Develop an internal customer service culture, effectively train all employees who interact with the external customers, provide information to customers that is useful and relevant using the communication methods they desire, and developing or enhancing a means to follow-up with customers.

What Is Culture And The Forces Of Influence?

A corporate culture “refers to the beliefs and behaviors that determine how a company’s employees and management interact and handle outside business transactions” (Investopedia, 2017). Culture is usually implied and not specifically ‘defined’ – as it organically evolves over time and accumulates traits based on whom the organization hires, it’s dress code, office setup, benefits, turnover, and client satisfaction based on operations or the artifacts the organization produces.

Aristotle said, “We are what we repeatedly do.” In general, his view indicates that repeated behaviors or habits are the core of a culture. What people feel, think or believe are the perceptions and ultimately the forces shaping our behaviors.

It is important to direct our efforts and identify the forces that shape our behaviors within our organizations and their relation to customer service. Describing the current and desired forces will assist with accurately capturing the thoughts, beliefs, and perceptions of the organizational structure and the incentives that deliver positive customer interactions by cultivating the desired culture of customer service.

Define The Customers: External vs. Internal

The distinction between internal and external customers isn’t always clear, however, we will can use an academic perspective for the purpose of this discussion.

External Customers look to “exploit artefacts[sic] produced by the organization with specific requirements and specifications” (Hobbs, 2016). External customers are essential to the success of the organization as it operates to produce the artifacts specified by external customers.

Internal customers are all members of the organization who rely on assistance from each other to fulfill their duties in the production of artifacts specified by the external customers.

Forces Of Influence And Customer Satisfaction

Customer satisfaction doesn’t start with the customer. It starts ‘in-house,’ with the employees, incentives, and programs within the organization. Employee recognition programs, cultural expectations set during on-boarding, opportunities for training (both formal and informal), competencies measured during appraisals, and policies are all forces that influence the organization’s culture and affect customer satisfaction.

Agility Starts Start At The Top

An organization’s leadership team must set the tone and embody the practices themselves. It’s not about setting expectations – it’s about ‘practicing what they preach’ and treating employees the way they want the customer to be treated. Additionally, leaders “must make the measurement of service quality and feedback from the customer a basic part of everyone’s work experience” (Morrow, 2000). The Agile organization embodies these beliefs because the leadership is passionate about practicing what they preach. Leaders set the tone. 

Agile Organizations Hire For The Culture

Organizations like Zappos, a leading online retailer for the shoe industry, is well known for starting with a “cultural fit interview, which carries half the weight of whether the candidate is hired” (Patel, 2015) by offering $2,000 to quit after the first week of training if the candidate decides the job isn’t for them. Zappos instills their ‘ten core values’ on each of their employees and dedicates a portion of their budget to employee team building and promotion of its values and culture. The idea is, when the organization gets the culture right, great customer service and brand recognition will evolve organically on its own. Agile organizations are infectious with their values.

Additionally, it may be necessary to remove any employees who do not show the behaviors required to foster positive customer interactions. Often, organizations allow employees who work with external customers to remain on the job when they are not suited for the position. “If employees don’t want to serve the customer in the best possible way, document their behaviors and use the information to help them change or to move them from areas away from interactions with external customers” (Morrow, 2000). It only takes one bad apple to ruin the bushel.

Agile Organizations Invest In Training

Formal training in customer service is a good starting point, however, organizational leadership should reframe its’ thinking and recognize that training extends beyond a mandatory class taken once a year. Training employees, again, is a top-bottom approach. Organizational leadership, managers, and supervisors should always be training their employees, offering guidance and coaching each other and their subordinates on a continual and iterative basis relative to informal or formal training initiatives respectively.

Agile Organizations Effectively On-board New Hires

Effectively setting expectations and training employees starts with the organization’s on-boarding process. On-boarding new hires is the organization’s first opportunity to set expectations, provide examples of excellent customer service observed by past and current employees, and explain how the culture affects customer service in the respective industry.

Agile Organizations Evaluate Performance And Customer Satisfaction

Work Performance Standards and employee performance reviews are another opportunity to evaluate the effectiveness of the organization’s customer service initiatives. When employees are appraised on customer satisfaction as part of their work performance standards, they will be motivated to meet and exceed customer service standards as they are clearly measurable and defined. Performance reviews provide feedback to the employee regarding their competency in customer service within their organization and helps align the employee with the expectations, standards, and behaviors that are expected within the culture. “Using customer satisfaction as a measure of on-the-job success is one of the surest ways to guarantee great service” (Johnson C., 2015). What gets measured gets done.

Agile Organizations Provide Opportunities For Growth

Providing exceptional customer service to every customer every time is an unreasonable expectation – no one person is fully equipped to know the best possible solution that fits a customer’s needs in the best possible way. It’s important for leaders to recognize that mistakes do happen. However, addressing these mistakes and making them opportunities to learn not only helps the employee grow and gain improved competencies in customer service, but improves the organization’s overall readiness to meet similar challenges and issues experienced when addressing customer concerns or demands. Transparency is the key to success when mistakes are made, though they should be handled tactfully so as not to embarrass the employee or customer(s), as they help all members of the organization learn from the mistakes made so as not to repeat them.

Agile Organizations Encourage Ownership Of The Issue(s)

Employees that feel empowered to make decisions will take ownership of the issues challenging internal and external customers. Conversely, employees who worry about job security protect themselves first. When employees feel insecure about their jobs, they will hesitate to take ownership of issues. When shaping an organizational culture, it is important for employees to feel trusted and empowered to make decisions regarding the issues faced by customers without fear of repercussion.

Agile Organizations Develop Policies That Encourage Empowerment

Establish policies that are customer-centric and show concern for customer needs. Eliminate “routine and rigid policies and guidelines and strive to be an organization that is easy to do business with” (Morrow, 2000). Customer service is not the sole responsibility of the Customer Service Department; it is an organizational effort and policies that facilitate this empower all employees to deliver exceptional customer service.

Agile Organizations Reward High Performers

Reward employees for the behaviors you wish to cultivate. Cash incentives and bonuses are great, however, there are other ways to let an employee know they have done a good job. Extra time off, an article in the organization’s newsletter, a trophy awarded at a recognition dinner, tickets to special events, or even hand written notes are ways to reward behaviors you wish to see more of.

Identify the Objectives of Customer Service

The organization should identify the primary objectives in customer service. Below are some quantitative and qualitative examples that can trickle into an employee’s work performance standards and performance reviews.

  1. “Determine whether the organization is providing a satisfactory service to its customers” (West, 2017).
  2. Confirm that the requirements of the customer have not changed
  3. “Individual Customer Service Performance” (Vulpen, 2017).
  4. “Employee Satisfaction” (Liebenberg, 2004).
  5. Provide your organization with an objective evaluation of customer satisfaction and/or dissatisfaction.
  6. Level of knowledge of the problem(s).
  7. Identify areas for improvement.

Organizational Culture is difficult to define, however, recognizing the forces that influence your culture will aid in its’ refinement. The best culture makes all employees feel safe and welcome and it should grow organically to fit the needs of external and internal customers alike. It should be adjusted if it causes the organization to end up with homogenized employees who think and act the same. “Trust in your employees goes a long way towards a positive organizational culture, because trust leads to independent employees who help the organization grow” (Patel, 2015).

Share your company culture by leaving a comment or connecting with me. Follow me on social media and let’s have a conversation.

Photo Credit

Sources

Hobbs, B. &. (2016). Projects with internal vs. external customers: An empirical investigation of variation in practice. International Journal of Project Management Volume 34, Issue 4, 675 – 687.

Investopedia. (2017, April 11). Corporate Culture. Retrieved from Investopedia: http://www.investopedia.com/terms/c/corporate-culture.asp

Johnson C., R. (2015, July 8). 5 Ways Corporate Culture Affects Your Customer’s Experience. Retrieved from smallbizdaily: http://www.smallbizdaily.com/5-ways-corporate-culture-affects-customers-experience/

Liebenberg, J. &. (2004). Factors Influencing a Customer-Service Culture in a Higher Education Environment. Journal of Human Resrouce Management Issue 2 (2) , 1-10.

Morrow, P. (2000, August 2). Eight Keys to Creating a Customer Service Culture. Retrieved from Inc.: https://www.inc.com/articles/2000/08/20028.html

Patel, S. (2015, August 6). 10 Examples of Companies with Fantastic Cultures. Retrieved from Entrepreneur: https://www.entrepreneur.com/article/249174

Vulpen, E. V. (2017, January 4). How 11 Factors Influence Customer Service Performance. Retrieved from Analytics in HR: https://www.analyticsinhr.com/blog/factors-influencing-customer-service-performance/

West, K. (2017, April 13). Customer Satisfaction Surveys and Your Business. Retrieved from National Business Research Institute: https://www.nbrii.com/blog/customer-satisfaction-surveys-and-your-business/