Join MarraM

cropped-cropped-allrays.jpg

Join Marram to explore the unknown and change how organizations (and companies) are going to organize and motivate people in the future. Yes, there are many variations and part of them are very advanced compared to the original concept of Scientific management. With the Information Revolution succeeding the Industrial Revolution and new generations (Y and Z) entering the work environment, we are sure that there are better ways to motivate and organize people. A way that will help organizations be more prepared to motivate the information generation and enhance their ability as valuable contributors.

There are already many new approaches being debated and implemented by thoughtful leaders in existing organizations. If you want to be part of this movement, if you want to change how organizations will motivate and organize people, if you want to do something about it, your place is with us.

www.marram.org

cropped-marram.jpg

Four reasons why we are implementing DevOps – 3rd reason: The power of diversity creates better groups

It’s already an axiom that the power of a group is bigger than the power of individuals. Groups can be much more powerful if they are built from a mix of different personalities and expertise. After all different personalities and expertise compensate each other in creating a whole which is greater than the sum of its parts

DevOps structure is a great opportunity to create diverse groups. Creating a group of developers, system admins, database administrators  and desk side support professionals is much better to handle IT tasks than a group of just system admins, developers or help desk professionals.

This power of diversity pushed us (at The Friedkin companies IT) to implement DevOps, but It also pushed us to implement DevOps by creating diverse IT groups.

Why DevOps - Diverse teams

Four reasons why we are implementing DevOps – 2nd reason: Current IT practice == Systematic Failure

Why DevOps - Systematic failure

Lets face it, something is fundamentally wrong with our current IT practice. during my long (cross continental and industrial) IT career over companies of different sizes, I never  heard from IT customers or seen any companies that are really happy with their IT group. Well, actually I never heard any CIO that didn’t claim that he inherit a mess as well. I never heard such a systematic attitude for financial, marketing or other enterprise groups.

I’m not claiming that I found the right way to practice IT. I just realized that if we won’t try completely different approaches to run IT, there’s no way that we are going to change the current situation. That’s the 2nd reason why we (Friedkin Companies IT) are implementing DevOps.

"sprint based mini-IT teams" is the future IT structure

The classical IT structure that helps us to go through the last 20 years challenges is not helpful anymore. Silos of computing, storage, developers, operation, support and network engineers won’t help us to successfully address today’s and future challenges.

Image

Business is being changed by disruptive technologies. As an IT organization, which needs to support business operation, we can’t create or predict the future technologies and business needs that the future ( and Darwin rules) will introduce us. What we can do is making sure that we are building platforms and IT organization that will enable decision makers to change business processes or practices fast, really fast.

The financial future is unpredictable as well, thus demanding agile, lean and dynamic IT organization that can support the business in the most cost efficient way.

To address the described challenges we, as IT leaders, need to stay away from the classical IT structure. The future IT structure should be build on the principle of one IT team with one common goal. The classical silos needed to be break into hybrid teams build from different IT specialist with different skill sets. I like to call them mini-IT, since each team is a fully functional IT group ( including infrastructure, networking, operation, development and support capabilities). Mini-IT teams have the spirit of a small IT group supporting fast growing companies. In such teams any task can be done by anyone. These teams are all about fast and efficient execution of IT tasks, that needed to support fast pace business needs.

Image

The drawback of Mini-IT groups is that over time each group become totally separated and distinct from other groups. Such an environment is obviously not a good enabler of one big IT group. To deal with this challenge the Mini-IT groups are actually “sprint based mini-IT” groups. Each sprint mini-IT group is created every sprint and staffed with different IT professionals, based on the need of the sprint. Actually we have two different structures. HR structure and sprint structure that could be different every sprint. This approach drives people from different IT domains to work with all other members of the IT group, thus creating one IT team.

Sprint based mini-IT groups have other benefits than creating flexible and fast pace IT groups such as decreasing finger pointing inside IT and increase service quality and customer satisfaction.

In this blog I’m going to share the success stories and challenges that we experience through the transition from classical IT structure to sprint based mini-IT structure.

Technical career path for IT

Everyone in IT had the experience of working with a manager that neither you or your team members can understand how on earth he became a manager. To tell you the truth, the same experience can be shared by IT management as well. It’s common in every IT shop.

The most common reason for those managers is single career path that leave managers no choice but moving very talent technical folks to managerial path to be able to increase their compensation and retain them.

To prevent this syndrome from happening at the Friedkin companies we spent a lot of time to create technical path. Our technical path is using the architect term to define equivalent technical career path to the managerial path (Solution architect, Architect, Sr. Architect, Enterprise Architect, Chief Architect). Each and every title in the technical path has the same payment band of the equivalent managerial path. The highest title of the technical path is equivalent to a director level in the managerial path. Obviously the technical path titles have equivalent compensation bands to the managerial path.

To provide our associate with a clear career path we also created road map for each associate. The road map defined what are the tasks and tangible goals required from an associate to promote him in his chosen career path. Road-map’s achievements should be evaluate every 6 months with the associate to ensure his eligibility for promotion. Associates have the option to change their career paths every 12 months.

Each position at Friedkin IT has a job description available on the corporate portal.

Image

Road-map:

Image