How To Become a DevOps Engineer In Six Months or Less

“Empty highway road in through a colorful desert” by Johannes Plenio on Unsplash

NOTE: This is Part 1 of a multi-part series.

Part 2 is here.

Target Audience

Are you a developer looking to shift your career towards a more DevOps model?

Are you are a classically trained Ops person and you would like to get a feeling of what this whole DevOps thing is all about?

Or are you neither, and simply looking for a career change and have no idea where to start? If so, read on!

Finally, if you have been doing this DevOps thing for years now, you might still find this useful as a validation of where we are and where this is going.

What’s This, Now?

First, what is DevOps?

You can google the definitions and wade through all that buzzword extravaganza but know that most are embarrassingly long word salads stuffed into giant run-on sentences. (See what I did here?)

So, I’ll save you the clicks and distill it down:

DevOps is a way to deliver software with shared pain and responsibility.

That’s it.

OK, but what does that mean?

It means that traditionally, the developers (people who create software) had incentives that were vastly different from operations (people who run software.)

For example, as a developer, I want to create as many new features as fast as possible. After all, this is my job and that’s what customers demand!

However, if I’m an ops person, then I want as few new features as possible because every new feature is a change and change is risky.

As a result of this misalignment of incentives, DevOps was born.

DevOps attempts to fuse development and operations (DevOps, get it?) into one group. The idea is that one group will now share both the pain and the responsibility (and presumably, the rewards) of creating, deploying, and generating revenue from customer-facing software.

Now, purists will tell you know that there is no such thing as a “DevOps Engineer”. “DevOps is a culture, not a role,” they will tell you.

Yeah, yeah. They are technically correct (the worst kind of correct!) but as it so often happens, the term has morphed beyond its original meaning.

Now, being a DevOps Engineer is something like “Systems Engineer 2.0.”

In other words, somebody who understands the Software Development Lifecycle and brings software engineering tools and processes to solve classic operations challenges.

DevOps ultimately means building digital pipelines that take code from a developer’s laptop all the way to revenue generating prod awesomeness!

That’s what it’s all about!

Also note that as a career choice, the whole DevOps space is highly compensated, with almost every company either “doing DevOps” or claiming to do so.

Regardless of where the companies are, the overall DevOps job opportunities are plentiful, offering fun, meaningful employment for years to come.

NOTE: Be wary of companies hiring for a “DevOps team” or a “DevOps department.” Strictly speaking, such things should not exist because ultimately, DevOps is all about the culture and a way of delivering sofware, not a new team or department to be staffed up.

Disclaimer

Now, let’s put the glass of Kool-Aid aside for a moment and consider the following.

Have you heard the old adage, “there are no junior DevOps engineers?”

If not, please know it is a popular trope on Reddit and StackOverflow. But what does that mean?

Simply put, it means that it takes many years of experience, combined with a solid understanding of tools, to eventually become a truly effective Senior DevOps practitioner. And sadly, there is no shortcut for experience.

So, this is not an attempt to cheat the system — I don’t think that’s actually possible to pretend to be a Senior DevOps Engineer with a few months of experience. Solid understanding of the rapidly changing tools and methodologies takes years to master and there is no getting around that.

However! There is a roughly agreed upon (trendy, if you will) menu of tools and concepts that most companies use and that is what the article is all about!

Again, tools are different from skills, so while you are learning the tools, make sure you don’t neglect your skills (interviewing, networking, written communication, troubleshooting, etc.)

Most importantly, don’t lose track of what we are after — building a fully automated digital pipeline that takes ideas and turns them into revenue generating pieces of code.

That is the single, most important take-away from this entire article!

Enough Talk, Where Do I Start?

Below is your roadmap.

Master the following and you can safely and honestly call yourself a DevOps Engineer! Or a Cloud Engineer if you detest the “DevOps” title.

The map below represents mine (and probably the majority of folks working in this space) idea of what a competent DevOps Engineer should know. That said, it is only an opinion and there will certainly be dissenting voices. That is OK! We are not after perfection here, we are after a solid foundation upon which to build.

NOTE: You are meant to traverse this breadth-first, layer by layer. Start (and continue!) with the foundation first. Learn the technologies in blue first (Linux|Python|AWS), then if time permits or job market demands, go after the purple stuff (Golang|Google Cloud).

DevOps Foundational Knowledge

