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.
Before participating in a career panel at the TechRadar conference in November’22, I sat down with the organizers to talk a bit about my career and of course – the unavoidable subject (even though we tried) – women in tech (Hebrew).
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.
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.
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.
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:
Over the 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.
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.
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).
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:
So… you’re looking for a job and you get a call from a recruiter. The conversation is going well and they’d like to move you into the technical interviews stage. Or maybe, you’ve already completed all the technical part and they want to prepare the job offer. And then they ask the dreaded question: What are your salary expectations? And you freeze. Or, at least – I freeze. I’m no good at this part… I think I know what I’m worth – but what if I have it all wrong? Or what if they can pay more than I expect? Or they can’t afford what I’m asking for and they won’t want to continue with the interview process?
Cousin Izzy
We have a family story about our savvy-salesperson cousin Izzy who (legend has it) used to offer the following sales advice: Imagine you’re selling two birds in a cage. A buyer comes in to your shop and asks “how much?”. You answer: “$50”. If they blink, you sell for that price. If they don’t – you say “for the cage”. They ask: “How much for the birds?”, you answer: “$20”. If they blink – sell for that price. If they don’t – say “each”.
Note: It’s quite possible none of this story is true, but that’s how I heard it and now it’s mine to tell as I please.
First, I do my research. I know how much I make now and how much of an upgrade I expect. I ask friends and use my network, check salary surveys, ask in suitable forums etc. Once I understand what the expected salary range for me should be, I want to maximize how much I can get within that range. That’s where cousin Izzy comes in.
Performance review season is upon us, and with it the dreaded self review. Many of us spend way too much time struggling with this task, how can we summarize our achievements in an appealing yet accurate way? SO MUCH STRESS. In the spirit of keeping the time and effort to a minimum, I’m sharing my tips on writing a stellar self-review, fast.
