The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.
But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.
Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.
I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!
> I don’t like being the person who talks and talks but doesn’t push code and ship features
It was fun while it lasted, wasn’t it?
Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.
At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.
It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.
1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.
You can limit chit chat very well this way.
You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.
For technical teams, almost every single thing I ship:
1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks
You can usually knock out the non technical team work and pick off 1 from technical team work along the way
Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.
I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle
Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals