Tag Archives: career

7 things employees wish they could tell their boss about salaries

LinkedIn had an interesting article Friday whose title I snagged for this blog post.

The 7 items are:

  1. We don’t care about pay scales
  2. Forget policies. We talk.
  3. We think about our pay a lot.
  4. We will sometimes let you take advantage.
  5. When we have to negotiate … we both lose.
  6. No matter how much we earn, it’s not enough.
  7. Still, reasonable pay is ok.

Several of the points resonated with me – especially in light of things I have written previously.

“If the company can’t afford to pay an employee more, smart bosses say so. If they think a certain percentage raise is fair, they explain why. Smart bosses use pay scales to build their budgets, and use reason and logic – and empathy – to explain pay decisions to employees.”

Can’t agree more: if you don’t treat your employees like rational, smart human beings, but rather like mere resources – you create and/or perpetuate a culture of dehumanization.

“Many companies actively discourage staff from talking to each other about their salaries. I know a few companies that require employees to sign agreements stipulating they won’t disclose pay, benefits, etc to other employees.

Doesn’t matter. Employees talk. I did, both when I was “labor” and when I was “management.” Generally speaking, the only employees who don’t share details about their pay are the ones who are embarrassed by how much or how little they make.”

Yes, yes, a million times yes! In my blog post “publicizing compensation – why not?“, I point-out that forcing people to not talk about their compensation makes folks more likely to try to find out, and can lead to discontent.

“Employees think about pay all the time. Every time they deposit their paychecks they think about their pay. To a boss their pay is a line item; to employees, pay is the most important number in their family’s budget.”

Funny thing is: managers get paid, too – but rarely think about that when it comes to their employees.

“Occasionally the job market is a seller’s market, but many new employees are just really happy to land a new job. And since business owners are born cost cutters, it’s natural to hire every new employee for as low a wage as possible.”

This is related to the next point …

“Great employees are worth a lot more than their pay. You get what you pay for, so smart bosses pay whatever they can to get and keep the best employees they can.

When smart bosses find great employees they always make their best offer, knowing that if their best offer is too low, there is nothing they could have done.”

If you want to be the best possible employer ever, you need to start with your best offer to candidates. If you start with anything less than your best, you’re implying that you don’t really value their time, expertise, or potential contributions to your organization. It has been said that “everything is negotiable” – but if you don’t start with your best offer, you’re telling your current/future employee they have to make you want them more. It may turn out that your “best offer” is $120,000 per year with 3 weeks of vacation. And maybe that employee really wants 4 weeks of vacation – and is willing to accept a somewhat lower salary for that perk. Start with your best, and then massage it into what is best for both of you.

“We all want more. It’s natural. Unfortunately no boss can always give more. And that’s okay.”

Wanting more is not inherently wrong (though wanting more for merely the sake of more is probably unhealthy) – and that’s why the last point in this article is so smart:

“People are smart. They understand market conditions, financial constraints, revenue shortfalls, and increased competition. They understand when a company can’t pay top-of-market salaries. What they don’t understand is when they don’t feel fairly compensated compared to other employees in similar positions, both inside and outside the company.”

“Fair is a concept that only exists in economic theories not based on effort.”* When you look at services like Glassdoor, you can quickly see that salary is only a single facet of employee compensation (and important one, and [generally] a large one, but only one). And it’s easy to get caught-up in the mindset of keeping up with the Joneses. While it is nice to have “more”, it’s important that honesty and transparency flow from management to employees as well as the other way around.


* publicizing compensation – why not?

what to automate

I have been in the world of automation for quite a while. Specifically in the realms of server, datacenter, and cloud automation – but I’ve been interested and/or involved in other tasks that tend towards automation (even for a short period of time) for far longer than just my post-college time in the world of HPSA and its related ilk.

One of the first questions customers ask us when we arrive onsite (heck – even way back in the technical presales cycle) is NOT what can be automated, but rather what should we automate and/or what can we automate first.

Analyzing the environment and finding some prime, low-hanging fruit to target in an initial automation push is vital.

To quote Donald Knuth, “We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil.”

In the realm of automating, that means picking on tasks that, while the tools at hand can make quick work of them, are done so infrequently as to not warrant an immediate focus, since the ROI on infrequently-done tasks is not going to be readily seen* should be skipped.

This is part of where being a good architect comes to bear.

