
Ask HN: “Go-to” employees: what do you go to them for? - himantopus
From a soon-to-be student who is curious by habit:<p>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?<p>I’m not looking for job-title specialties—front-end&#x2F;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.<p>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.<p>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?<p>Thank you.
======
bartonfink
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.

------
patmcc
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.

~~~
kohanz
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.

------
SocksCanClose
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!

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

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

