Ask HN: “Go-to” employees: what do you go to them for? | Hacker News Reader

Ask HN: “Go-to” employees: what do you go to them for?

6 pointshimantopus6 comments

From a soon-to-be student who is curious by habit:

Which of your specialties or areas of expertise have earned you respect and confidence in the workplace? Conversely, when you’ve had a “go-to” team member, what have you gone to them for?

I’m not looking for job-title specialties—front-end/back-end, for instance—just examples of well-honed skills that are not often so well-honed in the environments you’ve worked in, but are appreciated when they are. These will naturally differ from field to field and office to office; common answers would, for that reason, be of slightly more interest to me.

Answers could be directly related to programming and systems maintenance, but might be more general. Examples may include fluency in assembly language, a stronger-than-usual knack for prototyping or refactoring code, clarity in written communication, or all the hallmarks of a good soundboard.

In case I haven’t made my purpose clear, please note that I am not intending to use answers here as an excuse to over-specialize at the expense of general study. I’m well aware of arguments against this practice, and I am not in a position to agree or disagree with them. If this question has any actionable purpose, it is this: I can ask myself later, for those things that I’m good at or love to do, are they often in demand in the workplace? Should I indulge myself to “master” them? Should I remember them in interviews?

Thank you.

In my experience, it's not technical knowledge that makes me view someone as a "go to" engineer: it's reliability. I don't like surprises from anybody when it comes to work, and I really respect engineers who can deliver thoroughly and on time without surprises in code quality.

Getting something done on time can be tricky, but the hallmark of a "go to" engineer is that, if something's going to slip, they speak early about it. Going down a rabbit hole is a bad thing, but going down a rabbit hole without telling people and checking back to see if you still need to be down there is worse.

Getting something done thoroughly means, to me, that you've written code that is tested and is reasonably robust given the nature of what you're doing. Code that lacks null checks (if you're in a language where that's a concern) is not robust. Code that doesn't handle obvious errors is not robust. Code that doesn't have any tests with it is not robust.

Code quality is a matter of taste, but what it boils down to is how well code follows the established patterns in the codebase or, if those patterns need to be changed, how well the new solution solves problems the old pattern exposed. Most development does not take place in a vacuum, and if someone goes off and does a lot of extraneous refactoring, everyone else has to pay the price of merging their work together and acclimating themselves to whatever's changed. Frequently, large refactors aren't worth that cost, and a "go-to" engineer is going to understand that balance and err on the side of getting things done versus getting things perfect.

It's crazy how simple this is: be able to say "I'll take care of that" and then follow through.

At every workplace in every industry there are people that can be trusted to actually do things out people that can't; be in the first group and you'll always be valued. People who can do this will ask anyone for help, and provide help when asked, will root into problems that are non-trivial, and won't waste time trying to cover their asses.

You get to be the "go-to" person when everyone realizes that once it goes to you, it doesn't need to be worried about again.

Well put.

I would add that this doesn't necessarily mean that you yourself are the one actually completing the task. Part of this is knowing who the right person is for the job and delegating appropriately. The requester (often somebody non-technical who doesn't know who's best-suited for what type of work) usually doesn't care who does the work, as long as it gets done right and on time.

Even if someone comes to you with a task that some might consider "outside of your domain", it's better to try to help solve these problems (e.g. through connecting with the right people or stepping outside of your comfort zone) than to refuse the work because it's not "part of your job". I've often worked with engineers in the latter camp and they do not become go-to's.

I've found that a willingness to take on work, a friendly attitude, both towards superiors and co-workers, and the ability to complete tasks well and on-time (with the help of others) has often resulted in me being a "go-to" engineer.

as a military officer i can tell you that my "go-to" soldiers/sailors/airmen/marines are the men and women who can either understand what i'm saying or smart enough to ask questions when they don't. once they understand the task and the bounds of my authority, they go out and execute to the fullest extent possible, returning only when the task is either finished, or taken as far as they can take it without additional assistance (which is why they're coming back to me).

those who become "go-to" personnel must learn to be confident in their own judgement, and be willing to take calculated risks. as the officer, it is up to me to trust them to execute my vision, and when they make a mistake, know that the blame will be placed on me, and me alone -- since they were following my orders.

i find that failures of execution are as often failures of leadership (mine, most likely). when things go wrong, i often find myself asking subordinates if i have explained myself enough -- and then i circle back with them and try to clear up any misconceptions they had so they can go out and execute my vision.

this tool has proven effective in tech as well. i am developing a product right now, and spent the last 72 hours sitting with our coding team. two days later, they sent me a revised mock-up, and it became clear that they had internalized some, but not all of my guidance. and so i had to go back once again and try to explain in a different way.

an old english teacher of mine once said that good writing was like looking at footprints left in concrete, whereas bad writing was like looking at footprints in the sand. with the former, you can see exactly where the person is coming from, where they went, where they are going. the latter you can only see intermittent prints -- the rest is lost to the aether. hope that helps!

It comes naturally when you're confident (and wear glasses.)

when it absolutely positively has to be there overnight...:-)

Reply on news.ycombinator.com