DEV Community: rinaarts

Whatcha gonna do with a toxic colleague

rinaarts — Tue, 19 Apr 2022 14:51:47 +0000

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we discuss what to do about a toxic colleague. That person that makes you feel small and stupid, maybe taking credit for your work and ideas, or “stealing” all the interesting and promotable tasks you were supposed to be doing, maybe just rude and unpleasant in general.

Hopefully you’ll never encounter one of these, but if we’re being realistic – you probably will. Unfortunately, they may exist even in the best of workplace cultures because their behavior is easy to hide. Often, their misconduct will be directed at those lower on the organizational food chain, and therefore the powers that be may be blissfully unaware. If no one tells them – how will they know?

Identifying toxic behavior

The first problem you need to overcome is deciding if this person is actually being toxic, or if you just don’t like them for some reason and need to get over it and figure out how to work with them anyway. A lot of toxic behaviors are hard to identify because each incident may be small in itself, and identifying the collection of incidents as a pattern can be difficult.

I’ve had colleagues who are excellent people take credit for my ideas by mistake. The idea came up in a group setting or discussion, it sounded good and they remembered the situation as if they’d come up with the idea. As long as it’s an isolated incident – that’s an understandable mistake. You can fix it and move on. But when that and other bad behaviors compile over time – that’s when you start to feel something’s wrong.

Then you start thinking about communicating the situation to someone who might be able to help – and you’re back to the single incident thinking. How will you explain to someone else how these seemingly small incidents pile up over time into toxic behavior that hurts your ability to work? You’re essentially gaslighting yourself.

So, what you’re going to do is make a list of everything this person did and made you feel bad. It can be big or small, don’t censor yourself. The criteria at this point is only “did this make me feel bad”. Next – curate the list using the SBI (situation-behavior-impact) model. Some incidents may feel “small”, but a group of smallish incidents can fit in to the curated list if they form a pattern.

When you describe the impact you can and should mention how the behavior affected you personally, but try to focus mostly on how it impacted your work or the project, because that will be more compelling evidence than focusing on your (legitimate) feelings.

Now you have a list that will make it easier to tell if you’re being “too sensitive” or if there’s a real problem. Hopefully that will convince you your concerns are real and the problem needs to be taken care of.

Image by SeppH from Pixabay

What to do, what to do

You can leave. I want this to be out there as an option – you do not have to spend your time and energy on an uphill battle with a toxic person. If you judge that fixing the problem will be difficult and draining, and you can relatively easily find another job – that might be the easiest way out. Fixing other people is not your responsibility.

However, you might want to stay. Whether it’s because you love your job and the (other) people you work with or because looking for another job is too hard, or whatever other reason.

You can work harder. Someone’s stealing your ideas? Make sure everyone knows your worth. Someone’s being being mean? Avoid them. Be mean back. Ignore them. Someone’s taking credit for your work? Communicate what you’re doing far and wide.

While this is a possible strategy, I fear that it’s not always feasible. For one, if there is a severe power imbalance (say, that person is much more senior that you are, or perhaps your manager) – it won’t work and will probably backfire. Second, it relies on the fact that you are able to prove that you did the work and have good ideas – this is not always easy, could lead to burnout due to the extra effort and may make you look like you’re not a team player. Not to mention the fact that if one is not an exceptional worker that does not make it OK for them to have to suffer through toxic behavior. In addition, you’ll be allowing the toxic behavior to continue, even if it doesn’t affect you. I don’t believe in victims being forced to fix the world for everyone’s benefit – but it’s still something to consider.

Besides all the above, I don’t like this option because I believe that you should not have to change your life for the worse because of someone else misbehaving. This is my guiding principal throughout the rest of the post: You should not have to pay the price for someone else’s toxic behavior.

Action plan

Speak with your manager (or, if your manager is the toxic person – their manager). In the first conversation you should focus on sharing what’s happening. Use the list you prepared before as evidence to drive the conversation pointing at specific incidents and their impact on you, the team and any projects you’re working on. You should ask for the manager’s help and advice in navigating the situation yourself. Informing your manager serves two purposes: 1. Creating trust. 2. Preemptive strike in case the toxic individual decides to go to your manager and complain about you.

Your manager should help you prepare to speak to the toxic colleague in a way that will clarify the problem and attempt to solve it. If you manage to fix the problem by talking to them – that’s amazing! You will be perceived as a skilled professional who can solve their own problems.

If that doesn’t work, you’ll have to ask your manager to take a more active role in fixing the issue. Offer solutions that you want and think will be effective. This is the baseline for later negotiation – don’t offer to switch teams if you don’t want to, do offer to lead a new project if that appeals to you, etc. Your manager might come back with a counter offer that is not exactly what you want but still acceptable – and you may choose to accept. You should still try to start at the optimal solution for you. Remember, the guiding principal here is that you shouldn’t be paying the price for the toxic behavior.

Image by SeppH from Pixabay

A note to managers:

It is your job to solve this problem. Even if your employee has come up with excellent strategies to fix the issue for themselves, the toxic colleague can't be allowed to continue with their bad behavior.

Make it clear to your employee that your door is open for whatever they want to discuss. One of the scariest parts of reporting something like this is to end up as the problematic one who whines about everything. Try to reassure them that won't happen. If someone needs to be moved to a different team or any other change in roles and responsibilities - it is essential that the victim not be the one hurt by the change.

If the toxic colleague is unwilling to acknowledge their behavior or make an effort to change - they should be let go. If they are willing to try - create an improvement plan with a 3-6 month deadline, and make sure to follow through. Support them in their process and make sure that the victim knows that you are making an effort. If the deadline passes and insufficient progress has been made - they should be fired.

The message to the team should be that while management will help and support your growth as a professional and a person, it can't be at the expense of anyone else and bad behavior will not be tolerated. Otherwise, bad behavior will spread and the good people will leave.

If your manager succeeded in solving the issue to your satisfaction – excellent. If not, you’ll have to escalate, probably to the next level of management, but sometimes you might be able to identify some other person who is better positioned to solve the issue. If you can, keep your direct manager in the loop and let them know you plan to speak with someone else: 1. To maintain trust. 2. To give them the opportunity to try again before you escalate. At the next meeting you’ll be repeating the same process – review the the list of transgressions, let them know what’s been done so far, offer solutions and hope for the best.

The key to this process is to be proactive, positive, and offer solutions. That’s the difference between someone who will be labeled a cry baby and someone who will emerge from this process in a stronger organizational position.

There are no guarantees this will work. Sometimes the entire organization is toxic, or your managers are entirely ineffective and you will have no choice but to leave. At least you tried.

The floor is lava: a realistic approach to work-life balance

rinaarts — Wed, 30 Mar 2022 09:54:21 +0000

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.

Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session I addressed some concerns around starting a family while maintaining a tech career. While this post will focus on the specific challenges of pregnancy and raising children, some of the insights may be relevant to any kind of attempt to balance a career with other responsibilities and interests outside of work.

tl;dr: Balance is for people who don’t have a life or don’t have work. For anyone (everyone?) else – the most you can hope for is not to neglect either one too much.

The conversation started with the a concern specifically about how to manage the final months of pregnancy: Should she agree to reduce the scope of her tasks and responsibility? Should she start her maternity leave early? Does this internal debate mean she’s weak, and a man wouldn’t even consider reducing his workload just because he was pregnant?

40 weeks and some

Well, first, let’s address that last bit – I’m guessing that if men were generally the ones who carried babies maternity leave would start the second the pregnancy test came back positive. But they don’t, so let’s just put that part away. Now, maybe some women breeze through pregnancy energetically glowing the whole time, but most of us will have some form of morning (afternoon or evening) sickness, various types of pain and experience general exhaustion. Pregnancy is not a disease, but growing a whole new person inside your body is not an easy task.

I don’t know if this an encouraging message or not, but if we’re being perfectly honest – and we should be – the cost of pregnancy on our careers is small compared to the cost of parenting. You’re pregnant for less than a year, most of which you can work through (unless you’re having a really hard pregnancy, which also can happen). If you’re lucky enough to have paid maternity leave that will add 3-12 months off work (depending on the benefits you have where you live and work). However, you’ll be parenting small children for at least 6-10 years of their life, which, depending on how many children you have and how far apart may add up to 10 or 15 years of your career.

As we’ve established – being pregnant can be tough, but the long term cost of 1 month this way or that is rather small. So I say – do what you need to do to stay healthy and strong until birth. If you need to take time off or reduce your workload – go ahead. My opinion is that for long-term image management it’s better to start your maternity leave early than to take on “smaller” tasks, but not everyone may be able to afford taking leave before the actual birth. I’m all for entirely disengaging from work during maternity leave, but again – this depends on how you feel about it and how supportive your workplace is.

Back to work

Hopefully, you’ve given birth to a beautiful healthy child, you’ve had enough time to heal and you’re ready to go back to work.

Things won’t be the same.

Let me say that again:

Things won’t be the same.

It’s not like you can drop your baby off at daycare and just get back to work as if nothing’s changed.

I hope anyone who’s reading this is part of a household with an equal division of labor which will allow you to choose who picks up/drops off, and that your work schedule and location allow the flexibility you need to manage all the tasks that raising children entail, but no matter how much support and flexibility you have – your time at work will be limited and you will have new priorities.

Assuming you want to invest in your career and your family (I won’t judge anyone who chooses one over the other, that’s a legitimate choice – just in that case I’m not sure there’s much point to read on), you’ll find out pretty quickly there are just not enough hours in a day to do everything well. Something has to give.

Balancing act

For many years I worked a part-time 80% job and I felt I’d found the perfect work-life balance you’ve always heard of. I wasn’t stressed at work, I had plenty of time to spend with my kids, no pressure. In fact, it wasn’t balanced at all – I was focused on my family and my career suffered (I talked about this in How I got my career back on track).

Photo by Eran Menashri on Unsplash

I don’t like to talk about work-life balance or the newfangled term work-life integration, I like to talk about walking a tightrope over a pit of molten lava, because that’s what being a working parent is really like. Every step of the way you have to look a bit forward and a bit to the sides and decide what’s most important right now and what can be ignored. Maybe last week it made sense to burn the midnight oil to finish that project on time, but this week you need to wind down, hang out with your family and go to bed early. Maybe last year taking less challenging work while adjusting to a new baby was the right thing to do, but this year is the time to double down and get that promotion.

You don’t get to a perfect balance and then stop. There’s no such thing, it’s a constantly moving target that changes with your preferences and your personal and work situation. Having a supportive family and workplace is essential to enable this type of flexibility week over week and year over year, but you should be the one driving change to match your wants and needs.

It’s quite possible that you will have driven colleagues without dependents who will be able to work longer, harder and maybe even better and will get ahead faster than you. Remember, life is not a zero-sum game. You can’t live your life comparing yourself to others – there will always be someone smarter, more effective, luckier than you. If you manage to get through life without neglecting any part that’s important to you too much, that’s good enough.

Last, but not least – I’ve said it before and I will say it again: Ask for help. No one’s standing at the end of life handing out medals that say “I did it myself”. If you have extended family support – go for it. If you can afford a babysitter or nanny, cooking, cleaning and laundry services – do it. Anything that will free up time for things that are important to you.

Silly Baboons, Stubborn Elephants II: Navigating Culture Differences Across R&D groups

rinaarts — Tue, 22 Feb 2022 19:55:19 +0000

In September 2019 I published Silly Baboons, Stubborn Elephants: A Product Engineer’s Guide to Working with Platform Engineers. Since then I’ve expanded my thinking on culture gaps inside engineering organizations and how they affect our ability to collaborate across different groups with different motivations and incentives into a talk, presented at Reversim 2021 conference (right before Omicron hit and everything shut down again for COVID).

The talk is in Hebrew, so I’ve included the slides and my speaker notes (with bonus content I didn’t have time for!) translated into English.

Some of this repeats the content from the original post, but there’s a lot of new content and a new perspective on other culture aspects, so it’s definitely worth the read.

Story time! Well before COVID came into our lives, I was sitting with a friend drinking coffee telling her all about how I was frustrated at work. I was working on a super important feature, and the infra groups were giving us a really hard time. Between us, I wasn’t being objective about it – I was complaining. “Do they think we’re idiots?” I asked.

She smiled at me with what I though was empathy until I was done, and then said: “You are idiots”.

She explained to me that from her experience as a manager, infra developers and product developers live in parallel worlds. At some point she called the product development teams “baboons”…

Woah there! If we’re silly baboons… They’re… They’re… Stubborn elephants!

A bit about me: I was born in Israel, but both my parents came from the US, which gave me the incredible privilege of filing tax reports in two countries. Anyway, as I was growing up I couldn’t always tell if I was doing something weird because of my American heritage or because my family was just weird. The awareness of culture gaps was always there in the background.

Fast forward a few years, after my BSc in Computer Science I want on to study an MBA where I majored in organizational behavior (technically it was my minor but I never treated it that way so let’s just go with that).

While studying organizational behavior I studied with professors who were very interested in culture, and surprisingly (or not), considering what the B stands for in MBA, most studies were focused on the wider aspects of culture in a national context, and only then how those lessons can be applied at the organizational level. This fit right in with my personal inclination towards analyzing culture differences, and became one of the ways I analyze things that were going on around me.

So, when my friend told me I was being a silly baboon I said to myself: I guess we all want what’s best for our customers, and everyone is just trying to do their job well, but still… something isn’t working.

Maybe I should look at this conflict from a cultural perspective.

During this talk we’ll cover:

What is culture and how it works at work.
Culture gaps – which common differences exist and how we can navigate through them without crashing.
A few all-purpose practical tools that help us resolve conflicts in our day-to-day work with other groups.

Let’s look at this definition for a second – we’re all individuals, unique snowflakes with our own personality. There is a lot of variance inside groups. But… when we look at certain aspects – we will often compare ourselves to what is acceptable in our culture.

So we can summarize culture as:

But what is considered normal?

Let’s look at an example:

I can say something like: “I’m very punctual. I always arrive within 5 minutes of the invitation time”. This makes a lot of sense in the context of the Israeli culture where no one expects anything to start on time and 10 minutes late is perfectly acceptible.

Someone from another culture may be shocked at this – what do you mean 10 minutes late? That’s rude and inconsiderate.

Someone from a culture where it’s considered normal to be 30 minutes late will be very surprised when they arrive “on time” from their perspective (i.e. 30 minutes late) and the event has already started without them.

This is the idea of a cultural norm – there is some individual variation, but the norm is what we expect. If I arrive 5 minutes late to an event I’m expecting to start 10 minutes late, I will be upset the event started before I got there. But if I come from a culture where on time means on time, if I’m 5 minutes late I will be angry at myself for being late, not at the people running the event.

(In fact, this happened to me when I was 2 minutes late to my son’s recital. Not only did they start exactly on time, he was first! How dare they!).

So we could say that culture is relative and individual behavior varies with respect to their cultural norms.

When we talk about culture in a work setting we have to consider different cultural layers.

The first layer is national culture. This is a deep part of who we are, even if we can’t always see it. It’s our window to the world.

Over that we have a layer of individual variance, because no – we are not all identical just because we happened to be born in the same culture.

Over that we have the organizational culture layer. Such organizations may like to think that their culture “wins” over local culture, but usually that’s not what happens. Usually, the organizational culture is adapted to fit the local culture. Sometimes, if the organizational culture is too mismatched with the local culture – the organization won’t be able to “make it” in that location. More often, the culture and values of the organization are interpreted in a way that the management did not intend. Mostly values are ambiguous and even conflicting – so it just works and no one really notices.

The final layer, which is the subject of this talk: In every organization there are different functional groups like marketing, product and engineering. Each group has different goals, motivations and values. So while we expect some alignment with the organizational goals, it doesn’t always work out exactly as we thought.

At the organizational level, and even more so at the functional group level, we will see less individual variance. This is due to self selection – if someone feels their personal values or way of working is mismatched with the group or organization, they can easily move to another group or organization. It’s not the same as uprooting yourself from a place you’ve lived your whole life and moving to another country.

The positive side of the self selection effect is that people who work closely together can be well aligned and work smoothly together. But when they need to collaborate with another group of individuals who are aligned on a different way of working – there can be trouble.

Let’s take a look at some common culture gaps:

On Monday, the product development team ask the infra team for support. The product team needs to release their very important and absolutely essential feature within a few weeks, but the infra team is not available to help at the moment. Actually, they weren’t planning to support this requirement, it’s not in their roadmap and they don’t have the resources. But the product development team needs it… Now!

(This scale that will be going with us for the rest of the talk is a relative scale loosely based on the cultural scale from The Culture Map by Erin Meyer. There is no “absolute” metric, it’s just a tool to visualize which cultural gaps are significant and which are less significant)

Conflict source

Product developers usually work in short cycles. Days, weeks, maybe in a really big corp – a quarter. If you don’t deliver fast, you’ll miss the market.

On the other end of the spectrum we have infrastructure teams. Infrastructure projects are long, they get planned thoroughly and it may take years to complete.

This cultural dimension is not about how “fast” engineers write code or how long the sprint is – the speed refers to how long it takes to deliver a feature to its users and say “it’s done”.

Which is better? Working “fast” or working “slow”? The answer is – neither. Or both. Depends who’s answering.

“Fast” is good for product developers who need to deliver value to their customers and get continuous feedback as quickly as possible.

“Slow” is good for infrastructure teams who need to take their time and consider the long term effects of their decisions on the entire organization.

*Conflict resolution*

Product development teams: Don’t show up with requests at the moment you need support. Bring the infra teams in early on. A simple heads-up will enable them to allocate the appropriate resources, or at least – not be caught by complete surprise when you appear out of nowhere asking for things.

Another option is to suggest someone from the product development team will do the necessary work with guidance from the infra team. This way the product development team can get what they need sooner without the infra team having to put a lot of time and effort into it.

Infrastructure teams: Integrate ongoing support for your internal customers with your regular work process. You can’t make long term projects and internal plans your sole focus. Product development teams need support now.

Looking at this conflict from an organizational level – the infrastructure teams should be incentivized to give good service to other teams. We sometimes forget that’s what those teams are actually there for. If they give good service it will help everyone work together better and increase the overall engineering velocity. When product development teams don’t get the support they need – they’ll start using bubble gum and thumbtacks to hack their way into a working solution – and that never ends well.

On Tuesday the designer asks engineering to add a tooltip to an interface, it’s a small change. The engineer says: I’m sorry, we can’t. If they had more time and energy they’d say: Well, there’s really no such thing as “can’t” in software, there’s only “how long will it take”, but what you asked will take a long time so let’s not. But they’re tired and decide to cut out all that explanation and just say “can’t”.

Now the designer is upset because clearly this engineer doesn’t care one bit about customer experiences. And the engineer is frustrated because the designer is insisting on insignificant details and doesn’t understand what “real” work is.

Conflict source

When designers start working they’re almost literally starting from a blank slate. They don’t have to worry too much about what was there before. This is not to say they don’t take into account design systems, common paradigms or what they think engineering can implement in a reasonable time frame, but their design is not strictly limited by these considerations. The can (and do) decide what’s best for the new design and go with that.

On the other end of the spectrum we have engineers who are carrying a load of technical debt. I’m not going to discuss if tech debt is a good thing or how to manage it, I’m just acknowledging that it exists. And not only does it exist, it adds constraints and dependencies from the existing code and features which can severely limit our ability to do stuff.

So when the designer shows up with a pretty blank slate and has to work with someone carrying a pile of tech debt, things that may seem simple as adding a tooltip can get ugly quickly.

*Conflict resolution*

Engineering: Don’t stop and “can’t”. Explain where the existing system limits your options and makes it hard to do what design asked for. Don’t assume they know and don’t care. If you explain your side with good will – design will cooperate.

Try offering other options: Where are the pain points? Maybe you can make a small change in the design that will eliminate the problem? Maybe you can offer a solution that will give us 80% of the value at 20% of the cost?

Design: Wherever you can stay within the current best practices – please do. If things have been done before it will be easier to do them again. You don’t need to reinvent the wheel for every feature.

On Wednesday morning one of the engineers comes into the office and says “good morning” to the security guy who immediately responds: “no”.

(Insert laugh)

This is something you hear often from people working with legal and security. The block everything. And that can be quite annoying when you’re trying to do stuff.

Feature teams may be trying to do some quick and dirty experiment and legal and security are interfering with their plans just because they didn’t pay enough attention to legal and security restrictions.

Legal just keep insisting on these draconian measures like a long legal agreement with an “I agree” checkbox at the very end, or forcing the feature teams to consider what information they’re retaining, how they’re storing it and for how long (the horror!). I’m being sarcastic, of course, but these things can really delay development and the whole thing is unpleasant for both parties.

Conflict source

Some groups in the organization have more flexibility in the way they work and in their ability to change direction or decisions. Others – not so much.

The role of legal and security is to protect the organization. They have to make sure that all these pesky engineers won’t cause a security breach, hurt the users’ privacy or expose the company to a law suit. So to those of us who are trying to get things done, they really give off that stubborn elephant vibe. On their end, they may feel that the feature teams are being reckless, not really caring about the dangers they’re exposing the company to.

Let’s pause for a bit and try to remember that everyone is just doing their job. Legal and security are there to protect the company and the users. Feature teams are there to deliver value to their users as fast as they can and (hopefully) make money for the company. Both of these functions are essential for the organization, so we must reach a balance between the optimal amount of protection and development velocity.

Conflict resolution

Engineering: Do yourself a favor, get legal and security into the development process early. Talk to them often. It’s best if you can get a single point of contact for an entire project. When they have the appropriate context and intimate knowledge of what the team is working on – you won’t have to explain everything from scratch every time you talk to them. This helps them make faster decisions.

Best case scenario – they’ll be able to point the feature teams in the right direction before they get locked in to problematic solutions that will be hard to change. Even better case scenario – they’ll be emotionally involved in the project and feel that it’s “theirs”, pushing towards creative and flexible solutions on their own to make things successful.

Legal and security: Don’t say “no”, you always have to come up with an alternative solution. Process-wise – make sure that it’s clear to everyone that you have to be involved from the get-go and not brought in just before release. If you get organizational buy-in, your involvement may be seen as necessary and even welcome.

[Bonus content ahead! This part was not in the talk, which is why it’s structured a bit differently. For continuity let’s say all of this happened on Thursday]

I’m just a simple software engineer, I don’t get machine learning or how these people live with themselves. I give the computer instructions, and it does what I told it to do. Admittedly, it not always what I meant it to do, but it always does what the code says.

With machine learning it just doesn’t work that way. I mean, imagine a result coming back with a confidence score! What do you mean you’re not 100% sure? It’s never 100%. Sometimes things change when you re-run the exact same code. How can stuff like this be verified? [Cries in traditional software engineering]

Conflict source:

Look, there are a lot of open ended problems out there, but a lot of what we do as product managers and engineers is reduce that uncertainty and ambiguity and agree on how the product will behave.

In machine learning uncertainty and ambiguity are built in. That’s what they expect. Models are inherently unpredictable and the ability to determine if something has changed because something in the real world has changed or the model has a bug is limited.

This makes it very hard for us to work together without going off the deep learning edge.

*Conflict resolution*

ML engineers: Please help software engineers “get” that ML is not magic, explain confidence scores and how they’re calculated. Give us a peek into your mysterious world, maybe a “Machine Learning 101” course. I’m sure we have the ability to learn this stuff, but it doesn’t mean we already know it.

Software engineers: Breath. Meditate. Do whatever you need to survive the pain of uncertainty. Working with ML is surprising and inconsistent. It is what it is.

[/End bonus content]

On Friday engineering informs product that for the next two months all the software engineers will be working on switching from React to vue.js. Product is not happy with this idea.

You know how some engineers are, they love technology. The want the most stable, fastest, newest tech stuff out there. And that’s totally fine! Technology is part of an engineers job and it’s OK to get excited about new toys.

But then product comes to rain on the party, they don’t understand why the newest trendy tech is the most important thing in the world and why it’s worth delaying development for two months. They don’t see the value in switching to a different tech stacks – if it ain’t broke, don’t fix it!

Conflict source

It’s not that engineers don’t care about customers. I mean, some of them don’t – but even if they care deeply, a big part of what drives them is technology for technology’s sake, otherwise we would all still be programming in COBOL.

The problem is that engineers don’t communicate the value of technology to the product, so product is under the impression that engineering just likes doing whatever’s fun and trendy, with little regard to delivering value to customers, which is what’s really important.

In the short term there may be a tradeoff between worrying about technology and delivering value to customers, but in the long run it may converge. All engineering has to do is prove it. Show the powers that be how many dollars that tech is worth.

Conflict resolution

Engineering: Time is money. Easier recruiting and greater retention is money. Future development velocity is money. But you have to do the ROI calculation, you can’t just hand wave your decision because “it’s cool”.

Product: Sometimes you have to invest in the long term at the expense of the short term. You can find appropriate compromises. Maybe put a limited number of people or time on whatever engineering wants to do, or let them do a proof of concept. Something that won’t stop all feature delivery while engineering is checking out some cool new tech.

These cultural gaps or conflicts are not all the possibilities, they’re just some examples I’ve seen personally and wanted to deep dive into. This slide contains a few other cultural gaps you may consider, but the point is that identifying cultural gaps is another tool in our toolbox to analyze problems in group interaction and help us solve the deeper conflict, instead of the symptoms we see at the surface.

We’ve reviewed a few culture gaps, now let’s get down to business with some practical tools to resolve any conflict:

When something isn’t going well with another team or person, ask yourself if this is a personal issue or a cultural issue? If it’s a personal issue speaking with this person’s manager may help. But if it’s a cultural problem – escalation to a manager won’t help at all, because they’ll have the same point of view on the issue! This won’t get you anywhere.

Once you’ve identified a cultural gap, you should try being explicit about it. You can try saying something like: It seems like you’re approaching this issue with A, but we’re approaching it with B. Can we work together to bridge this gap?

It’s good to remember that just like you see them as behaving nonsensically, they see you as behaving nonsensically. If you share your point of view and how you perceive their way of looking at things – even if you’re wrong – it shows empathy and respect. It also gives them the opportunity to see things from your side, opening up their own point view, which is already a big step in the right direction.

Be nice. Respect them personally, respect their time.

Other teams are not sitting around idly waiting for you to give them work to do, they have quite enough to do on their own. If you need help, at least do them the courtesy of giving them a heads-up and some detail on what you’re planning to do so they can adjust their plans accordingly.

Even when there are conflicts – not only do you need to assume good intentions, you also need to assume competence (we kind of miss that part sometimes). You’re not silly baboons and they aren’t stubborn elephants, you work at the same company on the same end goal. Your immediate interests may clash, but it’s worth it to try and see the bigger picture here.

This is a nice little trick I’ve picked up over the years: If you need to collaborate with someone, one of the ways to get their cooperation is to frame it as a request for help. Asking for help is nothing to be ashamed of, right? It’s essential for being effective at work. But framing the request that way makes the recipient feel needed, it makes them want to cooperate and be generous with their time. They feel important and appreciated, and they’ll want to continue feeling that way.

This is the the most powerful tool we have in our toolbox. Almost every conflict can be resolved by first building a personal connection. And to build that connection – we have to communicate. I know, after all this time at home with COVID we’ve forgotten what little we know about personal communication, but in spite of the cliché, communication is the only thing that works in almost every situation.

When you have solid relationships and a wider personal view of the people you work with, you might come to realize they’re not that bad, even if you don’t see things exactly the same way. With some mutual trust you’ll be open to different ways of working and thinking.

Don’t be too scared or lazy to communicate personally and directly. If you can meet in person – great. If you can’t? Hop on a video conference. Can’t VC? Try chat. It’s much more personal and pleasant than emails. And if you’re chatting – use emoji and gifs. I don’t have any hard data to back this up but I’m sure it helps creating that personal connection.

Stay away from JIRA and other task management systems. These systems are important for managing and tracking projects, but there is nothing that kills trust faster than transferring tickets between groups and having long discussions in the comment section. First discuss and make decisions together, then update JIRA.

Summary:

“Culture is whatever is considered normal”

Culture gaps can create conflicts that are hard to identify and resolve because they are below the surface.

What should you do?

Identify the culture gap(s) – is the problem related to one (or more) of the culture gaps we discussed? Maybe it’s not a culture gap at all or there’s another culture gap we need to identify?
Analyze the culture gaps we’ve found and identify which one is causing the current conflict
Resolve the conflict with one of our practical tools: Raise awareness, be explicit, be nice, ask for help and building relationships.

Thanks Karen Cohen for calling me a baboon, without her this talk would never have existed. And thanks dear reader for making it this far! I hope you enjoyed it. And despite the slide, if you don’t know Hebrew I suggest following my English account instead at @_rinaarts_.

