This chapter will discuss the social side of professionalism: how to nurture the mutual respect and enjoyment that make professional relationships efficient and fun and how to avoid common engineer misbehaviors that can drive people up the wall. We’ll start with advice that applies to more or less all workplace interactions, then move on to more specific challenges—feedback, bosses, and system owners.
General Social Skills
Manners
Accept apologies eagerly: not “np” but “no worries! Things worked out fine.” Let them know you’re really fine so they can stop worrying.
When you go out for lunch, drinks, or anything else that costs money, pay people back absolutely without fail; make sure no one ever feels awkward about whether they’ll get their money.
When you meet any colleague, shake their hand (if that’s customary in your area), smile, and introduce yourself; show that you’re glad to work with them. Take special care with people junior to you; they’re naturally likely to be insecure about their position, and they’ll be glad to know you see them as an equal.
When you lapse in your politeness—by saying something curt, by accidentally wasting someone’s time, by cutting someone off, whatever the case may be—apologize thoroughly and earnestly. Help people recover from the discomfort of your rudeness, and show your respect.
When others reach out to you, respond as promptly as humanly possible, and apologize when you don’t; show that you value their time and consider it a commitment to help them.
Don’t interrupt in meetings or conversation. Have you ever felt a breathless, almost painful desire to say the thought that’s jumped into your head, even though other people are talking and saying reasonable things? Well, so have I, every single day, but interrupting shows disrespect and makes you seem oblivious. Outwit the impulse.
Thank people thoroughly every single time they help you—show that you don’t take their help for granted.
Giving Credit
One of the most important ways to build trust and mutual appreciation with your colleagues is to scrupulously give them credit when they do good work; one of the easiest ways to enrage someone is to either claim credit for their work or allow others to mistakenly attribute it to you.
Therefore, when someone does something that helps you, or even just that you admire, you should go out of your way (even way out of your way) to acknowledge that good work to them, their manager, and your mutual peers.
The first argument for this practice is aesthetic: one of the greatest satisfactions in professional life is to collaborate with talented, well-intentioned people, get good results together, and share a mutual appreciation; you can gratify your colleagues and yourself by acknowledging their good work.
The second argument is practical, not to say cynical: you want your colleagues to learn the lesson that collaborating with you is beneficial and pleasant so that they’re eager to help you again. Note that this doesn’t extend to flattery—you’re an engineer, not a politician, and deceit is likely to be transparent and will backfire. You should genuinely appreciate good work and share that appreciation from the heart.
Thank them directly by email or chat: “Thanks a lot for your help! This saved me a lot of time!”
Email feedback to them and their manager: “Cheng went deep on this problem with me and ended up finding a bug that’s been causing crashes for weeks—thanks so much!” I’m quite liberal in sending managers feedback; it’s useful for them for writing performance reviews and can give the engineer a real bump.
Mention their help in a broader email: “Special thanks to Guru, whose help on the storage side was essential to hitting this deadline.”
If a team goes above and beyond for you and your team, get them treats to say “thanks”: Cupcakes, donuts, or cookies will let them know you really appreciated their work. Your manager may let you expense this.
For truly exceptional work, get creative: I have sometimes bought trophies and given them out.
A Word About Charm and Positivity
I believe in charm among nerds. I use the term “charm” to mean making people feel good and finding common ground with them—building the connection that makes it a pleasure to work together. You should cultivate charm, first, because connecting with your colleagues makes work fun and gratifying and second because strong relationships make projects move more smoothly. This section will offer a few suggestions for doing so.
The fulfillment of connecting with people you work with should speak for itself—when I haven’t invested in it, I’ve always in the long run wished I had.
The professional benefit needs an explanation—and a defense from charges of cynicism.
In a healthy organization, people help all their colleagues; in many teams, not so much. But in every organization, you can get better results by building strong connections with your colleagues and making them feel good about themselves and their team. When people are stressed and busy, they’ll go that extra inch to help someone they feel close to; when something is hard and controversial, people will listen more eagerly and more carefully to a friend. So, even if you’re one of many engineers who find solitude or shyness natural, as I do, you should go out of your way to make people feel good and find common ground with them—as some would say, to be charming.
How to Win Friends and Influence People is long and dated, but distilled to one sentence, it has the best advice I know for connecting with people: take a genuine interest in others, and give them the benefit of the doubt. When you work with someone, find a chance to engage with them. Ask them how they are. Ask them what they did last weekend. Show them the respect of asking for feedback on a piece of your work. Ask them how their work is going, what they thought of the company meeting, and if they saw the same movie you saw last week. Then, ask follow-up questions; it may not be the entire art of conversation, but by golly it’s a start.
Finding fault is not a sport: Engineers often come off like precocious children desperate to prove that they’re smarter than a teacher—we love to prove people wrong. And indeed, sometimes people are wrong, sometimes proving that you’re right is fun, and sometimes people do need to be corrected. But, the hobby of proving people wrong has two big problems: it’s incredibly annoying, and it often doesn’t benefit the victim. All in, annoying colleagues for no benefit is a quick way to convince people to avoid you. Sometimes, when people are wrong, you can just let it slide and say nothing; when you have to disagree, you can do it while giving others the benefit of the doubt, as in How to Deliver Criticism. Generally, you’ll do better to comment on where you agree with others than where you disagree. Note, though, that this doesn’t extend to cases where people really need feedback, and I don’t mean to suggest that you should ever misrepresent how you feel—my advice is just to pick your battles, not to always smile and nod.
Bring other people up : Your colleagues are very likely admirable people beset by insecurities and worries, just like you (or at any rate like me). Expressing honest gratitude and admiration—finding qualities and actions you genuinely admire and commenting on them when the situation calls for it—giving credit where it’s due, and including others in your fun (e.g., including the new engineer when you go for coffee) make life better for everyone. I find that smiling, acknowledging other people’s struggles (“man, that sounds tough!”), and cracking the occasional G-rated joke go a long way too, particularly when there’s tension to resolve.
Seek out others’ opinions: You depend on your colleagues’ expertise, and you want them to know you value it—they’ll share their thoughts more liberally as well as enjoy your collaboration more. Asking for their thoughts explicitly, both in private and in public, is a vote of respect and a strong compliment. Obviously you need to weigh that compliment against the drain on others’ time; I consider it especially valuable with junior colleagues who may assume that you don’t value their input.
Leave when it’s time to leave: I can’t count the times I’ve had someone come into my office and start talking—someone I like and respect and am eager to share a word with—and then had them keep talking while I become progressively more desperate to get back to work. I don’t know if it’s a universal issue or a sickness specific to engineering, but it is a problem. My advice is to err toward leaving people to get back to work quickly, and especially to keep your eyes open for cues that people are done—shortened responses, half-turning in a different direction, and seeming antsy. You can always say, “catch up with you later” and make your exit.
Acknowledge struggle; be supportive : Like every job, engineering is filled with moments of frustration. People can become quite emotional when their project is canceled, they cause an outage, their favorite colleague leaves, or whatever else goes wrong. For me, it’s can be powerful when someone just asks, “how are you doing after that reorg?” or says, after I struggled to resolve an outage, “don’t worry about it, you did your best”; that support builds trust and mutual caring. Ref: Forget Feedback and Provide Support below.
Humility vs. Self-deprecation
I’ve worked with quite a few people who feel outclassed by their teammates; they see smart, experienced people all around them, and they feel that they’re behind and will never catch up. Respecting your teammates is a virtue, but I’ve seen many engineers manifest that admiration as constant self-deprecation: comments like “I have no idea what’s going on” or “I don’t think I should be making this decision.” Humility is a virtue, and so is esteem for one’s colleagues, but bringing yourself down is not professionalism—if you tell people you don’t belong in the big leagues, your attitude is proving it to be the truth, and they’ll believe it, because your colleagues know that deep technical work requires at least some trust in yourself. I advise against insulting yourself at work. Remember that everyone feels dread and self-doubt; we can share it with our friends, but at work we should keep our chins up.
Delivering Feedback
Finding fault isn’t a recreational sport, and we do our best to praise rather than criticize. However, sometimes people need to hear feedback; sometimes we’re the person to deliver it. This section will discuss when and how to deliver criticism. These principles are derived from my many misadventures in feedback with teams on three continents, and I’ve been happy with the results of following them. Remember, however, that expectations around feedback, and especially directness, vary across cultures and individuals; you’ll have to do your best to adapt to your own team’s context.
When
I’m in a position of authority, seniority, or friendship to them, and I think that the feedback will help them succeed personally; in that case, I have a responsibility to help them improve.
The behavior in question significantly compromises our shared work; in that case, giving feedback may be a practical necessity.
The criticism is mild and the benefit is large. For example, I may think that a colleague can make a tiny tweak to their presentation style for a big benefit; in that case, I may be able to deliver the feedback as encouragement and run minimal risk.
And these opportunities do arise—I’ve given peers and reports feedback on their communication, on their discipline, on bringing negativity to the office, on their sense of ownership, and on and on. Usually, I take the plunge out of a spirit of friendship or because I genuinely believe in people’s potential, and usually (not always) they’ve in the end come back to thank me; the right frequency is more than never. Once I have given some feedback, I’ll wait until the dust settles to deliver the next round; too much feedback at a time will exhaust even the most open-hearted colleague.
Foundational Principles of Giving Feedback
- 1.
Give people the benefit of the doubt: And tell them that you do. Assume that they mean well, that they’re trying hard, and that they want to be the best they can be, and tell them that you’re giving them feedback because you believe they mean well.
- 2.
Give feedback in the most positive way you can: Approach conversations with an earnest goal of helping them succeed for their own sake, starting from respect and optimism rather than contempt or anger.
You can apply those principles in a million creative ways to find the feedback most likely to succeed in a given situation, but I’ll suggest a few techniques that have given me a lot of mileage.
Empathy; Show Your Trust
Feedback lands softer if it comes with understanding. When you see well-intentioned people messing up, you can usually guess why—maybe they’re gentle people snapping because they’re stressed out, maybe they’re disorganized this week because they have too much on their plate, maybe their code isn’t up to snuff because they don’t know the language well or don’t understand the expectations for the system they’re changing. You can be explicit that you think the lapse is understandable and why, and by doing so, show that you feel no contempt, only respect.
Suppose Kate just took Steve to task in a meeting for coming unprepared. The feedback does need to be given, but we think the intensity was too high. We want Kate to take a milder tone next time; we give some meta-feedback.
So-so:
You were too tough on Steve in there; why did you talk to him like that?
Good:
I think that you may have been too harsh with Steve in that meeting. I was also pretty frustrated that he didn’t come prepared, and I completely agree that he needs to know that he has to do better for this project to succeed. That said, I think he might respond better if we approach him a little more gently.
Kate most likely didn’t go to town on Steve for fun; she wants this project to succeed, and it’s stressful and frustrating that her colleague didn’t come through. She may be embarrassed about her behavior already. We let her know what we think, but we also show that we find her behavior natural and relatable under the circumstances; we’re not remotely contemptuous.
Acknowledge What’s Good
You’ve probably heard of the unfortunately named “shit sandwich”—delivering criticism surrounded by praise to buttress someone’s ego. Ben Horowitz says in The Hard Thing About Hard Things that people see right through it, and it’s certainly risky—any stretch of honesty is more likely to backfire than help. I personally think some judicious honest praise can indeed lift someone’s spirits if it’s contextually relevant; you should be helping your recipient see real reasons to counterweight the disappointment they’ll feel at having erred. That means that the praise needs to be tightly coupled to the feedback, and it goes without saying that it should be honest—if not it will be much worse than nothing.
A non sequitur to be seen through:
You’ve done such great coding work this week! I just want to mention one thing that I think should be tweaked in the presentation.
An effective contextually relevant compliment:
I think the sections about reliability and performance are clear and persuasive. The section on implementation details is well done, but I think might be too much for this audience.
In the former, we’re clearly buttering someone up; the compliment is off-topic. In the latter, we’re commenting holistically on the work, including positive things to feel good about and areas for improvement; the compliment is truthful and fully relevant and can therefore be taken seriously.
Phrase Feedback As an Opportunity
This is a phrasing optimization that can make criticism subtly more palatable; rather than saying, “you need to do X” or “you shouldn’t do Y” or “Z is wrong,” we can say, “I think if you do X, <something favorable will happen>”.
For example, the following is direct and useful feedback: “you need to add an introduction or the rest will be hard to follow.” The same feedback can land a little better as, “I think that the main technical sections are good, but if you add a clear introduction, readers may contextualize them better.” The effect is subtle, but to me this phrasing makes it clear that we’re working together to a common goal rather than fault-finding.
Qualify Your Certainty
“Knowing Our Limits" (Chapter 7) discusses the elusiveness of certainty in the software game and the importance of explicitness about our level of confidence in a theory. When delivering feedback, expressing certainty increases the intensity for the victim.
A touch intense (and maybe unreasonably self-assured):
You need to cover more of the history in your doc.
Properly qualified:
How much does your audience know about the history of this system? Depending on what they know, I think the doc might benefit from a little more history.
These two sentences deliver the same message; the first is certain and therefore commanding and final; it’s a little slap in the face, a wake-up call and a debate finisher. The second is milder and less certain, an open door for discussion, debate and encouragement; you acknowledge that your colleague, whose judgment you respect, may have good reasons for a decision you prima facie disagree with, and you even offer a potential justification for their decision (maybe their audience does know the history).
You might well use the first occasionally, when your colleague needs a wake-up call, but I’ll always default to the second, and I think this acknowledgment that you may be wrong sets the stage for a supportive discussion.
Offer Help
Another way to help your colleagues receive feedback is to couple it with an offer of help; you’re showing therefore that you’re not just raining criticism and leaving them to struggle but that you really want to help them succeed. For example:
I think the postmortem might need a bit more detail about how the caching system works.
vs.
I think the postmortem might need a bit more detail about how the caching subsystem works. Are you familiar with it? If you like, I’d be happy to spend a few minutes talking over some of the quirks.
The feedback is of course the same, but the second is an open hand; you’re instantly in it together, an instant comfort for someone struggling with a difficult problem or perhaps embarrassed that they needed constructive feedback.
Deliver Feedback 1:1
This is a well-known method . While there can be good reasons to give feedback publicly, especially for a manager who’s trying to create a culture of candor, that requires a deft touch; it’s safer to deliver your feedback 1:1, in person or by a direct email, where you save your colleague the risk of public embarrassment (especially if your tone isn’t spot on).
Manage Your Tone of Voice
This one is a hard theory to convey on the printed page, but note: feedback stings when delivered with a vehement, staccato tone. When someone you like is doing something poorly, you may be frustrated with them—your earnest desire to help them may be mixed with frustration, and that can come through and hurt. Do your very best to find a mild, easy, friendly tone. You’ll see that this is just an extension into voice of all the themes above—trying to make yourself a friend to people enduring the tough business of receiving criticism.
Forget Feedback and Provide Support
I was once on a team whose manager had left, and no one was getting the close air support they needed from the second-level manager. As the most senior engineer on the team, I was trying to maintain a sense of normalcy (and keep the team together) during that tough period. One day, a colleague I held in very high regard said something quite snippy in our team meeting about how we’d been X months without a manager. I was, momentarily, livid; this was a senior person who should have been helping his colleagues cope, not spreading discontent, and I expected more of him. I was about to take him aside and give him a piece of my mind, when something else occurred to me.
The reason I expected more of him was that he was a great engineer and a strong professional; so why had he acted out? My conclusion was that he must have been in a dark place himself; maybe criticism would be justified, but maybe support would get better results.
I asked him: “are you okay? You seemed kind of upset in that meeting.” And, indeed, he had been. We talked about what he’d been feeling and why things had been tough recently—I think that was the first step toward what became a treasured professional relationship. So, sometimes, nurture is the better part of valor.
Tough Love
- 1.
When stubbornness seems to be about to cause a business-critical mistake.
- 2.
When friends’ seem likely to do themselves and others a significant disservice.
The business risk case speaks more or less for itself. If I give feedback gently and it isn’t followed, I’ll usually just let it slide—the upside usually isn’t worth the friction. If failure is simply not an option, for example, during an ongoing system outage, I won’t hesitate to use a strong tone and words to get things on track; for example, I’ve many times raised my voice to stop people from talking over each other during an outage. Set in a loud, unamused voice: “everyone stop and mute. I want to hear from Uday and no one else.” That’s something I would never say under normal circumstances, but when seconds matter, we impose ourselves as we have to. I’ll almost always circle back after the fact to apologize for being forceful and explain why it was necessary.
Similarly, if I feel that a system design decision is a real business risk, I’ll first try every gentle method in my book, but if that fails, I will absolutely say, “this decision is an unacceptable risk; we have to do better.”
The case of friendship is more delicate. We break out the tough love toolbox with friends for nonbusiness reasons: because we want the best for them where we might just let others make their mistakes. Once again, we try every gentle tool first, and even when forced to be direct, we’ll do our best to encourage. But, we will be direct. Said in real life to a friend who had a plan to give an ultimatum to their boss:
I don’t think saying that to your boss is going to get good results; I think he’ll experience it to mean that you’re no longer on the same side working toward a common goal, and that is not going to incline him to help you achieve what you want to achieve. I’m telling you this because I think it’s important and I think you can handle the feedback and do better.
Receiving Feedback
I have only three pieces of advice for receiving feedback: seek it out often, do your best to receive it with an open mind, and express appreciation whether you agree or not.
You should seek out feedback because it is a precious currency, a rare opportunity to use insightful people’s judgment to improve yourself or your work. I think asking for feedback can be a casual business to be done quite often, and in fact, asking is a show of respect—it can be a way to build a relationship. I suggest that you ask the most specific question you can. “Do you have any feedback for me?” can be a good show of humility, and you never know, you might catch something when you go fishing. However, to busy experts, more specific questions feel more intelligent and more actionable. “Do you mind reading this email and seeing if it’s clear for this audience?” “Do you have any feedback on my presentation? I’d appreciate a second opinion.” “Do you think my question was reasonable in that meeting?”
As we’ve discussed at length, giving feedback is a risk, and doing so is an act of generosity—the delivery may be annoying, the feedback may be wrong, but your colleague is trying to help, and you should do your best to give an honest thanks. Almost everyone naturally becomes annoyed and defensive—crush those impulses, find your maturity, and say “thank you.”
Completely apart from that, you should try to consider the feedback with the greatest openness you can. You might conclude that you disagree completely, and you might be right, but you should do your best to reflect on it; you may see wisdom in it after you recover from the initial shock of criticism.
Working With Your Manager
This section will discuss how to get the best results from your collaboration with your boss. We’ll start by offering a model for the relationship that underpins everything else. Then, we’ll cover the responsibilities and psychology of managers themselves, so you can model your boss’ own problems and motivations and optimize your collaboration. Finally, we’ll discuss what to do when things go wrong.
The Nature of the Relationship
One fact threads through every aspect of working with your manager: your interaction is above all a business relationship. Your Relationship With Your Employer (Chapter 1) argues that you should view your interaction with your employer dispassionately but not cynically; you deliver on your commitments, they deliver on theirs, and you both profit. Managers are representatives of the company, imbued with special authority over people and budget and special responsibility to the shareholders and the law—for example, managers in the United States have a special legal responsibility to act if they become aware of harassment. In fact, you can consider them personifications of the company, and you should have much the same expectations of them that you have of your employer overall.
Luckily, within the company, your interests are usually aligned. Success on your projects is good for your manager, and they usually want to see you rewarded, even at the expense of other teams, because they want their team members to stay happy and stay put.
Your interaction with your boss is also, unavoidably, personal—you see a lot of each other, and since your interests are aligned, you’ll struggle together to achieve the same ends. Their power over you and responsibility for you can also make them feel, sometimes (terribly misleadingly), like a parent. Sometimes you’ll love each other, and sometimes you’ll drive each other nuts. Like all good business relationships, you should enjoy a mutual respect and a degree of friendship, but we should organize our behavior around its nonpersonal core. Managers are obliged to maintain a professional distance from their reports; you shouldn’t expect your boss to be your close friend, to see you socially, or, especially, to party with you.
As in any business relationship, we should respect ourselves and our partners, keep our cool, and express our opinions honestly and courteously. It’s natural to be afraid of your boss when you start (see On Fear, Confusion, and Self-Loathing: Starting New Jobs), but they’re quite unlikely to summarily fire you, and your fear of them will fade. We don’t need to abase ourselves before our boss, and they should never ask us to; we should respect their position of responsibility, and they should return that respect. We should never expect them to do anything out of sentiment, and we should never expect a sense of entitlement to get us anywhere.
Finally, we should pretty much do what our boss tells us to do to the extent that ethics allow. Many engineers have been infected, in today’s talent seller’s market, with the false impression that they don’t need to listen to their managers. It’s true that you’re paid to exercise discretion; you should represent your opinions faithfully and even, in extremely rare cases, go over your manager’s head if you believe they are putting the company at risk. But, in the end, their job is to guide you in doing what the company needs, and your job is to do what they say, even when you don’t like it.
Managers Have Their Own Problems: Optimizing the Collaboration
Managers are accountable for goals—shipping software, maintaining reliability, and driving business metrics. They have project managers pinging them constantly, their own boss breathing down their neck, and an eye always forward to annual review season, when, it may surprise you to hear, they usually want to be able to get you the best review and compensation possible—which might require a knockdown drag-out fight with other managers.
And yet, they do almost none of the work with their own hands. Therefore, despite their authority over you, they suffer from a peculiar disempowerment: the main way they can get projects done is to sit back and let you do your job. You can probably see how this creates a temptation to micromanage—everyone wants, in their hearts, to be able to do something to influence their fate.
All of which tells you that the most important thing you can for your relationship with your manager is give them (justified) confidence that you are going to come through for them—help them wait comfortably, rather than anxiously, for you to come through. I suggest three ways to do that, one obvious, two less so.
The most important thing you can do, by far, is build a track record of delivering—the more you deliver, the more confidence your manager will have next time. Fine, we are done with the obvious.
Second, proactive, well-organized communication about project status helps put your manager at ease. If you come to team meetings and 1:1s with a list of project areas and a clear story for each, and you deliver that story with authority, you show that you’re on top of things. You can use the email template for project status updates (Chapter 13) to structure both email and in-person updates. Everyone wants to make a better workplace for introverts, but I still advise you to tell your story decisively, speaking firmly and at medium volume—conveying confidence builds confidence. Similarly, if you surface project risks and schedule slips the moment you’re aware of them, you let your manager rest easy that there are no surprises lurking around the corner.
Finally, managers love engineers who find a way. At senior levels, discretion and strategy are prized, but for junior engineers, getting things done (at reasonable quality) is more or less the beginning of the end. If you show that you won’t get blocked, that you’ll Just Do Something (Chapter 5) rather than let a project ever languish, you’re off and running.
Upward Feedback
Sometimes, your manager has a problem and needs to hear about it; maybe team meetings are too slow, maybe there’s a technical problem that needs more attention, maybe you’re being micromanaged. When you have an idea for how your team or manager can improve, you should (often) provide that feedback; it’s good for you, it’s good for your team, and when done right, managers will often (not always) respect and appreciate it. This is just a special case of delivering feedback, but (a) it’s scarier, and (b) the long-running nature of your relationship requires extra care.
- 1.
Your manager is a person too, and they can be wounded just like anyone, which will make them less open to your feedback. Express minimal anger or frustration, and don’t get personal; remember, this is work, not family. Try to make a specific, actionable request or suggestion. So, avoid the personal attack, even if it’s true:
You’ve been micromanaging me, and it’s really frustrating me.
Prefer an emotionally neutral, actionable proposal for improving your work together:
- 2.
Pace yourself. When you work together constantly, you’ll see many opportunities for feedback; too much at a time will make them feel beaten down and less receptive to you. Prioritize and trickle it out.
- 3.
Pay attention to the response; if they become defensive, ease off the gas and save it for another day.
Going Over Your Manager’s Head
Going over your manager’s head (raising a concern about them directly with their boss) is a drastic measure; it harms your trust with your manager, likely irreparably, and, if not well justified, your second-level manager will have their own doubts about your judgment. Mere disagreement isn’t a reason to take this step. If you don’t agree with your boss’ direction or methods, your first thought should always be direct feedback. If that doesn’t work, you can always switch teams or quit without burning any bridges. You should only go over your manager’s head when (a) direct feedback either hasn’t worked or seems impossible and (b) they are doing something so injurious to the company’s interests that you consider it a near emergency, something their boss desperately needs to know about. That situation has virtually never happened to me, but it does happen; at that time, you can reach out to your second-level manager and express your concerns with the same unemotional professionalism you would employ for direct feedback.
Tricky Subjects
You’re going to have challenges with your boss at some point, something between mild technical disagreement, which requires you to either persuade them or get over it, and harassment, which may require you to consult HR or a lawyer. This section will offer approaches to a few tricky issues that can arise in engineer–manager relationships. In almost every case, you can try to work with your manager to improve the situation. Also in almost every case—apart from illegal or discriminatory conduct—if that doesn’t work, your main options are to find your peace with it or move on. As emergency fallbacks for illegal behavior or terrible business risks (as opposed to simpler frustrations), you can go either up the chain or to HR.
Disagreement About Technology or Process
When you take issue with your team’s practices or technical direction, you have two choices: you can keep it to yourself, or you can offer constructive feedback.
“I think you’re prioritizing wrong” is whiny. Get traction with concrete feedback that doesn’t reference to individual qualities: “I’ve been thinking we might want to consider <doing X instead of Y>. X <has benefits>, but Y <has other benefits>.” For example:
I think we might want to prioritize the monitoring cleanup ahead of the UI. The UI is going to be a great product improvement, but right now, the on-call burden is really slowing people down, and we could improve morale a lot with just 2 engineer-weeks of work.
Remember that a mild approach (not putting people on the defensive) and a convincing argument are your sharpest tools.
You Want More Feedback
When I started my first job, my manager didn’t give me any feedback for the first six months or so—not a single word that I can recall. Since I was neurotically fixated on getting terminated, this let me get pretty worked up, to the point that my anxiety obstructed my work. Since, I’ve realized that if you’re not sure where you stand, you can just directly ask for feedback! In fact, it can come off quite well, as a sign of humility and eagerness to improve. I’d advise you to suggest a specific feedback cadence. For example,
I’ve been thinking that it could be beneficial for me get some more feedback on my work. Do you think we could try to have a regular cadence of feedback? It doesn’t need to be too heavyweight—maybe once every two weeks, or once a month, you could give me some feedback?
If you’re not sure, one good way to structure feedback is as two observations: one about what you’ve done well and one about what you’ve done poorly. That structure ensures at least some constructive feedback, but it balances the criticism with encouragement.
Slow Advancement
I hear from many engineers that they think they’re ready for promotion, and it hasn’t happened. This section will offer several options for approaching that problem; note that this analysis does not apply to scenarios of discrimination or harassment, which may be best discussed with HR or an employment lawyer. You should approach the issue of promotion cautiously, because perceived entitlement can grate on managers.
Personally, I don’t think this is a subject we should “be on top of” all the time; we should focus all our energy on (a) improving ourselves and (b) finding and executing on awesome projects, which is by far the shortest, straightest shot to a promotion. That said, sometimes, we need to be proactive.
I would broach this subject from the perspective of “making a career plan” with your boss. You can say, “I’d like to talk about my goals for the next year,” and then, in that discussion, say, “I’m starting to think about promotion to Level X. What do you think I should do to position myself for that? How do you think I’m doing against that standard?”
This is a perfectly acceptable subject for discussion; there’s nothing tasteless or entitled about a career strategy session and a request for feedback, and you may well learn a lot about where your manager thinks you stand. Of course, if you’re laughably underperforming, it won’t come off great, but if you think you are on track, it’s a graceful opening to the conversation.
If your manager responds that they think you aren’t on track, and you disagree, I suggest you start by assuming your manager is right and thinking carefully about their feedback. Of course, some managers are wrong about everything, but there’s a better-than-50–50 chance you’re getting ahead of yourself; you can also try to get a consistency check from a senior colleague, emphasizing that you appreciate candor.
If you conclude that you are being held back, I’ll offer three options.
You can be patient : If your boss says that you just need to wait a little longer (e.g., “in six months I think we can make a good case”), and your situation is otherwise good, I’d encourage you to just play it cool. Good learning and work you care about are worth more than a quick promotion. You can set a time limit for this approach and reevaluate after that time.
You can have a direct, professional conversation with your manager: What you should say is, “I’ve been thinking about my timeline for promotion. I respect what you’ve told me about this, but if you don’t mind, I want to make a case that I’m ready sooner than we’ve discussed.” Then, you can talk about why you think your promotion is justified. You should make that case calmly, be ostentatiously humble, and phrase your case precisely in terms of the work you do and the promotion criteria at your company.
“I work so hard,” “I think this is really unfair,” or, “why don’t you want to support me” are childish arguments that offer no information or logic, and they’ll annoy a businessperson with the tough responsibility of allocating promotions and budget.
On the other hand, if you tell them about work they may not know about, reveal complexity they may not understand, or clarify your execution against the company standards, you may impress with your professionalism and persuade with your logic. The following is an example of a direct, fact-based argument that avoids entitlement with an explicit show of humility.
I think that on Project X, I needed to step into a leadership role that’s appropriate for Level Y. That was a virtual team with four junior people, and they needed a lot of guidance; I also did all the project management, including sending the updates and maintaining the tracker, and the project shipped on time. The Level Y guidelines say that you need to be able to coordinate projects of two to three engineers. I thought that it may not have been obvious externally, because it was a virtual team, but this work met that standard. Of course, I understand that the promotion process might be more nuanced than I realized. What do you think?
You can quietly, responsibly leave: If your manager is truly unfair and intransigent, then this is your best option. If you do, you should never say that was because you couldn’t get promoted; that’s a bitter departure for no discernible benefit.
Project Dissatisfaction
Every career involves a certain amount of biting the bullet and doing boring, painful work. If you never swallow your pride and do the grunt work, you don’t deserve the good stuff; good work should, and usually does, go to team players who show that they won’t quit when things get boring.
That said, your career also can’t only be taking one for the team—good engineers want to feel the wind in their hair, and you deserve a chance to take on fun, ambitious projects. So, if you’ve been turning the crank for too long, how do you ask for a chance to do something more fun?
The first step is to make it extremely clear that you’re going to deliver your current work and that you understand you’re not entitled to just do whatever your heart desires. Then, you can ask about the future. You should prepare the most specific idea you can (sometimes that will be a very specific project, sometimes an area, etc.) and justify it in terms of business value.
We’re almost getting to the end of Project Jellybean. I’ve been thinking about what comes next after we’ve shipped. I’d really like to do a performance project if that’s possible; I think we have a lot of low-hanging fruit for performance, and it may improve the customer experience a lot.
If you get stuck in a rut despite giving input about your interests, you can be (cautiously) direct, still without whining:
My last two projects have been a lot of plumbing. I think they added a lot of business value, and I’m glad to have done them, but I think I could use a change of pace soon—do you think I could tackle some infrastructure work when we finish Project Gumdrop?
If none of that gets you where you need to be, remember that you can always move on: see “Maintenance Is for Suckers” in Chapter 4.
Working with Platform Owners
Platforms are software components used by many clients—a storage system, a widely used library, a networking layer, a build system, etc., etc. This can be compared to, say, a tool maintained in common by one team and used only by that team.
You’re going to collaborate with platform owners, and you’re going to want things from them; both require a special sensitivity to those teams’ position. This section will discuss how to get the most out of those collaborations.
The first thing to remember about platform teams is that their responsibilities are, by definition, broad—they have obligations to many users, most of whom are not you. They get tons of questions every day, many of them ignorant and answerable by reading a wiki; they get tons of feature requests, most either asinine or beneficial to only a single customer; they get constant complaints about “bugs” that are really misuse.
You’ll collaborate most fruitfully with platform teams when you do the exact opposite of those things—show that you respect the difficulties of their job, defer to their superior knowledge, and above all take full responsibility for your own success. Then, you can build a partnership where their expertise and your feedback improve both teams’ results.
Here’s how that looks.
Feature Requests
A good feature request is decorated with abundant context.
First, it should be framed in terms of what you want to achieve rather than how it should be done. For example, “Feature Request: a way to query a store’s most recent orders,” rather than “include recent orders in getStore API.” The latter is prescriptive; it implies that you know the best way to achieve your goals with your colleague’s platform, and it also doesn’t give them enough information to offer alternatives. The former gives them the whole picture. Sure, sometimes you truly need a tweak to a specific API, but even then, you should describe your needs at the highest level you can.
Second, it should explain the business purpose of your request. For example, “we want to add a view of the most recent orders to the Store View page on the site.” This helps your audience reason about alternatives and weigh the priority of your request. If you want the data for analytics or for a call to order, you might have very different requirements than if it’s for showing a real-time view to store owners.
Third , you should describe any and all relevant technical context, again to empower an informed response without the need for follow-up questions.
Finally, it should be expressed humbly. This is as simple as acknowledging that the team may be busy or that your request may not be viable.
Here’s an example to put it all together:
Feature Request: a way to query a store’s most recent orders.
We’re building a call to order on the store view. We’re hoping to show a near real-time view of the most recent orders in the user’s area. It’s not important that the data be extremely fresh, but the fresher the better for greater truthfulness. Currently, we get all the store data from the getStore API. We’re not sure whether the store service currently has access to this information, or if so, what the right API to expose it would be; if it’s quite tricky, please let us know, and we can meet to discuss how best to get the data. Thanks!
Debugging and Technical Questions
The two keys to getting help from a platform owner are
Going deep before you ask : Plenty of people come to a platform team and say, things aren’t working the way I expect, please help. Model clients aren’t afraid to go deep on their own; they read the docs, they read the code, they look at logs, they look at graphs, they try several things, and generally they act like a service owner themselves; they ask for help only when they’re fairly confident that (a) they aren’t doing anything wrong themselves and (b) going further on their own would be wasteful.
Asking clear, context-rich questions: See the debugging question template in Chapter 14. If you omit context or ask an unclear question, you’re blending in with an annoying herd. A well-framed question starts you on the right foot.
Bug Reports
What I’m trying to achieve
Exactly what I did, always including real commands or example requests, real version numbers or git hashes, and every possible bit of context
Exactly what I expected to see
Exactly what I saw, including real copy–pasted output.
Ideally, some attempt at debugging the issue
For example:
getStore API returns HTTP 500 if store is closed and user requests details.
I expect to be able to fetch stores even when they are closed. If I request the base store, this seems to work fine. However, if I also request details, I see a 5XX. For example, my test store, dhs-bookstore, is always closed.
$ curl https://stores-site.com/api/v1/stores/dhs-bookstore | jq --compact-output {"name":"dhs-bookstore", "status":"closed", ... }
Works fine, but
$ curl -v https://stores-site.com/api/v1/stores/dhs-bookstore?details=true
...
HTTP/1.1 500 Internal Server Error
It looks to me like this error is coming from the processOutput function, line 121, which doesn’t handle a null “inflight orders" field.
The importance of copying your real commands and real output can’t be overstated; good debuggers are too experienced with misleading questions to trust anything else (see the “Magic Question Templates” in Chapter 14).