Again, go after the first layer in every pillar. Then, time permitting, go after the second layer to add depth to your expertise.

Once you have the Foundation layer reasonably figured out, move onto the real-world set of skills:

Real-world skills

NOTE: What’s notably missing from the pipeline above is Test. That’s intentional — writing unit, integration, and acceptance tests is not easy and traditionally falls on the shoulders of developers. The “Test” phase omission is intentional, since the goal of this roadmap is rapid intake of new skills and tools. Lack of testing expertise is judged by the author to be an insignificant barrier to a proper DevOps employment.

Also, please remember, we are not after learning a whole bunch of unrelated techno-babble here. We are after a solid understanding of tools that taken together, tell a single, coherent story.

That story is end-to-end process automation — a digital pipeline that moves bits around in an assembly line-like fashion.

Moreover, you don’t want to learn a bunch of tools and stop. Tools change rapidly, concepts much less so. Therefore, what you want to do is use the tools as learning proxies for the higher level concepts.

OK, let’s dig in a little deeper!

Foundational Knowledge

Under the top line labeled “Foundation” you will see the skills that every DevOps Engineer must master.

Here, you will see three industry-dominant pillars: operating system, programming language, public cloud. These things are not going to be something that you can learn really quickly, check them off the list and move on. These are going to be skills that you must acquire and keep sharp on a continuous basis, to stay relevant and up to date with what is going on.

Let’s go through them one by one.

Linux: where everything runs. Now, can you be an awesome DevOps practitioner and stay entirely within the Microsoft ecosystem? Of course, you can! There’s no law that mandates Linux for everything.

However! Please know that while all the DevOps-y things can certainly be done with Windows, it is far more painful and the job opportunities are far fewer. For now, you can safely assume that one cannot become a true DevOps professional without knowing Linux. Therefore, Linux is what you must learn and keep learning.

Honestly, the best way to do it is to just install Linux (Fedora or Ubuntu) at home and use that as much as you can. You will break things, you will get stuck and then you will have to fix it all and in the process, you will learn Linux!

For reference, in North America, the Red Hat variants are more prevalent. Therefore, it makes sense to start with Fedora or CentOS. If you are wondering whether you should get the KDE or Gnome edition, get KDE. That’s what Linus Torvalds uses. 🙂

Python: the dominant back-end language these days. Easy to get started with, widely used. Bonus: Python is very prevalent in the AI/Machine Learning space, so if you ever want to transition to yet another hot field, you’ll be all set!

Amazon Web Services: Once again, it is impossible to become a seasoned DevOps professional without a solid understanding of how a public cloud works. And if knowledge of a cloud is what you are after, Amazon Web Services is the dominant player in this space, offering the richest set of tools to work with.

Is it possible to start with Google Cloud or Azure instead? Absolutely! But we are after the biggest bang for the buck here, so AWS is the safest play to make, at least in 2018.

You get a free tier to play with when you sign up for an account at AWS, so that is a good place to start.

Now, when you log into the AWS console, you are greeted with a simple, easy to understand menu of choices.

“Discovering yet another AWS feature I never knew about” by Tom Pumford on Unsplash

That was sarcasm. Good news is, you don’t need to know every single Amazon tech.

Start with the following: VPC, EC2, IAM, S3, CloudWatch, ELB (under the EC2 umbrella), and Security Groups. These things are plenty to get you started and every modern, cloud-enabled enterprise will be using these tools heavily.

AWS’ own training website is a good place to start.

I recommend you set aside 20–30 minutes daily to practice Python, Linux, and AWS.

NOTE: this will be in addition to the other stuff you will have to learn. Altogether, I estimate that spending an hour daily, five times a week is enough to give you a solid understanding of what is going on in the DevOps space within 6 months or less.

That’s it for the Foundational Layer!

In the subsequent articles, we will explore the next level of complexity: how to Configure, Version, Package, Deploy, Run, and Monitor software in a fully automated way!

How you can make a progressive web app in an hour

Progressive Web App’s use local service workers to load instantly, regardless of the network state. Image source: developers.google.com/web/progressive-web-apps

In this quick tutorial, I’ll show you how to add your HTML, Javascript, and styling to this template to create an app that works online, offline, in a browser, and as a mobile app

Progressive web apps are a hybrid of a website and an app that you might use on a tablet or mobile. Making one has a lot in common with creating a website, but with a few key extra files and concepts involved. It need not take a week of trial and error or trawling through a tutorial to get one up and running.

This post will show you how to make one in an hour that you can then host, use online as a website, and use offline and as a mobile app.

To give an example of what you could create, here is an example of one I made earlier based on Google’s codelab on web apps. It generates a QR code from the text you enter.

qr-code-pwa.firebaseapp.com

Some key feature of Progressive Web Apps:

Responsive — Fits any form factor: desktop, mobile, tablet, or whatever is next.
Connectivity independent — Enhanced with service workers to work offline or on low-quality networks.
Installable — Allows users to add apps they find most useful to their home screen without the hassle of an app store.
Linkable — Easily share the application via URL, does not require complex installation.

Use a template to start your app

To get started, clone this template repo (or just copy the bits you need). This includes the website project structure with everything you need to make an app.

├── README.md
├── firebase.json
└── public
    ├── fonts
    │   └── roboto
    │       └── ...
    ├── images
    │   └── icons
    │       └── ...
    ├── index.html
    ├── manifest.json
    ├── scripts
    │   ├── app.js
    │   ├── jquery-3.3.1.js
    │   └── materialize.js
    ├── service-worker.js
    └── styles
        ├── materialize.css
        └── style.css

What’s included in the template project

  • JQuery: A library for supporting JavaScript on your website
  • For styling and a range of quick to use components and effects, this has materialize.js and CSS from materializecss.com. Remove or replace it if you prefer something different.
  • public/service-worker.js: Service Workers allow you to run your app offline, as well as other innovative things. Currently, this will cache the app’s files for quick local access. Read more about this in Google primers: service-workers.
  • public/manifest.json: A JSON file specifies how your app appears to the user in the areas where they would expect to see apps (for example, the mobile home screen). It also directs what the user can launch, and more importantly, how they can launch it. Read more about this here.

Adding your code

The main files to edit are:

  • public/index.html: The main HTML page for your app. Currently it has title nav bar, a card, an input field for a message, and a button to display this on the card.
  • public/scripts/app.js: This contains the JavaScript to handle the logic in your app. It currently uses localStorage for storing data when the user clicks the button, and it is recommended to use another database in production, such as indexedDb (Read more here).
  • public/style/style.css: Add your own styling to this file.

Once you’ve made your app:

  • Update the list of your app’s files to cache in service-worker.js
  • images/icons: Create square icons of the number of pixels for each size and save them here. These will be used by browsers and operating systems.

Troubleshooting

If you are using the Chrome browser on a Mac, bring up the Dev Tools window:

  • View → Developer → Developer Tools

The Console tab will show you the logs from the app. On the Application tab,you can see the data stored locally.

  • Storage → Local Storage shows you the message stored by the app.
  • Cache → Cache Storage → template-pwa displays the files you have set to cache and retrieve from within service-worker.js

If you encounter problems, it’s often worth switching the service worker off and on again, then clearing the cache and reloading the app.

Also, see:
– Google Codelabs — your-first-pwapp
– How to debug Progressive Web Apps using Browser Developer Tools by Flavio Copes in freeCodeCamp

Using your app

Now try it out!

You should be able to visit the hosted app in your browser, and add it to your home screen on your mobile!

Here’s one I made earlier: qr-code-pwa.firebaseapp.com

Read more from ryanwhocodes

Mimecast acquires Ataata

Mimecast acquired Ataata laying the ground work for the most effective cybersecurity awareness training program imaginable.

The acquisition enhances Mimecast’s offerings, adding cybersecurity awareness training, risk scoring and real-world simulation attack scenarios to your already potent mix of cyber resilience services.

What Is Ataata?

Developed by top leadership from the U.S. military, law enforcement and the intelligence community, Ataata is a security awareness training and cyber risk management platform that helps you combat information security breaches caused by employee mistakes.

Ataata combines effective, modern training techniques with predictive analytics to solve for your company’s vulnerability to human error. Human error is involved in 95% of all security breaches. But humans are maddeningly careless and resistant to change. Employees’ casual mistakes lead to disaster all the time — and cost people their jobs. To change security culture effectively, employees have to know what to do, care enough to improve, and then do what’s right when it matters.

Creating a web app as side project

About the process of building my personal little side project 1tuner.com 📻

1Tuner is a progressive web app that you can use to listen to online radio. And it allows you to plan your own ideal radio listening day, so the player switches between radio streams automatically.
The app is pretty basic, but it changed while I was learning during development of it. In this article I will try to describe the process and decisions.

