Someone recently replied to me with comments by Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS:

“I have a couple of sayings that are pertinent. The first is: ‘Successful people do what unsuccessful people won’t.’ The second is: ‘If you don’t put them [bugs] in, you don’t have to take them out.’ I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none.

“So my advice is be a thinker doer,” Cutler concluded. “Focus on the problem to solve and give it your undivided attention and effort. Produce high-quality work that is secure.”

https://news.microsoft.com/features/the-engineers-engineer-c...

Unfortunately, I do not have this level of talent, but I do what I can.

I was sold this same line since I started my career in software as an intern ~15 years ago. Every year I've become less convinced that fully applying myself is worth it for my career. Any time that I've stepped up to fill a gap when it didn't directly benefit the short-term perception of my manager/skip-level, the effort was undersold or outright ignored.

Edit: ok - I'll admit, I didn't read the whole article at first. I still stand by my point, though - even when I'm simply identifying those gaps and not fixing them, I still don't see engineers being rewarded proportionally for the value they're bringing their employers.

I'd take some of this advice one step further. In the examples of when not to step up to fix a problem, the author states under-resourced teams. If you do step up to help out such teams, not only do you risk burning yourself out... you are also masking the problem. Helping those teams hit their targets sets up a long-term situation where leadership says, "They get their work done, so they must have enough resources."

It does feel off to not help is such situations. It feels like you are letting a team down. But in the long run, showing evidence that the team is under-staffed will force leadership to make a choice: Either increase staffing or decrease scope. Either way, the team is adjusted to have a healthy match between their staffing and their workload, the people have a healthier work environment, and the business has a more predictable and reliable work output from that team. Everyone wins.

I'm not saying to never help a team. I'm saying to look deeply at why the team needs help before jumping in. Maybe they could be fixed with mentoring or process improvements. Maybe their PM needs guidance in a better way to roadmap the work. There are many cases where you can jump in and help. But if the team really is running well, but simply overworked and under-staffed, that needs a different fix.

Being able to parse out the differences of where direct help is a benefit vs. a hindrance is exactly the type of perspective that takes people beyond the "senior" level role.

Some years ago I was one of the first 5 engineers at what became a semi-unicorn, in 5 years we spent close to 1bn before a sale to tencent.

In the first 12 months I built a dozen microservices, each which eventually had a team supporting them. As the team grew I and one other guy were the 'glue' that kept much of the platform working, we knew how things went together, and by the time the Eng team hit 200+ staff we were indispensable.

After year 2 however, as several of our peers from the beginning moved into team management roles (something I prefer not to do), we noticed we were 'too important' to promote, or to allow to move, or to take off 2nd lvl on-call (at all).

What started with us being the architects of the system turned into us being the 'glue' that kept a massive multi-country eng team operating, which eventually turned into being boxed into a shitty support role rather than promoted, watching people vastly less qualified get moved ahead of us.

Eventually I just quit and moved into a tech lead role at a startup for something different. I feel like this is a trap for IC roles, don't be so helpful as glue that you 'set' into an indispensable position.

I just started a new gig and I'm working on a critical glue stuff that was nobody's job so I can totally relate to this article. Don't stop at the title which is voluntarily provocative.

So far identifying coworkers ownership, planning and validating glue to make things work took most of my time but everyone appreciate that. Some veterans are astonished and say things like "wait so you get Mr Grumpy to do that?" or "How on earth could you get a validation from Mr Nitpicker with a single meeting?"...

Well acknowledging that "it's not my job" to do what is Mr Grumpy and Nitpicker area of expertise is exactly what made things works. They feel recognized and they also understand that the burden is on them if we collectively fuck up so the glue project can move on fast.

I had to have this talk with my partner recently, who works at a small-ish company that hires people competent with data science, but absolutely useless when it comes to architecture, git or even setting up a python development environment.

She does all of those things really well and ended up putting a lot of effort into fighting chaos (spaghetti code, spaghetti git flow, a lot of copy pasted code that doesn't have to be, a complete lack of dependency management, no automation for anything) at that place. I stepped in when I suggested some shared vacation days and she refused because she wouldn't be there to be her team's guard rails. That screams leadership failure to me.

Keeping in mind she barely gets paid better than a junior dev.

I'm in violent agreement with this post.

The biggest issue with making everything your job is that it hides the problems growing in the company. If there's a gap that needs to be filled, if you fill that gap, you're increasing your workload, and the work is being covered, so management may not even know they need to hire to cover it. At some point you'll be doing so much gap work that you'll burn out, leaving all those gaps uncovered.

Obviously you shouldn't be saying "That's not my job", but that's not the point of the post. The point of the post is that you should point that gap out to your management, so they can close it. They may ask you to help cover it, until it's hired for. They may find another team to cover it. They may do nothing, in which case either the work isn't considered high enough priority to cover, or they're not good managers.

Don't be a hero for the sake of being a hero. Be the glue that binds everyone together.

That first paragraph, not a great start when I have to do mental gymnastics just to figure out what the blog post is even about.

If you can't write about a subject directly, use creative license and make the situation up. Nobody knows / is going to find it different and it will help get your point across. I bailed on this article after the first paragraph.

This article seems to be advocating sticking your head in the ground when something goes wrong

There’s a world of a difference between telling others “that’s not my job” for tasks that have nothing to do with you, and owning the success of your own projects

And it feels like this author is conflating the two concepts

If there’s a dependency of yours that’s not working the way you need it to, it doesn’t mean you can simply go home free. At the very least you have to fill in the communication gap of informing management of the blockers.

If need be, then you have to own driving the call to either add more resources to your own project (to compensate for the bad dependency) or push forward the call to nix your project since it apparently has a high chance of failure

And if none of those attempts pan out, _then_ you can try to move on to a different place where you can actually be effective. But know that you’ll face this same type of challenges in your new role as well!

There’s no easy escape: if you took a position of leadership, then it’s definitely your job to lead

I agree the original tweet is wrong. Imo as you become a more senior your role should become more and more tightly focused. Narrowing down into things that are more important for the company. Examples might help here:

As a junior dev you can be expected to fix bugs in the product, work on features, maybe help with testing. Basically anything that the company wants to get you more experience. This is the role discussed in the tweet filling in any small gaps.

As an intermediate dev I would expect you to start working on your own features (with help from a senior+). Only when you're finished these you can tackle anything else like random bugs and suchlike.

Senior dev is more about helping others so you mentor juniors, help intermediate devs with their features and are given the slightly harder features to work on.

Principle devs shouldn't really be mentoring juniors. Certainly you can ask for advice but I would have all my principles working on the hardest parts of the codebase. Anything that requires research or things that the company hasn't done before. Examples of this would be adopting new technology, complex algorithms ...etc. Seniors go to you for advice, not mentoring or step by step by advice on how do I approach X or Y that sorted of thing. You should have a principle working on a low level bug (say a spelling mistake or poor grammar) that's for people further down. There's an element of people management here as well.

Staff roles are mostly hand off and are their to take the strategic approach that comes from the exec team i.e. the CTO / CEO and actually puts them into action. So think working with product coming up with reasonable plans that are actually doable. You'll work with the principles to execute your actions. If it's a big system and a big team part of this will be working out how to split the work amongst the sub teams.

This is what I mean by the responsibilities as you become more senior your responsibilities change from fixing spelling mistakes to help set and execute the roadmap of the product / service.

There is a class of these problems that's easy enough to talk about: "Glue work vs gap filling" is relatively easy topic. Broaching "doer/talker" ratios can be stickier.

Some not-my-jobs are evolved/strategic... they have meta reasons. Redoing the company's google-sheets inventory management horror might be high value, but is status-detrimental work for a senior dev, or assistant PM to do. "Excel dude" is low status. Within excel-dude land, the highest (personal) value work might be indulging executive pedantry over the formatting of dashboards. UI is low status at some shops. Talking to clients and tracing back requirements is thankless work at other shops. Etc. Incentives can be wacky in orgs, after all .

People naturally fill in gaps when they're motivated and work independently. You can see this with hobbyists, personal projects, startups, Community OS, small teams, criminal gangs, children playing and whole lot of other human endeavors.

They row in the same direction when they want to go in that direction, perhaps to reach a destination. In 80% of orgs, 80% of 80% of people's concerns are related to happenings on the boat itself. The vector of the boat isn't their job. They don't care where the boat goes.

You need to analyze the organizational landscape to know what your role as a staff engineer really is.

If your manager has sole discretion on your compensation, then you need to be strongly aligned with her goals in order to succeed. If she sees her goals as solely delivery of her projects, then that's what you should work on.

If you work in an organization (like I do) where your compensation is determined by a group of leaders, then you need to look at what the group wants from you and deliver on that. In my group, a big part of that for staff-level engineers is making sure that the overall organization is successful.

Story for me this year: I noticed another team struggling. Their deliverable is really important to my boss 3 levels up, and I have the background to help them get unblocked and be successful. This team works on something completely disconnected from my manager's goals.

I started working with them, and after a month or two told my manager I was working on it. She agreed that it was a good use of my time, and my involvement didn't interfere with other commitments we'd made. I've probably spent about 3 weeks in total on it. At review time, there was widespread agreement that it was the most important thing I've done for the year.

To close - As a staff engineer, you'll see lots of gaps (if you don't see them, you're not a staff engineer). Most of them should be handed off to others. But some of the gaps are things you're uniquely suited to fill, even if it's not precisely in your area of responsibility. They're "not your job" but exactly the right thing for you to be doing. If your role is too narrowly defined, go negotiate with your manager (or better, your manager's manager) to broaden your role.

This is good advice. Sometimes fixing things requires not fixing them yourself before getting people to agree that it's a problem

Adolescents act out because they quickly realize that the adults in their life give a lot more attention to problems than to things going well. I think this makes sense, and there's a psychological basis for this. I'm not surprised then that it works the same way in the workplace. No one is going to be willing to change things unless they feel the pain associated with not changing it. If someone keeps putting out fires at the expense of their work-life balance or health, then their superiors will simply direct their finite attention at the fires that weren't put out - just as the honor roll student with a dropout sibling probably doesn't get a ton of attention from their parents.

My experience working for a big company is that most things are not your job. It's not that you get to say "it's not my job", it's that you are not allowed to make it your job.

I like working for a smaller company because I can make things my job. In any company there are things that need doing that either aren't being done or are being done suboptimally. Almost every day I spot something and think "I could do that". So I make it my job.

This is a topic close to me, and one I have problems expressing my thoughts about without coming across as cynical. My bottom line is "not my job" is a way to avoid companies taking advantage of you.

I'll give you a real specific example. My wife joined a company as a junior fresh grad. As she grew into the role, started to expand her responsibilities to get to the next level.

The first time she got passed for a promotion she decided to take in even more responsibilities to strengthen her case. She was performing at the next level while getting paid the absolute lowest salary for her role. By the end of her tenure she was literally mentoring a newly hired Senior, and still got passed for a promo for the third time because "she wasn't ready yet".

Stretch assignments are a great way to grow, but there is a clear asymmetry of power here. Companies will easily extract as much value as they can from you and give nothing in return. I think it is perfectly reasonable to set boundaries and say not my job. The difficult part is choosing where that boundary should be.

I often work at small companies. There, you'd better not utter "it's not my job" unless you plan on resigning.

Someone should have told that to Scott Morrison - https://thenewdaily.com.au/news/politics/australian-politics...

If I do stuff that is not my job it will become my job to do that stuff. I'm not sure if I want the additional responsibilities or increased workload, especially when there's no guarantee that it will go hand in hand with pay increase. Why bother?

I honestly thought, this was related to the ex-prime minister of Australia (Scott Morrison).

I'm can't be the only one exhausted from all these pointless bloggers trying to point to how their promotion to hierarchical title N is justified because it's arbitrarily different than N - 1 at their org. Let's just acknowledge these things don't actually map across different organizations and therefore have no meaning. Hierarchical titles are for engineers that hide their mediocrity behind HR appointed titles.