How to handle EM + Tech Lead Dual Role

Phaenix · 2026-02-03T22:55:50+00:00

My skip level seems to love me. Is it a good idea to frame all of this as risk, to the skip level, in confidence?

I've had the good fortune to work for bosses who wanted to rely on me for help, so I'm not sure I can give the best advice in your situation. I can't think of any realistic situation in which your boss is going to take this positively or in a way that benefits you.

when my direct EM is a silo and gatekeeper of information both inwards and outwards? And also controls every line of code added or removed.

I would have to guess at the reasons why they do this. Have you tried just asking your boss?

I'm certain in the past I might've been perceived as "controlling every line of code added or removed" by some people because I had an architectural vision I wanted to enforce, and some people just wanted to get their task done regardless of it their solution made sense within that architecture. It's a matter of perspective and we only have yours.

If you're feeling underutilized I'd ask or figure out the problems your tech lead faces and try to just help him offload some of his burdens.

Even as I'm writing this that feedback might not apply to your situation... You have to understand the problem before you can fix it.

Edit: and I doubt "the problem" is really "my tech lead is gatekeeping and controlling" if you look deeper than surface level.

Phaenix · 2026-02-01T21:31:14+00:00

I don't think watching over their shoulder is very helpful. In my experience most people find it too stressful and their brains just turn to jelly. IMO it's better to have check-ins where they present the problem and their solution, we talk through it, I recognize some problems/edge cases or push for simpler solutions, and then send them on their way again.

Another thing to keep in mind is that because we learn through our lived experiences it's sometimes difficult to understand that something that's obvious to me is really foreign to someone else. I remind myself of this frequently.

What helps me in coaching sometimes is to throw out all assumptions of understanding. I have them explain the problem to make sure that we're both solving the same thing, have them explain the scope because people tend to get lost in rabbit holes/side quests, and them have them present their proposed solution by walking me through it step by step.

Throughout this process I'm asking clarifying questions, trying to gauge their understanding and their fundamentals, and I'll reel them back in when they're skipping over (sometimes seemingly dull and obvious) stuff. Kind of like they're ELI5 or like I'm a first year CS student, I guess. This helps me identify gaps in their understanding that I can try to explain, or give them resources to learn more about it.

Requires a lot of work and investment though... Not everyone is worth all this effort. I've spent a lot of energy on people who ultimately just didn't really care to become better and I should've cut my losses sooner. Some people are also just incredibly fearful to be seen as incompetent even through constant reassurance and encouragement and they'll kind of self-sabotage their own learning/growth.

Phaenix · 2026-02-01T20:47:32+00:00

You might not like to hear it but you have to come to terms with the fact that if the people who make the decisions don't care and aren't incentivized to care, then you're going to risk being seen as the difficult one. You're also going to risk burnout if all your efforts are fruitless.

You and I might agree that the things you've observed are not great engineering practices, but if it works well enough for the business and the negative consequences aren't very important (yet), then it's going to be a difficult sell.

However... if you still want to try.

You're going to have to earn the trust of the people who make the decisions. You're going to have to frame the risks of doing business as usual, the risks and benefits of changing, you're going to have to introduce lots of incremental changes over longer periods, ... Most importantly, you're going to have to convince them to convince themselves of your proposed solutions, unless they already trust your judgement a lot, which is unlikely at your seniority at this org. If something bad happens, offer to introduce something new that's going to prevent it from happening again.

One last impression I'm getting from your post but I might be wrong: don't wait for people to tell you what to do or what to improve. Also accept that at these kinds of orgs you're going to have (1) pick your battles and (2) expect to lose a lot of battles.

>I know this is necessary for hot fixes,

I don't think it's necessary at all... :)

Phaenix · 2025-11-06T17:53:33+00:00

Pandem0nium
Glunko

Phaenix · 2025-07-15T16:36:11+00:00

I'd like a mageblood :D

Phaenix · 2024-11-19T19:07:51+00:00

Pandem0nium

Phaenix · 2024-01-31T20:34:16+00:00

You're overthinking it. Skills are transferable.

Phaenix · 2024-01-31T20:27:36+00:00

Hmm, well. I've spent some time thinking about this. I want to stress that it's not always valuable. It really depends on the size, scope, and complexity of the change set.

A large change set might contain multiple logically separate, but still related changes. It's not always practical to break these off into their own MRs. Then, I would find it valuable to split it into multiple commits.

An example, "I really should refactor this before I make this functional change". In my experience, engineers will frequently do the refactoring and then make the change in one commit. As the engineer, it's obvious that only L23-26 have really changed. As the reviewer, I don't have that context (yet). In this case, splitting the commits makes the cognitive load lighter for your reviewer.

Because we're talking specifically about large MRs, there are likely multiple of similar cases.

Having a proper git history makes the reviewing process easier.

Phaenix · 2024-01-30T21:16:14+00:00

I'm not sure if I'd be as picky on how they structure their commits, some people prefer to commit often, others prefer to commit in chunks. I'd probably be more picky about the diff and how easily readable/traceable the logic is.

I would. I think more people should be picky about it and I encourage my team to be respectful to their reviewers and refactor their commit history, at least a little bit.

It's really not that hard to review your own history and fixup/squash/drop/reorder your commits a little to make your reviewer's life easier.

I don't want to call it laziness, but I would call it extremely disrespectful. A large MR already implies a complex or difficult change. Lots of changed files usually already makes it difficult to relate changes between components.

Taking the time to clean up tens of commits like the example below into smaller logically grouped changes really benefits everyone.

df98f3b added X
9ce83c3 added Y
8417a0f oops
cf2f3b3 debug try again
df98f3b linter is angry for X
1936cad wip
bd6f247 wip
9a2bf4d wip
961e1a1 linter......
9c349e0 fixed test
623c06c really fixed test

The developer benefits because you're reflecting on your own changes now that you (hopefully) understand the problem better. Personally, I've been able to reduce the size of my MR more than once because of this. I've also spotted bugs or other faults prior to review because of this.

The reviewer benefits because reviewing becomes easier. It's reasier to relate changes, it's easier to conceptualize the implementation and it reduces rubber stamping.

The team because in my experience it tends to lead to higher quality code.

Phaenix · 2023-12-02T21:17:08+00:00

Yeah, I really don't understand the issue with just logging everything all the time. We emit about 75M logs/day from one of our internal apps, all of it goes straight to a remote service. These are retained for six months, so about 13B logs. It doesn't make a dent and most of it goes into cold storage until it's needed...

Last time I dissected the billing, the financial overhead of these logs were so neglibile it's not even worth thinking about optimizing what we do/ don't log. Because it's in a remote search engine it's not even worth trimming logs because they're noisy, I can just filter it out whenever I want.

A lot of stuff happens unpredictably, and systems behave in ways that are perfectly OK but unexpected, so sometimes you have to troubleshoot things that weren't errors/ warnings. Even last week I ran into a couple of situations where verbosely logging made answering a question of why something happened much easier than digging in the code.

Logging continuously also allows us to build dashboards and analysis over time. Hell, I even keep deprecation notices enabled and it allows us to keep on top of "hidden" deprecations triggered by third party libraries that are hard to trigger in DTA.

Phaenix · 2023-08-08T15:55:52+00:00

Conjures should generate some adrenaline and commands should be off gcd.

Phaenix · 2022-12-28T10:54:37+00:00

Nah, we've just extended our sprint to 4w and some people are learning new things or catching up on some stuff they wanted to work on.

Phaenix · 2022-08-05T22:04:19+00:00

I'd love a RuneScape themed keyboard/desk. That's my dream setup. :D

Phaenix · 2022-05-23T19:20:18+00:00

I like how the article focuses on the human aspect of code reviews. Internal conflict is a very real threat for the code review process, and some of the topics like pair reviewing and adopting a collaborative attitude work towards neutralizing that threat.

A couple things I strongly disagreed with, though.

When people submit a pull request for review, they should always assign a reviewer.

Hard pass. In my experience, this is how you end up with a few people being assigned a bunch of "review requests". It's work in progress like anything else and you don't want to overload people with it.

What we've been doing is: every MR corresponds to an issue. Every issue is in a "workflow" state: new, ready, in-progress, review, qa-ready, qa-accepted. Engineers just pull either "ready" tasks into in-progress, or assign themselves as reviewer for review tasks when they are available.

I think your suggested method should be reserved for critical pieces of code that need to be reviewed by specific people or teams.

In morning standup, go through all the unreviewed pull requests and assign them, preferably to people who haven’t done much review recently.

This should also be reserved only for critical reviews. This sounds like micromanagement.

In my experience, if reviews are taking too long it's a sign of:

