Closed pburkholder closed 4 months ago
One thing that you might want to consider is something that I learned in a personal way recently. I guess the principle in careers would be "it's good know when to leave." Given things like the company trajectory or your career or feedback you are getting, it might be best to leave rather than try to fix things are ride things out.
I'm not sure what the devops equivalent would be. Perhaps something about not falling for a sunk cost fallacy or knowing when to give up on a service or service provider and switch.
Rick Spencer VP of Engineering Bitnami
The only thing I would really add is to know what's going on in the industry (aka don't live in your own current job bubble). If you lose your job and have to figure out other options/what other companies are doing/etc that can be a large ramp up hurdle. Also, I always like to have a 'I would love to do that job too' backup in my head at all times. It doesn't mean you're unhappy with your own job, but hey, there are a lot of cool gigs out there so there's gotta be another that speaks to you. The tldr of mine is kind of be cognizant.
You can just use my twitter pic and it's Jill Jubinski - Manager, Recruiting @ Simple
@rickspencer3 @JillJubs Good points, thanks, and both things that fit. To Rick's point probably as "Architectural Refactoring" when you've outgrown the original design limits of a system.
To Jill's point, I'll probably tune one of my slides to the idea of Lean, and that you should always be considering the product/market fit (where you are the product...).
Thanks much! -Peter
Jill, Tony, Rick:
As I mentioned, I'm giving an Ignite talk at DevOpsDays DC next week, where I thought I'd apply general DevOps principles to the idea of "Disaster Recovery for your Career."
Personally, I like to know that any advice I'm hearing has been validated by other knowledgeable folks and is not just one person's opinion. So I thought it would be useful for my audience to know to that I'm not just making shit up. Hence, the idea of an informal "advisory panel"
Nothing I'm saying in my first 12 slides is particularly controversial, so what I'm asking is: a) correct me if I'm saying something particularly off-key or b) pipe up if I'm missing something obviously useful, especially if it maps to a technical practice.
If you can, please comment on this pull request before EOD Wednesday.
One other thing: Please provide me with the name and title I should use for the advisory panel slide, and a photo link (unless you just want me to fetch whatever I like from Twitter/LinkedIn/Facebook/Google)
Thanks!
-Peter