W2? 1099? C2C?

One of the questions I get asked most often from those considering contract work is whether to work as a W2 contractor or should they consider 1099, or incorporate so they can bill corp-to-corp (C2C).  The answer is – it depends – and it mostly depends on you.

If you are going to contract long term, or you have a particular expertise that you sell, eventually you will move from working as a W2 Contract Employee to being Independent / Incorporated – in other words: A vendor.  These are not mutually exclusive, BTW. When you’re a vendor that means that you could be billing on a 1099 basis or you could be incorporated and use your corporation to bill the agent or client corp-to-corp (C2C). 

When you choose to bill as an independent vendor that means you are viewed as a business, which is a separate legal entity, and completely different from being an employee. When you’re independent, you have all the privileges and responsibilities of a business owner.

“Responsibilities” is the key word here:  If you choose either 1099 or C2C, you will take home a lot more money than you would as a W2 Employee. But if you are not prepared to handle the responsibilities (and risks) of being self-employed, mo’ money mo’ problems.

Whether you are a sole proprietor, in a partnership, or a principal of a corporation, if you are deriving “Schedule C” income, you are responsible for obtaining business licenses, paying business taxes, keeping accurate records, maintaining general liability, and other types of insurance.  If you’re working as a vendor, you may need to purchase and maintain your own tools, equipment, prepare your own contracts, invoices, and track your payables and receivables. Some clients will provide you a 1099 form for taxes; some do not. Sometimes they’re accurate; sometimes not.  Regardless, you are responsible for an audit trail of your gross receipts and expenses, maintaining bank records, and insuring you adhere to all applicable laws. If there is a discrepancy, you need to be prepared to prove everything.

When you are independent or incorporated, you are a vendor. Instead of a job description, you have a statement of work (SOW). The SOW details what you are to accomplish for the client, a time frame for doing so, and what are the payment and acceptance criteria. SOWs can be very general or very specific. There’s no “standard” SOW. Its specificity varies by the complexity of the project and your relationship with the client.

When you are a vendor, the client cannot dictate the manner and means by which you complete your work.  So, if you wanted to assembly your PB&J in a different order in your kitchen that is your prerogative. The client can only accept or reject the work.

Most importantly, if you are billing as independent or incorporated, you do NOT have the same legal protections as you would if you were a W2 contract-employee. You are a vendor, just like the Crystal Geyser guy. If the customer decides to go with Sparkletts, Crystal Geyser doesn’t file for unemployment. If the delivery truck gets stolen, Crystal Geyser doesn’t ask the customer to buy them a new one. Similarly, like the Crystal Geyser vendor, you also have an implied warranty with your service.  If something goes wrong, your service is defective, you drop your Pepsi on someone’s laptop, it’s not a “My bad!” you are financially liable for that expense.  If your work is on the critical path of a project, be sure to talk to an insurance agent and your client to ensure you have the coverage you need.  If you own things – like a house – and want to keep it, you’ll need to incorporate.

You want to run a business?  Make big bucks?  We live in a litigious society. Don’t take chances.

Unlike W2 workers, your client will want to pay you every 30 days just like they pay all their other bills. But, what if your client doesn’t pay you in 30 days? What if they pay you in 45 days or 60 days?  Or not at all? How long will you keep working without being paid?  A week?  A month?  Two months? How will you collect if they don’t pay? (A big concern in today’s “virtual” world.) What if they claim your work is defective, and they refuse to pay?   Similarly, who pays for your travel expenses? Are you putting them on your own credit card and waiting for client to reimburse? What if they don’t reimburse you or take months to do so? I’ve worked in big corporate offices my entire life: You’d be amazed how many rich companies don’t pay their bills on time.

If you suffer from people pleasing, can’t say no, can’t write a contract, could never see yourself suing someone, or all this sounds just too unpleasant for you, don’t waste time billing as an independent or incorporated contractor. I’ve listened to lots of stories (mostly from women I’m sorry to say) who thought they could handle this kind of relationship, and ended up being taken advantage of by someone who was really, really going to pay them as soon as <somecrisis> passed.

There’s a certain amount of cold, hard, capitalism required when you truly work for yourself. I can assure you that no one is more unpleasant than someone who owes you money. You can’t put up with excuses. Other people’s bills and emergencies and sick kids are NOT your problem. Always track your hours and tasks; always keep copies of your work.  Be prepared to withhold work until you are paid for it.  Be prepared to walk off the job if you’re not paid on time, and be prepared to sue. 

If you have a tough time sticking up for yourself, can’t handle people’s anger, or you’re afraid of being “mean,” being a vendor is absolutely not for you.

++++++++++++++++++

Excerpted from: The Temp Job: A Survival Guide for the Contingent Worker. Copyright 2021. Pierce/Wharton Research, LLC.  All rights reserved.  No part of this post shall be reproduced without permission. info@piercewharton.com.

Three Reasons Your Agile Practice Isn’t Agile

A strong Agile practice is a three-legged stool comprised of the Product Owner (the What), the Team (the How), and the Scrum Master (the Process). These roles are equal to and independent of one another.

In other words, there is no hierarchy in an Agile team; there are workstreams, and workstream owners. No workstream is above or below more significant or more important than another. Each has its own purpose, its own outputs, and its own responsibilities.

In a high-performing Agile team, there are no bosses – there are only teammates.

If your three-legged Agile stool is wobbling, consider these most common root-causes of poor performing Agile teams:

The Tyrant or Timid Scrum Master

No position is as misunderstood in the Agile practice as the scrum master. I often ask prospective clients why they’re hiring a scrum master (as opposed to a project manager or business analyst), and I’m no longer surprised that most cannot tell me why, or what, exactly, the role is responsible for (except for the events) or what the differences are among the PM, BA, and scrum master roles.

The most common answer is, “A scrum master is a project manager, except for Agile.” Dead wrong.

The scrum master owns the PROCESS. He does not determine what is built (that is the role of the PO), nor how to build it (that is the role of the team). The scrum master ensures a consistent, transparent process (timekeeping, utilization, governance, metrics.) He ensures accountability, keeping people honest (in other words, calling them out on their shit.) He demonstrates leadership through questions, coaching, by defining workstreams, R&Rs, working agreements, DOD, DOR, and using the word, “No.” It’s less about servant and more about leadership.

The scrum master is the “Servant Leader” of the team. Unfortunately, too many people stop at the word “servant,” especially if the scrum master is female or an immigrant.

As a scrum master, it’s not my role to “whip” the team. I’m an advocate and a coach. In some ways, I’m unconcerned about the project’s “success” or “value.” That’s not my lane. I trust that the PO has determined/documented the value of the effort, the success criteria, and KPIs. If that’s not done, I’ll ensure it is done, or I’ll escalate it as a risk. I might think the project is a huge waste of money. That’s not my call as scrum master.

The leadership of the scrum master is easily corrupted if the scrum master has a direct report relationship to any of the other parties in the team. It’s also corrupted if the organization hires a scrum master when it really needs a product owner, an analyst, or an architect — this is all too common with “Purple Squirrel” hiring managers in many tech organizations.

The Faux PO

While letting the team continuously iterate some BPOs “mind dump,” is a common ailment, even more debilitating is the old-school, top-down manager posing as a Faux PO.

The Faux PO is common in the Ghost Ship Agile practice, which means that from a distance the Agile Ship seems like it’s sailing along, but when you look a more closely, you see no one is on board.

The Faux PO tells you that the jury is still out on this Agile fad. He’s not convinced it works because the team is too incompetent to complete anything on time, which is why they need to be managed closely. Meanwhile: No metrics. No Dashboards, No backlog. No working agreements. No Definition of Ready (DOR). No Definition of Done (DOD). No separation of development from analysis. No Requirements. The Faux PO isn’t going to sully himself documenting requirements in JIRA. Plueeze….clerical tasks are for women and subordinates who can take notes while they hold court.

The Faux PO’s unwillingness to actually DO the work of being a bona fide product owner doesn’t mean that work goes away. Instead, like a house without front steps, everyone has to find a way around the Faux POs lack of output. What choice is there? Calling your boss out for being lazy AF isn’t really an option…

The Faux PO excuse is that he is much too important for events and deadlines. Because of this, there’s no cadence to the work. The Scrum Master/ Servant arranges a ton of last-minute, ad hoc brain storming or demo sessions to accommodate the Faux PO and other people with titles and opinions. At these meetings, the Faux PO talks at, past, and through the team, (who sit on mute, and stopped offering opinions long ago). No need for backlog refinement or DOR. The Faux PO tells the team exactly what to do, who to call, what to say. If they have questions, they can email the Faux PO for more detailed direction on how to accomplish their work.

But, I Like Being the Boss!

When I’ve suggested to Faux POs that the direct report relationship they have with the team is corrupting their Agile Practice, the Faux PO is incredulous! Don’t be ridiculous! They are natural leaders and visionaries! Their leadership is what is keeping this boat afloat. The team would be rudderless without them.

If everyone on your Agile team reports to you – you’re not an Agile team!

I’ve asked Faux POs if they would give up their direct reports and move their “vision” to another team as a loose-matrix product owner. They won’t. I’ve also asked if they would hire a bona fide product owner, who doesn’t report to them, and can make decisions independently. They won’t do that either.

So, I think we know what the deal is here – it’s called control – and if managers and executives are dictating the manner and methods by which work is accomplished by the team, then you’re not an Agile Shop – you’re old-school, command-control, boss-helper, my-way-or-the-highway shop, and it’s probably not going to change. Why? Maintaining a status quo (especially when you’re benefiting from it) is easier than change. Being a boss is easier than being a teammate. Hierarchy is easier than egalitarianism.

Bosses like being the boss. It’s awesome having people do what they’re told, when they’re told, without pushback or question. If only their wife and kids were like that…..

The Faux PO is a very common root-cause of Agile failure. In a risk report, it would fall under “executive-level support.” or “Unwillingness to adopt new systems and processes.” If there is an unwillingness to acknowledge these entitled behaviors or modify organizational structures, no Agile transformation can be had.

Architect as King

The Architect as King organization is really the worst of all possible Agile worlds. The team builds whatever it wants – the business can take it or leave it. There are no repercussions for crappy work, technical debt, or missed deadlines. UAT? What’s that? Open a ticket with the service desk….

The entire team, scrum master included, reports to an invincible lead, architect, or engineer, who doesn’t GAF about your process or product or metrics. You don’t like it? Do it yourself! Oh, you can’t? Oh, well. Scrum Master? Product Owner? Plueeze, The team reports to me, and your name is NOT on my performance review. Don’t piss me off, or I’ll quit, and then you’ll really be screwed….

From a product, user, and process perspective, the Architect as King organization is DOA for an Agile practice. Hire a technical writer to document the build. Anything else is a waste of money.

As amazing as this sounds, Architect as King is pretty common – especially in private or mid-cap companies. And, when I encounter a dev lead or principal architect who has been with one of these organizations since Christ was a baby, I know that this will be dev-driven development, an inelegant user experience, a shit-ton of technical debt, and I also know that nothing going to change until the king is deposed and replaced.

Final Thoughts….

It’s called an Agile practice, not an Agile perfect, and just like anything that requires practice, you’re going to suck at it the first 1000x you try to do it. But, you WILL get better. Things are never perfect, there’s always more to do. That’s why we have retros. Over time, you’ll begin to see how and why one team is better than another, why a coach is different from an owner, and how having a player in the wrong position or a hot-shot who hogs the ball can kill the team and ruin the game.

If you’re in software or tech, you’re going to have to learn to play the Agile game. Learn everything you can about it, and keep practicing. Agile is part of good project management, and good project management is Agile!

###

I hope you enjoyed this article, please check out some of my other posts and podcasts on Agile and the contingent job market. Thanks for reading!

###

Copyright 2021 Pierce/Wharton Research, LLC. All rights reserved. No part of this post shall be reproduced without permission.

How to Evaluate Your Boss

People leave managers, not companies. Be sure you hire a good boss. When workers have a good manager, they will often accept lower wages. When people quit, they’re firing you. You can’t put a price on a great boss…..

Nothing I just said is new. But, despite all the well-intentioned talent acquisition and retention initiatives embarked upon by company recruiters, I’ve yet to encounter any organization who routinely surveys a manager’s direct reports for feedback on his/her performance.

The answer as to “Why?” staff don’t evaluate managers ranges from the complex (cultural of hierarchy, management v. labor, men v. women), to the paternalist notion that a job is a “gift” that your corporate “family” gives you and you should be grateful for their kindness (versus the negotiated sale of your labor to a disinterested company who then sells the fruits of that labor to a 3rd party for a tidy profit), to the simplistic — but very real possibility of – retribution. All topics for another day.

Most of us are given a boss; we don’t get to choose one. However, if you find yourself in a position to evaluate your potential manager (or feel the need to leave an anonymous note on someone’s desk), here are ten questions to help focus your review:

True or False

~I know my boss always represents me and my skills in the best light.

~I trust that my boss is a strong advocate for me and my career.

~I believe that my boss is an effective advocate for my team.

~If there are changes or meetings with my client/workgroup, my boss informs me of the nature of the meetings so we can discuss how it might affect me or my work.

~My boss seeks to understand fully my situation or problem before s/he offers advice.

~My boss respects my work and appreciates the role I play within the company.

~My boss seeks my advice or input before making decisions that directly affect my job or affect our clients/customers.

~When I have a problem or situation I cannot handle, I am comfortable seeking advice and mentorship from my boss.

~If I were traveling with my boss, and we were stuck in an airport, s/he would make the time there better and easier.

~If I were in a position to hire my boss, I would.

What do all these questions have in common? Integrity. Respect. Leadership. These aren’t skills, they’re qualities, values. You got ’em, you practice them, or you don’t. Leaders inspire others to follow, they don’t tell people what do do. There’s no such thing as contextual integrity. You don’t get to be a great boss being respectful most of the time……

Whenever I interview with a prospective manager, I always ask, “If I were with your team at a happy hour, what would they say about you?” I’ve gotten answers that range from the hostile to obtuse…few have shown any genuine insight in one’s character, never mind management style. We all know how important a good boss is. Maybe the time has come to finally shift our focus from top down to bottom up?

Capture

+++++++++++++++++++++++++++++++++++++++++++

Copyright 2018 Pierce/Wharton Research, LLC. All rights reserved. No part of this post shall be reproduced without permission. info@piercewharton.com.

Where are my RFP Responses?

In one of my management classes, a group activity was to prepare a Request for Proposal (RFP). The purpose of the RFP was to hire an event company to create and manage a 300-person company picnic. No other specifications were given — kind of like real life.

The teams set to work creating the RFP. Most assembled a list of basic information for the vendor such as a date, number of people, and budget. A few of the groups had specific requests such as a special theme or specific venue. After a half-hour of discussion, the groups were beginning to disband, all except for Detailed Dina’s group. Detailed Dina was the project manager for her team, and she was not going to be so sloppy.

Keeping her group well past the time allotted, she insisted that the RFP include a questionnaire, which asked for references, sample menus, descriptions of other events done, for whom, when, what was the cost vs. the final budget of these events. What type of picnics had the vendor done before? What kinds of themes? For how many? She also asked for credit and banking references, and a list of their subcontractors. Dina assigned each team member a portion of the RFP, and then offered to assemble the final product herself (so it was up to her quality standards). An hour after everyone else left, Dina was satisfied and exceedingly proud of herself. She demonstrated collaborative leadership, and was a team player by taking on the task of assembling the final RFP. Dina was confident her outstanding RFP would result in a superior picnic.

The RFPs were farmed out to the vendor groups. Among the ten RFPs presented, the teams needed to choose five to meet and three to respond.

After all the presentations and discussion were completed, Detailed Dina’s RFP was not selected. Aghast at the slight, Dina demanded to know why no one selected her event. The answer was simple. There were other clients, and her application was too much. Said one team, “I know it’s a game, but it was just so ridiculous….” The instructor tried to mix it up bit. Everyone knew that Detailed Dina has no interested vendors; therefore, whomever bid on her contract was guaranteed to win the business. Wouldn’t that be easier than competing against so many others? Would any team trade creating three proposals for her one?

Lesson #1

First, Detailed Dina made an amateur mistake: She refused to scale. It’s a picnic, not a shuttle launch. Dina was so fixated on her emotional need for data because she felt that more data would help her to secure a quality vendor. Unfortunately, this project wasn’t about data, it was about teamwork and goals. Dina lost sight of the goal, which was to form a relationship with a vendor (which she failed to do), and then manage the relationship (which she was unable to do), for the company’s benefit (which never happened).

This project wasn’t about data; it was about teamwork and goals.

And, while Dina was adamant that she had a far superior RFP, and was friendly and collaborative with her team, no one could argue that if this were real life, her leadership was a failure. Bottom line: They needed a team to do this event, and she was unable to assemble a team.

Lesson #2

This story is also illustrates the shift in the American labor market. You’re hiring a <jobtitle> to do <somethingforyou>, you’re not marrying the guy! Because Dina was in a position to choose and pay the vendor, her attitude was one of entitlement. They needed to “prove” themselves to her.

Your hubris is counter-productive to building a team

And, while we all seek qualified vendors (and it’s natural to feel a little entitled when you’re writing the checks), remember that you’re not the person actually doing the work. If you’re an employer, your attitude needs to be one of partnership, not entitlement. You’re hiring someone because you CANNOT do the work yourself. Your hubris is counter-productive to building a team.

The Conclusion

Dina was surprised by the silence that followed the easy offer of her business.

Dina immediately offered explanations of the rationale behind the formulation of her RFP. The teams quietly discussed the trade-offs of a relationship with Detailed Dina. With fewer clients it could be less work – initially – but since this was a “fixed-price” bid, what was the risk that Detailed Dina would be a difficult client who needed lots of attention, extras or changes? How would that effect the time they spent on this class project?

I think we all know what happened here.

++++++++++++++++++++++++++++++++

Excerpted from: The Temp Job: A Survival Guide for the Contingent Worker. Copyright 2017 Pierce/Wharton Research, LLC.  All rights reserved.  No part of this post shall be reproduced without permission. info@piercewharton.com.

Your Culture is your Brand

I’ve been spending a lot of time thinking about culture, how it eats strategy for breakfast, and how most of us think we can’t do anything to change or affect the culture in which we live and work.  I strongly disagree, and so does Tony Hsieh, CEO of Zappos.com.  The following is an excerpt from Delivering Happiness: A Path to Profits, Passion, and Purpose.

“Building a brand today is very different from building a brand 50 years ago. It used to be that a few people got together in a room, decided what the brand position was going to be, and then spent a lot of money buying advertising telling people what their brand was. And if you were able to spend enough money, then you were able to build your brand.”

“It’s a very different world today.  With the Internet connecting everyone together, companies are becoming more and more transparent whether they like it or not.  An unhappy customer or a disgruntled employee can blog about a bad experience with a company, and the story can spread like wildfire…”

“The good news is that the reverse is true as well.  A great experience with a company can be read by millions of people almost instantaneously as well.  The fundamental problem is that you cannot possibly anticipate every possible touch point that could influence the perception of your company’s brand.  Every employee can affect your company’s brand…”

“Many companies have core values, but they don’t really commit to them.  They usually sound more like something you’d read in a press release  Maybe you learn about them on day one of orientation, but after that it’s just a meaningless plaque on the wall of the lobby.”

“We believe that it’s really important to come up with core values that you can commit to.  And by commit, we mean that you’re willing to hire and fire based on them.  If you’re willing to do that then you’re well on your way to building a company culture that is inline with the brand you want to build.  You can let all of your employees be your brand ambassadors, not just the marketing or PR department.”

“At the end of the day, just remember that if you get the culture right, most of the other stuff – including a great brand – will fall into place on it’s own.”

– Tony Hsieh

How Perfectionistss Ruin Quaity

Capture
In the early days of software (when every application came with manual), I took a class for technical writers.  Our first homework assignment was to write directions for how to make tea.  Several of my classmates had questions such as what kind of tea? Was it in a bag or loose?  The instructor said he would provide no other details except for the original task: Write directions for how to make tea.

When class re-assembled the following week, the instructor asked the students to turn in their homework.  He shuffled through the responses and chose several to present to the class. Before presenting, he requested the class hold all comments and questions until after all the submissions were reviewed.  Then, he placed the first page of Paul Perfectionist’s directions on the projector. “That’s mine!” You could see him visibly puff up. Because his directions were first up, they were likely the standard.

Paul had put together an exhaustive set of detailed directions. No detail was too small, no action overlooked, no exception left out.  Paul wrote step-by-step how to unwrap the box of tea, what size pot to select for boiling water, how to turn on the faucet, how to put water into the pot, how to turn on the stove (or light a stove, if necessary), how to set a timer for boiling water.  He created a branch for the benefits of a tea kettle verses a pot, how to choose a cup, how to lay the tea bag in the cup.  He had an alternate scenario for loose tea, including explanations of tea balls, strainers, and cozies…a couple shots of images for tea…all-in-all, there were more than five pages of directions for making tea.

The instructor continued with the next set of directions, which was also lengthy, but not nearly as exhaustive as Paul’s.  The instructor slowly continued on replacing page-after-page of instructions offering no comment on any of the efforts.

I’ve spent a lifetime as a teacher and corporate writer; I knew where this was going.  I sat back and began to look around the room. I could see some of the students’ body language had already changed. Shoulders hunched, furrowed brows — they looked confused, worse ashamed.  Had they misunderstood the assignment?  Was this more complicated than they originally thought?  Self-doubt descended like a fog.

As the presentation continued, the directions became significantly briefer.  One student (who had asked about loose or bag), wrote “One bag = 2 Tbls,” which I recall thinking was exceedingly clever copy for tea packaging. I remember Paul rolled his eyes when I complimented the writer on the usefulness of that line, “That doesn’t even tell you how to make tea!” he scoffed.  The last submission displayed was, “Add hot water. Enjoy.”

The projector went off. The lights went on.  Paul was beaming with pride.  “So,” the instructor began, “Which of these directions do you think is the best?”

“The last one,” I said quickly and with conviction.

“I agree,” the instructor responded.

Now, if you thought that Paul had a “ah-hah!” moment, you have little experience with the detail-obsessed, perfectionist disorder.  On the contrary, Paul was PISSED OFF!  Without a second of reflection, he launched into a full-scale attack on his classmates and the instructor.  The others didn’t understand the complexity of tea, and that’s why he detailed out every approach to it. These brief responses indicated his colleagues were lazy and didn’t want to do the homework.  It’s clear they took a short-cut in the assignment, which is why they wrote so little. Paul assured everyone that he had spent a lot of time working on this, and making tea was much, much, more complicated than we really knew.  No one had even thought to include images!  What if someone didn’t know what a teabag looked like!

My personal impatience with the narcissism of perfectionists notwithstanding, I gleefully threw coal in his furnace and offered that I wrote no directions at all; rather, I documented an audience assumption that tea – a staple of every kitchen in every culture – is something the audience or purchaser would already know how to make.  It’s not an enchilada.

Other real-world rejections of Paul’s work quickly followed: Tea does not come with directions now, why would we need them in the future?  No tea company would ever create collateral or change packaging to accommodate five pages of directions. No one buying tea would ever read a five-page insert if they did. Another pointed out that Paul’s directions (literally) included a section on how to boil water! Knowing how to boil water was the same reason light bulbs didn’t come with directions. Ha-ha. The class chuckled, the fog of self-doubt lifted, and there was a sigh of relief from those who had not crafted lengthy directions. Paul, however, was not amused.  He insisted that it was possible some men could not know how to boil water or turn on a stove (although most women were likely to know this, he conceded). Then, finally after all his other defenses were exhausted, Paul played the “safety” card (aka: the Hail Mary of all corporate disagreements), and strongly asserted that without directions someone might burn themselves or ingest the tea bag, which could result in a law suit…

