Tagged: Management

Maturing from a StartUp to a StartedUp culture – Series Part 5

People growth – Old blood vs New blood

I wrote my first post here on Jan 23 2011 and that post was titled “Startups – importance of your team“; Its been a little over 2 years since I wrote that post.

Most of us work 5 days a week, putting in about 8 or so hours a day (we will stick to the average/norm here). We come back home in the evening to spend anywhere from 1 to 4 hours with our family/friends.

When friends and/or acquaintances form a startup, the long hours and the close working relationship build on existing relationships and everyone at the startup works as a “family”; but what happens when there are no existing relationships? or what happens when you already have a family and someone new tries to come in? Wouldn’t it be awkward if you were out with your family/friends and a stranger joined your group and just hung out? would you be your self? most wouldn’t.

So how do you take an existing family (a started up culture) and add newer members to it? How do you mix the two so that you do not end up with friend circles?

I have 4 simple attitudes/behaviors that I build my base on:

“We are not that different”.
The new member see’s a whole new planet, different people, cultures, processes, jargon, etc. The first step should be to look for similarities between what they know and what they should know. For my teams I use a buddy system and its usually the previous newest member who buddies up with the new member. They go over materials, documenting anything new that might come up, go for lunch, talk about process, go through the who’s-who, engage the new person in conversations with the other team(s); they try to get to know this person as if they were dating each other.

“We got this, lets work on it together”.
How do you start work? where do you start? who do you ask? Scary questions for someone looking under the hood of something they do not understand. Here is where the buddy comes in again; during stand ups and sprint planning the buddy might offer “we can work on this together”, or someone else on the team might say “hey this is a good problem for me to show you how xyz works, and we can solve it”… they get the knowledge, they figure out how to start, they experience the process and they know how to close it. Build trust and accountability.

“Your team mentioned that you are catching on so quick, what can we improve?”
Over communicate reinforcement of team acceptance, ask for ideas on what can be improved, engage the new member; engaged employees have ideas and feedback that they want to share, things they have questions about.

“You are doing great, let me share my vision on how you play an important role to the team”
Setup a growth plan that’s challenging and communicate that it may be challenging and track to it. I like to plan for the 1, 3, 9, 12 and beyond and use data obtained directly or through peer feedback to gauge fit; if there is going to be tissue rejection, you need to act fast and figure out what you need to do to make it work successfully.

These 4 steps get you on track but you will still need to build additional on-boarding processes (around material and core knowledge ) that will grow the employees product knowledge. Its also important to keep your existing members in mind when you optimize culture as you want to grow the existing employees as well and not just the new ones.

At the end of the day it helps if we recognize that the teams we work with are more than just “Random people”; they are people we spend several hours with, they are friends, people we trust, can openly collaborate with and people we want to continue to work with.

When one finds a team they can work with for the rest of their life and can call family, its no longer “work”…it’s just a large friends & family gathering where they just happen to be working on something together and having fun.
We should all build and be part of such teams.

Advertisement

Maturing from a StartUp to a StartedUp culture – Series Part 4

The takeaway from the previous post on KPI and metrics was that we should proactively monitor process and optimize as needed; just because it worked when you were a startup does not mean it will work when you are “startedup”, you will need it to scale and by capturing metrics and KPI’s you will be able to perform analysis when/if  things go wrong. This however does not mean that you need process for the sake of having process or that you should focus on process over people; agility is important and being lean goes a long way.

The chicken and egg problem: What came first, the chicken, or the egg?
You have great team(s) and you have great product(s). Your team(s) is/are at capacity enhancing and maintaining the current product(s), but you need to create more product(s). In order to grow product(s) you need to add more people but these people need to be grown as well. Hiring people and not growing them will make product growth challenging as there will be a longer ramp up time or will disengage and leave (or you end up with an us vs them culture); and redirecting your current team to grow people rather than the current products will grow the new hires at a rapid pace but your current products will stop growing, what do you do? going back to the chicken and egg problem, I think in the long scheme of things it is irrelevant what came first; what is more important is the realization and existence of the chicken and egg, or the “idea” of a chicken and/or an egg, and that you need to ensure that the cycle continues, chickens give eggs and eggs (eventually) give chickens.

Single points of failure (Single Threads)
As engineers and architects we focus on identifying single points of failure within architecture; as managers we need to identify single points of failure within team members, processes and tools. Ask yourself, if I was to randomly start pulling people out (pto, resignations, etc) what would be the impact? Would we still meet delivery? Do we lose key subject matter experts? Most of the time people end up becoming single threads because there are many hats to wear and things need to get done; documentation and knowledge transfer becomes a “will get to it” task that many never get to.

Single points of failure and knowledge silos end up becoming a real impact to growth when you bring on new hires who need to be brought up to speed and grown because the same resources that need to help grow others are already busy with their existing work. Not only does it impact growth, it also negatively impacts collaboration and team culture, when people do not grow they disengage and this causes further issues. As you grow from a startup company with a smaller team to a “startedup” company with a larger and growing team, your single points of failure can grow and teams/members can get frustrated as they get pulled from different directions.

A few simple approaches to reducing and/or eliminating single points of failure are:

  • Focus on collaboration and knowledge sharing among teams (culture), the more people share what they learn the more people know.
  • Work-load for single threads can be split between product development and people development.
  • On-boarding programs and training documentation can be built as part of a product backlog.
  • New hires can be paired with senior resources to create mentor-ship and knowledge transfer programs.

Each organization is different and each has its unique attributes that require a solution or several approaches that solve the problem for that specific organization; a silver bullet approach doesn’t really work.

Summary

  • To grow new product(s) outside your current capacity you need to grow team(s).
  • To grow new team(s) who will grow new (products) your current team(s) can be impacted.
  • Your current team(s) can end up becoming single threads and/or single points of failure.
  • Recognize that this can become a problem.
  • Focus on culture, collaboration,  knowledge transfer, documentation, etc. so that the impact to the current team(s) and product(s) will be minimal and your new team(s) will rapidly grow and be engaged.

Maturing from a StartUp to a StartedUp culture – Series Part 2

The Startup and the 3 P’s: Product, Process and People

I will not pretend to know everything about startups and startup culture, but I will list the reasons why startup culture is exciting, at least for me:

You meet great people, people who have ideas and want to try things, people who have passion and want to make an impact, people who will challenge you to do better. There is passion for working together as a team, passion for building trust within the team and passion for collectively making an impact in other people’s lives; or sometimes, passion for just making something happen – to create. There is passion for possibly creating something that could go big – disrupt everything, all built from the ground up with the teams sweat, blood and tears where everyone is high on adrenaline. Suits? Offices? As long as you are connected with your team and are working well together, those things don’t matter. There is no red-tape, or big top-down structures, everyone and anyone has access to all. Anyone can start working on anything, there are many hats to choose from; wear all. You don’t get bored as things are evolving and stay fresh, there are new ideas, old ideas, odd ideas; anything can change anytime.

At the end of the day, a startup is defined by its growth; when a startup doesn’t grow, it dies; it stops.

There can be several growth stages for a startup, and startups evolve; once they start growing they are now “startedup” and will hopefully grow exponentially. In a perfect world, the cultural values that made the startup fun would remain and in some cases they do (depending on where the growth has lead the startup) but there are times where the culture itself that helped the startup grow and evolve starts conflicting with what is needed to grow to the next level.

Product Growth
Let’s say you follow agile and you end up with iterations, planned work, release schedules and a clear pipeline of what needs to be built. This all worked great when you had 2 products and a team of 10; since you have grown, the expectations of what you can or will deliver have also grown. Some brilliant folks in your team have discovered 2 more products that should be added to your portfolio; how do you grow your current 2 products (since they have a feature and defect backlog) and also work on these 2 new products without increasing your team size, changing delivery for current products or burning out resources? Before you grew, you may have had your own expectations of when and how you would bring on these two new products; now that you’ve grown, others may have different expectations from you and your team(s). Maybe you say “we need more people”, which brings me to the next point

People Growth
With the growth of the startup, either through sales, funding or more investment and the need to create more product it is decided that you bring on more people, and you do. You end up facing the same issue, how do you grow people with the same 10 resources you had who are busy working the two existing products; some of the people you bring on may be self-starters and will figure everything out by themselves but what about the ones who don’t? So now you say “we need some process and automation to free up some of the manual work so that we can do more with the same resources”, which brings us to…

