"Dumbest" is probably a harsh way of putting it.
But I knew I was the least experienced and had the smaller skill-set in a team of battle hardened and really skilled Engineers.
I.T. attracts some very smart people and I talk about this in my last post. And sure that doesn't always equal good things. But if you have been fortunate, like me, to end up in a team surrounded by knowledgeable and helpful Engineers (notice I didn't say "friendly"), you learn.
A lot.
Here are some of the key things I learned being the dumbest guy on the team.
Ask Questions.
Nobody likes being the dumb guy. Asking the "obvious" questions. Looking like you don't know your ass from your elbows. But if you've read everything you can, tried to work it out yourself and you still don't know? Ask questions.
Like the saying goes "Ask a question be dumb for 5 minutes, or don't and be dumb forever". Okay, that's not a direct quote, but you get the gist of what I'm saying.
The thing about asking questions when you don't know something (after trying to figure it out yourself) is someone with experience can give you an answer that actually works for you right where you are in the problem.
So ask questions. Be a little less dumb.
Don't turn up with your questions without having done your homework.
And by that I mean, searching for and reading the company's internal documentation. Googling for answers or reading a blog or two. You're demonstrating you're making an effort and aren't there to waste their time.
Now, what you consider "looking everywhere" when you first joined the team might have seemed like an exhaustive search. That is until you see their keyword search game and realize your search game is weak sauce and needs improvement so you're not sitting here watching them find an answer in front of you in 2 seconds that somehow an hour of searching produced nothing for you.
You could be discouraged, but you have to realize it comes down to experience and knowledge. Wisdom even. These guys have actually used this knowledge out here in the field and know what to look for.
Your job is to do the groundwork. Then realize the groundwork is bigger than you expected and adjust your efforts accordingly each time.
And why is doing your homework important?
Because time is valuable.
This goes two ways.
First, the guys I was learning from were on so many simultaneous projects it was crazy. They were doing a couple of big complicated projects along side lots of little fiddly projects and then supporting existing and already BAU projects as well.
Needless to say, they didn't have a lot of time to spare. They don't have time for you being lazy and not doing the groundwork. They don't have time for your bllsht know it all attitude. They don't actually owe you anything and aren't obligated to impart their knowledge to make your life easier.
So if you're going to take up their time, do your best to not waste it. Yes, you're going to ask a lot of "dumb" questions at the start. Yes, you're not going to always get the explanation first time. But if you remember and consider the value of the time they give to show you the ropes and point you to key documents, use it and show your appreciation by doing the work so the next question won't be so painful for them.
Save yourself time
And secondly, if you already get the first point, then this point will make the same sense.
If they can only meet you at 8am, or 430pm, you move your thing. You're the new guy and to be quite frank you're not up to speed yet so you're not offering much value at the moment. So if you've got a 'thing' and your more experienced team members need you to move it. Do it.
Why? Because a half an hour with an expert can unravel a complicated system setup and save you...time.
Do the work. Even if it means after work hours
If you want to be good at this (systems, projects, infrastructure etc), do the work.
There are no shortcuts. Even the guys who seem like they picked this up overnight have put in the hours. Reading, experimenting, discussing it with other Engineers.
Now it helps if you genuinely geek out on this stuff, but the concept remains the same. Hours, days, years need to be invested. If you want to be good at it.
I can be quite competitive. And I also get quite obsessive with solving a problem or understanding a system. So I'll log a lot of hours reading tutorials, reading documentation, setting up and building things in my lab. Just so I know how it works. Or equally, why it doesn't work.
Dont take it personally
Leave your ego at home. Turn up to learn.
If you're told your idea is not a good one, or its flawed and is kind of stupid and not very well thought out - don't take it personally.
No-one in my team had a vested interest in making me feel or look stupid. So remembering that even if my team mates didn't think my idea was that great, they would take some time to explain why it wasn't.
And I would learn a bit more.
Always be the dumbest guy on the team
Surround yourself with people you aspire to be like. If you see an opportunity to be in a position where you can learn from skilled Engineers in a field you want to be in - take it.
Even if you start at the bottom as a little fish in a big pond (not sure this is the best metaphor, but let's go with it).
What are you learning if you're the big fish in a little pond?
Not much.
Putting yourself in a "bottom" position means there's only one way to go.
Up.
And if you've got the right people around you one day you'll catch up (or get really close).
I started my contracting career because one of these people I look up to called me one day and asked if I wanted to take up a contract. He'd already recommended me to the company.
He helped me with the interview, and advised on how to setup to be a contractor. He knew I could do the work because I had done all these things I've just written about. And I had learned from him among others.
I wasn't the dumbest guy on the team anymore.
I was one of them.
...maybe not quite, but a hell of a lot closer than I was before!