Category: Startup Culture

Maturing from a StartUp to a StartedUp culture – Series Intermission

People?
Yes!

Product?
Hell Yes!!!

Process?
Boooooooo!

Is that what comes to your mind when someone mentions “process”? For many that’s a “Yes!”… “We don’t need no stinkin process; we just want to work”

“Process is just a book definition of something”, “its boring stuff”, or “Theory that doesn’t apply to the real world” are some of the phrases I have heard people use in disgust to define what process is; and in a past life someone used a “process is something that doesn’t apply to a startup or startup culture” on me….

“We care about people”

“We care about product”

“We only care about people and product”

..but what about process? why does process not get any love? What is it about process that makes people cringe? If process is evil, why is it that many methodologies (based on research and metrics) focus on the importance of all three (“People”, “Product” and “Process“)?

Process is everything that people and product are not.

Process:

  • is culture and a shared understanding,
  • it’s how your teams work and collaborate.
  • it’s how you measure performance,
  • its how you innovate, grow, plan and deliver product,
  • it’s how you engage and grow people,
  • Its more than ISO certification…
  • its a lot more than this

Life is a process that’s filled with people and products
(among other things)

Dilbert – Scott Adams Inc.

Advertisements

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 3

Several years ago I had a Volvo (88 760 GLE) and one day I noticed little streams of smoke from under the hood every time I would get back home; I had little experience with cars back then so I took it to a friend’s dads shop. I should have probably left when I got there because there was a customer yelling at him for messing up his beetle and charging him extra to fix it; apparently he put some hoses on wrong and then had to redo the work, I wasn’t there for the whole story, just the last 20 minutes of it and then the customer drove off.

My friend’s dad asked me to start my car and pull up next to him and leave the car running. He popped the hood and started to look around, he checked the hoses, looked at the pump, lines, drove it around, several hours passed by… he went from suggesting that there was coolant leak, to transmission leak to radiator oil leak… several more hours passed by as he came up with theories and looking at things… after being there for about 6 hours I decided to stick my head in and look at the engine block near the side where I told him to look and thought the smoke was coming from. Sure enough, just as I looked, I saw bubbles near the engine block’s cover, pointed it out to him and he said “ah, it’s loose! oil is getting out”; brought over his tools, tightened it and the problem solved.

I had been there for 7 hours, he wasn’t the type of guy who would say “this is my son’s friend, I am going to help him out”; he was a business man and to him I was a customer. I was upset with him for wasting 7 hours of my time; but what was really on my mind at that time was “how much will these 7 hours cost me?”, especially since he had a sign posted that had “Service hour rate: $45/hr” in big letters….  I will get back to this later in the post.

KPI and metrics
Man hours, hours, T-shirt size, story points, etc are measurements. I will try my best to not go down a rabbit hole with scrum, story point’s vs hour estimates… I will not! and hopefully I won’t lose my original messaging in all of this. Let’s start with this; at some point or the other, the focus and bottom line for a company will be “shipping product” against a “delivery schedule”. People, process, culture, story points, hour estimates, etc. will eventually stop existing if the “startedup” company cannot ship product and closes down (the focus here is shipping product according to other peoples expectations, i.e investors, C-suite, etc). With this at the back of our minds let’s continue on.

Story points are a measure of risk and/or effort and/or complexity (the and/or is there for the ones who disagree that story points do not measure complexity and/or risk).

Work/Task estimates are hours (usually) it takes to complete a task (with risk, complexity and effort already factored in).

Some argue that story points are just a block of time that provide the developers with padding; some argue that story points and hour estimates are not the same; some argue that time estimates need to be detailed and you should only use blocks of time (i.e. story points). I am not here to argue about any of these.

If you look at what part story points and sprints play: Story points (representing stories) go into sprints and sprints are boxed in time; at the end of the day, we are basically fighting for time. Others (Non-developers) usually want to know “how long will it take”, “when will it be done” because they need to set schedules, communicate to others, but (most) developers just want to work 🙂