Process Growth
How do you focus on process and automation to free up time when the people you have are busy with supporting the existing two products, or are supporting the existing two products and are also trying to bring the new hires on-board?

A part of me says that the above three growth challenges are not really challenges and that they are part of what it means to be a startup culture and are expected. However; there are a few by-products that the 3 P’s create that can become toxic, stop growth and hurt the culture if they are not accounted for when trying to grow.

The Frat party & the first team
The first team consists of the people that built the startup; it was their teamwork and effort that made the startup grow; anyone who comes later is an outsider and “we need to be careful about who we let into our frat party” (once upon a time I lived on frat row). This one is not intentional, but when you work closely in teams and blur the line between friendship and co-workers, you end up creating an inner circle and make it challenging for an outsider to easily integrate and feel welcomed. This by-product is a blocker for People growth.

The golden simple process
At some point there was predictability and little chaos in what all needed to be done (smaller team, less products) so everyone starts expecting things to always be perfect. Even though you have grown, you have kept your process simple and did not optimize for KPI’s and other metrics that can help with predictability, complexity, risk and estimation. There will be times where things change, dates get reset and/or product scope creeps. If you had built a roadmap of what releases when, had committed the teams to that and put all these releases with their iterations back-to-back (because of all the product that had to get pushed out to show growth and maturity) and dates or requirements change on you (usually not for the better) the team and its happy culture will get disrupted as it will take effort to get things back on track; when/if this happens all the time, it gets hard to get away from the domino effect and people burn out, get disengaged and/or leave. This by-product is a blocker for Process growth.

Single threads
When you were small, everyone knew what everyone else was doing, everyone shared and individuals had their skillsets. Now you have grown, 2 months ago you were 10 people, today you are 75, the 65 newer ones don’t understand the code base or the original design, there is some good documentation but they need more information and there are 3 key people who know different things about the original products; original products that you want the new 65 people to work on so that the first team can work on the two new ones; how do you distribute the knowledge known by the 3 key people, make them available to the 65 and allow the 3 key people to focus on their new projects? If they are constantly being pinged by others and cannot get their work done; their sense of accomplishment doesn’t scale much; especially if you did not plan for them to set time aside and help others. This by-product is a blocker for Product growth.

Each blocker is situation (just like leadership) and can be solved; we will examine and solve for each, before we move onto other “StartedUp” culture challenges. The next post goes into process KPI’s and metrics – addressing the golden simple process blocker.

Building high performing teams by showing your employees how they can do better

This topic builds upon the previous “Building high performing teams by telling your employees they suck” (its not as simple as telling someone “you suck”); the emphasis really comes down to communication (showing) and attributes (why) they are not performing.

I learnt very quickly in my career that quality metrics do not lie and can easily convince to win an argument. I also learnt that pictures and diagrams help me explain (and understand) things much quicker than words alone. This is why, whenever I have had to prove something to myself, or explain a point; I have turned to metrics and diagrams.

So lets first cover some basics

Many companies do an “annual review” dance; some do it twice a year, some don’t even do it (we wont talk about them)…  and during this review, the expectation or assumption is that the person being reviewed has been working towards their goals that were defined the year prior; or that if goals had changed, then things would have been appropriately documented to reflect that change…. Truth is.. we do not have time for this; especially when you are in a high demand team where priorities change on you all the time. However; if you have been actively carrying out your 1-on-1‘s and have been using it to develop the person/your team and have some sort of career path or individual development plan in place; you may be well prepared for this annual review – Great for you!

Some lucky ones get an annual, semi-annual (or sooner) 360 review; I believe this provides more value than an annual review because it lets you hook into career development much sooner and/or it will give you insights to how you efforts are perceived by a larger audience who may be working with you on much closer day-to-day basis; this can one stay on top of their game if its done in short enough period as it is a great motivator. Managers can then review the trend over time and see how one is progressing to give a more accurate review.

At the end of the day, with all these reviews, coaching, development plans, etc. what we are really trying to do is grow people (or remove the ones that wont grow), make sure they perform and build teams that work well.