The Lesson

Paul was a student in a class of colleagues, so the ability to critique his work is assumed.  That is rarely the case in real-life. Imagine if Paul Perfectionist were a manager, lead or (heaven forbid) stakeholder?  Given Paul’s predilection toward perfectionism, if he were someone’s boss do you think he would be open to a less-detailed approach or would he just see that as sloppy?  What are the chances that a peer – never mind subordinate – could call Paul out on his emotional need for detail?  Even if some courageous person did tell Paul he was being ridiculous, do you think the rest of the group would jump in and support their colleague’s “sloppy approach” compared to Paul’s exhaustive completeness?  Lastly, with so much ego and emotion displayed by Paul, even if the group felt that Paul’s directions were expensive or might result in a negative outcome, how likely is it that they would coalesce to fight actively against him?  Or do think it’s more likely the group would just “deal” with Paul because they have families to support and just don’t have the energy to argue with him anymore….?

Paul and Polly Perfectionists exist in every business. What all these perfect people have in common is the same narcissistic misconception that they – alone – can assure quality.  We euphemistically call them “bottlenecks” or say they need “special hand-holding.”  In private, we call them high-maintenance PITAs, and tell colleagues to circumvent them because do nothing but cause spin and churn.

Perfectionists are the most destructive of leaders and teammates because they talk non-stop about quality, but they don’t listen to quality. Quality is not a person. Quality is not a checklist. Quality is a process.  A quality processes requires a team, and the perfectionists of the world never have a good one because teams require honesty, communication, and trust.  Perfectionists don’t understand that state of being.  Their lives are filled with fear, suspicion, and distrust.  It haunts them at work; it strains their personal relationships. A Paul Perfectionist may run a team, but he rarely considers himself a part of that team because – qualitatively – he is sure he is above the others and perfectionism is not a flaw.

Excellence is a value; Perfectionism is an insecurity.

Everyone should take pride in his/her work, everyone should have input, but when I see over-engineered and voluminous solutions, I don’t think, “Ahh, so smart!” Rather, I corner my teammate(s) 1:1 and ask questions.  Inevitably, I’ll hear “Yeah, we had to do <whatever> because <controlfreakperfectionist> is a PITA, which is why we’re <late/over budget/short staffed>. Avoid them if you can….”

Over the course of my career, I have been amazed at the number of high-priced consultants and internal project teams who churn away days and weeks of expensive time adding linguistic dandruff to presentations, plans and proposals whose only goal is to sooth the emotions and ego of someone who is sure they’re adding quality.  CapEx budgets become bloated by stakeholder reviews and timelines are delayed all because no one going to jeopardize the financial stability of their family by telling Paul Perfectionist that we don’t need five pages of directions on how to make tea.

The Conclusion

The instructor cornered Paul during break and tried to talk him down, which was not easy because perfectionists are quite sure that you aren’t smart enough to see the world as clearly as they, and who are you to criticize their drive for perfection anyway?

The instructor explained to Paul the purpose of the class (and education, in general) was to challenge pre-conceived notions. Audience is the most important consideration in any communication, and Paul did not consider his when writing his directions.  Although Paul reluctantly agreed that perhaps boiling water was a bit much, he would not relent on the other stuff.  Besides, even if fewer directions were acceptable, more paperwork and detail is always better. I mean, this is tea, sure, but in real-life, in business, there would never be a time where more documentation or direction would be worse, right?

The instructor asked Paul to keep an open mind, and then politely turned to another student who had been patiently waiting.

Paul never came back to class.

++++++++++++++++++++++++++++++++

Excerpted from: The Temp Job: A Survival Guide for the Contingent Worker. Copyright 2017 Pierce/Wharton Research, LLC.  All rights reserved.  No part of this post shall be reproduced without permission. info@piercewharton.com; Follow on Twitter and Facebook @TheTempJob

Blog at WordPress.com.

Up ↑