This email should have been a document

rinaarts — Sat, 19 Feb 2022 20:09:47 +0000

Everyone knows about the terribly boring and ineffective meeting that should have been an email, but… Should it really have been an email? I’m not so sure. I think email in the workplace was fine when that was all we had, but that form of communication has outlived its usefulness and should mostly be replaced by other mediums. There, I said it.

Emails are traditionally used for 3 main purposes:

Announcements

This type of email is meant to deliver information and a response is not expected or required. It can include some call to action, but usually that action is optional (e.g. if you find something wrong in the information part) or external to the email (e.g. fill out some form).

As far as anyone pays much attention to announcements, email is a perfectly good medium for this type of communication. It lands in everyone’s inbox and waits there until they read it or it gets buried under the constant stream of emails. The subject can easily signal to the recipient if they’ll find the content interesting and relevant or not, reducing cognitive load.

Personally, I pretty much ignore anything that doesn't have [Action Required] in its title. I don't even do Inbox Zero, I just periodically mark everything as read. If I missed something important - someone will let me know one way or another. And if no one does - well I guess it wasn't that important to begin with.

Personal communication

Emails can be used for personal communication, but its asynchronous nature and formal structure (subject, content, signature) makes it feel a bit impersonal. So while it’s great for introductions, I think for chat is better for personal communication in general, but also specifically for workplace communication.

While chat has the advantage of being asynchronous, it does have a synchronous mode – once both parties are available at the same time, they can have a real-time conversation (that’s what the Alice is typing… is there for). Emojis and gifs and the absence of a strict structure makes it much closer to a face-to-face conversation. Email is far less conducive to this type of synchronous back and forth.

Discussions and decisions (D&D)

Some organizations rely heavily on email to get things done. In this usage pattern, they’ll send out a question and start a discussion over email. Typically, this type of email includes a short introduction with a description of the issue, a few points they want feedback on, and a call for action (let me know what you think).

This is where it gets messy and this is the type of communication I believe should be replaced by a collaborative document.

Common pitfalls in D&D emails

Splintered replies

Because an email is just a block of text, a person can only reply with another block of text. So, even if they’re only addressing to one point in the original email they have to respond to the whole thing. This sub-subject may require it’s own specific discussion, but it can’t be separated in anyway from other discussions on different points of the email.

Hey everyone!
background background
* Point A
* Point B
* Point C
What do you think?
Thanks, Alice

Looks good to me!
Thanks, Bob

Question about B?
Thanks, Carly

Answer on Carly's question about B.
Thanks, Alice

Comment about A. And also B?
Thanks, Daryl

Good point about A!
Thanks, Bob

Have you though about D?
Thanks, Ellen

Point about A taken, already answered B above.
Thanks, Alice

Oh sorry, missed that!
Thanks, Daryl

This is a manufactured example without any real content, but you can see how a discussion like this can be hard to follow. Some questions or responses may be lost in the thread, and it’s hard to discuss a specific point without spamming everyone who may be interested only in some other aspect of the discussion.

The format may also cause issues in some cases: I’m not sure how this happens, but I’ve seen threads that somehow end up reversed like some kind of weird corporate Memento – the latest response appears at the top , which makes it quite difficult to get a coherent understanding of the discussion. Others get so deeply indented the content gets squashed into something entirely unreadable.

Double quotes

In order to avoid misunderstandings, responders often quote the specific point they are referring to, making constructing a response a frustrating exercise in copy-paste. Eventually people get tired of copy-pasting the whole thing (usually within two responses) and the original context is lost, making it even harder to understand the conversation.

Hey everyone!
background background
* Point A
* Point B
* Point C
What do you think?
Thanks, Alice

Point A
I think we should use approach X.
Point B
I think we should reconsider this and do Y instead.
Thanks, Bob

I think we should use approach X
Sounds good to me.
I think we should reconsider this and do Y instead.
I disagree, this has been discussed before, we're sticking with B.

Derailing the conversation

Often, the first responder will ask about one or two points, and anyone who joins after that will only respond to what the first responder said. The original content will be lost and the conversation will focus only on a subset of the issues. It’s very hard to go back to the beginning and raise new issues and questions once the conversation has gone in another direction. See for example poor Ellen from the first email thread, who asked a question and no one even noticed.

Organizational Knowledge

While having an effective discussion is important, the above email ailments pale in comparison to the final and most important issue: Emails provide the illusion that a decision has been made and communicated.

The neverending story

At the most basic level, there is no way to effectively end an email thread. Even if there is a clear message at some point saying: This is the decision we’ve reached. Someone can always respond later with new questions, disagreement or even messages conveying support. There is no easily accessible and verifiable source of truth for the decision or its approval by relevant stakeholders.

Another side effect of the never ending stream of messages is that the decision may disappear somewhere in the middle of the thread. Good luck digging that up later.

Finding Nemo

Many messages are sent to specific people. That information is not accessible to anyone who was not on the original thread unless someone forwarded it to them. This specific problem can be solved by sending the message to some form of group (e.g. a Google group, Slack channel, Microsoft have their own version of this in Teams) but that may cause spam for many irrelevant people, or worse – having those irrelevant people chime in, adding to the general noise. Not to mention, anyone searching for this information will have to wade through a long back-and-forth of email messages to try and figure out what the bottom line was.

Most of these issues will occur in other conversation mediums as well (e.g. chat). The only advantage some of the other mediums have over email is that they're usually editable. So even if the rest of the post doesn't convince you this type of discussion should be moved to a collaborative document - do yourself a favor and use a medium that allows editing messages. When the conversation is over, update the final decision in the first message for future reference.

Recap

Emails are ineffective for anything but the most trivial discussion, and is inconvenient for uncovering the resulting decision at a later time. This means the organizational knowledge is effectively lost.

Use a document instead

Instead of sending out an email, write a block with the same basic elements you’d have in an email.

Date for historical reference, subject for context. Relevant background, content and call to action.

I’ve used different colors to illustrate which comment goes with which section, but in collaborative documents I’m familiar with – text which has been commented on is highlighted, usually with a yellowish/orange. When selected the matching comment thread is expanded. This enables readers to read comments in the appropriate context.

In this replication of the original discussion we can see the following improvements over an email:

Comments

Since comments refer to a specific section of the text, we no longer see splintered replies or double quotes. In addition, no single commenter can derail the conversation because the original text is still clearly visible and continues to be the main anchor of the discussion.

When Daryl selects point B to ask his question, he will immediately see that Carly already asked that question, eliminating unnecessary repitition.

Ellen has no appropriate anchor for her question, but she can still get her question seen and answered by commenting on some hard to miss unused real-estate.

Approval

Once the discussion is over, each stakeholder must explicitly state they’ve reviewed the content by checking their box. In some collaborative documents users can be tagged and they will be notified that they have an assigned task waiting for them. Some even include reminders that will continue to nudge the assigned users until they complete the review (i.e. check the box).

Total recall

After the comments have all been answered and the review completed, Alice can tidy up by resolving the comment threads and updating the text to reflect the important points and final decision. If anyone wants to see how the decision was reached, the comments and edit history are available in previous revisions of the document. For everyone else, the main points and final decision are easily accessible.

To ensure the information is available to whoever needs it, the document should be kept in an accessible and searchable location. This means its permissions should be set to the widest appropriate audience, preferably a group and not specific individuals.

If, at a later time, the information in this document becomes obsolete – it’s best to update it to reflect that or even archive it. Don’t delete it! It’s important to keep the historical context. Just make sure it’s clear the information is no longer up-do-date.

[Action Required]

Since task assignments may also get lost in the constant stream of notifications, I do recommend calling the attention of required approvers via chat or email. Be careful not to duplicate the content from the document, just give the subject and a link so they can complete the discussion and review in the document and nowhere else.

One document to rule them all

Some heavy weight processes like design reviews are already carried out in documents. However, if you start opening a document for each minor discussion, you’re going to end up with a lot of documents, which can become rather hard to follow. It’s still better than email, don’t get me wrong, especially if you keep them all in the same folder. However, there is a better way to keep all that knowledge under control.

The Pensieve (or: Project Log)

In the Harry Potter Wizarding World, a Pensieve is a magical basin where one can store their memories and enables the owner to examine and sort through thoughts and ideas.

Each project should have their own Pensieve document where they store all those one-off, relatively scoped discussions and meeting notes. If spontaneous discussions did happen via email or chat – they should be summarized and copied into the Pensieve. This creates a single location which can be relied on to contain all the little things that will need to be referenced later, but don’t really deserve a document of their own.

If you maintain some kind of page or index as the main entry point for each project which contains all the project information like design docs and product specs (which I think is a good practice), you should link to the Pensieve from there, as it’s an important piece of the project.

The name Pensieve was suggested by one of my Twitter followers, and I think it's genius. Unfortunately, it's been a tough idea to sell and I've seen several teams who've adopted the idea (yay!) calling their Pensieve a Project Log. I've started doing the same, so I guess you can't argue with success.

Illustration

This is how I suggest you structure your Pensieve, but it’s entirely up to you how to manage it. You might want to add team meetings, retros, on-call hand-offs etc. in the same document – or not. You may have some advanced documentation framework that enables creating an effective Pensieve in some other structure other than a single document. Experiment with the tools you have and see what works for you.

✏️ Our Project Log ✏️

Welcome! This document is meant to be the “hive mind” of Our Project. It will help us make decisions effectively and preserve a collective memory of why and how those decisions were made.
[Important link] [Important link]

Feb 14, 2022 | Product sync meeting notes
Attendees: Alice, Bob, Carly, Daryl, Ellen
Summary:
* Point A
* Point B
AIs
[] Bob to clarify X
[] Carly to finish-up Y

Feb 10, 2022 | Rollout plan decision
Slack discussion summary
We've decided to start rollout at 5% on Feb 15th, increase to 20% the following week, and if all goes well - GA by Feb 28th. The feature is opt-in and we feel the risk of a fast rollout is low.

Jan 31, 2022 | Copy adjustments
The copy in user flow Z is confusing, we think it should be changed to have a clearer call to action. Suggestion:
#1 Start now!
#2 Begin free trial
#3 Activate!
Please vote on your preferred option!
[] Bob [] Daryl [] Alice

Jan 15, 2022 | M1 status update
We are on track for M1 GA at the end of the month.
Task 1 - done
Task 2 - done
Task 3 - in progress
Task 4 - done
Task 5 - not started

I know this is a major change from how most of us do things, but I hope I managed to convince you why a collaborative document is a better and more effective way to discuss and decide, as well as preserve organizational knowledge.

I don’t usually end posts with a call to action, but in this case I’m quite curious and excited for you to share examples of what you’ve done with these ideas.

Tips for starting a new job

rinaarts — Mon, 07 Feb 2022 08:52:17 +0000

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.

Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we’re helping someone who’s about to start a new job and is worried about onboarding. There is an infinite amount of content on how to start a new job and how to onboard well, so I’m going to focus on 3 tips:

No use crying over spilled milk

You are not perfect. You made a few mistakes in your interviews. Maybe stupid mistakes. Now you feel unworthy, as if you’re being let in as a favor or someone might deem you unworthy because you didn’t ace all the interviews.

Nobody cares.

Assuming your interviewer remembers you (it’s quite likely after interviewing dozens of people, they don’t), and they work with you (if it’s a big company – you may never see them again), you’re in. You got an offer, passed the bar. What happened before is no longer relevant. Blank slate.

So let it go and move on. No use dragging that stuff with you into work.

Just to add a bit of credibility to this tip, you should know that I did not do well on one of my technical interviews at Dropbox and then worked closely with the interviewer who had a very vague memory of the whole thing, it didn’t hurt our working relationship.

Great expectations

There is no way you can pack everything you need to know into your brain during onboarding. Unreasonable. Can’t. Won’t happen. Even if the onboarding materials are well planned and well written and/or recorded (which is quite a stretch), it’s just too much information all at once.

I suggest writing everything down, even if you don’t understand much (including all the links you happen to come across) and revisit them after a few weeks. You might understand a bit more the second time around.

In any case, don’t feel bad or stupid about not being able to absorb knowledge which may have taken years to create within a few short weeks.

Who you gonna call?

One of the toughest internal debates during this time is when to give up trying yourself and ask someone. You want to give a good impression and don’t want to appear dumb. To overcome this I suggest the zero-ducks approach: Prepare before asking by gathering background and relevant information and listing what you’ve already tried.

This strategy makes you look proactive and professional, helps you feel more confident about having done everything you can before asking and actually helps the person you’re asking to focus on what you actually need from them and get to an answer faster, win-win.

If by some chance it does turn out to be a question you could have found the answer to yourself (there are no “stupid” questions, not really) – it’s OK. You’re new. No one expects you to know everything. Also, people’s memory is short – they will forget. Don’t worry about it.

Note to employers

I think that by now we should know the “all you can cram” approach doesn’t work. I read somewhere that the purpose of a good onboarding program is to create an experience of success and a feeling of belonging. Sending your new hires to read or watch a whole lot of materials creates neither. It probably creates the exact opposite – an overwhelming feeling of loneliness and failure.

I think a better approach is to give them something small to work on, together with a training program for the most basic and essential things they need to know which should be presented personally by people they will be working with. They should leave this process knowing where to look for answers, who to ask for help, and a feeling they did something productive and useful, however small.

In any case, if you’re feeling lonely and overwhelmed – you should know it’s not you, it’s the process. Almost no one gets it right, and it will get better.

Defensive estimations and time management

rinaarts — Tue, 01 Feb 2022 16:17:34 +0000

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.

Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we’re dealing with a manager who doesn’t trust task estimations and asks to reduce them, resulting in stress and overtime. Add to that a feeling that you’re not keeping up with the tasks you’ve committed to completing… This is, of course, not the healthiest environment, but unfortunately, still quite common.

Defensive task estimations

So, under the assumption that this organization chooses to give task time estimations (not obvious) and under the assumptions that everyone is terrible at it (including you) and your manager is undercutting the estimates you give, here’s what you can do:

Break the project into tiny tasks. Tiny tiny tiny. Smaller than that. Each task should have a clear definition of done.
Give each tiny task an estimation. No tasks should take less than 2 hours, no task should take more than 2 days, 3 if you must.
Sum all of that up and add 20% buffer.
Add on-call duty, time off, holidays etc.
Add another buffer for customer bugs and unplanned interruptions and delays.

(Some of this is just good task definition and management, but the level of detail and having to explicitly state things like holidays which should be obvious is the defensive part)