The “problem”

At the office, we always listened to good-old radio. For years, we tuned our browser to the audio stream of the Dutch public radio channel 3FM. We heard nice pop/rock tunes, some fine jocks and a good news service.
Then came our problem, jocks left the station, and a music format switch brought us shittier music (and OK, a better logo maybe). At the same time, the dusty Dutch Radio 2 was changing as well — for the better in our opinion (reluctantly admitted at first). We were also looking for other alternatives. In the end, we switched throughout the day to Radio 2, to 3FM, to Radio 2 etc…

I knew this had to be fixed. So I started a new web app to start Radio 2.5; an automatic stream switcher.

Where to start

I was fairly late to the “front-end framework party”, and wanted to dive in. This side project seemed ideal for that. I started with Vue.js, and wanted to try Webpack as well. I found some basic boilerplate projects and started by trial and error. Lots of errors actually… The thing with side projects is: time. I’m not sure how other people manage this, but to be fair it’s hard to start up each time when you leave your code behind for some days. And when you finally found out where you got stuck, it’s time to sleep! 🙄 I was struggling in the world of Webpack modules and loaders, and somehow corrupted npm modules.

Another confusing problem at first, was the audio element. Initially I used the “autoplay” attribute, and then just changed the audio source. This worked in Chrome on desktop, but not on mobile — audio didn’t play on mobile.
It took some time before I understood this was an “autoplay” problem (later on, the autoplay behaviour was the same on desktop).
From my experience; just avoid using autoplay 🙂. Nowadays you also should trigger audio change on user gestures like the tap/click of a button.

Start over

Once I had a basic app that was switching the audio streams, I was done with it for some time. But I also read a lot about Preact, and when preact-cli came by in my Twitter timeline, I wanted to try that! So I started from scratch. Or maybe not really, because preact-cli works like a charm right out of the box.

One thing that bothered me with my previous setup was file size and loading times. I was using Firebase as well, which was actually quite big (with all the bells & whistles). And together with all inefficient things I had included, the total (optimized & minified) size was ridiculous — because I was just tinkering around.

The fresh start with Preact was also reason to keep things more efficient. Finally, I came to the conclusion that I needed to keep things as simple as possible. So no more authentication and saving to Firebase, but save all user data locally, and use the power of URL’s! Progressive web apps rock! 😎

UI / Design

OK, don’t laugh. I really thought things through. I wanted an interface that was as clean as possible, because the main way to use the app would be to tap and listen.

Icon
The main branding would be the app icon. But I still had to choose a name and register a domain. First it was stream-zapper, stream-switch, tunar, stream-tune… I ended up with 1tuner.com. One advantage of the name is that it’s on top at your app list/drawer when it’s sorted alphabetically. 😉

Progress in icons

For the logo and icons, I used the online vector tool Gravit Designer — it’s free and pretty amazing actually. Open, edit and save to SVG.

Fonts
Because I wanted a quick loading and a native-like app experience, I wanted to go with system fonts. By using system fonts, you always get the default font of the device. Stuart Frisby wrote a nice article about implementing system fonts on Booking.com.

Layout
I started with a default header menu and a play button on the main screen. Then I moved the play button to a fixed positioned footer.
Recently I moved the navigation to a fixed icon/tab bar for mobile and left-hand menu for bigger screens. For web apps, the tab bar navigation can be problematic because in some browsers you get a double navigation at the bottom (app + browser navigation). But overall the experience is better this way I guess.

PWA features

I use the Media Session API to display the current playing radio station notification. Obviously this puts in the “progressive” part in the web app, as this only seems to be supported in Chrome on Android right now. However, it works out great; you’ll see the logo with play/pause on your lock screen, and even on your smartwatch!

The Media Session API gives the web app a “native app feel”

As you may have noticed there is only a “pause” icon. Because in the 1tuner app you are listening to “live” radio, I handle the pause event as “stop”. Unfortunately, there seems to be no stop event/icon from the media notification right now.

The Web Share API is another great addition to the app. It’s easy to use and directly opens up the native share menu when you click the share icon.

Other

  • Navigator.languages/language for the default “Region” filter.
  • I use idb-keyval from Jake Archibald, a simple way to store key/value data that is implemented with IndexedDB.

Tools, services & resources

It’s just so great that there are so much free tools and services!
Yes, I‘m Dutch. 😁 An overview:

  1. Visual Studio Code is awesome to use with the integrated terminal, together with preact-cli and live reloading. 👍
  2. Preact-cli is amazing, you can start with some demo projects, routing, pre-render and a service worker that just works out of the box. Preact is like React, but smaller! Big thanks to Jason Miller.
  3. I used the online vector design tool Gravit Designer for the logo and icons. You should really try this out!
  4. Gravit Designer easily exports to SVG, but the output can still be optimized. If you don’t have it automated in your project, you should use the excellent SVGOMG from Jake Archibald.
  5. To get all the app icons: https://realfavicongenerator.net. It’s pretty full featured as you even get a Safari Pinned Tab SVG traced icon for instance. You can also use the favicon generator API and use this in your own automated tasks.
  6. I use Firebase for hosting and the database. I don’t use much of the other features anymore, but authentication for client-side apps is really easy with Firebase!
  7. The header image is from Pexels, a free stock photo library (CC0 license).

Upcoming versions

Besides debugging and adding more radio stations, I have a couple more ideas that I would like to add to the app;

  • Let users add radio stations.
  • Share planning with timezone support. Had a quick look earlier, but this is a bit complex because of daylight saving times.
  • Podcast support (also for use in the planner).
  • An option to cast to Chromecast directly.

Thanks

❤ Rianne

🙂

How to Build Your Own “Spotify Model”

It is early 2011 and you are the CTO of Spotify. You’re staring out of the window of a coffee bar in a snowy and dark Stockholm. It has been an amazing year. Your company is acquiring customers faster than ever and you’re launching in more and more countries. However, Google and Apple are catching up. It’s not a question if they will launch their own music streaming services, but when. To survive that eventuality Spotify must become a truly global player.

You have to do this while still figuring out how the music streaming business actually works. What do customers really want? What will they pay for? What do you need to do to convince someone to stop buying CDs or MP3s and instead be willing to pay for a monthly streaming subscription?

“We need to innovate, experiment and learn faster than the competition.”

To do all this on a global scale you have to grow your engineering team. It has been a huge challenge to grow your team from 10 to 100 in the last year. Some people predict you might even need to attract another 1,000 engineers to pull this off. You feel overwhelmed. How can you attract the right talent with the right mindset across the entire globe?

Managing a team of 100 is already complicated. But if you grow even further, how do you stay agile? How can you keep the start-up culture that has brought success so far and prevent becoming a lumbering bureaucracy?

Spotify’s organization design

Another two years have passed and the company now has 15 million customers. The engineering team has tripled in size to 300 people. A challenge that has been top of mind for a while now is, “With 30 teams, how do we make sure we build a castle that makes sense to the customer, instead of a pile of 30 bricks that nobody likes?”

The teams have started to experiment with a scaling model that uses Squads, Chapters, Guilds and Tribes who aim to implement ‘minimum viable bureaucracy’ and balance high autonomy with high alignment.

Source: Spotify’s engineering culture

This structure is just one piece of the puzzle, though. Through a few workshops, the agile coaches came up with a set of organizational design principles with the autonomous team as the core concept. This extension of the agile manifesto is called “Agile à la Spotify”, and has been printed on the walls across the office:

  • Continuous improvement: At Spotify, part of my work is to look for ways to continuously improve, both personally, and in the wider organisation.
  • Iterative development: Spotify believes in short learning cycles, so that we can validate our assumptions as quickly as possible.
  • Simplicity: Scaling what we do is key to Spotify’s success. Simplicity should be your guidance during scaling. This is as true for our technical solutions, as for our methods of working and organising the organisation.
  • Trust: At Spotify we trust our people and teams to make informed decisions about the way they work and what they work on.
  • Servant leadership: At Spotify managers are focused on coaching, mentorship, and solving impediments rather than telling people what to do.

Full autonomy is a trade-off

Fast forward to early 2018. Spotify has 140 million users in 61 countries. It has announced an IPO at a $20 billion valuation. Engineering and R&D is now 180 teams and 1,800 people. In total, Spotify employs over 3,500 people: the organization is no longer a startup, it’s a global enterprise.

A lot has gone really well. The culture is known for a high level of empowerment and trust, a focus on personal development, and is known for its sense of purpose. Teams are fully empowered to fulfill their mission and have the freedom to act independently. But as Joakim Sundén pointed out, it is far from an agile nirvana.