High-performing teams don’t just happen, they are made.

It is my opinion that in order to build high performing teams that work well; you have to instil a culture around “working well”. The annual, semi-annual, etc reviews really need to tie into a day-to-day type of thing; it may be seen as a lot of work (initially true), but just like good and frequent maintenance goes a long way, so does this.

To recap; what I have just stated is that we should focus on reviewing everyone on more frequent basis; something that ties into the day-to-day and can be captured daily or weekly… or best, if it can be captured adhoc as long as its captured within some frequent frequency. We would of course want this to be documentable, repeatable, measurable and actionable… we would want a process.

So, if this all has not added up yet, we want quality metrics that will provide diagrams/results based on process that can be used to communicate performance.

Every couple of weeks; I will ask my leads “without any thought into this, respond to my email and stack-rank your team”; or I will ask “If you had to do a project, who are the 3 people, in order of preference, you would pick”. Then there will be the “who is the most active volunteer” or “who is the least to volunteer”…  While these questions lead to answers that I plugin to my brain somewhere and maintain on spread sheets… they do not translate to quality metrics because they are not standardized enough… nor really repeatable.. (and probably other reasons as well). Another flaw with my method of capturing metrics is that it doesn’t allow “everyone”offer an opinion; only the ones I happen to ask or interact with that day. So while I may be able to “wing-it” and come up with diagrams based on some metrics… we need to focus on improving the quality of these metrics.

Quality Metrics

What does “team work” mean to you? What are the attributes of a team player? What type of people do you want to work with? or what type of people do you want working for you?

Here are some interesting data points that one can use a 1-5 scale to rate someone on (in no particular order)

  • Reliability
  • Constructive communicator
  • Active listener
  • Problem solver
  • Active participant
  • Shares solution/ideas
  • Volunteers assistance
  • Flexible
  • Customer focused
  • Respectful

In addition to defining the data points; you want to make sure that everyone has an opportunity to provide this data on “any one” without a need for self-identification (remain anonymous) and you will want some way of reminding people to go back and update (or resubmit) data at some frequency.

Creating a process around capturing these metrics and emphasizing the need to submit feedback sends a strong message to your team(s) that this is important.

Communication

Once you have reviewed, tweaked and confirmed (adhoc charts) that you are capturing data that is meaningful; its time your shared the results with the team (where appropriate) and with individuals (as needed).

The diagram below is probably more for your own viewing (rather than sharing with the team)

ImageThis diagram identifies the low and high scorers (averages of combined attributes); and you can see from above, Employee 4 is a low scorer.. (bottom of stack rank)

You may want to dive deeper into this, and you will see

Image

Where everyone lies based on attribute; is there a deviation for anyone? or does everyone score low in a specific category?

Again, from the above two it seems like Employee 4 isn’t at par with the rest.

Communicate

Communicate how/why/where they are not performing… a picture says a lot more than words, see below:

Image

This chart can be used in a 1-on-1 with Employee 4 to go over their specific performance; and can be tied in with what the “average employee” scores (which is just avg score per attribute), see image below

Image

This image that compares employee 4 to the average employee gives the employee actionable data that is backed by metrics. They can then use this information to focus improvement efforts.

Conclusion

So while its easy to focus on the literal words used. The goal should never be to tell someone that they suck (and stop at that); it should be to help drive change, development and improvement in someone by clearly communicating areas they need to focus on so that you can build a high performing team.

Leadership: Mini-Motivators of Motivation

In my journey through leadership , I learn a lot through experiences and observations… here is one observation:

We all work for different things and we are all entitled to our personal (or not) reasons for what motivates us. Motivation is probably the single most powerful thing that keeps an employee (willingly) at a company.

Motivation comprises of many things; I will not pretend to be the expert on motivation (or leadership) but for me and maybe for you (and possibly the general public), I think it breaks down into three mini-motivators.

  • Market: Product/Space you work on/in, the day-to-day things you do
  • Money: How much you get paid to do what you do
  • Manager/Management: Your belief, trust and/or respect for the person or people who is/are your leader(s).

To ensure that people are motivated, all leaders should focus and be challenged to ensure that all three mini-motivators are attended to as in an ideal job, one would have a good mix of all three.