At this point this type of manager will say “that’s too much”. Now you can ask: “OK, then what do you want to cut from the project?”. If you’d given an estimate for the project as a whole, or week-long tasks, it would be easy to say “cut the time in half” or “this task shouldn’t take a whole week”, but with such a detailed plan it would be tough to say “this task should only be 6 hours instead of 8”, and since they want “this” done they won’t really be able to cut individual tasks. So they’re going to try to cut time from your 20% buffer. That’s annoying, but there’s not much you can do about it. Next time don’t include a buffer, just add 20% to each task. Your manager has shown their judgement can’t be trusted.

They may try to cut the bugs and unplanned interruptions and delays as well, just make sure you tell them that if you don’t plan for those they will happen anyway and you’ll have to prioritize them as they occur. That’s fine (and actually, the way it should be).

Make sure your plan is recorded and it’s very clear what the manager changed.

As you work, be sure to keep your manager updated on how things are going relative to the plan and exactly what’s causing delays. This is a good practice in general to keep your manager in the loop, but it’s even more important in a low trust situation like this.

You may still fail to deliver “on time”, but you’ve laid down the groundwork to show that you did your absolute best. Hopefully, you’ll be able to show your manager that the buffer was necessary and where the delays happened and move one step closer to convincing them that you can’t just cut time estimations and have the work magically be done.

This might be a good place to stop and say that if this relationship does not improve and there is no immediate reason to stay in such a work situation, you can also consider switching to a different manager or workplace where there is more trust and less need for defensiveness.

Time management

I’m guessing that under such a stressful environment a lot of mental bandwidth is being wasted on your mind buzzing with “not enough” – not getting enough done, not working fast enough, not good enough. Just that part is going to ruin any chance of productivity. This could be the case even if your work environment is fine, but you’re suffering from some form of imposter syndrome.

So, first of all – it’s possible that all of that “not enough” feeling is in your head. If you can get some real feedback on your performance – get it. You might be doing just fine. If you get positive feedback and everyone’s happy with you – try to let it go. You’re enough.

If you can’t get quality feedback at all, are told you need to improve, or can’t accept that you are enough, there are still things you can do to improve your experiences.

I recommend documenting everything you do for a week or two. You can do it every hour, or if you can manage every 15-20 minutes – that’s great. Document what you’ve done in the past period of time, but also how you felt. Were you in flow? Did you feel productive? Were you interrupted? Couldn’t concentrate? I admit, this is not an easy task, but it’s for a short time, so I believe it’s worth the effort.

Now that you have a log of what you did and how you felt, you can identify common themes, which tasks and work environments work for you and which don’t, which hours of the day you feel more productive etc.

If you’re more productive in the morning, but are used to starting at 11AM – try adjusting your work hours. If you have trouble concentrating in the office – try to find a quiet corner or work more from home. If there are tasks you hate doing – try to get them out of the way quickly so they don’t sit in the back of your mind ruining everything else. Figure out a strategy that works for you, get support from your manager or colleagues if you can get it.

I think even a small improvement in your subjective feeling at work can create a virtuous cycle which will improve your overall wellbeing and productivity.

I hope that was helpful!

Rubber duck debugging – out. Talking to a person – in.

rinaarts — Mon, 17 Jan 2022 20:01:31 +0000

If you’re part of the software industry you may have heard of rubber duck debugging. The idea is when you’re trying to debug an issue, you’ll explain it to an inanimate object and the answer will present itself. This sounds cute, especially if you visualize yourself speaking to a rubber duck, or teddy bear, or cat. But trust the software industry to find the dark side of any cute idea.

Photo by Quang Nguyen Vinh from Pexels

Many software engineers, particularly when they’re just getting started (but not only!) find it hard to strike the right balance between asking questions and figuring things out on their own.

First, they’re afraid of looking “dumb”. Second, many engineers convey (whether on purpose or inadvertently) that their time is too precious to answer “unimportant” questions. Third, often effective communication is neither engineer’s strong suit, and things may break down in that area.

Now, don’t get me wrong – it’s very important to be able to figure things out on your own. One of the most important skills for software engineers, actually. Figuring stuff out on your own helps you grow and learn. And to be honest, interrupting someone for every tiny question you have will hurt their flow, cause some annoyance, and isn’t the most effective course of action if, for example, you have to wait for them to answer. However, sometimes, something that will take you hours or days to figure out on your own can be solved in under a minute by speaking to a person.

Balance is key.

To ask or not to ask, that is the question

This is where the rubber duck comes in. When used correctly, before we interrupt an actual real live person, we talk to the duck as if it was a real person. You explain the context and background, you carefully phrase the problem. You cover what you have done so far to investigate or try and solve the issue. Since you have some motivation not to look “dumb”, you’ll put quite a bit of effort into this process – verify your assumptions are correct and you’ve covered everything you could think of and try yourself. Often, at this point the solution presents itself, and that’s that.

Sounds perfect, right? Where’s the problem?

Photo by Ann H from Pexels

Explaining a problem to a rubber duck is not like explaining it to another person. There’s no inhibiting factor of not wanting to appear like you haven’t tried enough or not wanting to interrupt someone for no good reason. So, you may skip some of the prep work of explaining the context and background and trying new approaches, in which case the fake conversation is not effective and doesn’t lead to a solution.

But the main problem is that speaking to a duck is actually dehumanizing. Imagine someone telling you to go talk to a duck before interrupting them. That’s embarrassing and humiliating. This sways the balance way too far in the direction of figuring things out for yourself and not asking. Even if that was the most effective way to resolve the issue. Over–communication is not really a problem in the software industry. People have enough trouble scraping up the courage to ask a question, do we really want to discourage them by pointing them at a duck?

Zero ducks

Let’s get rid of the duck and focus on the part that actually matters: Preparing for a conversation.

Write a message or, if necessary, a full fledged document. Include all the relevant context and what you’ve tried so far. Explore those side tracks to double check what you’re saying is accurate and try things that occur to you as you’re writing. By the time you’re done – you either have the answer or are fully prepared to have a useful conversation with someone. You’re being respectful of them and their time by preparing everything you think they need to know ahead of time, and by making sure you really need their help.

Even if this is your best friend at work and you feel that you could contact them with any question you have no problem at all. Even if this is the most attentive senior engineer who absolutely loves mentoring and answering questions. Help them help you, come prepared.

Thank you Shir Granot Peled for making the point that rubber duck debugging wasn’t just “cute” and could be abused in the real world. I hope I’ve convinced some of you to be careful when using or referring to this tool.

How to write an effective design document

rinaarts — Wed, 12 Jan 2022 19:56:29 +0000

So, you’ve come up with a beautiful, elegant, solid software design. But to move forward you have to get it approved. And to get it approved, you have to communicate it to others. Because, unfortunately, having the idea in your mind is not enough to get it built as you envisioned it. Getting your design across effectively is not a simple task, and many software engineers are not skilled at it. But as most skills, your skill at writing design documents can be improved, I hope this post helps you on your way.

As we write a design document we should keep two main concerns in mind:

Purpose

In my opinion these are the three objectives of a good design document:

Get buy-in for the high-level architecture from relevant stakeholders (engineering managers, technical leaders, engineers from other relevant groups).
Provide a blueprint for implementation.
Provide documentation (for historical reference, onboarding etc.)

But most importantly: A design document may include a summary of requirements, if appropriate – but it should not read as a wishlist. Someone reading a design document should get a clear idea of what you are planning to do.

Image by Pexels on Pixabay

Audience

Who will be reading the design document:

People who need to approve/provide feedback on the design.
People who need to do the work outlined in the document.
The author (you’re not going to remember why you did any of this in a couple of months).

In addition to their role, readers may have varying context on the design:

Internal readers who already know the background whose memory just needs to be refreshed.
External readers or newcomers who have no or close to no context and need a high level overview of what this document will cover.

When we write a design doc we need to keep the purpose and the different audiences in mind so we can write the right thing in the right place at the right level of detail.

Now that we know why we’re writing a design document and for who, let’s get into what it should include:

Intro

Before we do anything, we need to catch the very limited and easily distractible attention of the reader. They’ve just received some form of notification letting them know we’ve shared a document for review with them, they want to know what this is all about. If we don’t catch their attention they might move on to the next email in their inbox or the next notification. Don’t waste this precious area on technicalities, give them something interesting.

So, after the title – the first thing a design document should include is the relevant context and background information needed to understand the problem being solved: What are we trying to solve and why.

This should be a summary of what you want to achieve, not how you want to achieve it. A good way to check if your design works is to check if it actually achieves the objectives laid out in this section.

Make it short

One or two paragraphs.

And to the point

Think how you would explain the issue to your skip-level manager if you met them in the elevator. They have some context and technical know-how, but are not involved in the bits-and-bytes of the project.

Clear

Try to avoid unnecessary abbreviations and internal terms. Link to explanations of the terms used where possible.

Bullet points

You may use bullet points if that helps you clarify the problems or objective, but you don’t have to. If you’ve got more than 3 bullet points check yourself – are they really different objectives? If so, maybe you’re trying to achieve too much with a single design and this should be split into different features or components to be designed separately?

Tell me what you want

If you’re having trouble figuring out your objectives you can ask yourself: What value are you trying to deliver? Toyota’s 5 whys may also help you define what you’re really trying to achieve.

Outline

If there are a few main sections to the document, you can provide a high level outline at this point. Not every heading and subheading should be here, but links to the main sections can help the reader skip to the part that interests them. Remember, we’re trying to keep this short.

Technicalities

Now that you’ve got them hooked – add the bureaucratic bits about the approval process, things like:

Document status: WIP / Under review / Approved / Implemented / Cancelled
Author(s) / DRIs / Owners
Last update date
Requested review date
Approvers list

Make your approver’s life easier:

If they’ve been called in for a specific purpose, i.e. security or legal review, point them in the direction of the relevant section using a direct link. They shouldn’t have to read about your APIs if all they care about is the retention policy of your user’s information.
Not everyone carries equal weight. Clearly mark which approvers are required and which are optional.
Set a date for the review. People are busy, they have to prioritize their work. If you leave things open-ended and depend on people’s good will, they may not get around to reviewing your document. Be respectful, give them enough time to complete the review, but also feel free to nudge them as the deadline approaches. You may escalate or move ahead without their approval if they don’t provide timely feedback. The show must go on.

Image by geralt on Pixabay

References

You can’t possibly include all the background and history of a given project in a single document. However, some of it may be necessary in order to understand the context and decisions being made in the design document. Add a section with relevant links to help your readers out. This may include:

Requirements documents
Related design documents
Marketing or user research
Meeting notes
and more.

Use your discretion in deciding what’s important.

Glossary

Every domain has its own terms, language and acronyms. For anyone who’s been around for a while these terms are transparent, but for newcomers or readers from other groups – they might make your document impossible to read or understand. Therefore, including a glossary is extremely important. On the other hand, it may be long and redundant for readers who are already familiar with all the terms, and this area of the document is expensive real-estate.

An appropriate solution is to add a glossary as an appendix at the bottom of the document and link to it from here. Most of the time you’ll just be copy-pasting the glossary from one document to the next, so it’s not a big effort. If you happen to have your organizational act together and actually have a living, breathing glossary which is kept up to date you could link to that, but having a specific glossary with only the terms included in the document may be easier for the reader to handle. Remember, this is not for you – so do whatever you think is more convenient for the reader.

Non-goals / out of scope:

If there are similar or related issues you’ve decided not to address in this design, specify them here. Comments and questions like “why didn’t you handle X or Y” when you intentionally left them out can be distracting and annoying. Let’s not annoy the reader nor ourselves.

High level architecture

The next section should include a high level overview of the solution. This will normally include a diagram or flow chart with the main components of the design. You don’t have to use UML or precise annotations, no one remembers the rules of those anyway. It should provide the reader with a general understanding of what you want to implement and how the different pieces interact, without going into too much detail.

For example:

Made with excalidraw.com

You may think your diagram is clear, but it is not self explanatory. After the diagram you should include a description of the different components and how they interact.

For (the same) example:

When trigger occurs, the process begins and the result is stored in the database. Alerts are generated and the user is notified. The user may then provide optional feedback, which is also stored in the database. The process health and quality is monitored and saved in the monitoring system. The process results, monitoring and user feedback are combined and displayed in internal dashboards.

Detailed design

The detailed design should explore the details of the components listed above.

If you find yourself adding top level headers that are not listed as a component in the high level architecture you should ask yourself if this is part of another component in which case it should be moved under that component, or if a component is missing from the high level architecture. You should always make sure the reader understands where the details fit in the big picture, otherwise they will get lost.

Details that are appropriate in this section:

APIs
Pseudo code
Class structure
Database schema
Specific technology stacks
And more

Decisions and tradeoffs

This section may include decisions that need to be made – for instance, choosing one technology stack over another, reusing existing components or writing new ones from scratch, some API or data model decisions etc.

Start with an overview of each alternative, but keep it focused. 3-4 paragraphs should be more than enough. If it gets too long, move the discussion to the end of the document as an appendix and include only the main points in this section. The detailed discussion is for you so you can justify your thought process and for nitpicking reviewers. Most readers don’t need to know. I usually put a big “STOP READING HERE” before that part or: “Unbaked thoughts, proceed with caution”.

After you’re done with the overview of the different options, summarize the pros/cons and tradeoffs in a table. Help your readers by deciding which option you prefer, but be open to changing your mind. If you didn’t want feedback you shouldn’t have asked in the first place.

Option #1

Overview of this option

Option #2

Overview of this option

Option #3

Overview of this option

Summary

	Option #1	Option #2 💜	Option #3
Criterion #1	⛔ reason	🚧 reason	🚧 reason
Criterion #2	❗ reason	✅ reason	❗ reason
Criterion #3	✅ reason	🚧 reason	❗ reason
	Unacceptable risk	Best match for criteria	Not best at any criteria

Each row contains a specific criteria and how that option measures up.

The final row of the table will include a summary of the tradeoffs for each option to enable the reviewers to make an informed decision. Remember, there is no guarantee for a right answer, there is only choosing between alternatives based on what you feel is most important. If the project is on a tight deadline – you may decide to choose an option based on what is fastest to develop, even if it’s not the best option based on other criteria. Perhaps you’ve promised your customers excellent performance and reliability and can’t compromise on quality. Highlight these considerations when you summarize each option.

I 💖 emoji

As you can see, I’ve filled the table with emoji. You don’t have to use them, but it gives a visual indicator which option is best and by which criteria. I specifically used different icons and didn’t rely on colors after being told red / orange / yellow / green circles were not helpful for color-blind folk. Learn from my mistakes and be inclusive from the get-go.

It’s best to include a legend below the table what each emoji means. At first you might want to include a detailed explanation:

⛔ blocker – can’t choose this option under any circumstance.

❗ serious issue – can choose this option but it has serious disadvantages compared to the other options or in general.

🚧 mild issue – can choose this option and has some acceptable disadvantages

✅ OK – no serious downside or the best option.

💜 Recommended option

But as people get used to the idea you might be able to limit it to a one-liner:

⛔ blocker | ❗ serious issue | 🚧 mild issue | ✅ OK | 💜 Recommended

Decision fatigue

It’s easy to leave all the decisions open for feedback and discussion, but to be honest – most issues are pretty straight forward. For these, write down your reasons for choosing whatever you think is best and keep the detailed discussion with pros and cons in the unbaked thoughts appendix for anyone who has doubts or questions.

If you keep too many things open two things will happen:

You won’t be able to make any progress on your design until you get everyone’s approval on every small decision.
People have opinions on everything, so you’ll end up wasting a lot of time discussing things that don’t matter much or are obviously the right way to go.

Therefore it’s best to limit the number of decisions you want to get feedback on to a few that are key decisions: those that deeply influence the design or will be difficult to change later (type 1).

Other stuff

Once the design details are covered, there are other concerns that need to be addressed. Some of these will be specific to your product, others are common across the industry. These should be included in your organization’s design document template so you don’t forget about them.

Common subjects included in this section are:

Testing strategy
Documentation
Monitoring and analytics
Performance and scale
Legal & Security
Product lifecycle concerns: e.g. what happens when a user joins/leaves, when a customer is upgraded/downgraded etc.
Release plan: feature gating, A/B testing, migration etc.
And more.

Much of this post is adapted from the design review process at both Dropbox and Google, with a few touches of my own. Thanks to the people who developed these processes and I had the good fortune to learn from. Also thanks to my mother, who at 10 years old made me write specifications for operating telephones as an exercise, and gave me my very first experience at writing tech specs.

Follow the technical road (in high heels)

rinaarts — Tue, 02 Nov 2021 06:53:48 +0000

In recent years we’ve seen an explosion in content about and for women in the workplace, and women in tech specifically. Broadly speaking, there are two types of approaches to this subject:

Play the game: Represented by the esteemed and critiqued book Lean In by Sheryl Sandberg, this type of content focuses on getting women to succeed within the existing framework, hopefully getting them into positions of power where they will be able to help others.

Smash the patriarchy: Represented by the 2020 book The Fix by Michelle King, this type of content focuses on highlighting all the ways the system is broken and has to change for women to succeed.

Smash the patriarchy is often opposed to play the game advice because they feel it’s literally playing into the hands of the existing power structures. While this is true in some ways, I personally think waiting for the revolution to come is not the best course of actions for all individuals, we should probably try to do both, in appropriate contexts.

There is a 3rd genre, represented by books like Brotopia by Emily Chang. This type of content can be summarized as “everything sucks, you’re not imagining it, it’s not your fault”. I’ve stopped reading this kind of book because I already know I’m not imagining it and it’s not my fault (though not everything sucks, at least not all the time), so I feel it doesn’t help me grow, it’s just depressing. This content is important to understand, but not for me, not right now.

Most of the content written about women in the workplace targets women on the management track. I think women trying to make their way up in technical roles face a unique challenge which is not being addressed yet. In this post I will try to share my perspective on some of the obstacles in our way and how to overcome them.

Before we begin:

I will not go into nature-vs-nurture. Let evolutional psychologists and sociologists figure that one out, not my field of expertise. For the sake of this post, the only thing that matters are behaviors and attitudes as they are observed, whatever their root cause is.
Women behave differently on average as a group. I am writing from accepted research and from my own experience. Of course we are all individuals and some of what I’m saying will not apply to everyone, this goes without saying (there, I said it).
I am well aware there are other under represented minorities and intersectional identities in tech with their own problems, some of the content here will be relevant for them too, some won’t be. I don’t presume to speak for them.

Whistling Beyoncé

Starting from an early age, girls get the message they don’t belong in STEM. Even the best intentioned parents can’t control everything their children hear and see – popular culture, teachers, friends… We are constantly exposed to messages and images telling us girls aren’t good at math.

Photo by Teo Zac on Unsplash

In his book Whistling Vivaldi, Claude Steele describes a phenomenon called “stereotype threat” which occurs when there is a negative stereotype associated with a group or social identity we feel we belong to. Our awareness and fear of confirming that stereotype will undermine our efforts, sometimes causing the stereotype to appear true. An example of this is that simply believing that women are expected to do worse on math tests will make women perform worse on math tests. Another group who was told that while some tests have a bias against women, this specific test does not – performed just as well as men. This effect is very strong, and it causes a negative feedback loop that is holding women back.

Story time

When I started out my CS degree I had no idea what I was doing. Other guys there seemed to know their way around a CLI and Linux but my last programming experience was in 3rd grade, telling the turtle in Logo to do something 1M times and waiting for it to finish which was after the class ended. There weren’t many girls around, so I don’t know how much they knew. I was so clueless I assigned variables from right to left instead of left to right. Like this:

public class Point {
   private int _x;
   private int _y;

   public Square(int x, int y) {
       x = _x;
       y = _y;
   }
}

(Our intro to CS class was in Java)

My private members weren’t getting the right values and I had no idea what was going on. So I turned to the guy sitting next to me and asked for his help. He looked at my code and said: “Are you stupid or what?”.

How it works

Obligatory xkcd #385

Let’s look at this interaction: The guy was obviously a jerk. He may have been a jerk to other guys as well, I don’t know, but it doesn’t matter – being the only woman in the room, and aware of “girls aren’t good with computers” meant that as a woman, the comment is taken differently than if I were a man. For a man it’s an unpleasant interaction, but for a woman it’s more than that. It has a broader context. It’s read as another sign she doesn’t belong.

Even without such interactions, which unfortunately do happen from time to time, just being aware of the stereotype can cause women (and other stereotyped minorities, of course) to be afraid to speak up and ask questions. If they are wrong the penalty (real and perceived) will be larger than for other majority groups who don’t have to prove themselves. Instead, they try to figure it out themselves, without getting help and essential feedback. What if, after that interaction I’d tried to figure it out myself – I could spend hours on a simple problem where someone could have just pointed me in the right direction in a minute. You have to remember there was no Google back then, but also that when you are that clueless – you wouldn’t even know which terms to search for or how to read the results.

On top of the time wasted on doing things by yourself, the mental energy spent on fighting the stereotype in your own mind takes its toll as well. Sometimes this leads to getting lower grades, which seems to confirm you don’t really belong and so on.

Don’t believe the stereotype: you belong.

You belong just as much as any dude who tells you they’ve been programming since before they were born. Even if they are good programmers, which is not necessarily true, you can definitely catch up. Don’t sweat it.

Get a support group

One of the easiest and most effective interventions from Steele’s research was to work in a group with other women (this applied to other minorities as well). Seeing that other people have similar struggles helps you feel normal and allows you to feel safe asking for help when you need it. Facing things together, helping each other, celebrating successes together – improves performance further, creating a positive feedback loop.

All’s well that ends well

After Mr. “what are you stupid” finished, I looked at him and said: “I guess you don’t want to help. I’ll ask someone else.”. Which I did. And someone else helped. Just to show you that not everyone in tech is a horrible person. And here we are, almost 20 years later, and I still know how to assign variables.

Do I have to wear a hoodie?

No, you do not have to wear a hoodie. But it can get cold in offices, so you should probably have some kind of jacket handy.

But seriously, when we think “software engineer”, we think classic “hacker”: a young man, wearing a hoodie (or maybe just a black t-shirt if it’s warm), sitting in a dark room in front of green letters running across a dark-mode screen. Sitting alone in a room in front of a computer screen for 9 hours a day wearing a hoodie over your head is not attractive to most women, and not just because of the lack of style. Women, on average, don’t enjoy working in isolation. They tend to choose occupations that include human interaction.

Photo by Sora Shimazaki from Pexels

There’s a lot of talk about women in STEM, but there doesn’t seem to be a shortage of women in biology, and that’s a science. So I think this image is one of the root causes that deter women from a career in specific branches of science – those associated with “lone geniuses”. So – math, physics and computer science specifically, which is what we’re talking about today.

How it really is

Good news! You can, if you really want to, sit in a dark room in front of a computer all day with little-to-no human interaction, but most software engineering jobs are not like that. In fact, one of the most common complaints of software engineers is they have too many meetings. I’m not saying useless meetings are a good thing, but a lack of human interaction is not usually a problem when working in tech.

In your daily work you’ll probably have a quick standup meeting with your team every day or at least a few times a week, you’ll also have a 1:1 with your manager, a sprint planning and retro every so often. But that is not all! On top of regularly scheduled meetings, you’ll have a lot of impromptu communication with product managers, designers, other software engineers etc. This is all required for you to be able to do your job – you will have to communicate with people a lot to understand what you’re supposed to be developing, ask questions, help others etc. The more senior you get the more talking, presenting and collaborating you’ll have to do. And of course, tech jobs are not devoid of casual conversation and office gossip, even if these days it’s just over slack. Fun!

Juniors: Careful, it’s a trap

Women are often good at all this communication and collaboration work (called soft skills, even though they’re hard!), and tend to gravitate towards it. Especially if they have doubts about their software engineering skills. This can cause junior women to focus on and get rewarded for exhibiting soft skills too early, before they’ve established their technical credibility. This will hurt the professional options they have open to them later. So be careful about balancing the different aspects of your work: when you start out your career focus on the tech side of things. Doing diversity work, collaboration stuff etc. is not as important. You can do some of those things if you want, but get consistent feedback from your manager and more senior peers to ensure you are on track for delivering software, which is what you are paid to do and what you will get promoted on at the early stages in your career.

Story time

During my career I was asked several times if I wanted to become an engineering manager. Often, when I expressed some feedback on the direction I thought the product should go, I was asked why I’m not a product manager. I was never asked if I wanted to become an architect, even after showing my strength in software design. In fact, I was deemed to be “not passionate” about technology (you can read more about that here) and discouraged from following that path. If I refused a management position I was deemed to be unambitious instead of just… not interested in management, despite being vocal about my actual ambitions. I felt, everywhere I turned, women were being discouraged from following technical paths, it was like no one, including women themselves, could imagine a woman in a senior technical role.

This hit me hard after seeing several threads where women were asking advice on dealing with pretty normal workplace dilemmas in women-in-tech Facebook groups, and all of them got answers basically telling them they should leave the technical path and become PMs. This response was so common it started to look something like this:

Software engineer who is a woman: I don’t like my manager, what should I do?

Responses: Become a PM.

SWE WIAW: My work is getting boring, what options do I have to change things up?

Responses: Become a PM.

SWE WIAW: I want to learn a new programming language, where can I find good resources?

Responses: Become a PM.

SWE WIAW: Sneezes

Responses: Become a PM!

Don’t sneeze

Why is it so hard to imagine a woman in a senior technical role? I think it starts with preconceptions I mentioned above about what software engineer looks like. If you read about what makes a good senior++ engineer it will probably include excellent technical skills combined with communication, collaborating and mentoring. But when women exhibit those same skills – the technical skills somehow become invisible and they are pushed into engineering management and product management roles.

There is nothing wrong with being an EM or a PM. If that’s what you want to do. However, if you’re being pushed into that role because you have excellent soft skills, but you’d like to have a chance to develop your technical skills and see where that takes you… Then that’s what you should do. I think as more women make this choice, the message that soft skills enhance technical skills and make us better technical leaders may become more obvious. Then it might be easier to imagine women in senior technical roles, and it will become a legitimate and even expected choice.

Being Glue

Most of what I discussed in this section is explained clearly in Tanya Riley’s must-see talk “Being Glue”. Watch it. Re-watch it. Send it to your manager. Make them re-watch it. I hope this gives you what you need to be able to push back on the pressure of anyone trying to push you off the technical path. It’s not easy, but you owe it to yourself.

Photo by Jo Szczepanska on Unsplash

Presumed competence

According to the latest statistics, women are still only 25% of software engineers. When people think “software engineer”, they think “man”. When a woman walks into the room, she’ll be assumed to be someone from HR, or maybe a receptionist or a designer – not a software engineer. And if she’s recognized as a legitimate software engineer, she’ll be assumed to be junior or just incompetent.

By the way, there’s nothing wrong with being HR, or a receptionist or a designer – those are all important roles and should be respected. However, in this context – it means having your professional competence questioned all. the. time.

Story time

I have so many stories about this I don’t even know which one to choose!

Should I share the one where I was having lunch with a candidate (that used to be part of the process before COVID) and he assumed I was from HR. When I corrected him and said I was a software engineer, he asked if this was my first job in the industry. I was 36 or so at the time. I guess I could take that as a compliment I look young but… I don’t think he would have asked a man my age if it was his first job.

Or maybe that time when I came back from maternity leave and my team lead asked the new guy to fill me in. The new guy proceeds to ask “Why should I? What does she know about this?”. The team lead looked at him and said “She wrote this code”.

Oh, I know! Maybe about the time when a technical expert came in to do due diligence on the company where I was leading the development. He walked into the room and asked: “I thought there would be two representatives from R&D here”. My colleague looked confused and said “Yeah, her”. The technical expert continued to talk over my head to my colleague who kept trying to redirect the conversation back at me because he didn’t actually know the answers. It was so ridiculous I wasn’t even mad.

Anyway, the point is: Men walk into a room and are presumed to be competent. Women “don’t look the part” so when they walk into a room they are not presumed to be anything.

May I see some credentials?

The day before I started my CS degree someone I knew called me to talk (back when this was appropriate behavior, somehow) and tried to convince me I didn’t need a degree and I should just start working. I told him that as a woman, I couldn’t just “start working”, I would have to prove my worth constantly everywhere I went, and my degree would help prove I was “the real thing”. I have no idea how I had this intuition at the time. But it was true. I’ve had to metaphorically wave my credentials in people’s faces so many times it’s just, sigh.

Who needs titles?

Women, that’s who. Having a senior title helps you prove competence men are presumed to have. No additional cost.

Some companies pride themselves on not having titles or levels. Everyone here is a software engineer, they say. If you want more responsibility – take it! If you want professional respect – prove you’re worth it! Anyone can call themselves a senior engineer – so it means nothing.

This all seems to make sense on the surface, but the reality is that if you don’t assign titles – people will assign themselves titles. And since, on average, women tend to undervalue and be cautious about how they present themselves – the people assigning themselves senior titles will be predominantly men. Thus contributing to the perception that women are not senior.

If your company gives out titles – make sure you get one that accurately presents your skills. No, not that one. The next level up. If your company does not give out titles but it’s common practice to have an external title (e.g. on LinkedIn) ask someone that you know has your back what they think your title should be, and give yourself that. Or check out how your colleagues are presenting themselves and do the same. You’re worth just as much as they think they are.

Is that always a good thing?

This is not to say a senior title gives you a free pass to make decisions unilaterally without convincing other stake holders your solution is correct. It does, however, give you some authority so not everything you say is second guessed and you don’t have to build your credibility from the absolute bottom up.

The other side of this is when you don’t have a senior title yet and you do have to prove yourself. That’s annoying, but remember – it’s only temporary. First, presumed competence is only when you walk into a room where no one knows you. If they know you and you’re doing well (of course you are!) there’s nothing to presume. Second, if you prove yourself consistently (and loudly in the right places) you will eventually get that title you deserve, and when you do – it will save you time on proving yourself over and over.

Affirmative (re)action

Sometimes people will think all this equality stuff has just gone too far! Equal opportunity is fine and just, of course everyone should be treated the same, but we’ve taken it all the way to equal outcomes! The bar is being lowered for women!

THIS IS NOT TRUE.

No one is lowering the bar for women.

Never in the history of the world would anyone hire a less qualified woman over a more qualified man for the same job with the same pay. This is not a thing that happens.

Photo by Alex Knight on Unsplash

Let’s imagine, just for one second, there is a man with objectively equal qualifications and skills (as if we can really measure such things objectively) and a woman got the job because of “extra bonus points” for diversity. Where is the problem? They have equal skills, why shouldn’t she get the opportunity? Not giving her the opportunity because she’s a woman… that would be the exact mirror image of the same “discrimination”. Only… who knows how many opportunities she didn’t get because she’s a woman? And how many opportunities were open to this man because of presumed competence, bro-culture, or not having the weight of negative stereotypes dragging him down constantly? If this were really a problem we’d see the numbers of women in tech going way up in the recent years, and that hasn’t happened. So let’s not worry about this imaginary scenario too much.

How to respond

Sometimes, someone will find it important to share that you were hired for diversity. First, refer to the previous section to remind yourself why this is not true.

If it’s a colleague – try to recruit allies. Your manager can help (if you trust them), but from my experience, management can shake their finger at people talking like this, but as long as they feel it’s socially acceptable – they will shake management feedback off and continue to say such things. They’re so cool and edgy saying things everyone knows but is just too afraid to say, management won’t keep them down! If you can get even one senior person, best if it’s a man, to push back when they hear something like that, it will work wonders. You will feel supported and that person will not feel comfortable saying things like that again.

If it’s your manager and you feel they have good intentions – try to explain to them why saying things like that is hurtful and wrong (or ignore it, if you think it’s not worth the confrontation). If you think their intention is to put you down or they’re not listening to what you say – try to get out of there as soon as you can. Staying under a manager like that will mean a constant uphill battle. You’ll have to do your work while proving you’re good even though you’re “just” a diversity hire… It’s quite likely to have a damaging effect on your career and your self esteem.

If you’re a manager or a colleague thinking of saying something like this – don’t. Ever ever ever. Even if your intentions are good. Especially if your intentions are bad (WTH!). There is no possible positive outcome from saying something like that. Your “diversity hire” probably already feeling insecure just by being one of the few women around, adding this bit of information is just going to make her feel stressed, probably hurt her performance, and maybe make her question if she should stay at all. If she feels confident in her skills – she’ll think you’re an idiot, and that’s not good for your relationship. Just don’t.

I stopped wearing high heels a few years ago, after I was convinced they’re bad for me. But I still wear dresses and I’m doing fine professionally. Just saying.

Going places: How to manage your career

rinaarts — Mon, 25 Oct 2021 12:20:17 +0000

After my last post on how I got my career back on track I was flooded with (at least 3) requests to share my advice on what I did to “level up” my work so other people could get ahead the same way.

The easy answer here would be “I can’t say”. Each person, each manager, each organization, each situation is unique and who am I anyway to be giving advice on things I’m still figuring out myself. That said, my “obvious” might be someone else’s “mind blown”, so here goes.

Growth Dimensions

The first thing you have to figure out is where you want to go, or what counts as progress for you. This isn’t a life-goals-what-do-you-want-to-be-when-you-grow-up kind of question, it’s smaller in scope. More like what do I wish I could be doing right now or what do I want to be able to achieve in the next year or two.

My first instinct is to go new-age on you and tell you to spend some time reflecting on what you like and dislike about your work or thinking about someone we aspire to be like. However, most of us don’t have the appropriate context to understand if what we like/dislike is actually important for our growth and wellbeing, nor do we know what that person we admire really does and if we’d like doing it. So let’s not waste time on ineffective low-context self-reflection.

Instead, let’s look at some options for growth and try them on for size. Exploring most of these options will have little to no effect on your career. Even if you choose one of the more extreme options (like switching professions) as long as the experiment is limited in time, the long term effect on your career will probably be minor.

Climb the stack

If you are a frontend developer – learn some backend technology. If you are a backend developer – do some frontend. If you’re a product engineer, perhaps you think your stack is full – you can still try some platform or infrastructure work. Platform engineer? Try some product work.

This will expand your skill set and give you a wider view of the different groups, their culture, work style, constraints etc. Whether you like your new area or decide to go back to where you were before – you will have gained a unique and important perspective.

Photo by Sean Stratton on Unsplash

Switch stacks

This could be a minor move like switching from react to angular or .NET to node.js. It could be a major move to an entirely different stack like web to mobile or almost (but not quite!) an entirely different profession like switching to DevOps or machine learning. The more major the switch – the harder this type of change will be.

If you’re switching from angular to react, most of your existing know-how will still be applicable. This might shake up things a bit, give you that sense of freshness that comes with learning something new – but in most cases it’s not an upwards career step, unless! Unless you’re trying to become a generalist-expert in your field who can easily switch between stacks. Good for you if you enjoy programming languages and tech stacks for their own sake (not me).

If you’re trying a major change like getting into ML or DevOps you’ll have a lot of catching up to do. A lot. It’s not impossible, but you should take into account a period when you’ll have to learn a lot of new things you may not have been trained to do before. Going back to being a newbie is not always easy emotionally, but if you think you’ll enjoy it it could be the start of a beautiful new career path. You can always go back if you change your mind! The cost? Maybe a short while doing something that doesn’t directly lead to a promotion. The benefits? Knowing and understanding first hand what other teams do might give you new ideas on how to do your own job better, and most certainly makes you collaborate better.

I know some companies already do this, but I think everyone would be wise to have loaner programs in place where software engineers switch teams for a short time to gain insight on different ways of doing things and perspective on other parts of the engineering org, perhaps even extending to customer service and other business-y functions. The experience will make them better engineers, not to mention the gain from building personal relationships across the org.

Become an expert

Another way to grow is to dig deep and become an expert in an area that interests you. Read the documentation, follow relevant releases and blogs, try to get assigned tasks in that area or initiate your own projects.

Writing is always a good idea, but for this career path writing about what you learn is especially useful. It can be internally in whatever tool your org uses for group communication or externally in your own blog. Writing has two advantages for you:

It forces you to become an expert. You can gloss over points you don’t quite understand, but most people will realize as they’re writing that there’s a point they don’t quite understand and go figure it out. Be that type of person.
It positions you as an expert. If you write about it – you must know what you’re talking about, so you’re the person to talk to if there’s a problem in that area! More questions, more digging deep, more expertise. Virtuous cycle.

If you want to go down the expert path, make sure it’s something you like doing a lot – imagine becoming the go-to person on something you hate. I do not recommend.

Consider if there already is an expert on the subject in the organization. If there is – is the organization big enough to have more than one expert on this subject? If you feel there’s room – join forces with that expert, you can learn from them, and eventually they may also learn from you. If you feel there’s only room for one expert and you’re not that person – maybe you should try to become an expert in a different area. Don’t turn it into a turf war, that’s not good for anyone (not to mention it’s likely that the current expert will win).

Moving on up

The obvious road “up” is to become a manager. However, in many engineering organizations nowadays. there is also a path to become a senior IC (Individual Contributor, i.e. someone who “just” works without being a manager). The senior IC path deserves a post of its own, there’s so much to discuss, but for the scope of this post I’ll stick to the basics.

When you’re fresh out of college (or bootcamp) you’re expected to know the basics of programming, but not much else. As you gain more experience you’re expected to be able to handle increasingly complex projects increasingly independently. Eventually you might be expected to define technical strategy, lead and provide technical guidance to others. This is the essence of the senior IC path.

If your company has set career ladder expectations – great. Use that as a reference. If not, look up other company’s career ladders. Having worked there, I’m most familiar with Dropbox’s but I’m sure there are other ones out there.

Look up the level you think you’re at and go over the expectations. Check how many of the sections you match: The one’s you’re already doing well are strengths to build on. The one’s you don’t feel you do well are your areas for growth. If you feel you cover almost all the expectations of that level – look at the next level up and repeat the process. That will be your outline for growth.

Photo by Markus Spiske on Unsplash

Moving on out

Sometimes switching to a new company can be exactly what you need: Moving from a 1000+ organization to a small startup or from a mid-size company to a “big tech” company can be an amazing opportunity for change and growth. Each size and type of company comes with different challenges and requires a different skillset. Startups can be chaotic, while offering a fast learning curve and a lot of scope for responsibility and influence. Larger companies are a good place to learn how to navigate organizational politics (in a good way, hopefully) and execute at scale.

Now to something completely different

I love being a software engineer, therefore I’m not encouraging you to be something else. However, people are different and you may not enjoy it as much as I do. Strange but true. Assuming you want to stay in tech, there are other adjacent professions you can explore. The most obvious is to become a product manager, but product analytics, UX, L&D (learning & development) are all viable options if you feel like changing direction entirely.

Try to find out which other roles exist in your organization, talk to people in those roles and try to figure out if you think you’d like to do them. It’s OK to change direction, just because you’ve been doing a thing for a while doesn’t mean you have to do it for ever. Really.

Tip: Play to your strengths

It’s easy to make the mistake of focusing on everything you don’t know or don’t do well. Those are painfully present when we think of our performance at work. However, when we’re going for growth – that’s not always the right path to take. Improving our weaknesses will only get us to ground level, making good use of our strengths will take us to new heights.

Getting there

So, you’ve done your research and decided what you want to try next. We’ve outlined a rudimentary path on how to get there. However, even if you decided to switch companies – doing it on your own will prove to be difficult. In order to do our best work, we need some kind of feedback and support system in place.

In a perfectly ideal world, you would be able to talk to your manager about what you want to achieve and they would help you find the right opportunities. If such an opportunity doesn’t exist in their team or organization they would even support you in finding a new job elsewhere. But in the less than ideal world we live in, even the best intentioned manager may not be able to provide the perfect opportunity right away. Even so, your manager is probably best positioned to help you.

Help them help you

My ex-manager Jonathan Seroussi told me once (not an exact quote, in a different context), that once you reach a certain level, pointing out what’s wrong is no longer enough. You have to show up with a plan how to fix it. But even more so, you have to be willing to invest time and energy to fix it yourself, otherwise it’s just complaining. Trying to find your next opportunity is similar in some ways – you can’t expect to be passive about it, and the more senior you become, the more active you should be.

So yes, talk to your manager about what you want, but don’t let them take all of the burden. Come up with some initial ideas or a high level plan for what you’d like to do and ask you manager for help achieving it. This will open up a discussion that can point you in the right direction, while showing you as proactive, motivated and worthy of the opportunities you’re asking for.

You should also:

Keep your eyes and ears open for opportunities and ask for them specifically.
Create opportunities for yourself by identifying existing pain points or ideas in your area of growth and suggesting you work on them.
Remind your manager occasionally where you’d like to grow and ask them how you’re doing. A (not so) gentle reminder to look for relevant opportunities can’t hurt and their feedback can help you focus on things to do or stop doing in order to achieve your goals.

Other channels

Photo by Joseph Barrientos on Unsplash

Unfortunately, some managers are stretched to thin and don’t have time or mental energy to look for opportunities. Maybe they don’t have enough organizational pull to get you considered for relevant positions. Maybe you’re so invaluable in the team and role you’re in they don’t want to risk losing you… A million reasons why your manager might not be helping you with your growth goals.

Don’t give up.

If you can get your skip-level manager on board with your goals, they might be able to help you directly or help your direct manager help you, so if you’re diplomatic about it – this can work.

Another good option is to find a mentor. Someone who works in the level or area you’re interested in. It’s best if they work in your organization because they’ll have more accurate context and more power to actually help you, but even someone from outside your company is fine.

A mentor be able to provide valuable feedback and insight how to achieve your goals. If you manage to build a solid relationship with them – they might be able to tell you about opportunities you can try to get or even sponsor you in getting them. You’ll still have to put time and effort in making the mentorship effective, but it’s something you can do while still working on your regular tasks.

Good luck

If you ask me how I got pretty much anywhere, it’s hard to give an exact recipe. Not only is every situation different, things in real life aren’t linear. Some things you worked on because they had to be done end up being a huge growth experience. Projects you were sure would get you to the next level fizzle out and die. I think many people with inspiring careers are at least partially restructuring their narrative in hindsight, making things that were lucky accidents out to be premeditated.

This is not to say hard work is not necessary, it is absolutely necessary. This is also not to say luck is everything. I think that success (whatever that means to you) is a flywheel of lucky opportunities appearing, being able to identify them, and applying skill, drive and hard work to make use of them. This, in turn, will make more opportunities available and your ability to notice and take advantage of them greater.

Get the wheel going.

How I got my career back on track

rinaarts — Thu, 14 Oct 2021 16:43:17 +0000

My career started pretty normally, I guess. I went to a respected university and finished a BSc. in computer science and an MBA with good grades. I was working as a student at a well respected international corporation and was offered a full time job. I was totally set up for success. Somehow, 12 years passed and I found myself in a dead-end job with a feeling that I’d missed out on my potential and I would never make up for lost time.

