You’re working with another org in coming up with a joint architecture for web-based applications. They want to use WebComponents, while you think React is the better way to go. They’re emotional about their choice, and don’t want to budge. How do you hold a rational discussion with these people?
The situation is a common cause of frustration and needless conflict. Now, I’m not saying that these types of issues are easily resolvable, and sometimes you’ll have to involve upper management and let them fight it out. …
One of the key challenges senior ICs and new managers struggle with is effective delegation. For some the idea of delegating something they could perfectly well do themselves just doesn’t make any sense. Others run themselves ragged trying to do everything on their own because they can’t bring themselves to trust their reports.
Or you have the managers who dive-bomb delegate, showing up at your office to drop a task on their report’s head, and disappear into the clouds like a cowardly kamikaze.
They aren’t being assholes. They are just bad at delegation.
One day I had an epiphany: delegation actually can look very different depending on its intention. It’s sort of like climbing a mountain, starting with the easiest/most obvious way of delegating, and getting up into the rarified heights reserved for truly great managers. …
Dealing with Ambiguity is one of the core competencies Microsoft tests for in their interviews. It is the ability to approach complex, ambiguous problems in a systematic manner, and make sustained forward progress without getting lost in tangents.
Today I’d like to drill a little bit into this competency, explaining how it plays out in real-world scenarios, and a couple approaches to succeeding in highly ambiguous situations.
Moreover, I would like to show that ambiguity permeates every aspect of software engineering, and dealing with it effectively is the key component of career success.
In a previous post, The Career Stage Bullseye, I explored the chart on the left as a progression of scope, but another useful way to look at it is as a progression of ambiguity. …
Ever wondered what it’ll take to get you to the next level in your career? I’ve written several posts analyzing different facets of this question (links below), but today I want to talk about a diagram a manager at Microsoft drew for me at our first 1:1. I’ve used this diagram since, and it had never led me astray.
One of the common issues I find early-stage engineers facing is how to position themselves on a team in such a way as to be given work they’d enjoy doing. All too often folks feel stuck, feeling like code monkeys, just executing their manager’s vision.
So what do you do if the tasks your manager hands down to you aren’t interesting? What do you do when every day at work feels like a drag? You watch other engineers be given interesting, fun challenges and think “But what about me?”
If you haven’t already read Douglas Adams’ The Hitchhiker’s Guide to the Galaxy, go read it. Now. …
Today I want to talk about the space familiar to all software engineers (and likely many others outside the field), the Dreaded Impact-Effort edge. I’m talking about the unenviable position many early-career engineers find themselves in, of doing all the work, and getting none of the credit/recognition/rewards. Of feeling under-appreciated, taken for granted, of feeling like your career’s stalled and you don’t know what to do about it. …
As mentioned in the previous post, all work you undertake falls somewhere within the following triangle:
Impact: how valuable your contribution is to the business
Effort: how difficult it was to implement
Visibility: how aware the rest of the organization is of your contribution
Today I want to talk about this triangle a little more, and explain how staying at any of the extreme points of this triangle can be superbly detrimental to your wellbeing and your career.
So, let’s take these one at a time.
As an Engineering Manager, I often have the “How do I get promoted?” conversation with my directs. After repeating the same spiel dozens of times and having had positive feedback from people receiving it, I thought it might be fun to write it up so others might benefit as well.
I can offer you three ways of career development. Which one you choose depends on your personality and how promo-motivated you are. Each is based on my personal experience working at companies such as Microsoft and Adobe, as well as experience managing dozens of individual contributors.
I joined Microsoft at level 60, their next-to-entry-level rank. Given I’d already had 7 years in the industry (working for Silicon Valley startups), I was quite motivated to start finally growing. I lucked out in that I had a terrific manager, Brian (I’ll write up a separate post on what makes a terrific manager later), and was able to have frank discussions with him about my performance. …