This week Greg talks to Matt Whiteley about his top 5 tips, British TV, and Brexit.
The Tips:
1. If you don’t know how it works, you won’t know how to fix it.
If you’re new to wireless, put a bridge pair up and set it to auto-everything and then put it into production, you’re probably going to be spending a lot of time retrospectively learning about DFS, interference, Fresnel zones and wireless in general. Understanding how it works before you put it into production will save a lot of phonecalls which leads into
2. Bench it and break it. (Then document it and put it in production)
Then you’ll know how to fix it and also which config should go on there from the get-go. Put it in your test bed and break it every which way you can and fix it every time. Then get someone else to break it for you. You’ll know your products and your setup inside out at the end of it. In a rush to get the service up and running … don’t! At least don’t make a habit of it. It’s so much harder to try and put a proper config onto something once it’s in production and you’re trying to keep services running whilst you change the config, I estimate you will waste 4x however long it took you in the first place to put it right. Also I bet you rushed it and didn’t document it up-front and you’re now trying to retrospectively document it which takes longer. And finally because you’ve now put a new config on something probably remote from where you are, you’re not going to have the right labels on the right bits of equipment. It will be a maintenance nightmare.
3. Somebody else fixing it this time isn’t going to help you fix it next time.
Sure if you’re in a bind and your service is down then get some external help, else fix it yourself. You’ll know what to do next time and it’ll help you improve on how you set your service up to avoid it ever happening again.
4. Understand/Replicate/Fix/Confirm
Understand the issue, if a customer is explaining it or a tech is telling you what’s going on, probe them to make sure you get a good understanding of the issue and make sure their language is the same as yours. Rubbish WiFi could mean anything from WiFi connection flapping to poor signal to poor download speeds. Really nail what they’re saying.
Replicate it. If you can’t replicate the problem yourself then you’re going to have no idea when you’ve fixed it. From section 1 “Understand” you might have realized it was poor download speeds, so jump on their PC and replicate that. Ensure you can replicate it and you also get poor download speeds.
Fix it. Now you have a repeatable process from section 2, you can be sure you’ll know when you’ve fixed it.
Confirm it. No point fixing it if you don’t then get back to your client. If they still think it’s broke for the next 24 hours you’ll just get bad feedback even though you did good work . Not just an email confirmation either but a telephone conversation so they can thank you in person!
5. You can fix anything! If it’s still broke then you just don’t have enough information yet to know what the solution is.
When people come to me and tell me they can’t fix something what they normally mean is they haven’t gathered enough data to analyse. They’re normally skilled enough to fix it, they just haven’t enabled the logs yet, gone through them and picked out the line that tells them what’s wrong and often the difference between a good engineer and a great engineer is nothing than some more patience. The best engineers will have an instinct and will know how to get that information the quickest but anyone can be a great engineer just by being methodical and persistent.
Help support us by becoming a patron! <==join our Slack team! Keep contacting us: contactus (at) thebrotherswisp.com or https://facebook.com/thebrotherswisp
Here’s the video:(if you don’t see it, hit refresh)