In this post I’ll share how I recovered from an unknowing attempt to kill my career, and how within a few years became a senior engineer with my eye on higher IC levels (maybe staff engineer in a couple of years? Keep your fingers crossed).

Image by uniquedesign52 on pixabay

Before we continue:

There is nothing wrong with “just” having a job and not a career. Even a mediocre tech job offers higher compensation than you would get elsewhere, and if you’re not particularly ambitious that is absolutely fine. You shouldn’t feel pressured into doing something you don’t want to do. What I do want you to take away from this post is:

Make a conscious choice that is what you want. Don’t do “job” if what you want is a career.
You can change your mind. Just because a “job” works for you now, it doesn’t mean you can’t have a career later.

How it started

After finishing school, my husband and I decided to move to a better location with more employment options, so I looked for a new job. I was young, with no real constraints and excellent credentials and within a month I had 3 offers. I took the highest offer and stayed there for 6 years.

While I was there I had 2 children and reduced my hours to make life easier. When I was ready to leave I was set on getting a job in a convenient location and if possible, part time. That seriously limited my options. I ended up working 80% in a small, local-market company about 5 minutes from home and stayed there for 6 years as well + a 3rd kid.

These are the simple facts. It doesn’t sound so bad – right? I was working, I was happy, I was being a “good mother”, what’s the problem?

Setting (no) direction

Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where–” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

“–so long as I get SOMEWHERE,” Alice added as an explanation.

“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

Perhaps one of the most quoted passage ever from Alice’s Adventures in Wonderland, I apologize for being so cliche.

Let’s start by looking at that second job right after university – it wasn’t bad, but I hadn’t made the choice to work there by considering how it would help my career. I didn’t really think of much of anything before looking for a job, I just sent my CV out using a placement service and took whatever they offered. The money was OK. The people were nice and professional. I learned a lot there. But I wasn’t progressing anywhere.

Now I had two problems

The first problem was that I did have other priorities besides work. I had 2 kids and… I was doing crafts. This was a bit more than just a hobby, I had a blog and in a way, I’d subconsciously bought in to the idea that tech wasn’t for women in general and for mothers in particular. Men plan for getting “old” in the tech industry by investing in real-estate, I was planning to transition into the crafts space – do workshops and sell crochet instructions online. OMG WHAT WAS I THINKING (probably this).

The second problem was that I knew I didn’t want to be a manager. When one of the team leads left (or was promoted? I don’t remember), they asked me if I wanted to be a manager and I said no. I wanted to be a software architect (this was before IC professional paths were common, senior IC wasn’t really a “thing”). When they did find a manager for my team, we discussed what I wanted to do and I remember they asked me why I wanted to be an architect, I was obviously not “passionate” about technology. I don’t know if they decided that path wasn’t right for me or just didn’t really care – but the facts were that they did not invite me to the right meetings (even though I told every relevant person they should invite me).

I’m a pretty confident person, sometimes stupidly confident (as you’ll see later), but this conversation about passion for technology really hit me. It is very true I don’t have a passion for “technology”. I couldn’t care less about the latest feature in .NET core or Java whatever version they’re up to now, and I’m bored to death by articles about the latest trendy framework. I will study a technology when I need it, but I’m not “passionate” about it.

Some exceptions apply: pattern matching in python is pretty cool or way back when they introduced null propagation in C#.

I am, however, passionate about creating good software designs and practices that will be flexible and understandable for future generations. Since then I’ve discovered things like Domain Driven Design (I feel was written for me ❤️) and other more abstract and non-technology specific software design principles beyond the design patterns I learned about in university. It’s a thing.

I don’t think they were gatekeeping – they probably thought they were being honest with me for my own good. But I was right and they were wrong and it set me back because I didn’t believe I could advance in the IC path without getting excited about… things I wasn’t excited about. I gave up, and again – it wasn’t a conscious decision, it’s just happened.

Aside: Why I didn’t want to be a manager

In truth, I wasn’t interested in being a babysitter. Today, I don’t think managing is babysitting exactly, but I didn’t, and still don’t, want that element of the job. Even today, as a senior engineer who’s very inclined to and very much enjoys mentoring – I’m glad that some stuff is out of my scope. Let them fight about the air conditioning without me.

I may find myself managing sometime in the future, and I think I’d be good at it. For now, I’m glad that I have the option to continue on the IC path which I’m more passionate about. There’s that word again.

Thank you, next

The next job I took was based on convenience – I wanted a place that would be relatively close to home and would enable me to pick up my kids. You have to remember this was quite a while ago, not many employers were open to the idea of flexible hours. I remember speaking with a recruiter from Microsoft (!) and telling them I would have to leave at 4PM to pick up my kids, and they wouldn’t even consider it. Today it would be a non-issue (at a place like that) you wouldn’t even have to ask.

I remember another employer telling me it would be fine for me to leave at 4PM, but my salary expectations were a bit high (they were not, I was deliberately setting them low because I wanted flexibility). Also I was expected to stay after 4PM if there was work to be done. Umm, what? They were surprised when I declined to continue the process. Fun times.

Finally I found the perfect situation. They were looking for a .NET expert, I was looking for a convenient place to work, the stars aligned in the sky and everything was great. I worked directly with the CEOs to define the product and implemented complex data migrations and delicate business logic (including the accounting system change I talked about here). After 4 years there the business was sold to a European media giant – I had a hand in that.

If this had been a startup my title would have been CTO and I would have made a lot of money off of the sale. As it was, I got a nice bonus equal to what I would probably get every year at a big tech company and some appreciation. I don’t blame anyone, it wasn’t a startup and it is what it is, I (thought I) knew what I’d signed up for.

Winds of change

While I worked for that company I had a 3rd kid and taking a 9 months maternity leave. During that time two important things happened:

The first was trying to create a startup. I hadn’t really given up on the crafts stuff, but I had realized it was stupid to take all my education and experience and switch to doing something that wouldn’t be very profitable. However, I did have an idea for an app in the crafts space that would be really cool and I thought might have a good market.

In between feeding all these kids I found time to write a business plan and realized that I could do this thing, but it wasn’t a high growth startup, it was a nice business. I would end up working really hard and earning as much as I would earn at a FAANG company without working so hard and with less chance of absolute failure. I gave up on that.

Which lead me to the second thing: I was doing my taxes and realized I wasn’t making enough money. I know, money doesn’t define your worth as a person – but it does indicate your worth in the job market. I was clearly being underpaid. The comment all my teachers added to my report cards had become true: I was wasting my potential.

9 months at home is a long time and I had a lot of time to think about what I wanted from life, and I knew it wasn’t feeding kids and driving them places. I mean, I would do that too, but I didn’t want it to be the most important and deciding factor in my life. I changed my mind, I wanted a career.

Into the lion’s den

We have a saying in Hebrew: “It’s better to be lions’ tail than the foxes’ head” and that’s what I felt – I’d been the foxes’ head for too long and it was time to go somewhere I could learn from other people who were smarter and more experienced than me and maybe… pay me what I thought I was worth.

Image by ArtTower on pixabay

Stupidly confident

I decided to go for a job in a FAANG company (or, actually, FAMGA as we don’t have a Netflix branch in these parts). I was told to try interviewing for other companies first, but I did the whole “cracking the coding interview” thing and thought I was well prepared. Ah, if I knew then what I know now.

I failed miserably.

My first mistake was starting at Google. My very first coding interview was at Google. WHAT WAS I THINKING. I didn’t even pass the screening interview. It was sad, really.

The second place I went was Facebook. The first screen I was so stressed the interviewer didn’t get a good signal, so I was offered a second screen. I passed the second one, but not the rest. They were looking for front-end engineers and instead of insisting on going through the full stack process (which I might have had a chance of passing) I agreed to do the front-end interview loop. My Javascript skills were not good enough. I did not fail so miserably there, but failed nonetheless.

Then there was Microsoft. I won’t go into the details of what happened there, but let’s just say I tried for 2 groups and was not accepted for any of them. By that time I was pretty well prepared, but I was so stressed I kept making stupid mistakes in areas I knew well.

I’d submitted my CV to Google, Facebook and Microsoft through people I knew, but since none of that worked out I started widening my search, and wasn’t getting any callbacks. I didn’t understand what was going on.

Tiers in tech

I’m sure there are parallels in how other tech markets work, but in Israel there are two separate paths for working in tech.

You can work at an international corporation (many of which have branches in Israel, not only in Tel-Aviv) or a startup aiming to conquer a global market. This type of company uses cutting edge processes and technologies and keeps up to date with the latest trends.

The other option is working at a local company, aimed at the local market. This could be the IT department at banks or companies like the one I was working in. These companies don’t usually lead technologically. And even if, by chance, they do apply modern technologies and procedures – no one will believe it or take you seriously.

I had gone from the first tier to the second tier, without realizing at all what that meant. I did excellent work, really. But it didn’t matter because I’d done it in a local, no-name company.

Turns out, that was why no one was getting back to me. Lucky for me, the company I worked for had been sold to that European media giant I told you about. Once I’d legitimately changed the name of my employer, I started getting calls. Amazing. But I still really wanted that multinational corporation.

Last(?) chance

Dropbox having a local branch was not well known in at the time, but it was in my search radius so I sent in my CV. Nothing. Then, somehow a connection through a friend’s relative surfaced, and they referred my CV. Another chance at a top-tier multinational! By then I was getting better at this type of interview, having made all those mistakes at Google and Facebook. I passed the screening interviews (two of them) and was moved on to the on-site interview. Exciting!

In the mean time, I got a chance to try for a 3rd group at Microsoft. And failed. Again.

By this point my mental state was less than amazing. I’d started out over confident in my abilities, and now I felt I would never get out of the mediocre situation I was in. I felt Dropbox was my last chance at what I really wanted and was totally losing it.

Help comes

A few months before any of this happened (but after I decided I wanted a career) I joined a group called Baot, Israel’s largest community of senior software engineers, data scientists and researchers who are women. This is an amazing group of women I’m proud to be part of. One of their many excellent programs is “finding your next job” which offers mock interviews, long term and ad-hoc mentoring.

This is a while ago and I was very stressed at the time so I don’t exactly remember who I talked to, but I was matched with the inspirational Hila Noga. I was sure this was it, it was my last chance, and said so. The gist of what Hila said was: You’ve got this. And if you don’t, there were other options. I’d been so locked in to the multinational corporation idea, that I didn’t really understand I could level-up by switching to another first tier company like a mid-sized startup, and even if I did end up pursuing FAANG – I would be starting from a better place.

That was what I needed to hear and internalize. This wasn’t my last chance. I showed up at Dropbox calm, collected and ready. And I got the offer.

How it went

I’m going to be honest even though this is a bit… uncomfortable for me: I didn’t do very well on the Dropbox interviews. I had no idea what I was doing in the system design interview. Add coming from a no-name company into the mix, and that did not inspire a lot of confidence.

I got the offer, but I was down-leveled (not that I knew what levels were at the time). I took the offer anyway. They made that decision based on the information they had, and I needed to get out of the career hole I’d dug myself into – so I guess it was a win-win. Still, I wasn’t positioned very well when I started.

Corporate life

Things weren’t easy, there were ups and downs. Sometimes I wondered what inspired me to want a “career” in the first place and if maybe that decision was wrong. I cried in the bathroom. It took time to get my bearings in this new environment.

About a year in, suddenly everything seemed to click – someone came over to where I was sitting (remember before COVID, when we could speak to people in person?) and asked me a question about something not directly related to something I was working on. Incredibly, I knew the answer. Click.

Aside: on being a working mom

Juggling work and kids is never easy. In my previous jobs I was working 80% at low pressure positions and it still wasn’t easy.

Dropbox, at the time, allowed for flexible hours and working from home a day a week (after COVID they switched to “virtual first”, in essence – full time working from home), so I could still juggle. However, since I decided I was going to focus more on work – I wanted to get help. Many forces coincided in a way that didn’t actually allow me to get help, and then COVID hit. By now, I’m working from home half the time, my youngest kid is 5 and my older kids can help, so pickup help became a non-issue.

However, just because I never got the chance doesn’t mean I wasn’t right. Get help. Outsource cleaning, cooking, daily pickups. Whatever you feel comfortable with and can afford. No one’s standing at the end of life handing out medals that say “I did it myself”.

Slowly, I built relationships, figured out how to work in an enormous and complex codebase, how to design stuff big and small and make things happen in a multi-team, multi-national settings. I helped improve team processes, I gave valuable code reviews. I wrote blog posts and gave public talks. I worked with amazing people I could learn from and discovered they had things they could learn from me as well.

It’s hard to be sure, but I think I arrived at Dropbox already a senior software engineer, I just had to prove it. I also think my particular talents and skills were well suited to Dropbox. Eventually I got the promotion to senior software engineer I totally deserved. Later I got a tech lead role I really wanted on a project I was very excited about. I’m not saying this to brag, I’m saying this because I’d gone from a head-of-foxes situation to the middle of a lion’s den (in a good way) and I was doing well. If I could do it, there might be hope for anyone! Take that imposter syndrome!

Image by RoyBuri on pixabay

Even after all that, it was hard to shake the feeling that I’d never catch up. I’m almost 40 and there are a lot of younger folks around who were way ahead of me. I didn’t let myself ruminate too much, because really – you can’t live your life comparing yourself to others, it’s not healthy. There will always be people who are better, smarter, with more drive than you. But it still hurt, a little pinch every once in a while.

How it’s going

Then my time to leave Dropbox came and I discovered just how much things had changed for me. I knew what I liked doing and what I saw myself doing in the future. I wanted more technological depth, more platform-y and less product-y work and I looked for something in that space.

I’d been a senior SWE and tech lead for a while and all these companies were taking me so seriously! The interviews weren’t easy, but I knew my way around them and got several excellent offers. They thought my blog posts and talks were impressive. They were considering me for technical leadership roles as if I was a real senior engineer! Which, I guess, I am.

Compare that to my many sad rejections just 4 years ago.

I’m not saying my next role won’t be challenging, because it will – but I feel up to it. It doesn’t matter that I “wasted” over 10 years, I’m here now and I’m ready.

So, there it is. This post is not very advice-y, because a lot of the advice I have to give has been covered by previous posts (How to ruin your career in 8 easy steps, Yet another guide to tech interviews), I just wanted to share my story in hope it makes someone believe that they can get out of a dead-end job if they want to.

Thank you to everyone who helped me along the way, there are too many to mention by name. I appreciate you all.

Yet another guide to tech interviews

rinaarts — Wed, 13 Oct 2021 07:10:46 +0000

This is probably one of the most common types of posts, though sometimes I wonder if you just have to go through it yourself to figure it out. I’m not sure. But in the hope that it helps someone out there – I’m writing up everything I’ve learned about getting ready for tech interviews, I promise these tips are tried and tested and will help you if you read and apply them carefully.

Caveats:

A few of the insights included in this post are most relevant for “big tech” companies, but most will be useful no matter where you apply.
I live and work in Israel, so it’s possible there are some culture-specific details that won’t be applicable to your work situation (e.g. like most of the world, we’ve never heard of thank-you notes). Use discretion when applying 🙂

This post is long, so I suggest bookmarking it and reading it in sections. It covers:

Writing an excellent CV
Coding interviews
System design interviews
Deep dive interviews
Culture fit interviews
Questions you should ask
Resources

Writing an excellent CV

Image by congerdesign on pixabay

There are many guides on how to write an excellent CV, and I won’t go into everything, but the message I want to get across is that a good CV tells a potential employer what you can do for them. You want to make it easy for the recruiter to say “I want this person on my team!” and that’s hard to gather from a laundry list of technologies and projects. Focus on skills you have and what you bring to the table as an employee.

My CV is structured as follows:

Basic personal details

Name, email, phone, LinkedIn profile. That’s all. Your address, other personal information or profile picture can only add bias and don’t really add any relevant signal.

Mission statement

Not everyone agrees with me on this one, but I still like to add a short sentence or paragraph about who you are and what you’re looking for. I currently use my personal brand slogan, but most people don’t have one (go figure).

A short, and I mean short – no more than 2 lines long – “Full stack software engineer with 7 years experience, passionate about revolutionizing buzzwords, looking for a position that will make the world a better place” is a convenient way to help recruiters decide if you’re a good fit for the position before they read your entire history, so make it good.

Ask friends to read it and give you feedback on what vibe they’re getting – I once wrote one of these that made me sound like a lone wolf who can’t work in a team instead of sounding independent and motivated. What a miss.

Employment history

I have more than a few years of job experience so I don’t provide full details on every job I’ve ever had. I list the last two jobs and put the rest under ancient history (yes, that is what I wrote) with a reference to LinkedIn for anyone who really cares about where I worked 15 years ago.

When I describe a specific position, I list the skills I used in that workplace and how I demonstrated them. Remember, I want to focus on “what I can do for you” and not so much “here’s a long list of what the job included”. So, something like (OK, this is a real extract from my CV):

Focus on results and customer impact:

I excelled at discovering the essence of what needs to be done and eliminating non-essential features or requirements and even entire projects in order to deliver value to customers with minimal time & effort from engineering. I have successfully used this approach to navigate product, design, legal requirements and resolve engineering conflicts to arrive at the best solution.

This is the type of thing I’m good at as a senior engineer and I’m looking for an employer who appreciates that type of thing. If your focus is more “technological expert” you might want headers like “Problem solver”.

Got any real numbers to share? Things like improved efficiency, KPIs you’ve improved etc.? Include them. If you didn’t actually measure any of this stuff, please don’t invent numbers, if someone asks how you measured the improvement you won’t end up looking very good.

At the very end I add a bit about the technology stack so I pass the automatic filters, because I’m looking for an employer who’s looking for a technology generalist. If you’re an expert in a specific technology you might want to put an emphasis on that. The point is to craft the message so it tells employers who you are and what type of job you’d be best for (and make it match the job you want).

Bonus points

Don’t forget to add any extra-curricular activities like talks, blog posts, open source contributions, mentoring etc. I do this stuff because I enjoy it and vaguely thought maybe someday it would create some startup co-founding opportunity network, but I was surprised at the effect some of these had on potential employers.

Submit

Reach out to people you know, through online groups and other networks and get them to refer you. A referral can really make a difference, even if your CV is far from perfect. Use those connections to get inside info on the process and ask for advice on how to prepare. Most people will be happy to help, either because they’re nice or because of the prospect of getting a referral bonus (or both).

Do yourself a favor and try uploading your CV to one of the HR systems companies use and check how well it can parse them, there’s nothing more annoying than having to fill in a million details manually because you used some elaborate design they weren’t designed to understand. This is especially important if you submitted your CV through a referral, you don’t want to get on your referrer’s bad side by making them enter a whole lot of details manually.

Coding interviews

Image by Skitterphoto on pixabay

RTFM

Seriously.

Big tech companies like Google, Facebook and Dropbox will send you a lot of information on how to prepare for their interview process. Read it. The recruiter will call you to prep. Listen to what they’re saying and take notes. They want you to pass. The chance you can pass without paying attention and preparing is extremely low. Take advantage of the resources they offer you.

Coding interviews receive a lot of hate, some of it justified. Unfortunately, no one has figured out a way to assess potential candidate skills perfectly, so we use proxies. Every proxy has advantages and disadvantages, but if you want that job – you’re going to have to “play the game”.

Coding interviews below the surface

Pay attention: even if an interview appears similar, it doesn’t mean it’s actually the same. The coding interviews at different companies test different things even if they all start out with a leetcode style prompt. At Dropbox they start out with a simple coding prompt and then expand on that in a way that’s similar to issues you’d actually encounter at work. At Google they emphasize algorithms and run time analysis. At Facebook they start with an easy warm-up exercise and then move on to something a bit more difficult. Each company has their own interview structure and assessment.

What this means is that solving leetcode (or interviewbit or “cracking the coding interview”) challenges is not enough. You can (and should) practice this type of question, but that doesn’t mean you know how to articulate your thoughts, analyze runtime correctly, or solve more complex problems based on the coding exercise, which is absolutely critical.

In fact, I’ve had candidates who say they “already know this one”, because they’ve seen the prompt on one of these sites – but if they can code it (and unfortunately they don’t always succeed), they’re not necessarily prepared for the next parts of the interview.

How to prepare

Don’t panic!

Start by interviewing for jobs you’re not sure you want. Be fair, don’t waste time on a company you’re sure you don’t want to work for under any circumstances, but don’t start with your #1 dream job. Use these interviews to prepare. If you pass and get an offer – great! You might have a change of heart and decide you want to accept, or use it as a counter-offer for another job. If you don’t, you’ve at least gotten some experience interviewing.
Do mock interviews. There are sites that can pair you with a mock interview, community groups, friends… Some companies offer them, take them up on the offer! Those mock interviews are golden because they give you insight into what that company is looking for and exact feedback on how you did.
If you already work at a company that does this type of interview, join the round. Read the interview guides. Getting behind-the-scenes experience on how the process works takes some of the mystery out of the process helps you reduce stress.

During the interview

Remember to ask clarification questions and share your thought process. Another thing to notice is not to make the problem more complicated than it is – don’t jump ahead into premature optimization before you know what you should be optimizing. The interviewer (usually) knows what they’re doing, so listen to what they’re saying. If they’re trying to point you in a different direction please let them – they want to help you succeed and you’re probably coding yourself into a corner without knowing.

My top absolute #1 recommended guide for this part is cracking the coding skills flow chart which takes you through the coding interview step by step, laying out the expectations from each part and how to get through it successfully. The first time I went through these interview loops I memorized the steps, and it helped me feel more in control – when my mind tried to go into stress mode and black out I would say to myself: “OK, you’ve done Listen and Example, next is Brute Force” and I would be able to get my focus back. By now, after being on the interviewer side of things for a while, it’s just second nature.

System design interviews

Image by fudowakira0 on pixabay

I don’t know about you, but this one had me super stressed. System design interviews are one of the main factors considered in leveling, which significantly effects your compensation and role coming into the company.

(Don’t know about levels? Ask your recruiter. Also google it. And check out levels.fyi. It’s important.)

On the one hand, our daily work may already include quite a lot of system design so this should be easy, but on the other hand – most of us are working within existing systems, systems which have already solved most of the basic scale and performance issues so we don’t have to worry about them. The DB is distributed, the servers autoscale, new keys are being magically generated. And that’s the stuff they ask about… So… not as easy as you might presume.

How to prepare

I prepared by reading System Design Interview – An insider’s guide which outlines how to approach system design interviews and a number of basic problems and common practice solutions, as well as common system design interview problems. After that, I followed up with Grokking the system design interview. What I did was look at the problem and write down my thoughts as if I was designing this system. I found scale and performance issues and focused on parts of the system I found interesting. This did not always match the solution they gave, but actually – the solutions didn’t always match the book either! That’s actually expected with this type of interview, there is no “right answer”.

Same advice as the coding interviews applies here – throwaway interviews, mock interviews and join the interview rounds if you can. I used the mock interviews offered by the companies I was interviewing for to practice system design and they gave me invaluable feedback which really helped me improve how I was leading the conversation.

During the interview

The idea in a a system design interview is to work with your interviewer to understand the requirements and constraints of the system and come up with a scalable design that makes sense. There is no correct answer, they want to see how you think. The more senior you are, the more they’ll expect you to lead the conversation.

The weird part was that by the time I got to the actual interviews I knew the common questions so well, I ended up trying to remember what the solution was instead of having working with my interviewer to create a good design. Apparently it worked, but it still felt off, almost as if I was cheating. The only system design interview I felt went really well was Google – where they asked something totally out of the box which really allowed me to think about things I didn’t already know. That was fun and interesting. So if you’re reading this and are in a position to do something about it – I want to ask, for everyone’s good, please stop asking “design Instagram” or “design Twitter” and think of something new.

Deep dive interviews

Image by Carola68 on pixabay

Unfortunately not all companies have one of these, where you’re asked to present something you built or a project you worked on. And I say “unfortunately” because I’m really good at these. And I think they give some good signals on the candidate – how well they understand what they did, how it fits in with other systems, their approach to working with systems they didn’t write themselves etc.

The first rule of deep dive interviews is “no BS”.

The second rule of deep dive interviews is “no BS”.

The third rule of deep dive interviews is “don’t reveal any company secrets” because (1) that’s not OK and (2) you’ve probably signed an NDA so you’d be breaching your contract. It might also send a signal to the interviewer that you’re not trustworthy. Bad idea.

How to prepare

Choose a system you know well and were involved in developing. If you were involved in the design – even better. Decide where the system boundaries are.

If there are subsystems your system interacts with, but you don’t know very well, that’s fine. No one expects you to know everything about everything, show you know the API and understand how the other system integrates in to your system. If you try to deep dive into the details of a system you don’t know well – it will show and the interviewer will notice you don’t know what you’re talking about. Remember the first rule – no BS.

Practice your presentation with a friend. This will help you discover where you get “stuck” and should dig in deeper, where you’re straying out of the boundaries you decided on and into BS territory, which parts of the system are interesting and which parts are dull.

During the interview

Don’t apologize for what you don’t know. You’ve already decided what you plan to talk about and where the system boundaries are. In a company of almost any size it’s impossible to know everything about everything and still have time to get your own work done, so there’s nothing to apologize for. You can use the word “sorry” if you like, as in “I’m sorry, I didn’t develop that part and I’m not sure about all the implementation details”, but you shouldn’t feel sorry or have it throw you off.

If they insist on talking about something you don’t really know, do not BS. You can say you guess it’s built like this or that or suggest how you would do it if you were writing that component.

Still pushing? Arggg so annoying. Switch into a design mindset and work with the interviewer to design such a system.

Culture fit interviews

Image by StockSnap on pixabay

The point of this type of interview is to get to know you and assess how you fit in with the organizational culture. I think it’s important to understand how important this match is. A person can be incredible in some work settings and terrible in others, depending on what the organization values and rewards.

How to prepare

The first and most common mistake with this type of interview is to think you don’t have to prepare because it’s not “hard” the same way technical interviews are hard. But you do, because:

It’s hard to come up with “good”, representative stories during the interview.
It’s even harder to construct a clear narrative on your feet.
The same story can be told in a way that makes you look bitter and passive or empathetic and proactive, it’s all about how you craft your narrative. It will be very hard to get right if you didn’t give it some serious thought ahead of time.

I recommend writing down your stories and thinking about the different situations and which qualities you displayed in each. Read about the company values and try to have at least one story for each value (you can use the same story for different values).

When they ask you about a time when you had to solve a conflict or made a mistake or got some tough feedback – you’ll have a story ready. Sometimes they’ll surprise you with some situation you weren’t prepared for, and you’ll have to quickly adjust one of your stories, but at least you’re not starting from scratch.

Get a friend to listen to your stories. As with other interviews – practice makes perfect. Also, they might see things in the story you don’t see and their feedback will help you refine the message or choose different stories.

Questions you should ask

Image by terimakasih0 on pixabay

Remember, they are not the only ones interviewing you – you should also be interviewing them. Starting a job and then finding out the organization doesn’t meet your expectations – not fun. You need to interview them to make sure, as much as possible, that you want to work there.

How to prepare

Sit down and make a “wish list” for prospective employers. It can be anything from team structure and release schedule to personal development and management style. Think about everything you do and don’t like about your current and past employers and what you’d want at your next job. You can also google for “questions to ask your interviewer” for inspiration.

Once you have that list, you know what you want to find out. Some things you can ask directly (e.g. do you have an L&D budget? What is your performance review cycle like?). Others you have to ask as an open ended question, or you won’t get a real answer. For example, if consistent and honest feedback is super important to me, I can’t ask “do you give consistent and honest feedback?” because the answer will always be “yes”. I need to ask something like “What is your management philosophy?” or “How do you conduct 1:1s?”.

And the life-hack I learned somewhere (I’m sorry! I don’t remember who told me this): Ask every interviewer what they like most about working at that company and what they don’t like very much. I’m very careful about not using strong words, because people won’t want to share what they hate about their employer, but you’ll get honest answers to “don’t like very much”. This question provide a wealth of information, mostly about things you wouldn’t think of asking.

I wish I’d known some (all) of this many years ago, and I hope this helps you in your journey. You can do it! I’ll be sharing how I got my career back on track in a future post, so if you come from a non-traditional background or your career took a “wrong turn” sometime in the past… follow to get an update when that post is up.

Good luck!

Resources

This is a very incomplete list of resources that may be helpful, but there are plenty of other resources out there, choose whatever works for you.

https://thetechresume.com/
https://www.careercup.com/resume
Cracking the coding interview (of course)
Leetcode, interviewbit… any number of these sites.
The material companies send you!
https://www.levels.fyi/
System Design Interview – An insider’s guide
Grokking the system design interview
https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews/
https://techinterviewhandbook.org/