I’ve been doing the above as a consultant for a couple of decades. Here’s what I see:
o As others have said it’s a lot. That said it sounds like management trusts uou. More than hiring someone off the street to take the reigns. This means there is room to breathe and room to fail a little bit.
o Talk to all biz units to learn what services they rely on. Thus will not be 1:1 with servers and applications as you see them. But it’s an important starting point.
o Inventory all the systems that you can see/find.
o identify backups, DR and put together a list of your concerns. Document this and share with management. This will give you cover.
o develop your own priority list. Be prepared for management to give you a different set of priorities. You will need to learn skills of push back and compromise.
o learn to reach “good enough” in the short term. If you try to fix everything elegantly and perfectly other problems will wait longer.
Slack is a huge time waster. It is a constant distraction. As as it becomes standardized it’s assumed you will be on it all the tome. Through the workday and even after. The only time can get work done without distractions is after hours.
With slack the world becomes one big long meeting. Lol
Also as a consultant it is a problem. With email I have paper trails of conversations. But with slack when engagement is ending I lose all that discussion & history. It forces me to double up my note taking (more lost time) and try to hack a backup of some of that stuff as an engagement ends.
Yes I get the advantages but those have long since been buried by all it’s problems
Yeah. Ditto. 49 myself. I enjoy coding as much as I did when I was 20. Do I need to be learning everyday? Yep. Same as back then. And I enjoy it just as much :)
Your mileage may vary of course. But i’ve been independent consulting now for 25yrs. Started doing primarily dba/unix work in the 90’s and now of course cloud heavy. Devops is in extremely high demand. i do docker, ecs, terraform, kubernetes, aws, gcp. Python. postgresql, mysql, redshift. athena. it goes on & on.
yes as others have mentioned you have to be willing to learn. to be also excited to learn. that’s key.
i’m also much more mature now. so i can work well with anyone and see perspectives others miss.
I've written quite a bit about this topic (www.iheavy.com)
Yes getting "out of the building" is important, and going out & meeting people is key. All the time. Also don't hard sell people. Instead introduce one person to another person. At first you are simply giving your connections. But soon people see you as a go-to person, and will bring things to you. Also people don't forget gifts of introductions & business you bring.
Another thing. Don't go to "peer" events with other engineers. These events are useful to build your knowledge, but not work building your business. Stronger leads come from business owners, managers & CTOs. Start going to events outside your subject area of expertise. Go to pitch events, vc events, startup events, entrepreneur events.
You will be surprised how valuable you will be in a non-tech business event. This will also teach you to communicate better with non-tech folks. And share what you know. Also ask people, "what events do you recommend?" Then go to those events. And so on!
This is an organizational alignment issue. your application SLOs can be at but not above your dependent components. if that db has 90% uptime than your application cannot be better. add an outage message that makes the cause loud & clear
o As others have said it’s a lot. That said it sounds like management trusts uou. More than hiring someone off the street to take the reigns. This means there is room to breathe and room to fail a little bit.
o Talk to all biz units to learn what services they rely on. Thus will not be 1:1 with servers and applications as you see them. But it’s an important starting point.
o Inventory all the systems that you can see/find.
o identify backups, DR and put together a list of your concerns. Document this and share with management. This will give you cover.
o develop your own priority list. Be prepared for management to give you a different set of priorities. You will need to learn skills of push back and compromise.
o learn to reach “good enough” in the short term. If you try to fix everything elegantly and perfectly other problems will wait longer.