2 - "Humans, Not Resources"
===========================
In most businesses of any type, the people who make up the business should be
the biggest consideration. They make the processes work, they solve the
problems & innovate, they (usually) are what cost the most.
Therefore, it makes the most sense to focus on the people next, specifically
your Engineering department. Let's deal with common misconceptions first:
**"Humans, Not Resources"**
As the title says, they are capital-H *Humans*, not *Resources*. A resource
is a uniform raw material (e.g. wood, metal, glass). Within their category,
they're largely completely interchangable. And you *expect* to **consume**
them in the process of making something else.
But that's not true of the human beings that work for you. True, some of
their skills have (significant) overlaps. But their experience, their
thoughts, their approaches, & their situations (at work & outside) are all
very different. So you should not treat them as interchangable resources, but
as the people they are.
And if you *expect* to **consume** people, you're designing for burnout,
resentment, & turnover. Stop wasting your time, & stop reading here.
**Work Should Be Their First & Only Priority.**
Sorry to be the one to break it to you, but these are human beings. They
have rich & diverse lives outside of work. Many have families, and/or a
network of friends.
Even in the blackest/bleakest of work conditions, they spend at most half
their time at work. They may work for the company for a handful of years. In
the context of their life, you & your company are a blip (or a bump) on the
timeline.
If you want to be remembered well & want your workplace to be great, you
must support a healthy work/life balance. Extra hours, emergencies, unplanned
trips, etc. will all happen, but they're easier to accept (& put in your
best) in they're not the norm.
**They Owe Their Loyalty To The Company.**
At past times in history, this was the case. When there were society-changing
events (e.g. Industrial Revolution in the West), when there were no other
options (e.g. large-scale depressions), when companies took care of their
employees *beyond retirement*.
We don't, and haven't, lived in this world for a long time now. And unless
your company somehow either literally owns their body, or somehow saved them
from death, the people you employ **DON'T** owe you their loyalty.
In the modern era, you're employed At-Will. Companies will terminate you, at
any time, for any reason (& sometimes no reason). What's often overlooked is
that this is a two-way street.
If you want their loyalty, you need to earn it. And you need to expect it
in moderation, because there is almost always someone in their life (e.g.
spouse, partner, children, parents, etc.) who has or deserves more of their
loyalty.
Early on in my career, a friend once told me: *"When you're on your death bed,
it won't be the company by your bedside, it'll be your family & friends.
You won't be wishing you spent more time at work; you'll be wishing you spent
more time with these people."*
You work with Adults, so treat them like Adults.
So, with the misconceptions out of the way, what're some positive things you
should be doing?
Results, Not Hours
------------------
This one can be devisive, but hear me out:
.. important::
As a rule of thumb, I couldn't care less *what hours* my people work; I care
about *the results* they produce.
Especially in Engineering, the vast majority of the effort in
producing/maintaining a product of service is **non-mechanical** and
**non-linear**.
It's the work of the mind, and minds aren't machines. Minds aren't reliably
productive all the time, they work in fits & spurts, and they are not solely
dedicated to one task/one situation.
We've all had times where we're In The Zone™, periods of intense productivity.
We had a flash of insight, finding a solution that's novel, or will save an
immense amount of time/effort. Or we're feeling inspired and motivated,
effortlessly churning through work in a fraction of the normal time it would
take.
Conversely, we've all had times where we're sluggish post-lunch. Or we aren't
sleeping well, & are struggling to get started. And that's not even including
the curveballs life throws at us: our child needs to go to the doctor, a death
occurs in the family, a friend needs a pickup at the airport.
And, perhaps surprisingly, in my two decades of experience in the industry,
the company *almost always* comes out **ahead** regardless. If you have
motivated, happy, fulfilled employees who like their jobs & like what they work
on? They're personally invested, & they make damn sure the job gets done and
done well.
The **results** of the employee's efforts are what sell the product, not their
time card.
In practice, this looks like:
#. Communicate the expectation of results, not hours.
#. If necessary, setup a subset of the day as "core" hours, where everyone has
overlapping time (to facilitate setting up meetings, pairing, etc.). Keep
this window as small as reasonable/possible.
#. Communicate the expectation that people let their manager and/or team know
ahead of time if they'll be unable to work some portion of "core" hours.
#. Ask people to setup their (shared) calendars to reflect the hours they
normally expect to work, & to keep their calendars up-to-date.
#. Then just focus on measuring results, not timesheets.
.. note::
Of course, there are exceptions to this. Some may try to abuse the
flexibility, or there may be extenuating circumstances, or if your company
has contractual obligations to external parties for dedicated times.
Generally, if it's interrupting others, or if it's affecting results, it's
time to talk with the employee & try to work through things first. There may
be something in play that you're unaware of, or that they can't control.
Be clear in communications, in recording of meeting with the employee, in
the affect on results/others, and use good judgement on when more is needed.
You work with Adults, so treat them like Adults.
Trust
-----
Short of handing over the *"keys to the kingdom"*, you put your trust in your
employees to the **greatest extent** possible. If you can't trust your
employees, maybe it's time to *re-evaluate* either your hiring practices or
yourself.
.. note::
I define *"Keys to the Kingdom"* to be things like: root AWS credentials,
my passwords, my private SSH keys. Things that could be used to immediately
& irrecoverably destroy the business.
And. That's. All.
Everything else should be fair game, with process/accountability/auditing
to back up such access.
I've been at several companies, where management (knowingly or unknowingly)
tries to hoard access, or demand they're the final sign-off in pull requests,
etc. It always has an adverse effect on the company, sometimes to a massive
extent. If you fail to trust your employees:
* You become the bottleneck of all operations
* Your time becomes incredibly fragmented
* You will experience interruptions at **ALL** times of the day
* You, as a human, will deteriorate into a mess
* All while dragging down morale without even trying
While I'll cover this more in future sections, what you need to do is exactly
the opposite: put as much power as you can into your employees hands and
**trust** in them. While this can be hard for some to do, the more you empower
your employees, the better off the business is.
* You reduce your impact on day-to-day operations
* You get to focus on your job, making the organization run & grow
* You can afford to take time off & disconnect, like all *knowledge workers*
need
* Morale is boosted, because your people can solve problems without you, feel
good about being trusted, **and give their trust in return**
If you can't go *"whole hog"*, experiment with giving out more in small
increments. Give a team complete ownership of a single service, or change up
your review process to alert you but not require your sign-off, then monitor
how it changes employee behavior. You may be surprised at the results.
You work with Adults, so treat them like Adults.
Respect
-------
Along the same lines as **trust**, you should be giving your employees your
utmost **respect**. And you should be requiring they do the same for everyone
else.
.. note::
I'd go so far as a well-communicated zero tolerance policy. Unless it's
playful banter between friends, being disrespectful never necessary in a
business setting. There are other, better, ways to handle things and this
is a slippery slope.
If you need to be disrespectful, save it for either deep-in-a-beer-after-work
between friends, or ideally in a session with your therapist.
When everyone is (required to be) respectful of everyone else, it creates an
environment where it feels safer to ask questions or make suggestions,
where there are fewer unnecessarily/accidentally hurt feelings, and less
resentment. This is positive for everyone, but especially for junior employees
and minorities, which just turns into further/accelerated growth.
You work with Adults, so treat them like Adults.
Autonomy
--------
And the third pillar of this trifecta, give your employees as much **autonomy**
as you can. This is part of being a good manager, delegating to others, and
builds off the **"A Seat At The Table"** tenant.
Everyone wants to feel like they at least have a say in their own fate/destiny.
It's your job to enable them (with the bonus that, when done well, it reduces
your workload as well).
Have your senior/staff engineers assist with project planning/roadmap, have your
junior engineers help their seniors in feature planning, offer them chances to
give feedback about how things/processes work **AND** make visible changes as
a result.
You work with Adults, so treat them like Adults.
No SPoFs
--------
In the industry, the acronym **SPoF** stands for: *"single point of failure"*.
This is a forever ongoing process, but you should strive for *zero SPoFs*. Not
in your processes, not in your product/applications/services, and critically,
not in your employees. This includes **you**.
An SPoF is usually the result of either a shortcut, an unaddressed point of
growth, or someone erroneously thinking it will make them *"irreplacable"* in
the name of job security.
But it what it is in practice is a **danger** to the company (& by extension,
everyone who works there):
* A technical SPoF can lead to downtime, which kills customer trust, revenue,
perception of the company.
* A process-based SPoF leads to inefficiencies, & worse, the *acceptance* of
such inefficiencies elsewhere.
* And a human-based SPoF leads to **overwork** & **burnout**, while holding up
everyone else, usually unnecessarily.
You may not be able to deal with the SPoF immediately, but by combining early
identification, widespread acknowledgement/communication of the issue, and
prioritizing addressing them (say, within the next quarter) + following through
goes a long way.
Blameless Errors
----------------
When the site goes down, or a major bug is found, it can be tempting to point
fingers. And **nothing** creates a **toxic** workplace environment quicker
than allowing this. It creates an environment where:
* People are afraid to make mistakes
* They hunker down & choose only the *"safe/quiet"* choices
* They are afraid to commit
* ...And where resentment can flourish
The solution is to enforce a *blameless* environment. And the best part is that
it's easy & well-trodden ground to do.
First, *accept early/widely* that mistakes and/or downtime will happen, and
build a process for handling those classes of mistakes quickly. A
troubleshooting playbook can go a long way in this regard. Your target: a living
document, that handles 90% of situations, with step-by-step instructions that
can be copy-pasted in the dead of night by your most junior employee, & updated
by everyone.
Second, when an incident happens, there's no finger-pointing or blame. No one
suffers punishment, no one's pay is docked, no one is fired. In practice, it's
rarely just one person's fault anyway. Maybe there weren't enough safegaurds
in-place, or something was missed in code review, or maybe something needs
automating instead of a fallible human process. Regardless, it's a broader
failing by the *team/department*, and it's simply something that *needs fixing*.
Third, setup a **"5 Why's"**. The team that owns the code/service should start
a document that drills into what happened. Start from the highest level (e.g.
*"Service X went down, causing an interruption of feature Y for customers"*),
then answer why this was the case. To that answer, ask *"Why"* again & answer
that. Typically, try to get about 5 layers of *"Why"* deep. Keep it factual; no
emotions allowed.
Finally, hold a review meeting. Include other people from other parts of
engineering, to serve as accountability/information-sharing. Go over the
document, establish a checklist of short-term & long-term fixes,
assign responsibility of those items, & hold people accountable to results of
those items.
.. note::
In this document, it's OK to acknowledge specific commits or actions by
individuals. This is part of fact gathering, but it **NEEDS** to remain
facts-only.
It's easy, as the person at fault, to feel tremendous guilt/weight from an
incident. It's management's job to *allieviate* those feelings from the
employee.
Let them volunteer to create/manage the document, or have them present the
document at the meeting, or to take on the short-term fixes. Nothing feels
better than being given a chance to fix your mistakes. But do **NOT** let
them take the blame.
Lead-By-Example
---------------
Finally on the topic of humans, let's address the one human I know this will
affect: you.
This section assumes that you're interested in workplace culture, and that
someday, maybe right now or maybe the far-flung future, you may have a say in
creating that culture.
As someone tasked with managing other human beings, their wellfare, enjoyment, &
sense of fulfillment are in your hands. There's also the aspect of power, as
it's all in your control.
I'd urge you to *put aside* those feelings of *control*, and to save them as a
last-resort.
This [1]_ is [2]_ a [3]_ well-researched [4]_ area [5]_, with plenty of books [6]_ &
how-to guides. So I'll let further reading on this to be an exercise to the
reader.
Instead, I'll offer some practical ways you can do this in the everyday work
environment:
**Write scripts to make people's lives better**
A little bit of *"managerscript"* can go a long way, especially if you bite
off *something small* no one else has time/priority for. Maybe it rolls up
the weekly commit history by author for reporting. Maybe it's a small tool
that makes deployment easier. Maybe you get a small start on adding metrics
to one small chunk of the codebase.
Your code doesn't need to be great, just improveable. This can also be a
great starting place for junior engineers to improve upon things between
projects.
The actual result is that your employees see that you care about them, and
are trying to work with them on an even footing.
**Communicate the fruits of your labors, and seek feedback**
From the trenches, it can be hard to see what leadership is doing. Rather
that allowing presumptions/guesswork, share what you're working on with
your employees. If they're doing standup, join in, even if it's just
occasionally (more in the next section). If it's high-level planning, share
initial version with your senior engineers, & gather ideas or feedback on
prioritization. If it's internal company wins, like getting a budget
increase, share that good news.
**Be the shit-shield your team needs**
I'm trying to keep the language in this guide relatively clean, so please
keep that in mind as I re-emphasize:
**Be the Shit-Shield Your Team Needs**
There will always be demands for your people's time, for errors made, for
unexpected delays and/or overruns. You could let these flow through to your
team unabated, but I'd urge you to reconsider.
These things represent diversions at best. And at worst, they can be
unwanted/undesirable cultural leaks from other parts of the company.
This doesn't mean you shouldn't let your people know, or have them handle
tasks to appease other parts of the organization. But, framed another way,
this is a chance to protect the team you've worked so hard to build & care
for. And you have the power to do something about it, which they (likely)
may not have.
Finally, it's your chance to positively/gently affect the rest of the
organization, to guide them towards how you'd like them to interact with
Engineering.
Take the time, and be the shield they need.
A friend from the past once phrased it as: *"As the manager, you should work
FOR your employees, not the other way around."*
You work with Adults, so treat them like Adults. And they are Humans, not
resources.
.. rubric:: Footnotes
.. [1] `"Impact of Leading By Example on Employees' Organizational and Job Psycological Ownership" `_
.. [2] `"Leading by example: The case of leader OCB" `_
.. [3] `"Words and Deeds - Experimental Evidence on Leading-By-Example" `_
.. [4] `"The Integrative Effects of Leading by Example and Follower Traits in Public Goods Game" `_
.. [5] `"Like It or Not, You Are Always Leading by Example" `_
.. [6] My personal favorite is `"Managing Humans" by Michael Loop `_.