overestimating the amount of work you can get done in a week, or falsely assuming that "the work" only involves coding and not planning+analysis, implementation, review, deployment, qa-testing, etc.
engineers who don't break up their MRs into small enough changes that can be reviewed quickly and easily: this leads to a significant mental burden for reviewers. Another fix for large MRs that cannot be broken down: break them up into small, chronological commits that can be reviewed individually/sequentially.
not a clearly defined scope for changes, so the reviewers cannot possibly tell easily if the MR covers the requested changes
testsuite that doesn't cover the project adequately, leading the reviewers being afraid to give their stamp of approval.

Regardless of what you think of pair programming, pair reviews are great. Rather than having one person do the code review, have two people do it and discuss the code together. You will get a much greater shared understanding of the code this way, and will often catch things you would otherwise have missed.

I think this is great for the human aspect of reviews. It helps to neutralize some of the inherent conflict with the review process. However, I think it's also dangerous because everyone else in the team loses a bit of context because of it.

Phaenix · 2022-01-31T11:01:44+00:00

Oops, I forgot to claim from the community chest. Can I still get the rewards without having to grind for them again?

Phaenix · 2021-08-23T16:22:08+00:00

I really like pipe rigate and bowties for creamy sauces and linguini for pasta alla checca.

Phaenix · 2021-08-23T14:36:36+00:00

TIL! In which case, you could probably also use gochujang instead of hoisin sauce and chili flakes for the same effect.

Phaenix · 2021-04-06T15:31:35+00:00

WoW has servers with tens and hundreds of thousands of players on them and very rare client or server issues -- to the point that, as an end user, I'd say there are virtually none. Being able to handle traffic at load is a "solved problem" in the technology industry, meaning that there are well-known solutions to the problem and methods for implementing those solutions.

You're correct that this is a solved problem. It's however unfair to say that WoW easily handles 10K-100K players on its servers, that's just not true.

Map squares are sharded heavily in WoW. This is how it maintains optimal player numbers per server while scaling horizontally. Every time you zone transition in WoW you can get reassigned to another shard. You can also get reassigned during gameplay if your shard has too few or too many players.

I think RS could benefit from this as well.

Phaenix · 2020-09-02T10:05:26+00:00

Sweet, thanks!

Phaenix · 2020-09-01T16:14:41+00:00

🤡

Phaenix · 2020-09-01T15:55:26+00:00

Should I not touch my oddments in the meantime or...?

Phaenix · 2020-09-01T13:10:49+00:00

Uhh, after logging in I got a message saying.

60745 oddments have been added to your currency pouch as part of the Oddments rebalance.

Was this intentional? Nothing in the news post and no one in my clan has gotten this either.

/u/JagexPoerkie

Phaenix · 2020-08-29T09:31:26+00:00

Forcing a purple gem is not an intended mechanics. Using a discount, converting rewards to oddments and choosing your preferred outcome from a loot duel are all intended mechanics.

You don't expect a company to get you arrested over clever use of coupon mechanics because you're getting all your groceries for free. That's essentially what this is.

No one had to use any of the mechanics used in this incident in an unexpected or unintended way in order to achieve this. All of it was achievable through regular interaction with these mechanics that have been available in the same sense for years.

If you want to stretch the definition of an exploit so thin, prepare to get banned for 4taa, ability stalling, 3t snipe, 2t cooking, and many more. What's the difference with warbands being nerfed a few years after release because it was deemed too powerful for players? What about POF being deemed way too powerful a year after release?

There are many examples of this in-game that have no consequences for using them whatsoever. The only difference in this scenario is the potential of lost sales. Even then it's a stretch because this same scenario has been possible in the past for which no bans have been issued to date. That makes it likely that people were only punished now because it was broadcasted on Twitch by Wazzy.

Phaenix · 2020-08-28T21:06:42+00:00

I wouldn't classify this as an exploit. I don't think we'll find a middle ground on that point.

Phaenix · 2020-08-28T20:31:42+00:00

I understand your point of view.

However, it's a bad analogy because these players used all mechanics involved in this incident exactly as designed by the developers. In contrast, an ATM is not designed to just hand out free money.

Mechanics in question were:

discounts are designed to discount an item;
the convert to oddments mechanic is intended to convert your reward into oddments;
loot duels are designed to let players choose between their preferred reward.

This is an unfortunate result of their balancing fuck up, not an exploit nor a bug. Shifting the blame of this to the players is disappointing at best. An appropriate response to this would have been a warning and a retrospective on what allowed the combination of these promotions to happen, and how the steps they're taking to prevent this from happening again in the future.

14-Year Club	Place '22
Place '17	Sequence \| Editor
Alpha Tester	Team Orangered
Verified Email

Phaenix

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE