Stories, and Meaning [at work]

Tl; Dr: All people are motivated by meaning of their work. The ability to shape the “stories” that we tell ourselves gives meaning and thus is an essential motivational tool. This meaning is also key for personal satisfaction.

Let’s consider a standard engineer. There are a lot of “outlooks” this engineer might have. I’ll go over 5 out of thousands of possibilities just to illustrate some variety:

  • I’m the star engineer here, and I’ll turn this place around. Others might not quite see it yet, but it’s only a matter of time.
  • I’m a great engineer but nobody appreciates my work. How come that other engineer got promoted, I don’t think their work is as good as mine. I should run the company, the CEO is only CEO because he has blue-blood 1% investor friends. The world is rigged against me.
  • I’m so excited to be an engineer. I earn multiple times the median household income and I get perks too, while my other friends are still paying off their college debt.
  • Work’s good. It’s just a job though.
  • Why am I always the one under pressure? Nobody ever thanks me no matter how hard I work. Why do I get mistreated? I’m such a victim. It’s not right.

What I’m proposing is that the same engineer having the same experiences could retell that same experience in any of the ways I listed above.

In fact, you’ll find that a lot of people gravitate towards common narratives. I have a friend, let’s call him Fry who always sees the same story: The big guy is mistreating the little guy. One thing I learned quickly was that he liked and actively chooses (if not entirely consciously) to see the world in these terms. And if I want his help, I can motivate him by giving him a rebel story he can play a part in.

For example, if I’m trying to create a new tool, I could tell it in a way that plays up the opposition, especially if it’s an entrenched “senior” group that’s cautious about new ideas, and it’ll make him want to help.

Everybody has a narrative or two that resonates with them. I have another coworker, Bender, who always promotes the story: People are stupid. I know not to try to change his story, because it’s a choice and likely inspired by some very frustrating life experience (I imagine those frustrations are valid, albeit rather long-lived). If I need him on a PR I can ask it in a way that implies I need his expertise. That way he act can out his fantasy of undoing the damage of incompetent/indifferent through the act of improving my code. A win/win.

Sometimes these narratives are just plain counterproductive. I can think of experiences when teammates were annoyed that some “undeserving” party “stole credit.” In these situations you can try to rewrite the narrative, though it takes a certain skill. One way to accomplish this is to bring up an opposing narrative like, “Yeah so his name was mentioned in a meeting big deal… I don’t do great work so some manager can mention my name, I do it because there are literally millions of users who are experiencing what I make and I think I’m lucky to be able to be in a position to help so many people. That’s something I can be proud of.” [And sincerely, for those of us who take more pride in the good we do that the numbers in our bank statements, our reward needn’t be recognition. It’s a rewarding philosophy to live by]

And the fact that people are choosing to live these stories is an important fact. For a long time, I would have thought doing this type of thing was “manipulative” or “tricking” people into work when I could instead explain to them why their underlying narrative was too black&white. But knowing that these narratives are choices, with symbolic importance, that give meaning to the individual who holds them, I see now that people choose to live these stories hoping to “play them out.”

And most importantly, we all have narratives. Mastering other peoples narratives is a great tool, but mastering your own is probably more important.

———

Part 2.

If you’re a leader in an organization, you need to be aware of the stories that occupy the minds you oversee. Do people see themselves as battling each other for recognition? Do they see themselves as allies against a great evil? Do they see themselves as victims of your rule?

People within the company all have their narratives, and those attitudes are contagious. Your actions will have a great role in deciding which attitude wins out.

I’ve seen organizations torn apart by leaders who were out-of-touch with the effects of their actions. The cultural effects you have are of supreme importance. Actions like requiring engineers start an hour earlier, for example, are incredibly dangerous, because they give room for the narrative “We are seen as code monkeys” to thrive.

To win this battle you must understand the narratives that you are battling against. You must truly understand them, you must know and appreciate the day-to-day of your workers. For example, you must know that your Office Manager Lela is frustrated, sleep-deprived, is wondering where her life is going, and is starting to feel like the “manager” in her title is meaningless. When you know the people you work with you’ll know what stories are compelling to them. When you understand, you will be capable of offering the service of arming them with a better story, a brighter story, a more compelling story. Because as bad as Lela’s life is, it’s better for everyone if she feels like her work matters at the end of the day.

This is your value.

Understanding engineers by understanding authors

