What is Reddit's opinion of
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win?
From 3.5 billion Reddit comments
By popularity on Reddit, this product is:
23 reviews of this product found across Reddit:
Read the book "The Phoenix Project" https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290
It does well at explaining its your job to enable business and not restrict it, while still being a (semi) interesting read via story telling.
The first step is changing your mindset, then others will too.
Remember you’re supposed to know the product side, not do the engineering.
Try reading the Phoenix Project and the Unicorn Project by the same author.
This isn’t exactly dealing with your issue, but I think it would provide some inspiration:
The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win) https://www.amazon.com/dp/1942788290/ref=cm_sw_r_awdo_navT_a_S8BT779Y3SGHQQM5YQQW
This may not be what you’re after, but check out the The Phoenix Project.
It’s more conceptual, but does a great job at explaining how the world is transforming and what your goals should be, from a 10,000 ft view.
Agreed with /u/dcoulson and /u/Szeraax. The vision and strategy is going to depend a LOT on where your specific business is at and what its challenges are - both with IT and just in general.
Generally, IT should be a force multiplier for the business, not a black box cost center, but that's the way almost every CFO looks at it in my experience until you can prove otherwise. What are the current challenges your company has with IT? What problems do you want to solve?
Are there knowledge gaps on the IT team? Maybe you need to look at offering career development or certifications in areas where the team is weak. Or maybe you need to create new roles or restructure existing ones.
Do you have a lot of inefficient processes in your business where tech could help streamline with quicker turnarounds and lower cost? Maybe you need to talk to department leaders and ask the 'magic wand' question (i.e. if you could wave a magic wand and fix one problem for them, what would it be?)
Are there regulatory concerns or compliance issues that haven't been addressed? Risk assessments are boring, but an ounce of prevention is worth a pound of cure and can also help you cover your ass.
Does your CFO think IT costs are too high? Maybe they need to see where that spend is going and what they're getting for their money. Highlighting specific areas (support, applications, infrastructure, management) is a good way of illustrating trends and identifying inefficiencies.
If you have a little time on your hands, I'd recommend reading The Phoenix Project. And feel free to reply here or PM me if you want to ask anything specific. I've been a DIT in SMBs for a while and have worked for several CFOs that started off not appreciating IT only to later see the light!
Less of a technical learning point but I would also recommend reading / listening to “The Phoenix Project” .
It’s a fiction book but is a great lesson in the principles and value mindset of devops.
I would be very cautious before you start this. You need to have a much better understanding of why you’re doing this before you start. I think breaking up ops teams may be an answer to a different question. That question should be: “how do I deliver better business value?”
The first step is to understand what you’re trying to achieve. Gene Kim, Patric Debois et al talk about the “three ways”. It’s essentially three steps towards embracing devops culture.
The first is all about increasing flow through the system - that system being your organisation. The idea is to look at how your organisation goes from a business need to realising business value. For instance, how do we go from wanting to provide another payment option on a website, to customers being able to use it?
One way of analysing and visualising your organisation as system is something called “value stream mapping”. This looks at how a piece of work gets requirements, gets developed and how it gets to customers (even if that’s internal customers). You need to understand the process, where the delays are, where teams hand off from one to another, where things go wrong. Ideally you want to optimise this process. One of the issues that many organisations look at just automation and essentially automate a slow and inherently crap process. This will never give the returns that many people are after. Looking at this level, you should be looking at organisation goals. How do you measure this work in a frame that other people are going to understand who are not IT? Is it how fast you can get a feature to market? Increasing individual spend? Increasing reliability of the service you provide to customers? If you’re not framing this initiative in those terms, then it’s doomed to failure. Be specific and measurable.
Once you understand your process, you can look at opportunities to optimise the feedback loops (the second way). It might be that infrastructure is required by dev teams that gets delivered by ops but isn’t what they need. There is a team hand-off here that needs to be addressed. There are many solutions to this problem, but it might be a start to move where the person provisioning that infrastructure sits. Put them in the dev team. You might still keep them as part of the ops team logically to start out with. The point is, you’re looking at the system, understanding the constraints and trying to optimise pain points.
You can achieve a lot without adding any new automation or technology solutions and this shouldn’t be underestimated, but ultimately, handcrafting systems isn’t repeatable or fast enough. This is where reorganising teams might look sensible, but you should know what outcomes you are string to achieve. That might be difficulties provisioning infrastructure fast or flexibly enough, it might be deployment of code to live being too slow, it might be that testing is too slow. Once you know you need improve, you can look at tooling to better achieve that.
/u/quailtop mentions:
>In my (admittedly limited) experience, you can solve needing faster development velocity (the first problem) through staffing a new team whose job it is to help improve the deploy, test and release process for all developer teams. Their job is necessarily cross-cutting across all dev teams. They would develop internal tooling e.g. a standardised build/release process that all teams can employ. This is a great pattern because it avoids encroaching on existing territory and is a very clear contract between engineering.
This is otherwise known as the DevOps “hub and spoke model” and is what my organisation has implemented. It’s worked very well for us and it’s a clever way to start a reorg.
For certain ops teams, you may want to keep them together. For example, you may have a large and complicated network setup and still need a dedicated networks team. My focus then, would be putting an obligation on those teams to allow others to better consume their services. They may need to add other people to this team to make that happen. For example, if you have a complicated network, with lots of steps, look at both automation of those steps but also to allow other teams to more effectively consume them. Amazon spent a lot of effort building the culture that ever system or service is an API that should be able to be consumed easily internally (have a read here: https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ . So, for this case, you may add a tech lead and some software engineers to build network APIs rather than splitting the team up. This may include some of your more traditional network admins to look at replacing on prem infrastructure to support this. The goal however, should always be about the organisation level goal. Improving the speed at which you can reliably deploy network changes should be in support of one of those strategic objectives.
The third way then focuses more on continual learning and experimentation. You should have embedded a set of objectives that you’re working on achieving but you’ll have lots of legacy systems, legacy processes and behaviours. Focusing on outcomes and consistent asking of “why?” will start to help. This is also where SRE becomes really relevant for me. IMO SRE isn’t something that is particularly useful to start out with. It’s best when you’re looking at elevating and existing DevOps culture to a new level. This will look more at observability of a systems and understanding where the more difficult optimisations can be done.
Let me be clear. DevOps is a long road for any organisation to change to. To really get mature it will take many, many years to properly bed in. My organisation started around 5 years ago and we still have more progress to make. One of which is to move from project based way of organising work to more long lived product teams. This organisational change is probably the biggest thing holding us back right now, and has nothing to do with automation or technical practices.
I wouldn’t start out by reading about SRE, I would start with a book called The Phoenix Project and then read The DevOps Handbook, at least twice. Start with the strategy before you make any changes. I would also look to see if you have a cloud strategy because many of these practices are much harder to implement purely on premise.
​
Edit: Thanks for the silver!
Edit2: One thing that's also worth noting is that for many people, moving from traditional sysadmin to DevOps is a hugely scary change. It means that many of the staff won't have the job security they thought they had and they need crucial skills they don't have. To make this work, understand this point of view and support them. This requires really mature and experienced leadership at all levels. This is a good, short and free ebook to help the more traditional sysadmins understand why they have to change.
That's great that you're being involved in the interview process. I think that should give you some confidence that your company are looking to hire the right person.
If you have the time, you may find the book "The Phoenix Project" an interesting read. It's a novella that builds a story about specific management and leadership styles and how they are used to turn around a struggling incumbent organisation from the point of view of a Senior IT Leader who is fresh in the role: https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ref=pd_lpo_14_t_0/257-0577089-4636535?_encoding=UTF8&pd_rd_i=1942788290&pd_rd_r=4898482d-06c3-4e20-b6be-cdd9ae60bad3&pd_rd_w=GO3cY&pd_rd_wg=8oKPD&pf_rd_p=da0677f5-a47b-4543-8b54-10be576b8f26&pf_rd_r=2MK9VRWESAWE5PY4MD9C&psc=1&refRID=2MK9VRWESAWE5PY4MD9C
It is a made up story, but it paints a very good picture of how good IT leadership can work.
Hey,
There is no clear single path. It's almost always you replacing the guy who used to do the job or helping someone else so who knows the setup. Either way start in on general things like Linux and Networking since those are universal. Read a couple devops books and just keep it.
Ultimately I'd say don't ask us - I'd recommend that you find ~20 jobs you like the sound of on dice.com and coalesce a solid todo list for yourself. Obviously no human can know it all and know it all to an extreme detail, but you can certainly get in the direction and over time build the skill set and experience and eventually the door opens.
So I guess all in.
Read - Phoenix Project
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ref=sr_1_2?dchild=1&keywords=Gene+kim&qid=1610598724&sr=8-2
Read - Unicorn Project
https://www.amazon.com/gp/product/B07QT9QR41/ref=dbs_a_def_rwt_bibl_vppi_i2
Linux Administration
https://www.redhat.com/en/services/certification/rhce
Linux Troubleshooting
https://www.redhat.com/en/services/training/rh342-red-hat-enterprise-linux-diagnostics-and-troubleshooting
Linux Security
https://www.redhat.com/en/services/certification/retired-rhcs-server-hardening
Ansible Automation
https://www.redhat.com/en/services/certification/rhcs-ansible-automation
Network Security
https://www.cisco.com/c/en/us/training-events/training-certifications/certifications/professional/ccnp-security.html
AWS Cloud Architecture
https://acloudguru.com/learning-paths/aws-architect
AWS Devops
https://acloudguru.com/learning-paths/aws-devops
Jenkins/Software Release
https://www.cloudbees.com/jenkins/certification/
Cloud Security
https://www.isc2.org/Certifications/CCSP
Various other -
Python and Bash shell Scripting
- Github
- Chrome DevTools, know them well!
- Sublime text and VIM, learn the tricks!!!
- Docker
- Puppet (often found where Ansible isn't) or Chef
- Elastic Search AND/OR Splunk
- Nagios OR check_mk
- Vagrant
- JIRA/Confluence go hand in hand, gonna need those.
Go to Amazon and download a book called The Phoenix Project
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290
DevOps as a concepts is separate from the cloud/web based systems. But is heavily used by the cloud/web based systems.
Really DevOps is about optimizing the process of getting some idea for something through development and being deployed in as quick and as safe a way as possible. This concept apply to any product and really DevOps shares a lot of the ideas from lean manufacturing - ie reducing work in progress, small batch sizes, automating processes etc.
I would recommend having a read of The Phoenix Project and/or The Goal. The ideas introduced in these books can be applied anywhere, though you may or may not need to build more of the tooling yourself for areas that have not yet widely adopted DevOps practices and built tooling for specific cases for that areas. Though you may find tooling for other areas also works for you.
You really need to identify the problems you are facing first before looking for tools though.
But it is not uncommon for embedded systems to talk to web services so there is lots of scope for projects that touch on both sides.
DevOps was a term that originally was meant to mean breaking down the walls between the dev and ops teams and merging them into one team that works together towards a goal rather than separately on counter goals. It used to be that the dev team was responsible for delivering features as fast as possible, and the ops team would be responsible for stability and security of the system.
And this just results the dev throwing new code at the ops team to deploy and maintain - but with no responsibility or skills in how to run a production system and a push to deliver things faster just resulted in quick hacks to get things working, no thought to long term support, no effort in developing tools to help the ops team and a constant want to release new things.
And the ops team never wants things to change as change mean things break. Which caused a rift between the two team - apposing goals that end up working agienst each other.
DevOps was originally meant to be a merging of these two teams, so the ops people join with the dev team and work together to work on the same goals: deploy reliable features to serve business needs.
This was not meant to be a role one person or team gets - but a merging of teams to break down walls. So lots of people argue that DevOps is not a role, it is the culture of devs and ops working in the same team.
If you want to learn more I would highly recommend reading The Phoenix Project and The DevOps Handbook.
But at the same time google was solving similar problems. They did it with similar methods, but in a slightly different way. With this they created the Site Reliability Engineer role (aka SRE). These work as a separate team working on, well, making things more reliable. But they don't do it as just a separate team, the can work with other teams to teach/train them or work on tooling for other teams to use. The idea is still that the dev teams (with hired or learnt ops experience) are still responsible for deploying and running the services they create (just like DevOps describes they should).
This is all described in detail in the Google SRE books.
Nowadays companies have taken these ideas and done different things with them. Some want to be devops so reliable their Ops team as a DevOps team and have no functional change - maybe a bit more automation. Some have an SRE team that is labeled as DevOps. Some actually practice DevOps or SRE. And some have some half way house towards these goals.
You shouldn’t read this book. I think you’d enjoy it given this experience.
The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win) https://www.amazon.com/dp/1942788290/ref=cm_sw_r_cp_api_glt_i_Y0SQY3P0FFGWPKR4QYCD
Another book reccomendation to go with "The Practice of System and Network Administration" is the "Phoenix Project":
​
Learn Kubernetes, what is, what it does, why people deploy it, how to control it, scale it, etc. I like these booksfor the surrounding whys-
The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win) by Gene Kim
And the book it’s based on: The Goal: A Process of Ongoing Improvement - 30th Anniversary Edition
| Item | Current | Lowest | Reviews |
|---|---|---|---|
| Phoenix Project: A Novel About It, Devops, And He… | - | - | 4.6/5.0 |
^Item Info | Bot Info | Trigger
There are millions of things that I've got hold of over the years but there are two I'll cherry pick here.
1) Understand what the business needs. I can't possibly hammer that home enough. I read this book recently and laughed repeatedly as the depiction was all too real - it's worth a read if only to look at the way the lead guy conducts himself and if you don't have the development side that necessitates most of the lessons. If you take nothing else from this whole thread, go away and understand what your business does. Recognise that for instance you need to secure the firewall, but there would be no business if the main customer got pissed off by the extra loops in getting orders through that they took their business elsewhere. People might look at you funny but go stand on the shop floor with the operatives running the extruder, go sit with the woman in Finance that runs the invoice processes, go understand why HR still runs paper processes and has a large room full of filing cabinets look at the wider market your business works in, consider the things that are done in other industries but haven't reached yours yet and listen when the senior team talk about the things that worry them. If you do this, you'll contextualise everything, prioritise better and align the IT function with what the business really needs, not just encouraging shadow-IT and wielding a screwdriver.
2) Own your shit and act like a manager, not a coward in a suit. Your shoulders are broad enough to take the weight of failure and your team should be praised for their achievements. If something has gone wrong, take ownership of it. Making mistakes is human and it's a baller move to stand up and own stuff. Similarly when your team achieve something good, single them out and point at them. Everyone already knows it's your function that's done it but your team member needs the credit. Remember, if you treat your team well when things are good, when things go sideways your team will help you shore it up. Support them!
I've done it for businesses. You're right, I don't know your specific business, maybe I'm just jaded. But commonly the issue is management doesn't understand how to manage, they blame it on the workers and it's a shit show.
All I'm getting at is look into some way that would make sense for your company to prioritize work item tracking. It makes a world of difference. I'm not just making this stuff up, it's well studied and it works. Check out this book (there are many others that cover similar stuff):
Microsoft page describing the Agile methodology:
https://docs.microsoft.com/en-us/devops/plan/what-is-agile
Google page with courses:
Forbes article about Amazon's success with this stuff:
https://www.forbes.com/sites/stevedenning/2019/06/02/how-amazon-became-agile/?sh=5ef251b531aa
Harvard Business Review article about how successful Agile has become and how it's moved many, many companies out of old, broken ways:
https://hbr.org/2016/05/embracing-agile
Why an "API first" approach will help you be successful:
https://nordicapis.com/business-benefits-of-private-apis/
https://swagger.io/blog/api-strategy/benefits-of-openapi-api-development/
On that point - think of an internal API as a "map" to your business. Anyone developing any kind of workflow or integration inside your organization can be given this map, and with the right access follow it to get anything they need to build/support the solution you hired them to work on. Without this "map" your employees are wasting a ton of time in meetings talking about what they would find on that map if it existed....
Web (Front End)
I personally work more on the backend than the front end, but I think it's safe to say that in both cases you should focus on understanding 1) fundamentals, 2) how to implement specific concepts in a well-known framework. If you're a good React developer, I can teach you how to be a good VueJS developer on the job because the concepts will translate.
- Learn how basic HTML, CSS, and JavaScript work. Understand how your browser works.
- Learn how to apply the fundamentals above to a web app.
- Spend time to learn a SPA framework (Vue, React, or Angular are solid choices).
- Learn session management and authentication. It's the 21st century and everyone should be using HTTPS now.
Web (Back End)
Understanding backend development is still important even if you plan to focus on the front end (and vise versa)- if you specialize, it means you're going to have to work with other specialists. If you understand a little bit of how their world works, this will be a heckuva lot easier.
- Learn how to write testable code. I don't believe you need to unit test every line of code you write, but making sure you can isolate and test pieces of your app will force you to write reusable and well-structured code (I'd recommend learning jest or mocha+chai).
- Learn a traditional RDBMS (like Postgres) and a NoSQL DB (like MongoDB). Learn both the query language as well as how tables, indexes, and queries work. You don't need to be a DBA, but you do need to understand how to take your application's data structures (objects) and translate them into database data structures (e.g. tables or documents) which are optimized for the way your app needs to read and write data.
- Learn the theory behind RESTful APIs (what makes an API RESTful? what are its limitations?)- I personally think it's overrated, but you need to learn the rules in order to break them in an educated way. Then you can go learn something new and shiny like GraphQL.
- Learn how to think in terms of asynchronous events. What happens if steps occur out of order? ("temporal coupling" is sneaky like that) What happens if an event fails or never gets received to begin with? Thinking in these terms will help you write more resilient code.
- Learn the basics of how containers work. I'd recommend starting with Docker+Swarm and then K8s if you're really interested.
NodeJS Specific
- Understand how non-blocking code works. In particular, you should understand the "callback-oriented" style of programming in NodeJS and the "promise/async/await" oriented style of programming (and how to communicate between the two).
- Learn how the NodeJS V8 engine works at a high level. Learn how the event loop works and the order in which code gets invoked. Is it single threaded or multithreaded? (the answer is "Yes").
- Understand how package management works. Understanding npm and how packages are structured can let you do some really interesting things to keep your code structure clean. Be comfortable with adding 3rd party libraries to your code.
- Understand how transpiling works between versions of JavaScript and Typescript -> JavaScript.
Tooling / Process
Some of these things (version control) are essential to being a developer; other things here will help you if you want to advance the career latter or become a manager.
- Version control is a must. Learn git well enough that you are comfortable creating/merging/deleting branches, rolling back commits you made by mistake, and structuring commits intentionally so that the person reviewing your code can understand your thought process.
- You should probably learn what this agile nonsense is. I wouldn't worry about learning a particular form of "Agile" or getting certified, but take some time to learn the things that let you develop agile software (software you can develop quickly and change easily).
- Closely related to that, try to get a "big picture" understanding of where software development fits into the business. You should understand how you provide value to your customer, and how to eliminate everything else (waste) as much as possible. The Pheonix Project and the Unicorn Project aren't going to win any prizes for literature, but I have found them helpful in expanding my thinking of what it means to not only develop code, but to operate it and monetize it.
- Learn how to build a business case and sell your ideas. I know a lot of engineers who know that they'll have more agile / efficient / reliable software if they can just spend a few days to re-write some legacy code. But since they can't articulate the business value in concrete terms, the people with the money who decide what gets worked on never prioritize that change.
So... it's 1 AM, this became a teensy bit long, and looking back on it I feel like I wrote the job description for a senior position or a team lead. Regardless, I hope this helps to give an idea of the skill set you should strive for, and how the majority of it really isn't specific to NodeJS.
Podcasts have been a great way for me to keep up. I mess around in my home lab too, but work and family growth eats more and more into that time (not a bad thing!). Finding ways to fill in the gaps like podcasts on commutes/exercise, reading a book instead of binge watching a whole season of Doctor Who, or using a good RSS reader to effectively follow blogs will help you prioritize what you want to play with in the lab.
As far as retention, I find I retain information the best if it is learned from breaking something or by teaching someone something new.
They should have read "The Phoenix project" book
Popular alternatives to The Phoenix Project: A Nove...
How to Talk to Your Cat About Gun Safety: And Abstinence, Drugs, Satanism, and Other Dangers That Threaten Their Nine Lives
How to Read a Book: The Classic Guide to Intelligent Reading
