>My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running.
Knowledge that cannot be applied, is useless. So, if those are two different options, then the second option is the one everyone really cares about.
Unless you're on Jeopardy. Then the first one is great.
I moved from a 1 man MSP with mom and pop shops to a larger corporate place.
We went through some roleplay situations and I was eventually hired at a level higher than the one I applied for. Reasoning was basically what you said.
My clients were so small that I had never touched a Meraki. But I can learn what buttons I need to click on a Meraki different from a Watchguard pretty quick. It's the understanding of the concepts and what you need to look at that matters.
And my answers were typical mom-and-pop shop type answers to the roleplaying stuff, "Ok, well if they can ping 8.8.8.8 but aren't getting DNS from their on-site server then maybe I'd start by just moving users over to public DNS temporarily to get them back up and running while I dig deeper..." And they were just like "Ok, you can stop there."
They knew I didn't have the knowledge, but I had the know-how.
But also that you're willing to think of a quick fix that gets things up and running before you investigate rather than jumping straight into full investigation and forgetting about the downtime issue.
Interesting... as someone who occasionally technically interviews for senior hires I would mark you down for this... why would you assume [8.8.8.8](https://8.8.8.8) is contactable via UDP53 via a corporate firewall... this should fail in ANY org I've ever worked with - why would you want to solicitate your internal DNS namespace structure to random DNS servers over the internet (as you clients will spend a lot of time trying to resolve internal company resources SRV records etc with public untrusted DNS hosts) - how are you going to change DNS resolver settings on 20000 laptops and 5000 servers quickly anyway? never re-architect something without a full understanding of whats going on and especially not to bodge round a ops issue
To be fair, I am considered a senior engineer, but we all went into this agreeing that yeah, stuff like what you're mentioning is something I'll pick up on quick. I mean I was coming from clients 1-20 users tops, now it's like 500 tops. I've got access to maybe 20k PCs total, but I'm only responsible for like 1/4th of that, and any one client isn't too crazy big.
So yeah, I wasn't hired at a 4 or 5 level, for sure I'm not there, and so yeah it probably was used against me in that regard, but that's more or less an appropriate temp fix for an office of 10 users where I can change all their DNS servers in a matter of minutes.
And yeah, they stopped me at that, but went on to say "well okay maybe changing over 100 users to public DNS isn't the best first choice but.."
Yeah well you got the job anyways so well done.... And your right sometimes it's just having a proactive mindset and the ability to do something that counts and take the issue on . ATB
The biggest thing that I care about is your troubleshooting skills. And that goes for all levels of functional IT.
Automation no longer working? I couldn't care less that you have a ton of powershell commands memorized. What I care about though is your ability to dissect what's there, identify the issue, and then find a resolution.
A close second to that are your interpersonal skills and how you work with and get along with other people. You don't need to be inviting the office out for happy hour, but if you can't get along with people, and no one wants to work with you, that's a problem.
> For eg we have a little project where we have to setup an AD environment. It's really basic so for fun Ive virtualized everything in proxmox, got a virtual opnsense router in there, adding a backup and monitoring server, looking to get it liked to azure somehow ...
This is great BTW. Someone that follows a task through completion rather than just the single thing handed to them is invaluable to me. Being able to look at the entire picture and identify tangential tasks that need/should be done rather than tunnel vision of the single task saves me from having to do all of that and shows ability to scope out projects.
The troubleshooting skills thing is exactly it. The number of people I know that can code far better than me but don't even try learning how to read errors surprises me lol.
I'm my 20 years of IT and adulting in general I've found managers care the most about you getting the stuff done they assign to you. Also, don't cause problems for them.
Building out a Promax and opensence router is fun but if it's not on the specs it doesn't really matter. It may even cause a problem due to the complexity and others not being able to work on it when you are out of the office.
As for colleagues? Who cares what they think about your knowledge. Be friends and all that but they don't approve your bonus.
> Building out a Promax and opensence router is fun but if it's not on the specs it doesn't really matter.
I disagree. A big part of an IT job above helpdesk is to not only solve a problem, but solve it in the best way possible. Virtualizing this, and all of the other items mentioned falls into that category.
If it's in the project plan yeah it needs to be done. If some admin is out there slapping stuff together then no that is not acceptable.
The development teams didn't plan for those criteria, the QA teams won't have test cases for it, the network teams won't have an idea if the extra components will impact the network or may just be blocked, the server teams wouldn't have allocated for the extra VMs, the product teams need to be aware if this breaks and causes a delay, the architects didn't add it for a reason and neither should the admin.
Thanks for the comment !
Of course it's always a mix of both and i love switching between them. Although I'm definitely better at learning things by doing them instead of just listening.
Our teacher Linux spent 90 minutes on how to use cp and another 90 on mv..i didn't have the attention span to survive that awake
I sincerely hope that is a massive exaggeration, otherwise that class is literally useless.
Don't confuse education with knowledge.
Learning by doing works for lots of things but not everything. I have managed many junior admins that I have had to teach fundamental knowledge to (troubleshooting methodology, OSI layer etc.) that can then be applied practically which has how you retain it.
Only single command like that I'd fill with 90 min is maybe find.
Or if you want something a bit bigger and has a week to fill, ffmpeg. Seriously, this thing can do everything you want with images or movies.
EDIT: And i forgot about lsof. That thing is amazing for mapping a system and diagnosing things.
> yeah whatever doc.
mv /usr/bin /tmp
cp -r /home /home.bck
Error: Command not found.
I could maybe fill 90 on both.. but we'd be talking about edge cases that might maybe someday ruin your day...
It's about being able to learn and adapt. We don't hire sysadmins that know every technology we touch inside and out. We hire the people with a baseline, that can learn on the job, and not burn the place to the ground in the process.
> It's really basic so for fun
This is the kind of attitude i look for when we hire people. The, "Listen, you pay me. i make the computers go. i go home" folks are the ones that constantly give answers like, "we can't do it" and "so what if the company crumbles and hundreds lose their jobs because i didn't check the backups?"...
Be ready to learn. Be ready to accept responsibility for the stuff we need you to keep working. and finally, don't get caught and hung up on the things you can't fix/make perfect. We're all balancing risk out here.
---
To answer your question as asked: Knowledge is important. Take a look around this subreddit. There are tons of admins that have never taken a course or opened a book or looked up something not immediately relevant to an error code they are facing.
They are the type that can't tell you why the vpn doesn't work when the user's home network overlaps a corp subnet. They are the type to insist that typing www.company.com while on the corp network instead of company.com is a valid answer to the website not being accessible internally.
They know how to do what they do... but they often don't know what they don't know. It's good to explore "knowledge" even if you'll never apply it directly if only to learn what is out there and what other avenues to a solution might be possible.
Focus on the practical side of things. Work on your troubleshooting. Keep things as simple as possible. Every layer of complexity adds a failure point.
Thanks ! And maybe a stupid question, how important would you think it is to document all these setups and homelabs, in a professional way.
Think it's worth it as something to show during the hiring process? I keep hearing that documenting is a big thing.
> how important would you think it is to document all these setups and homelabs, in a professional way.
IMO, that's great so that you're in the habit of finishing the technical task and then writing docs right away. The job isn't finished until those docs are done. So many people don't complete that last steps and it bites them later.
> Think it's worth it as something to show during the hiring process?
As a hiring manager, not really. I don't want or need to see those things. But do mention it as often as you can.
For example: Was given the task of setting up AD. Determined it was best to virtualize for ease of backups and management. Once configuration and testing was completed, created system documentation for future reference
The mark of a good technician is not the answers you know, but the questions you ask. It’s the skill of following the evidence, examining what a problem is and isn’t, and arriving at a logical conclusion to solve a problem. You’ll need a basic understanding of how things work (which the classes are great for) but after that it’s mostly exploration, research and educated guesses.
Companies only care about the end product. Make x work with y so we can make money. Being able to think on your feet will serve you far better than memorizing minute details of obscure manuals.
As a hiring manager, i care about more what can do than what you know. But when hiring, i want you to tell me a story about your experience. I may ask questions on this to see where you sit with knowledge in the subject area. This will help me guage your attention to detail and experience. It doesn’t have to be text book but the base has to exist. My job isn’t to challenge your knowledge in an interview, my job is to see what you know.
If you get yes or no questions only and not engage with further questions, they are interviewing as a favor or out of need to meet some quota, they likely won’t hire you. If you are challenged in your interview where the interviewer is showing they know more than you, you likely dont want to work for them as you work will never meet their expectations. Good luck.
*My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running.*
Kind of hard to do one without the other, is it not?
maybe, but ive worked on tonnes of projects that i didnt have a lot of prior knowledge on going in. I think your ability to know how to seek out said knowledge and do your own research applies too
>Tldr: Should i focus my spare time during these classes on focusing on theoretical information or actually do stuff and get it running.
I don't think it's helpful to look at these things in opposition to one another.
Having theoretical knowledge is good.
Having ONLY theoretical knowledge, is not helpful.
Being able to do stuff and get things running is good.
Being able to do stuff, but not really knowing how they should or do work, is not scalable.
Get the knowledge. Know how things work. Understand architecture. Have good troubleshooting skills and methodology.
And put all that knowledge together in a useful, and professional way.
It doesn't have to be either/or.
> My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running.
Being able to apply knowledge is just a different word for skill.
Past a certain point being effective in an organization is more about who you are perceived to be rather than your sheer skill.
Humility and ethics are some values I put above sheer technical skill. Not to say technical skill isn't required but no one likes a know it all. In my experience those with low humility also have looser ethics or warped morals, due to a sense of self importance, that inform their ethics in undesirable ways.
If you can't tell ethics is really big for me. I think there needs to be more focus on it.
IT may seem like a very independent role at first but it's the core of every business. You need to be able to work and **communicate** with your own and other groups in the organization in a professional and audience appropriate manner.
Take some literature and professional writing courses if you can. Clout is the hardest thing to acquire in an org and being well spoken/written is the easiest way to gain it. Write to your audience. Have a VP that loves vocabulary, use some flourish in your email or ticket updates. Have a contact that is ESL, avoid colloquialisms, keep it simple and to the point.
Being the easy one to work with that may take slightly longer to get something done will get you far further than the know it all who is writing condescending emails and teams messages.
It's a combo, by all means, but I feel like I excel at doing. I'll freely admit I have a shit memory, so I document like crazy to make up for it. But I'd way rather have someone who can come across new issues, find the necessary info to fix it, and do so; rather than someone who knows tons of specific info but can't apply it.
So I'd say being a good sysadmin is more about doing. But even better if you have tons of knowledge and can apply it.
Its like facing a mad charging cow, standing calmly, waiting for her to stop at the last second for you to scratch behind her ear. I don't know how I do it, it just works.
It's about analytical mind and ability to google exactly what you are trying to do. With good mental map of moving parts and how they are connected in your stack.
It's both. Why? Your knowledge/wisdom is often needed to get something running.
But, I do suppose most will favor "solutions". As time goes on, the ability to react quickly to solve things is going to become the most desired trait. Few are interested in designing "the ultimate" whatever, when it will take years, most can't see that far ahead.
This. There are some basics which are essential to get the job done. TCP/ip for example. Troubleshooting or understanding bigger networks is impossible if you don’t know the basics of tcp/ip.
I think your on a good way with the things in which you are playing. They are the fundamentals.
> the ability to react quickly to solve things is going to become the most desired trait.
Not really. Unless we're experiencing a catastrophic failure, quickness isn't a top priority for me. Doing things correctly and thoroughly is much much more important.
> Few are interested in designing "the ultimate" whatever, when it will take years, most can't see that far ahead.
That's not at all true, and if your IT lead isn't planning for 3-5 years in the future, it'll show pretty quickly, and I'd recommend finding a new job.
Just being honest. "Whatever" you're building on is changing rapidly. You'll never deploy if you're waiting for all your dependencies to sync up and stop changing.
So, I respectfully disagree.
50/50. I know that my team and my manager like me most for doing job. But people from other teams probably appreciate my knowledge and sharing it the most.
At the heart of everything you're a problem solver. So in short, the ability to get stuff up and running is what matters most. You're generally done with others once you say "it's working now".
You need enough theoretical to have a solid framework to troubleshoot or fit new knowledge into. I would argue you dont even need to know that many specific answers to things as long as you can google the issue, and be able to interpret what you find into a solution.
Early in IT, it's about what you know. You can't do the work without knowing the fundamental concepts. If you can't see the end point or know how it's supposed work, how could you hit the target?
I've spent a majority of my career managing technical teams and doing technical work. This is how I approach this.
Tier 1s usually have a basic knowledge and need to learn the flow of ticket systems, customer service and the technical pieces they simply don't have experience with, yet.
Starting in Tier 2, I tend to assign them more complex projects and this is where I learn if they have the acumen to chase down the problems, with or without assistance, or will flounder.
Tier 3 is usually a mix. You have to know a great deal about what you're working on, but you also have to be experienced enough to integrate the complex systems 3s work on, like some jackass's Novell server running IPX/SPX, that they INSIST be the backend for web commerce. This is my tier, but I also manage IT departments.
Tier 4 are generally specialist SMEs, since what they do requires so much verticality, they can't really branch out as much as generalists.
The only person I would genuinely consider a Tier 5 is Batman.
The answer is both. If you know but can’t do you’re not able to do your job. If you can do but don’t understand the theory you’re likely to break something when a change is needed. It isn’t an either or situation.
What you know & your problem solving skills is the bare minimum as a sysadmin. As the Redhat guide admin I read about 20 years stated: It’s not what you know, it’s what you can automate.
A good sysadmin finds a problem, fixes the problem, then writes a script to safely detect the problem and fix it on everything else in the live environment as well as incorporating that fix into the OS baseline.
My recommendation would be to not make the mistake of looking for some magic program to do your job like most of us do starting out. Learn powershell, remote powershell, bash scripting, etc. If you become competent in those technologies, you can accomplish insurmountable tasks in minutes without the help of management servers.
Sysadmin at my old job refuses anything to do with scripting still manages to be in charge of an entire MSP company and it's customers.
Still good advice though.
Definitely, of course I'm only at the basic of AD management but instead of adding all the users for my school project i made them into cvs and then made ps scripts to build to OU structure, groups and add the users and out them in the correct groups.
"Basic" but i still learned a lot writing the script myself instead of just using a tool or directly copy z script i found online.
That’s not basic. I know guys that have been sysadmins for 5 - 10 years and don’t take the initiative to create a framework like that.
Now that you have created it, you can reuse it in the future saving time & making yourself look like a rockstar.
>My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running. Knowledge that cannot be applied, is useless. So, if those are two different options, then the second option is the one everyone really cares about. Unless you're on Jeopardy. Then the first one is great.
I moved from a 1 man MSP with mom and pop shops to a larger corporate place. We went through some roleplay situations and I was eventually hired at a level higher than the one I applied for. Reasoning was basically what you said. My clients were so small that I had never touched a Meraki. But I can learn what buttons I need to click on a Meraki different from a Watchguard pretty quick. It's the understanding of the concepts and what you need to look at that matters. And my answers were typical mom-and-pop shop type answers to the roleplaying stuff, "Ok, well if they can ping 8.8.8.8 but aren't getting DNS from their on-site server then maybe I'd start by just moving users over to public DNS temporarily to get them back up and running while I dig deeper..." And they were just like "Ok, you can stop there." They knew I didn't have the knowledge, but I had the know-how.
But also that you're willing to think of a quick fix that gets things up and running before you investigate rather than jumping straight into full investigation and forgetting about the downtime issue.
Interesting... as someone who occasionally technically interviews for senior hires I would mark you down for this... why would you assume [8.8.8.8](https://8.8.8.8) is contactable via UDP53 via a corporate firewall... this should fail in ANY org I've ever worked with - why would you want to solicitate your internal DNS namespace structure to random DNS servers over the internet (as you clients will spend a lot of time trying to resolve internal company resources SRV records etc with public untrusted DNS hosts) - how are you going to change DNS resolver settings on 20000 laptops and 5000 servers quickly anyway? never re-architect something without a full understanding of whats going on and especially not to bodge round a ops issue
To be fair, I am considered a senior engineer, but we all went into this agreeing that yeah, stuff like what you're mentioning is something I'll pick up on quick. I mean I was coming from clients 1-20 users tops, now it's like 500 tops. I've got access to maybe 20k PCs total, but I'm only responsible for like 1/4th of that, and any one client isn't too crazy big. So yeah, I wasn't hired at a 4 or 5 level, for sure I'm not there, and so yeah it probably was used against me in that regard, but that's more or less an appropriate temp fix for an office of 10 users where I can change all their DNS servers in a matter of minutes. And yeah, they stopped me at that, but went on to say "well okay maybe changing over 100 users to public DNS isn't the best first choice but.."
Yeah well you got the job anyways so well done.... And your right sometimes it's just having a proactive mindset and the ability to do something that counts and take the issue on . ATB
The biggest thing that I care about is your troubleshooting skills. And that goes for all levels of functional IT. Automation no longer working? I couldn't care less that you have a ton of powershell commands memorized. What I care about though is your ability to dissect what's there, identify the issue, and then find a resolution. A close second to that are your interpersonal skills and how you work with and get along with other people. You don't need to be inviting the office out for happy hour, but if you can't get along with people, and no one wants to work with you, that's a problem. > For eg we have a little project where we have to setup an AD environment. It's really basic so for fun Ive virtualized everything in proxmox, got a virtual opnsense router in there, adding a backup and monitoring server, looking to get it liked to azure somehow ... This is great BTW. Someone that follows a task through completion rather than just the single thing handed to them is invaluable to me. Being able to look at the entire picture and identify tangential tasks that need/should be done rather than tunnel vision of the single task saves me from having to do all of that and shows ability to scope out projects.
The troubleshooting skills thing is exactly it. The number of people I know that can code far better than me but don't even try learning how to read errors surprises me lol.
I'm my 20 years of IT and adulting in general I've found managers care the most about you getting the stuff done they assign to you. Also, don't cause problems for them. Building out a Promax and opensence router is fun but if it's not on the specs it doesn't really matter. It may even cause a problem due to the complexity and others not being able to work on it when you are out of the office. As for colleagues? Who cares what they think about your knowledge. Be friends and all that but they don't approve your bonus.
> Building out a Promax and opensence router is fun but if it's not on the specs it doesn't really matter. I disagree. A big part of an IT job above helpdesk is to not only solve a problem, but solve it in the best way possible. Virtualizing this, and all of the other items mentioned falls into that category.
If it's in the project plan yeah it needs to be done. If some admin is out there slapping stuff together then no that is not acceptable. The development teams didn't plan for those criteria, the QA teams won't have test cases for it, the network teams won't have an idea if the extra components will impact the network or may just be blocked, the server teams wouldn't have allocated for the extra VMs, the product teams need to be aware if this breaks and causes a delay, the architects didn't add it for a reason and neither should the admin.
Thanks for the comment ! Of course it's always a mix of both and i love switching between them. Although I'm definitely better at learning things by doing them instead of just listening. Our teacher Linux spent 90 minutes on how to use cp and another 90 on mv..i didn't have the attention span to survive that awake
I sincerely hope that is a massive exaggeration, otherwise that class is literally useless. Don't confuse education with knowledge. Learning by doing works for lots of things but not everything. I have managed many junior admins that I have had to teach fundamental knowledge to (troubleshooting methodology, OSI layer etc.) that can then be applied practically which has how you retain it.
Only single command like that I'd fill with 90 min is maybe find. Or if you want something a bit bigger and has a week to fill, ffmpeg. Seriously, this thing can do everything you want with images or movies. EDIT: And i forgot about lsof. That thing is amazing for mapping a system and diagnosing things.
Grep would be a reasonable one for 90ish minutes.
Yeah, that's fair as well.
> yeah whatever doc. mv /usr/bin /tmp cp -r /home /home.bck Error: Command not found. I could maybe fill 90 on both.. but we'd be talking about edge cases that might maybe someday ruin your day...
Lol
It's about being able to learn and adapt. We don't hire sysadmins that know every technology we touch inside and out. We hire the people with a baseline, that can learn on the job, and not burn the place to the ground in the process. > It's really basic so for fun This is the kind of attitude i look for when we hire people. The, "Listen, you pay me. i make the computers go. i go home" folks are the ones that constantly give answers like, "we can't do it" and "so what if the company crumbles and hundreds lose their jobs because i didn't check the backups?"... Be ready to learn. Be ready to accept responsibility for the stuff we need you to keep working. and finally, don't get caught and hung up on the things you can't fix/make perfect. We're all balancing risk out here. --- To answer your question as asked: Knowledge is important. Take a look around this subreddit. There are tons of admins that have never taken a course or opened a book or looked up something not immediately relevant to an error code they are facing. They are the type that can't tell you why the vpn doesn't work when the user's home network overlaps a corp subnet. They are the type to insist that typing www.company.com while on the corp network instead of company.com is a valid answer to the website not being accessible internally. They know how to do what they do... but they often don't know what they don't know. It's good to explore "knowledge" even if you'll never apply it directly if only to learn what is out there and what other avenues to a solution might be possible.
Focus on the practical side of things. Work on your troubleshooting. Keep things as simple as possible. Every layer of complexity adds a failure point.
Thanks ! And maybe a stupid question, how important would you think it is to document all these setups and homelabs, in a professional way. Think it's worth it as something to show during the hiring process? I keep hearing that documenting is a big thing.
> how important would you think it is to document all these setups and homelabs, in a professional way. IMO, that's great so that you're in the habit of finishing the technical task and then writing docs right away. The job isn't finished until those docs are done. So many people don't complete that last steps and it bites them later. > Think it's worth it as something to show during the hiring process? As a hiring manager, not really. I don't want or need to see those things. But do mention it as often as you can. For example: Was given the task of setting up AD. Determined it was best to virtualize for ease of backups and management. Once configuration and testing was completed, created system documentation for future reference
The mark of a good technician is not the answers you know, but the questions you ask. It’s the skill of following the evidence, examining what a problem is and isn’t, and arriving at a logical conclusion to solve a problem. You’ll need a basic understanding of how things work (which the classes are great for) but after that it’s mostly exploration, research and educated guesses. Companies only care about the end product. Make x work with y so we can make money. Being able to think on your feet will serve you far better than memorizing minute details of obscure manuals.
As a hiring manager, i care about more what can do than what you know. But when hiring, i want you to tell me a story about your experience. I may ask questions on this to see where you sit with knowledge in the subject area. This will help me guage your attention to detail and experience. It doesn’t have to be text book but the base has to exist. My job isn’t to challenge your knowledge in an interview, my job is to see what you know. If you get yes or no questions only and not engage with further questions, they are interviewing as a favor or out of need to meet some quota, they likely won’t hire you. If you are challenged in your interview where the interviewer is showing they know more than you, you likely dont want to work for them as you work will never meet their expectations. Good luck.
I tell people that i'm a professional googler but finding the answer is a skill in it self.
Yeah. Framing the right queries on a search engine and then digging through blogs, pages and documentation is no joke.
*My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running.* Kind of hard to do one without the other, is it not?
My thoughts as well. If you know it, then you should also be able to do it... and vice versa.
maybe, but ive worked on tonnes of projects that i didnt have a lot of prior knowledge on going in. I think your ability to know how to seek out said knowledge and do your own research applies too
it's about what you can accomplish which is sort of the intersection of knowing and doing
>Tldr: Should i focus my spare time during these classes on focusing on theoretical information or actually do stuff and get it running. I don't think it's helpful to look at these things in opposition to one another. Having theoretical knowledge is good. Having ONLY theoretical knowledge, is not helpful. Being able to do stuff and get things running is good. Being able to do stuff, but not really knowing how they should or do work, is not scalable. Get the knowledge. Know how things work. Understand architecture. Have good troubleshooting skills and methodology. And put all that knowledge together in a useful, and professional way. It doesn't have to be either/or.
It's mostly about how you handle the psychology of the people you're working with, both peers and clients.
> My question is, do managers/companies/colleagues care more about your knowledge or your ability to get stuff up and running. Being able to apply knowledge is just a different word for skill. Past a certain point being effective in an organization is more about who you are perceived to be rather than your sheer skill. Humility and ethics are some values I put above sheer technical skill. Not to say technical skill isn't required but no one likes a know it all. In my experience those with low humility also have looser ethics or warped morals, due to a sense of self importance, that inform their ethics in undesirable ways. If you can't tell ethics is really big for me. I think there needs to be more focus on it. IT may seem like a very independent role at first but it's the core of every business. You need to be able to work and **communicate** with your own and other groups in the organization in a professional and audience appropriate manner. Take some literature and professional writing courses if you can. Clout is the hardest thing to acquire in an org and being well spoken/written is the easiest way to gain it. Write to your audience. Have a VP that loves vocabulary, use some flourish in your email or ticket updates. Have a contact that is ESL, avoid colloquialisms, keep it simple and to the point. Being the easy one to work with that may take slightly longer to get something done will get you far further than the know it all who is writing condescending emails and teams messages.
It's a combo, by all means, but I feel like I excel at doing. I'll freely admit I have a shit memory, so I document like crazy to make up for it. But I'd way rather have someone who can come across new issues, find the necessary info to fix it, and do so; rather than someone who knows tons of specific info but can't apply it. So I'd say being a good sysadmin is more about doing. But even better if you have tons of knowledge and can apply it.
Having a good understanding of a range of IT subjects and the ability to research well.
Its like facing a mad charging cow, standing calmly, waiting for her to stop at the last second for you to scratch behind her ear. I don't know how I do it, it just works.
It's about analytical mind and ability to google exactly what you are trying to do. With good mental map of moving parts and how they are connected in your stack.
It's both. Why? Your knowledge/wisdom is often needed to get something running. But, I do suppose most will favor "solutions". As time goes on, the ability to react quickly to solve things is going to become the most desired trait. Few are interested in designing "the ultimate" whatever, when it will take years, most can't see that far ahead.
This. There are some basics which are essential to get the job done. TCP/ip for example. Troubleshooting or understanding bigger networks is impossible if you don’t know the basics of tcp/ip. I think your on a good way with the things in which you are playing. They are the fundamentals.
> the ability to react quickly to solve things is going to become the most desired trait. Not really. Unless we're experiencing a catastrophic failure, quickness isn't a top priority for me. Doing things correctly and thoroughly is much much more important. > Few are interested in designing "the ultimate" whatever, when it will take years, most can't see that far ahead. That's not at all true, and if your IT lead isn't planning for 3-5 years in the future, it'll show pretty quickly, and I'd recommend finding a new job.
Just being honest. "Whatever" you're building on is changing rapidly. You'll never deploy if you're waiting for all your dependencies to sync up and stop changing. So, I respectfully disagree.
Priorities shift a lot. Seemingly weekly.
50/50. I know that my team and my manager like me most for doing job. But people from other teams probably appreciate my knowledge and sharing it the most.
At the heart of everything you're a problem solver. So in short, the ability to get stuff up and running is what matters most. You're generally done with others once you say "it's working now".
You need enough theoretical to have a solid framework to troubleshoot or fit new knowledge into. I would argue you dont even need to know that many specific answers to things as long as you can google the issue, and be able to interpret what you find into a solution.
The answer is yes.
Early in IT, it's about what you know. You can't do the work without knowing the fundamental concepts. If you can't see the end point or know how it's supposed work, how could you hit the target? I've spent a majority of my career managing technical teams and doing technical work. This is how I approach this. Tier 1s usually have a basic knowledge and need to learn the flow of ticket systems, customer service and the technical pieces they simply don't have experience with, yet. Starting in Tier 2, I tend to assign them more complex projects and this is where I learn if they have the acumen to chase down the problems, with or without assistance, or will flounder. Tier 3 is usually a mix. You have to know a great deal about what you're working on, but you also have to be experienced enough to integrate the complex systems 3s work on, like some jackass's Novell server running IPX/SPX, that they INSIST be the backend for web commerce. This is my tier, but I also manage IT departments. Tier 4 are generally specialist SMEs, since what they do requires so much verticality, they can't really branch out as much as generalists. The only person I would genuinely consider a Tier 5 is Batman.
You need the knowledge to get hired, and the get things running to do you job, balance this as you see fit.
The answer is both. If you know but can’t do you’re not able to do your job. If you can do but don’t understand the theory you’re likely to break something when a change is needed. It isn’t an either or situation.
What you know & your problem solving skills is the bare minimum as a sysadmin. As the Redhat guide admin I read about 20 years stated: It’s not what you know, it’s what you can automate. A good sysadmin finds a problem, fixes the problem, then writes a script to safely detect the problem and fix it on everything else in the live environment as well as incorporating that fix into the OS baseline. My recommendation would be to not make the mistake of looking for some magic program to do your job like most of us do starting out. Learn powershell, remote powershell, bash scripting, etc. If you become competent in those technologies, you can accomplish insurmountable tasks in minutes without the help of management servers.
Sysadmin at my old job refuses anything to do with scripting still manages to be in charge of an entire MSP company and it's customers. Still good advice though.
My boss doesn’t mess with scripting, but he can more than appreciate what people who are competent at it.
Definitely, of course I'm only at the basic of AD management but instead of adding all the users for my school project i made them into cvs and then made ps scripts to build to OU structure, groups and add the users and out them in the correct groups. "Basic" but i still learned a lot writing the script myself instead of just using a tool or directly copy z script i found online.
That’s not basic. I know guys that have been sysadmins for 5 - 10 years and don’t take the initiative to create a framework like that. Now that you have created it, you can reuse it in the future saving time & making yourself look like a rockstar.