No.

That’s not true.

This is where being a good listener and collator comes to bear. In a future post I’ll talk more fully about the art of architecting – but for today’s topic, let’s focus on the true key personality traits you must display to get a successful project started, implemented, and running.

You need to listen. You do not need to “hear” – you need to process what is being said, ask it back, take notes, ask for clarifications, etc. In the counseling world, this is called “active listening“. In the rest of life, it’s called being an attentive, thoughtful, caring, intelligent, adult human being.

When you hear a customer say they have a real problem with some task or other (beware – managementspeak coming!) – ie, they have “pain points” in various places, ask about what those individual tasks are actually comprised of. Investigate what can be touched today, what can be planned-for tomorrow, and what needs to be tabled for a future engagement (for you architects and sales folks reading, this translates into “what can we sell them later – after this project is successful?” – how can we build and strengthen this relationship?).

Take these notes and conversations you have to your colleagues and tease-out coherent lines of attack. Collate all the notes form everyone involved into commonalities – what has everyone heard a customer say? What did only one guy hear? What order did each person hear them in?

After you’ve listened, after you’ve taken your notes, after you’ve powwowed with your colleagues – then comes the fun part of any engagement: the actual automation!

Bring your cleaned-up and trimmed-down notes back to the customer in an easily-digestible form, and give a solid plan for what we will do now, what we want to do soon, and what really needs to wait to be done til later. Put an N, S, or L next to each item on your list. – it’s a first-cut priority draft. Then ask your customer for how they view those tasks, and listen to what they say are their priorities (including “real” dates, if any exist). You may need to reorganize your list, but keeping it involved in all project discussions will show you’re truly paying attention to them.

And at the end of the day, everyone’s favorite topic is themselves. Always – even shy people want to hear themselves bragged-up, talked-about, promoted, and given attention.

When you showcase your individual focus and attention on your customer, it will show in their willingness to accept you into their closer rings of trust – their readiness to receive you as a “trusted advisor”, which is what you want to be for them: you want to be who they can talk to about problems they’re seeing in their environment (current or potential) so you can bring your expertise to bear on their issues.

The role of any consultant who wants to be more than a mere grunt is not so much technical or business acumen, but that of their business therapist and/or best friend. You want to be able to say with Frasier Crane, “I’m listening”. And you want them to know that you really are.

Some of the early steps you can take today to bring yourself there are to:

  • avoid electronic distraction in meetings
  • document everything you do for work
  • be detailed
  • know industry trends, what competitors are doing, etc
  • treat everyone you come in contact with at a customer as if they were the most important person there
  • anticipate what you may be asked, and where you want to go
  • never speak authoritatively about that which you do not know
  • learn – be a “Lifelong Learner”: the day you stop learning is the day you stop growing, and the day you stop being reliable to others

*Unless, of course, those infrequent tasks are only infrequent because they’re “hard”, and therefore automating them will yield a solid ROI by allowing them to be done more often

the seven stages of expertise

I recently found The Seven Stages of Expertise in Software Engineering.

  • Stage 1: Innocent
    • barely knowledgeable if at all
  • Stage 2: Exposed
    • seeking knowledge
  • Stage 3: Apprentice
    • has read case studies and tries to apply those techniques
  • Stage 4: Practitioner
    • can actually apply concepts learned in one context to a not-identical context
  • Stage 5: Journeyman
    • professional understanding and application of the field; can mentor
  • Stage 6: Master
    • moved from “whats” and “hows” to “whys”; can mentor very effectively
  • Stage 7: Researcher
    • the teacher, presenter, mentor, speaker, evangelist, writer, authority

Presented firstly in the humorous guise of The Seven Stages of Expertise in Bear Hunting, Meilir Page-Jones makes a highly-compelling case for progressive advancement in [nearly] any field.

Some of the ideas seem similar to what Malcolm Gladwell brings in Outliers (review) or Robert Greene does in Mastery (review). Which seems to only lend more credence to those other works, given that this article is © 1998.

unsales

I am a huge believer in unsales. And not in the pharmaceutical industry sense.

Because “shipping is a feature“, and because I intensely dislike the “do it for me, then hand me the keys” mentality, I routinely follow the unsales methodology.