I’ve written before about the challenge it can be for non-engineers to understand engineering work. I’m not the the first to observe that the non-technical need a metaphor to understand invisible and often abstract output an engineer creates. Traditionally, that metaphor has been physical engineering/construction. Others have already, and rightly, criticized the physical labor metaphor.

Instead of ridiculing the wrong metaphor, I offer a substitute. I posit this: To understand engineers, think of them like writers.

to understand engineers, think of them like writers.

Why is this a good analogy? It explains several aspects about engineering that otherwise seem downright unreasonable.

  1. Emotional attachment to work
    Like an author, many engineers see a work project as an opportunity to exercise their creativity and build something the take pride in. Like an author, engineers develop a sense of owning what they create. If the project gets cancelled, handed-off, or drastically changed (especially without notice), compromising their artistic vision, the engineer may experience frustration. But this is natural, how would an author feel in such situations?
  2. Difficulty in measuring progress and estimation.
    If software were physical construction, it might be reasonable to have an easily-predictable timeline. One might confidently answer “how far along are we?” But like writing, and unlike construction, everything one makes in software is new. And like writing, progress can’t merely be measured in the amount typed, refinement and reduction are actually an important and lengthy part of the process.
  3. Ambiguity and subjectivity of excellence
    Every week somebody writes a blog post on how to find out in an interview who’s a good engineer. And every week it gets (rightly) torn to pieces by commentators. The fact of the matter is that there are many independent components that comprise engineering talent and measuring them is very difficult. Even among the very best stylistic difference might mean two greats may not appreciate each others’ virtues, like Faulkner and Hemmingway.
  4. Challenges of collaboration
    And on that note, collaborating can be hard. Like writing, there are an indeterminate number of ways to write software, but each engineer has a style. I can tell you from personal experience that writing software with other people is hardBoth want a sense of ownership and freedom to express their creativity, but must now answer to the confines of the project itself as well as their partner (or team’s) creation. Imagine a group of professional writers trying to work together, of varying cultures, varying talents, varying dispositions, and varying skill-levels. With no objective answer to many issues, engineers reviewing one another’s code is a touchy topic.
  5. A need for freedom
    As a creative endeavor, software’s workflow can be unpredictable. A creative solution may come at any moment, often in the shower or a dream. Sometimes, when all the factors align, answers comes pouring out at a great pace. During such times, the absolute worst thing that could happen would be an interruption (or a required meeting). Compromising on artistic process will compromise the product.
  6. It’s not work
    One of the most persistent and most damaging misunderstandings I have witnessed is the erroneous perception that engineers will avoid work if they can “get away with it.” Perhaps those who feel this way think of engineering as labor, as if it were physical construction. But writing code, like other writing, is a passion that cannot be avoided. When I go on vacation from work I always end up recreationally writing code within a week. I can’t generalize for every engineer, nor every project. Like a writer, if an engineer really doesn’t believe in her work for moral reasons or is so constrained she has no space for creativity then she may lose motivation.
  7. Can we rewrite?
    Another commonality is that due to stylistic differences, every individual prefers their own way of writing things. (And to be clear, in software there is a lot of room for styles, styles that are often so unique that one can often tell who wrote code just by reading it). Each considers her own style clearer, cleaner, or better; often because it aligns so directly with her own thought process. Learning to compromise on this a key skill.
  8. Some produce more than 10 times another
    Is there any number of E.L. James that could produce the Great Gatsby? For specialized work (e.g. advanced problem solving, revolutionary user experiences) there’s just no substitute for a prodigy. On the other hand, if what you’re making is the software equivalent of a gossip magazine, having Shakespeare on your team might actually be a recipe for failure.

I want it to be clear that I’m not saying all engineers automatically deserve to have any project that they work on adapted to conform to their artistic whims. I am advising all to be sensitive to the pride and passion that people put into work.

But most of all I’m trying to help people understand engineers. It can be hard to relate to an engineer who expresses slight negativity about meetings, blows off people who check-in on them, never knows how long their work will take, doesn’t like standard schedules, might prefer to work alone, gets disappointed when their work is shifted, or thinks they’re amazing. So if you care to understand and relate, I’ve given you the tools.

Select vignettes of a tech company