“What is the best thing about working at Spotify? What is the most challenging thing about working at Spotify? The answer for both questions is the same: Autonomy.” — Joakim Sundén

Managing 180 autonomous teams can feel like herding cats, especially when it comes to projects that span across teams.

Some recent examples: implementing SOX compliance to enable the IPO, keeping up with new privacy laws and moving all infrastructure into the Google Cloud. Also, the lack of focus on architecture and technical standards has made it challenging to scale the platform to support its growing user base.

Implementing these initiatives top-down wouldn’t work in Spotify’s culture. A team can simply say “I don’t want to do it” and would need to be seduced to give these priority.

Over the years, the lack of central planning and standardization has enabled hyper-speed, hyper-growth and hyper-innovation. But it has made certain things a lot harder that are easy for more traditional organizations.

“There is no right or wrong, it’s all trade-offs” — Henrik Kniberg

Time will tell how Spotify will continue to evolve. It’s a challenging balancing act between doing the right things, doing the things right and doing things fast.

Don’t copy the model

As agile organization designers, we’ve been following Spotify closely. Over the years, we’ve visited their offices several times. It’s an awesome company and there is much to learn from them. We love how the engineering culture videoshave inspired thousands of people to start upgrading their organizations.

However, if you’re considering implementing the ‘Spotify model’, please think again. Is your organization building a music player? Is your organization still trying figure out its business model? Is your organization facing hyper-growth? Is “move fast and break things” applicable to your product?” Maybe. But, probably not.

Source: xkcd

When people copy the ‘Spotify model’, it often happens through a top-down directive, without taking a close look at what kind of culture and leadership is needed to make it work. Often the existing hierarchy is changed into a new, static matrix blueprint (even if the matrix is labeled with Squads, Chapters, and Tribes), instead of growing a culture of continuous participatory change. This will inevitably make things worse. Even people who work at Spotifyrecommend to not copy their model.

Don’t get us wrong: in order to enable agility in an organization, we do recommend that you move away from top-down management and focus on empowering capable teams. But to copy a pre-existing model and believe that your problems will also be solved, is short-sighted and naive.

“The only Spotify way of working that actually works is turning on the Spotify volume really loud and dance.” — Erwin Verweij

Evolve your own organizational model instead

Just as startups are focused on finding product-market fit, we believe you should start on a journey to find your organization-context fit. Spotify has been able to do both.

We love this quote that is at the heart of what we believe:

“Stop trying to borrow wisdom and think for yourself. Face your difficulties and think and think and think and solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up.” — Taiichi Ohno

So what can you do if you want to gain agility, speed and innovation? Where to begin?

First, ask yourself, is there a clear picture of what issues you’re trying to solve with a new organizational model? If possible, find a few measurable indicators of what needs to be improved.

Involve not only your leadership team, but also a wide variety of people in the organization to gather ideas and co-create a picture of the desired future state. A good question to ask is: what is holding you back from doing the best work of your lives?

Don’t forget to appreciate what is going really well and decide what you definitely want to keep.

Take inspiration from a wide variety of future of work practices and companies. Look at different models of self-organization that fit different scale and risk contexts. Look beyond Spotify and even look beyond agile to gain org-wide agility.

Figure out what the main capabilities are you need to upgrade and where in the organization they are rooted. The OS Canvas is a useful tool for this exercise.

Design and start a number of pilots that help you try out new ways of working and allows you to quickly learn if it fits your specific context. Expand the pilots that show promise. End the ones that don’t produce the effect you’re looking for. Build your organization’s ability to constantly try new behaviors and learning from those experiments.

At the end of the day, use the Spotify model as an inspiration for what’s possible when you spend time and attention developing your own operating system — not as a model for what your own system may end up looking like. Design, test, and evolve your own model as inclusively as possible. Don’t do a big-bang change towards a new static target operating model, but instead build the muscle for continuous participatory change.

Don’t “do the Spotify model” — do your model.


Co-authored by a friend of The Ready: Roy Gielen (Agile enabler, trainer & coach at Ctree)


Ready to change how you work? The Ready helps complex organizations move faster, make better decisions, and master the art of dynamic teaming. Contact us to find out more. While you’re at it, sign up to get our newsletterThis Week @ The Ready delivered to your inbox every week.

Follow me on Twitter | Follow The Ready on Twitter | TheReady.com