How can I tell you how long it will take to fix when I have not even looked at the code; code that someone else wrote years ago!

When you have your team of 10 who have been working on a project (or two); the story points, velocity charts and estimations work out great. The team of 10 will negotiate points and the best suited person will do the work; everyone starts getting a good idea of what others and they themselves can do with improved accuracy (and velocity).

What risk can come up when you throw in 65 new hires and 2 new projects?
One thing that can happen is that the wrong person can get the wrong story; it is also possible that the new team may incorrectly estimate story points.

This happens or can happen because it takes experience and familiarity to get both (story point estimates and story assignment) of these right. Let’s say everyone is working on their tasks for a sprint, there is 1 story (something to do with SSL)  remaining and it MUST make the sprint (which closes sooner than the story can be worked); the one developer available knows NOTHING about SSL, and a simple change measured as 2 story point remains, there is a developer on the team who knows about SSL but she is already working on a different feature that requires her knowledge on encryption.

Why did this get set as 2 story point when it was obvious to the team that there was risk? Rather than negotiate for 5 points the team settled for 2 because they expected the more senior programmer to have a better idea of how many story points it would take; the senior programmer saw no problem with 2, because in the past, her team was comfortable with it being 2. Repeat this several times, and you have a pattern; how do you break this pattern? or how would you even recognize this pattern? How would someone have suggested 5? How do you further refine estimating story points so that its not just based on gut, experience or familiarity? You start building and tracking additional KPI’s/metrics. Velocity and Burn Up/Down charts are common KPI’s that most use, you need more to help fish out patterns and gaps.

I think it’s important to acknowledge that in a true scrum setup (a perfect world, which is possible) these things may not happen (or happen rarely); if something doesn’t make a sprint, it moves to the next, but in most (all) of the places I have worked at, true scrums do not exist, shit happens and you cannot NOT make the dates; unless the team pulls together, works OT and possibly burns out (if it keeps happening).

As many others do, I like to base my estimation on experience and collectively agree with a team; but wouldn’t it be easier if there was another set of metrics that provided extra assurance or a reality check? i.e. historical data. Either metrics against tasks or metrics against similar stories. i.e. a story around “user login” averages to be a 4 point story based on previous similar stories; a task to “check credentials against db” takes 2 hours? The metrics can be captured after sprints/projects are done in adhoc meetings or release review meetings the data would be used for new hires, for times when things are under/over estimated. New hires and others could use this data to help estimate and understand gaps between what it takes on average and how the teams perform; the KPI’s would further detail teams health…

Going back to the Vovlo; I was waiting at his desk while he put his tools away, then he walked back to his desk, opened up a book, flipped pages to a section that read “Diagnostics”, found a line item for “Oil Leak” and sub-item “Gasket”, and said “2 hours, so you owe me $90 for fixing the problem”. Even though he spent 7 hours on it, he charged me for 2 because that’s what the book that had metrics for that type of service said it should take. 

The Volvo example is important to me because it identifies performance issues; i.e. he should have done it in less than 2 hours if he was a good mechanic because that’s how long it takes on average; he should be asking himself “why did it take me more than 3 times as long and how can I do this better” because that’s what we would use similar development metrics for. “I seem to always under estimate UX changes, I need to pay better attention”.

The example I used has so far revolved around a startup company of 10 growing to a startedup company of 65; let me use a different example: A software development boutique is agile and they have client projects captured in back to back sprints. There are account executives that double as product owners who talk to the customers and based on experience and some dialogue with a few dev leads, they estimate effort and agree to a schedule and  budget. Once they are ready to start the sprint (for a new project) the dev leads will update the team and as soon as sprint planning (stories placed) is done they start rolling.

A few issues:

  1. The dev lead and account executive time-boxed the maximum amount of time it can take based on their meetings with the customer; there was no team review
  2. Account executives double as product owners;  their stories aren’t reviewed by developers until the work actually starts since developers are already busy on other projects
  3. There is no room for scope creep; things cannot get thrown out since this is a client project, and it must meet a date
  4. When there is scope creep and because its boxed; resources will work over time and burn out since the cycle just repeats it self – regardless of what your story points are, they have to fit in the sprints.

You could point out that the issue here is that there isn’t team involvement with the original estimation (for the time box) but this is because of how the company chooses to operate, so you cannot change this. You could state that the issue here is that there will always be some sort of scope creep so you cannot expect a hard stop but this is also because of how the company caters to customers expectations and needs to operate.

I would argue that the issue here is that the account executives do not have a “rate book” or “performance history” for similar tasks/stories that can help them come up with better estimates and factor in complexity when needed. In addition to that, since this company is in a pattern of running over (and solving by having people work over time, every time) there should be some sort of analysis done after each project to come up with “mistakes made” or “lessons learnt” so that people can learn from the patterns and put out better estimates; there will be times where you cannot change the entire companies culture, so instead you need to look for what can be improved.

With focus on additional KPI and metrics; one can identify issues with process or gaps before they become a bigger problem; Don’t just  stick with how things worked when you were a startup and expect things to continue to always be perfect once you start growing, when you are “startedup” you need to start looking at adding new KPI’s and measurements that will help the bigger team work better and scale.

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.

Maturing from a StartUp to a StartedUp culture

The content for this discussion is several pages long so I will release it in posts as a series.
Introduction

A couple of weeks ago I had interesting discussions with a software lab focused on mobile tech out in the Boston, MA area. Ideas were exchanged, we spoke about different issues that impact teams, growth, product, process and discussed different ways they could be solved.

After the dialogue, reflecting back on the content and looking for a root cause or pattern I realized that this wasn’t the first time I had discussed or worked on solving these type of issues; growing pains, single threads, lack of process, maturation are just some of the terms used to describe the root cause and in most cases its all of them as they mean the same thing and to me that is “growing startup culture”

A startup company or start-up from http://en.wikipedia.org/wiki/Startup_company

A startup company or startup is a company, a partnership or temporary organization designed to search for a repeatable and scalable business model.[1] These companies, generally newly created, are in a phase of development and research for markets. The term became popular internationally during the dot-com bubble when a great number of dot-com companies were founded.Lately, the term startup has been associated mostly with technological ventures designed for high-growth. Paul Graham, founder of one of the top startup accelerators in the world, defines a startup as: “A startup is a company designed to grow fast. Being newly founded does not in itself make a company a startup. Nor is it necessary for a startup to work on technology, or take venture funding, or have some sort of “exit.” The only essential thing is growth. Everything else we associate with startups follows from growth.”

And from the same source, a startup culture

Startups utilize a casual attitude in some respects to promote efficiency in the workplace, which is needed to get their business off of the ground. In a 1960 study, Douglas McGregor stressed that punishments and rewards for uniformity in the workplace is not necessary, as some people are born with the motivation to work without incentives.[11] This removal of stressors allows the workers and researchers to focus less on the work environment around them, and more at the task at hand, giving them the potential to achieve something great for their company.

This culture has evolved to include larger companies today aiming at acquiring the bright minds driving startups. Google, amongst other companies, has made strides to make purchased startups and their workers feel right at home in their offices, even letting them bring their dogs to work.[12]The main goal behind all changes to the culture of the startup workplace, or a company hiring workers from a startup to do similar work, is to make the people feel as comfortable as possible so they can have the best performance in the office.

This is what most of us understand startups to be; but I would argue that startup cultures do not only apply to a new or young company (a startup) or that the culture is inherited through acquiring a startup; applying the culture and model that exist in a typical startup one can “build startup culture”.

If startup culture is a “must have” then how can there be any issues with that culture? To clarify, in my opinion startup culture is great, they build great teams, focus on product, have a great culture and are fun to be in – and I respect and thrive in them; you start running into issues once the startup has started-up and you need to scale three core P’s: people, product and process. For me, the key is using teamwork and relying on your peers to figure out how to scale all three at the same time while everyone is busy with their other workload.

The next post will outline some of the end-products of startup-culture that should be addressed/changed in order for the startup to mature as it goes from being a startup to started-up culture

Building a dynamic onboarding program for Martians

Chances are that you have been through some form of schooling (high school, college, maybe some random instructional education) and have hopefully figured out that everyone learns differently.

For me, learning and passing my classes meant that I showed up to all classes, took no notes – just listened and the day or so before a test or final, skim through the text books (if i had purchased them) and then just showing up for the tests. Once I figured out how to do that very well, my last 3-4 semesters for my Bachelors, Comp Sc were filled with A’s and my Masters, Software Eng was a solid 4.0.

Was  it a piece of cake? Nope, but I surely made it seem like it was.

So whats the secret? or whats the relationship to that with onboarding? or well what is onboarding?

From Wikipedia

Onboarding, also known as organizational socialization, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.[1] Tactics used in this process include formal meetings, lectures, videos, printed materials, or computer-based orientations to introduce newcomers to their new jobs and organizations. Research has demonstrated that these socialization techniques lead to positive outcomes for new employees such as higher job satisfaction, better job performance, greater organizational commitment, and reduction in stress and intent to quit.[2][3][4] These outcomes are particularly important to an organization looking to retain a competitive advantage in an increasingly mobile and globalized workforce. In the United States, for example, up to 25% of workers are organizational newcomers engaged in an onboarding process

Some organizations have great onboarding programs; some don’t. There are going to be cases where you inherit a team that has single-threaded subject matter experts and as a manager you may be expected to distribute that knowledge and grow the team – with no process or onboarding program in place. Yes, you have to create it, so where do you start?

Do you invest time in meetings? create videos? printed materials? who will read all that? who will do the work if your team is off training new hires? is that really a good use of their time? or a real-world question “Do you have bandwidth?”. The answer is No.

So, why not use what you, or I learnt during schooling? when we ourselves were learning? how did you learn? How could you create an onboarding program from nothing? and how could you be sure it would work? You really do not want to invest time in something that is  not going to work so it needs to be agile enough to change on a whim.

Okay – enough of the red flags, here is what I did. Ill try to make this as generic as possible.

I inherited a team of martians, and the problem is that they only speak a special language, called martia. Turns out that its a very ancient language and that no one really speaks martia nor is it taught in college. The small group of martians have been speaking it for 15 years and they as a team are great at it, theres just a few of them. It also turns out that there are all these documents that come in that need to be checked for grammar and spelling, and corrections – in many cases the martians really have to research and see what the intent of the document was because in some cases they have to re-write the document correctly – it can definitely be time consuming and this is the only team that can do this.

This team of martians is also aging, some have retired, others were move to other planets so I have to hire more martians – but, there are none around. So I hire a martian from a different universe and tell it that it needs to learn martia and I will help it learn this language; the language it speaks, we dont care for it. Here is the process that gets put in place

1. Every day the new hire will sit with a senior martian for 2-3 sessions and learn stuff

2. The sessions will be 30 minutes long and after every session there will be a break, during which the new hire will document all that was covered

3. During the next session, the senior martial will review notes, as a refresh to where they left off, and continue the information offload

4. Steps 2 and 3, repeat for a week or so; after which the new hire will then attempt to work the documents

5. as the new hire works the documents, it will have questions, it will document them

6. the new hire will setup additional sessions with the sr martian to get clarification and answers

So – you say this is just common sense and normal stuff.. how are we reducing the dependency on the sr martian who is already busy? here is the answer:

A couple of months go by and another new hire is brought on

1. The new hire sets up sessions with the x-new hire, i.e. the junior martian.

2. the new hire reads all the documentation created by the junior martian

3. several sessions take place where the junior martian and new hire go over content

4. a session every now and then takes place where the sr martian comes in to listen in, and see how the training is going

5. if the sr martian adds anything, its documented in the growing on-boarding document

6. the new hire then also attempts to work documents and goes to the junior martian for assistance – and if needed, they both go to the Sr. martian.

So, its somewhat like train-the-trainer you say…. yes, it is., except, the trainer role gets passed down to the newest hire. if you keep hiring, you start building a 2-tier training team, where the junior martians, through teamwork, will try to come to a conclusion, and then will be empowered to go to the senior martians for confirmation. This helps build teamwork, confidence and helps them acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.

Sooner or later, your team of martians will grow and the martia language, once so uncommon, will become common and the perception that its the monster in the closet that only the select few can understand, soon goes away.

Building high performing teams by telling your employees they suck

.. well maybe not as bluntly as that…

*this post has a follow on post Continue and read building high performing teams by showing your employees why they suck*

Every now and then, managers get together and play this wonderful game where they take all their employees and put them on a “9 box”; if you ask me., its more like snakes-and-ladders (aka chutes and ladders).. but the end goal is the same., identify where each employee is and figure out how to move they into the top-right corner (and promote), or move them into the bottom-left corner (and out).

Many of us have played this game many time….  In my opinion the problem with this game, and the way that many choose to act upon it is that its just too politically correct. For the individuals who fall in the bottom left corner we have decided that they suck but wont tell them that to their face, the ones who are in the top right are the super stars and we don’t want to make it too obvious to others…. so rather than say it how it is, we waste endless hours trying  to figure out how to get the message across and build a better performing team all by ourselves….

Where is the fearless leader? where is the animal instinct and the competitiveness? Forget the politically appropriate messaging., I say call it all out: Hold a team meeting, tell people where you think they land and get it over with. Yes, either your team will think you are an ass for doing it., or they will respect you for being open and straight forward with them. Use your team to help pull the ones in the lower left corner and let the team know who the obvious role models are; Why do all the work your self? trying to be careful not to hurt someones ego? we are all here to work, get the job done and perform. Does your team really want dead weight slowing them down? holding them back? You are accountable when someone else has to work over time because someone in their team didn’t get their work done. Its you who they curse when they are putting in 60 hours because you didn’t have the guts to fire the bad apple and get a new one. yes, its always your fault.

So why the emphasis on being open? why the public humiliation or the public praise?

Not too long ago, an employee asked me “Why don’t you tell your people that they did a great job? Did you know he had to work through the weekend to get it done?”; My answer was “They day any of you guys, works more than I do, I will personally congratulate you and send you a box of chocolates”…… It was in humor that I made the comment, and followed up with a “the reason why he had to work the weekend was because he was not at his desk most of the week, coming in late, leaving early… he was off doing personal things”…   What I am outlining here is the perception that someone else in the team had of me not being appreciative and recognizing someones hard work vs the fact that the person was simply making up time lost during the week – The thing about incorrect perception is that its never “just one person”… it could be your entire team!… Using a team meeting to dish out things like this helps reset perceptions and gives everyone a clear picture of what you see; essentially such a group setting promotes conversation that goes both ways… don’t be surprised if your team starts telling you what you are not doing and what you need to improve on. A team that gives you honest and open feedback about yourself as their manager not only tells you that they trust you, but it also allows you to use that information and grow yourself.

So do the 9-box and get a team meeting together: tell the ones who suck that they suck and that you and their team mates are here to help them improve and talk through issues – tell the high performers that they are high performers and that you and your team will be demanding more from them to help them grow to the next level in their career. Do this and you will build high performing teams that follow and believe in your fearless leadership.

**updated**

Continue and read building high performing teams by showing your employees why they suck