Underneath the “machine” of an engineering company is ultimately emotions. I’ve selected a few vignettes I think most engineers could relate to that highlight common themes of misunderstanding in software engineering.

  • Thinking to motivate people, an executive names a select employee for an award. One employee gets motivated, the rest get demotivated
  • Eager to prove his place a product owner fantasizes about his project that will prove him great like his idol, Steve Jobs. When talking to his team about his product he patiently listens through their objections before ignoring their opinions and making proceeding with his initial plan. The rest of the team no longer feels like this project is a good outlet for personal creativity (since their input gets ignored) and withdraws.
    [This exact same behavior is done just as much by engineers who are equally prone to wanting to take full control of a project]
  • A manager picks an employee who’s already been labeled as a “problem,” and decides to prove they can turn the situation around. The manager gets increasingly involved with day-to-day decisions of the engineer suspecting it will force the engineer to work harder. The engineer, who’s just as likely to be as good as any other engineer, then comes to resent the manager at a personal level, to see treatment as inhumane, and refuses on principal to participate with the tactics. One of the two, and not too unusually both, get fired.
  • Seeking to engage with engineers a manager tries to have a conversation about a project. Bringing up, “firing on all cylinders,” “endzone,” “deliverables,” and “grand slams.” Having no interest in cars, football, or baseball (nor analogies for that matter) engineer gets a sense the person he’s talking to couldn’t ever understand him.
  • Manager wants to present an air of knowing, so pretends to understand things he does not, and honestly could not. His direct reports immediately pick up on this and lose respect for him. Nonetheless they are patient and respectful to his face.
  • Blindly mimicking the culture of management, a manager refers to Sally as a “resource.” With this analogy material resource manager encourages his tendency to think of engineers as fungible. Also, Sally  now hates this manager guy who keeps objectifying her!
  • Seeking to create an objective way to numerically rank candidates and assign bonuses, a 360 review process is put into place. Immediately friends give each other great scores.

All unfortunate situations.

Disclaimer: none of these are inspired by employers past nor present.

Death By Metrics

‘A little knowledge is a dangerous thing’ – Alexander Pope

 

TL;DR – Graphs, dashboards, and metrics give a psychological illusion of control and understanding which is usually false and can be worse than no information at all.

Why is it so easy to fall subject to crappy metrics? Let’s consider a story. You’re a project manager and you just got yelled at because the engineering project you manage is already 2 sprints behind. You feel helpless. You asks the engineers why everything is taking longer and they give technical explanations about unknowns that you can’t see at all. You really don’t know anything.

Then something magical happens: you discover you can look at the engineers’ pull requests, and see how many PRs they make each day and how many diffs are in them. You start to look at these and start to notice patterns. Maybe less PRs get done on work from home Mondays… are they slacking off? When all you have is a nail, everything looks like a hammer.

And you just ruined the company. Suddenly you’re wondering why Bob has the fewest commits, why there are fewer PRs on work-from-home Mondays, why there has been a decrease in number of PRs last month. The answers respectively are: Bob is the only one to comment  his code so everybody except him is sped up because of it, sprints start on Mondays and fewer PRs have 1 day turn-around so this biases your results. Everything your one tool might lead you to assume has been entirely incorrect.

Or worse, you decide to evaluate engineers based on their Jira tickets. You have engineers estimate their tickets and then see if they can meet their goals on time. Suddenly you have incentivized your engineers to overestimate tickets, play “hot potato” with responsibilities (“Not really a bug! Ticket Closed!”), not help each other (teaching time just makes you look slower), and not invest in long-term architectural improvements that won’t show immediate benefits.

Or you judge the success of a UI change based on a funnel. In an attempt to get the best open-rate for your marketing email you have somebody come up with various subject lines and pick whichever has the highest open-rate. This is an A/B test. Suddenly you’re sending out emails with link-bait titles like “See what your friend posted about you,” that get a high open-rate but immediately get deleted for being deceitful once opened. Or your new button placement gets tons of clicks because it’s too close to the scrollbar.


Or worse yet, you decide to judge the success of your company based on Monthly Active Users. 
You have your awesome facebook game and have 30 million MAUs. You force all of your users to send out invites to all of their friends and Viola 31 million MAUs! You change your code so that every one of your users must send invites to friends every week. Now you have 32 MAUs. The graphs look pretty convincing, you get promoted. And you wrecked the company. A year later facebook changes the rights to your app so that you can’t spam its users, your users have been pressured by their friends to stop spamming invites, your entire company has become a laughing stock in the gaming industry and is now lampooned everywhere for the rest of its existence.

The common pattern here is  individuals trying to substitute a simplistic chart in place of deep industry experience. It is people with finance degrees changing videogame experiences, MBAs insisting on multiple A/B tests to change an icon, or a non-technical hiring manager not calling a Bill Gates for an interview because he doesn’t have a CS degree.