What is unsales? It is [almost] only selling what a customer can use today. I want to give a customer something they can both use and play with. I want to give them something at the end of any engagement that does actually accomplish something. But I don’t want to do everything for them – I want them to learn, explore, and discover their own use cases. As they discover what can be done with the tools they’ve purchased, they can start to engage in the paradigmatic shift from “automating” to “automation“. And as they explore, discover, and build, they’ll start to see where further services, training, or products can be brought in to do more.

Some people believe in the “moneyball” approach – sell everything (especially the big-ticket, high-margin products), and then let the customer more-or-less fend for themselves after some extended period of services work.

This is good for the vendor doing the selling … but only this quarter. If you sell “everything”, you have no basis to come back to the customer. You’ve developed no relationship. You’ve only “made a sale”. You’ve followed the Walmart model – sell what you can, when you can.

The better model, in my opinion, is the relational model wherein you spend time getting to know the customer’s employees: the engineers, managers, officers, etc. Get to know them personally, and become someone they can turn to as a “trusted advisor” regarding their pain points.

Relational selling (and working, for that matter) tend to lead towards long-term partnerships, engagements, repeat business, etc.

You can take the short-term view, or you can take the long-term view. One yields consistent returns, one may only ever give a single return.

Be relational.

the value of face-to-face

I have been working from home for nearly 5.5 years.

The benefits are myriad – not least of which is the minuscule commute and savings on fuel, eating out, etc.

Sometimes I travel for work. This accomplishes many good things – a chance to put faces to names and voices, get a chance to read faces and body language instead of just vocal tones, engage more of a customer’s engineering staff, etc.

Remote meetings (Skype, Lync, Google Hangouts, Webex, GoToMeeting, etc etc) are fantastic tools. Being able to work via VPN or other tools is amazing.

But nothing can replace the face-to-face meeting. Video calls are good, but not a full replacement. As more and more employers embrace optional and/or suggested remote work arrangements, workers can be more and more productive – with less downtime and wasted time (eg commuting).

But never let the power of remote engagement become a full replacement for the power of personal connection when in-person.

new documentation should always augment the status quo

In my line of work, I often need to create documentation for clients.

Documentation in general is a Good Thing™.

But good documentation’s goal should always be to augment and improve upon what already exists – not to supplant, downgrade, or muddle what already exists.

A prime example of this has come up with a client partner recently. They asked for “as built” documentation. They failed to define that term. It turns out that their definition of “as built” is a “screenshot-by-screenshot” replacement of the vendor-supplied installation and configuration manuals.

This is a phenomenal waste of time, effort, and space. “As built” should mean to note any deltas or site-specific configurations that vary from or augment the vendor-supplied manuals.

Why is this the case? Because recreating vendor documentation means attempting to do a better job of documenting a product then the people who wrote it! The odds of you being able to do this are extremely low.

In fact, I’d go so far as to say you cannot do it. Ever. The vendor has dozens, scores, hundreds, or even thousands of man-years of experience with the product across the whole team. They know where the source code sits, and can reference it directly. They have the ability to truly say what is and what is not authoritative on the product.

You will never be able to outdo them. Even if you have been using the product since it was in pre-alpha form, you cannot, as one person (or even an outside team of people), possibly have as much experience as the development and documentation teams that design, build, and describe the toolset. They don’t just hold the trump car, they are the trump card when it comes to how something works.

Whenever you document a process, make sure that you document anything that is site-specific about what you did. Make sure you reference the vendor’s materials as often as feasible to make sure you backup your claims and directions with authoritative data.

But don’t worry about recreating what the vendor has already done – your documentation, in this regard, will never be as good as the vendor’s: they publish errata notices, updates, etc. You have to do the same to have a remote chance of matching them.

You will not be successful.

Focus instead on making great documentation that goes hand-in-hand with vendor materials to supplement them; don’t try to supplant them.

always use verbose output when troubleshooting

In my eBook, Debugging and Supporting Software Systems, I wrote about several aspects of submitting good bug reports and support ticket, how to communicate, and more.

If you’re ever troubleshooting a problem, it is universally helpful to enable the most verbose output possible in logging (stdout, stderr, and log files). You may not want it on all the time – but when there are issues, it’s vital.

It’s especially helpful if, as a group, you are involved in a ticket smash.

Verbose output saved me just this week in seeing that a bind mountthought was working properly was not (and causing an entire install to fail).
Thanks, –verbose 🙂