So the question is: What happens when you start taking things away? or what if you had to focus on just one to grow your team? In my opinion (and many others as well), “Manager/Management” is the silver bullet.

People work for great managers/management teams and will continue to work for them even if the pay is low or the job is boring; however, if you take away the great manager/management team and give the person a great market opportunity and/or over compensate, eventually, the individual(s) will leave for other opportunities where they feel they will also get the “manager/management” balance.

There have been quite a few times when I have heard the phrase “People don’t leave companies, they leave managers” and slowly, it has started to make sense.

Leaders must focus on motivation and be managers that are looked up to; if you have leaders who are not respected and looked up to, or “followed“; you have a motivation problem and (good) people will leave.

Horizontal Management – Maintaining momentum: Keep progress moving

While machines might give the same level of output everyday, the same doesn’t apply to people.

In a real environment, each member’s momentum and motivations will change without notice. This requires management to step in and make sure they are constantly evolving the processes so that members will remain motivated. Leadership is important to motivate key players, channel information to keep everyone engaged and make working horizontally routine. To accomplish this, management might bring in an outside champion, who will help wring in new ideas and “fresh” stream of motivation. Instead of looking at a project as a whole, it should be broken down into smaller goals that are realistic and achievable. Management should encourage and build on small success, to demonstrate that it was an important milestone and motivate members. Progress and results should be demonstrated so that members can all acknowledge the ongoing progress and success.  Management can keep the members interests by ensuring that they are always focused on achieving the goals that were set, and if deviation is detected, corrective action is taken to bring things back on track.

A horizontal team is dynamic as it is always changing, management needs to account for its dynamic nature and make necessary adjustments to accommodate/adapt to the change. Money is probably the best motivator, but too much money too early in the process can hinder individual initiative and prevent people from innovating. Since horizontal structures focus on team collaboration, a downfall is that meetings can go on forever and schedules can be missed; this can unmotivated some members who feel that decisions are not being made in a timely manner, which is why management can implement deadlines which will help practitioners develop a common schedule and manage workloads effectively so that the projects momentum is kept at a steady pace.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Horizontal Management – Building support structures: To keep Horizontal team in check with Vertical roles

Even though a “horizontal structure” is flat in nature, it does still need a (vertical) support structure.

The main purpose of a support structure is to help managers build lasting relationships and achievements with teams. There are two basic type of support structures that managers can mix and match when building or working with teams, depending on the requirements as each has its own attributes.

  • Informal structures don’t define rigid roles and responsibilities, they are open to interpretation and people can define their own roles and swap roles as needed, hence they are less resource intensive, more flexible and less binding on members; Informal structures help promote open discussion and communication among its team members; and
  • Formal structures are more rigid and roles/titles might be defined where members have specific responsibilities; this makes them more resource intensive but less ambiguous; they require some logistical skill and expertise to implement. These structures are great when consistency and quality are important factors.

It’s important for management to recognize what type of structure needs to be in place and when its put in place; as “when” a structure is erected, it can play an important role in the success of the teamwork initiative. If too much formality is introduced early, people might feel there is no difference in the “horizontal structure” and the “vertical structure” where vertical structures are rigid, formal and bureaucratic and would be less motivated to work with the initiative. In contrast, waiting too long to build a support structure or the lack of a support structure can hinder the ability of the team to successfully work together as a team, especially when they need to be able to adapt when in tight spots.

Since the resources and effort required are greater when setting up formal structures, informal structures are great for short projects, however when the projects will go on for a long period of time or are of large scale, formal structures would be more suited as they are less ambiguous and will stay well formed longer (as they are more solid than informal structures).

Authority and roles in informal structures are more ambiguous and can be swapped around; In formal structures, the roles and responsibilities are more definitive, hence less ambiguous and in that regard, formal structures would work best in situations where important decisions need to be made.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Application Lifecycle

SDLC along with the words “Agile”, “Iterative”, “Kanban”, etc are, in my opinion buzz words. You can pick up a book and learn “Agile development”, you can take a few courses and get your “Scrum Certification”, but following the documented approach, as is, will only get you so far.

To really understand SDLC you have to get into the guts of how things really work; why do people do things the way they do and understand the “natural processes”.

For Start-ups, small companies, new companies, walking in one day, or starting of with something like “We are going to follow agile development”, works. It works real well because they choose to start with the textbook definition; it works real well because you have new developers who will be agile and flexible, and do things the way you choose to do. For such an environment, someone can walk in and make sure that things are being followed the way they are supposed to be; but unfortunately, this is not how it works when you try to take something that has been running for a (very) long time and you try to make it different.

As an example, look how some auto manufacturers have decided to implement and offer “high MPG vehicles”; some chose to restart and build a brand new vehicle; others attempted to re-purpose or salvage their offerings.

So talking about SDLC methodologies; Who really wants to follow a waterfall model? that makes you sound too outdated and boy, I wouldn’t want that on my resume. (Sarcasm). For many, waterfall is still the best methodology but they still want to move to something that’s more agile; and there is no harm in doing so, just as long as you understand and implement something that works well for you.

Now, to build something that works well for you, you really must understand YOUR current “Application Lifecycle” and see how it can be optimized. SDLC is just a very small part of the “Application Lifecycle” and once you understand, document and optimize your “Application Lifecycle” you can focus on modernizing your SDLC.

So, to build the example of understanding the “Application Lifecycle”, I will draw up a few diagrams. I will focus on the positive paths and not the negatives so that the model doesn’t get too complicated and I will also make some assumptions/skip extensive detailing, saving that for a separate post.

Starting the cycle.

  1. Once you have gone through all the (painful) steps of creating a product (in no order: Sales, Requirements, Dev, Qa, Test, Release, Etc) you end up with Product
  2. Customers use this product and they
  3. Report issues
  4. Reported issues go to your support team (hopefully)
  5. and the support team analyzes these issues.

Image

Pretty simple right?

You have now documented the beginning of the cycle as after product deliver, you are getting things back that require work. So what does support do after they Analyze the issue?

  1. Confirm the issue and provide additional documentation (if needed), sending it to
  2. Some review board, or decision maker as to what to do with this supposed issue, and determine if its something that needs to be resolved now (defect) or something that needs to be done at a later time (enhancement), or maybe you do not want to do it. In any case, 
  3. The review board makes a decision in regards to releasing it (now).

Image

At this point, hopefully there is some queue setup that allows intake of things for development to work on as they will trickle things into their work queues (depends on what SDLC methodology you follow)

  1. Development picks up work and resolves the issue; after the issue is resolved, it is
  2. sent to QA for additional testing, and once 
  3. QA approves the resolution, its 
  4. given to Release Management, who then
  5. releases the resolution
  6. giving you a packaged resolution.

Image

All this assumes that there was actually a code defect, and that it required immediate resolution as it was critically impact a live customer. Things get a bit more complicated when you bring enhancements, non-code issues, and other things into the picture.

Also, big “hand waves” are done at various points in my flow, for example, the following things need to be looked at as well

  1. How is the intake of work managed and prioritized, and by who?
  2. What is the regression/integration process?
  3. Who manages the movement of the issue from one area to another?
  4. How are issues that should not go to the review board handled?
  5. How does the information go back to the customer?
  6. How is information distributed to other customers?
  7. … and so on….

Understanding the Application Lifecycle, really does take “process improvement” to the next level as it allows you to follow several different best practices when it comes to SDLC or even the Organizational Lifecycle; For some organizations, they have a dedicated Business Process Office (or process office) that is responsible for looking at the big picture and ensuring that process is continuously optimized and improved.

So the next time you find yourself, wanting to “improve things” ask your self, “how big” of an impact you plan to make.

Being involved in such efforts right now, I wish you good luck.

 

The super hero characters we play

I feel that similar to the characters in the movie x-men, we all play different characters at work and have different attributes/powers. I however like to think that there are just 4 main characters….

Promoters: This is entrepreneurial-ism at its finest. These types of characters need no reason to introduce change that improves the lives of others around them. They simply walk in, look for something they can help improve and go at it. They promote change, new ways of thinking and mentor by example and strive to do exceed their own expectations. There is no fear of accountability or making a decision, be it right or wrong, they will act regardless of being asked or not. They are also overly positive and negativity does not demotivate them in any way.

