How Would YOU Caption This?

This cartoon and it’s original caption, “Describe what you can bring to this company,” has gone viral on Twitter and FB. I’ve collected a few hilarious – and a few very pointed – responses off the various feeds, and I would like to hear….

How would you caption this?

~Well, you are the most qualified, but I’m not sure I want to get a beer with you.

~I don’t disagree with your recommendations, but you need to tone down your presentation. You don’t want to sound bitter.

~We are ready to begin the inquiry into the sexual harassment complaint you filed.

~If you work really, really hard and prove yourself, we might consider hiring you full time.

~I’m not sure that the team will respond to your management style.

~The most important thing is we hire someone who reflects our culture and values.

~I’ll have the turkey wrap, and make sure there’s enough cookies and water for the afternoon.

“~~my life debating Republicans in committee each week.” – AOC

~I’m not sure you have the leadership skills for this job.

~We’re looking for a team player. Are you a team player?

~If all you bring is your gender and skin color, then you aren’t worth very much.”

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.

The Vol-en-Told Analyst: Three Things NOT to Do

So, your <checkwriter> has determined you can’t afford an analyst for your technology project.  Instead, they want you to do it. (You? Have they met you?)  After Googling “business analyst,” and “elicit” you realize you’re even more clueless than you thought.  Worse, your PM and development team just asked you what the team should start working on….

I can’t teach you to be me, but I can tell you a few things I definitely would NOT do…..

Don’t Become Immersed in Current State

Resist the temptation to become (another) subject matter expert (SME). Chances are you’ve got lots of people in the weeds.  Ask them about the swamp; do not get in there with them. You’ll learn along the way…

Too often novice analysts (and insecure project managers) focus on mastering (and tirelessly documenting) the current state – as if having a Visio now makes it okay to finally get rid of it!  Business process owners are also guilty of the “let me show you ….” instead of providing an answer to your question. Steer clear!  If not, you’ll find yourself burning week(s) learning and flowing out someone’s job when all you really needed was agreement on a data set for the cloud architect.

Unless current state flows and docs are a specific deliverable in the project’s SOW, don’t waste time documenting system’s past. Focus your efforts on eliciting the information you need from your SMEs to define, build, and document future workflows, future components, future interfaces, the future.

Don’t Be Afraid to Assign Deliverables

One of core responsibilities of the team’s analyst to provide the infrastructure and artifacts needed by the appdev (and devops) team so they can build (and test) software.  That doesn’t mean that the analyst is the only person who has to write stuff down.

Every team has a different division of labor, and each analyst has a different style and approach.  Style notwithstanding, we can all agree that I cannot do a Vulcan mind-meld with the DB architect.  I need a schema and component diagram (regularly updated) regardless of how busy you are. Similarly, business process owners aren’t exempt from writing stuff down, either.  I need a list of the exact data points everyone wants retained.  Another demo of “how I do it now,” isn’t a deliverable.

The beauty of a Waterfall effort is that there are clearly defined inputs and outputs. The Gantt is not forgiving.  It shows everyone in the room if a gate is open/closed, and who/what is keeping that gate from closing.  The beauty (and curse) of Agile is that it’s much more flexible. Things requiring more discussion, bigger decisions, “grooming and refinement” can easily be re-prioritized in favor of backlog items upon which there is violent agreement.  As an analyst, you offer insight and best practice advice, but at the end of the day, deliverables codify key business decisions. I can’t make those for you.

Don’t Forget Whose Side You’re On

Whose side are you on?  The Development Team. Period. Why? Because that’s the team you’re actually a part of, and they’re the people doing the work (for you.)

If you’re new to being an software analyst, you will quickly see that your seat in the development team is to articulate the client/business vision.  That doesn’t mean you’re the client.  Conversely, when you sit in client meetings, your role is to be a relentless advocate for the development team.  But, that doesn’t mean you can make decisions or agreements on their behalf.  Being the “creamy filling in the Oreo,” can be difficult.  Empathy, and helping others to have more of it, is an essential skill.

The reality is that no matter how smart you are and how much you’ve thought about something, you’re going to make a mistake or mis-assumption.  Analyst’s mistakes are built into the code, seen in public – sometimes in really big meetings.  You can’t let your client blame the “stupid developers,” when you know full well your poorly written acceptance criteria was the cause.  If you throw your team under the bus – even once – you will quickly regret your lack of courage.

Final Thoughts

There’s a certain amount of frustration involved in the analyst psyche. You’re usually on a steep learning curve, and time is not endless.  You have to accept ambiguity (sometimes a lot of it) and push forward despite unknowns. Learn to say, “I haven’t gotten there yet,” “That was my mistake,” and “We can do it, but it will take more time and money,” and you’ll be just fine.

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

Copyright 2017 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.

Blog at WordPress.com.

Up ↑