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.
Footnotes