Workers: These are your dependable characters; you want something done? They will get it done for you and not let you down. They will invest hours, sweat and blood to deliver what you ask of them; however they still need a little nudge from someone else; someone like a promoter. They are accountable to the tasks that are assigned to deliver on by someone else. In many cases they go over and beyond just to make sure they have met the expectation by a 100%. These characters have a positive energy most of the time; negativity gets them and their motivation down.

Watchers: These are characters that walk around, see what’s going on and assist when asked. They prefer to keep their necks low, blend in with the decor, and wait around for the next check. They would prefer do the minimum to meet what is expected of them. These characters have a neutral personality, neither negative nor positive, but will tend to appear more positive than neutral.

Negators: These are the toxic characters that not only are negative but will attempt to derail the promoters, be in the way of the workers and try to solicit the watchers to join the negators in their quest to make no progress. It wasn’t their idea, so it must be wrong; these characters fear change, do not want to be accountable nor do they want any new expectations set. If it was up to them, they would crawl under a rock and stay there forever. When they do come with a good idea, they cannot deliver as it requires them to actually do the work, be accountable and deliver; it is at this point they look for the workers to push their workload onto to get the task(s) done.

We should all strive to be Promoters that reward, mentor and recognize the workers, making them fellow promoters; motivating the watchers to become workers and pushing aside the negators if they cannot be changed. This may be a lot of work for an individual, but a piece of cake for a superhero………and thus; we should all let out our super hero identities.

Making Changes: Change Cycle

To stay ahead (or on top) of the game, we must recognize that change is good and that we must be continuously improving the way we work. While reading a book “90 days” I realized that I had been through these stages multiple times, fortunately walking away successful. It also made me realize how close I was to a possible failure in some of the changes I had made and because of this realization; the Change Cycle will always be on the back of my mind when I attempt to drive Change.

I took the concept that was in the book and modified the terms as it was easier for me to relate the “change cycle” to something I already knew, the “process cycle”.

Here is what I do and have to say about process:

Good process should be well tailored to the organization that intends to benefit from it. Process is much easier to implement when its implemented in stages based on a feedback loop; When improving or introducing process, a big concern is usually how fast and how much? Well, too much too early generally results in resistance to change and too little too late results in process loss.

So what should be done?

A rapid agile approach should be taken when implementing process. Process is implemented and/or improved when the lack of process has been identified. Once an idea of what process needs to be implemented has been formed, the cycle starts with

  • Introducing the process as a pilot, if the pilot is successful
  • It should then be verified that it’s repeatable. If the pilot is successful and repeatable
  • It should be formally defined and shared among the team as the formal process.
  • The process should now be managed and measured to obtain metrics to figure out how successful it is, its ROI, etc. These metrics should then be used to
  • Optimize and continuously improve the process.

The concepts of the “process cycle” for introducing a process are very close to the concepts of a “change cycle” for introducing a change.

In a change cycle, you:

  • Introduce a change and if the introduction of the change seems successful you then
  • Maintain the success to obtain stability. Once stability has been insured you
  • Optimize and introduce other changes as needed; this is your optimal success cycle.
  • Should the change not be maintainable, you will need to
  • Adapt the change to make it maintainable; this is the adapting cycle.
  • If you cannot adapt your change to be maintainable, you might have to
  • Change direction and counter the change; this is the Counter cycle.
  • If the change cannot be countered and be made maintainable, you will end up with a failed change. You can also end up with failure if your introduced change is not successful. A change can easily be unsuccessful if it’s too large; rubs people the wrong way, inappropriate, incorrect, etc.

Sometimes we start in this cycle at a completely different stage, for example we may realize that we have inherited a change put in place by someone else (different team, a VP, etc.) and we now need to act and adapt their request, or counter the change, making it successful. The 90 days book does a good job of giving a more general view of the change cycle; for me, the stage comparison of the two cycles makes sense.

The change cycle for making changes is just a small piece of the puzzle. How you go about obtaining buy in from your team, peers, and higher ups is another big part of the puzzle that will either result in success or failure. That will be a topic for another day.