DevOps Dudes
Published in

DevOps Dudes

DevOps: Team Structure, Collaboration, Toolchain & New Shiny Thing

A discussion about the term DevOps

I think most of the significant organizations and SME or even a start-up company know about DevOps by now either they are currently doing the adoption mode or currently implement DevOps culture.

Recently, a person from Sematext company approached me and asked several questions about initials questionnaires that most organizations have when the time they want to start their DevOps journey. Here my answers for the following questions;

Part1: Team Structure & Collaboration:

1. What do you think the ideal DevOps team structure would look like?

The standard DevOps Team Structure

By looking at the above table, you might think several roles might hard to get, or there is insufficient talent in your region to meet the high structure. I know some country or region is hard to get the “ideal” DevOps person that has combined experience Development & IT Operation, and most of the DevOps talent is either from Development or IT Operation background. I usually saw some job vacancies posted in Job Portal for DevOps position not been found or filled with candidates.

This or the company cannot find suitable candidates, or they just make a job’s requirement is hard, which ends up wasting time tried to find “perfection” from DevOps talent. If you really know what DevOps means, you don’t need perfection for DevOps talent; you can build your DevOps team within your current unit. If you want to optimize your existing team structure, you can re-locate between Development and Operation team, because your internal staff has a better understanding of what your product architecture and what your product capabilities. Then you only inject them with DevOps knowledge, and you can get online or paid training for them in no time.

DevOps is about the journey, hence the amount of time you seek for DevOps Engineer or Consultant out there, it better you use it to building your own team, the fast your get your hand dirty with DevOps culture and method, the more comfortable you will get on how to implement DevOps in your organization. If your geographically dispersed organizations, I had written about how you can do DevOps adoption, you can click below;

2. How can DevOps teams minimize burnout caused by context switching between Dev and Ops?

  • Keep DevOps Process Simple and Clear:

Sometimes the process introduced by DevOps made both team Dev and Ops stressed out by complicated means and steps to do even simple things. DevOps leaders can simply or automate several tasks that involve both teams; hence both teams can have more collaboration to be innovative and deliver more features to existing applications or create new applications and services.

  • Anatomy Vs Control:

Many research shows that when people have little sense of autonomy and control in their work, there is more stress and more burnout. One way DevOps leaders can help fight burnout is to create more independence in their teams and not to impose restrictions on them. This means that leaders should not make all the decisions that affect team members, but rather allow them to make their own decisions.

  • Remove Bottlenecks and Overburdens

With context-switching, defects, too much work-in-progress, and bottlenecks, It often means that agile tempo is lost, and teams are overburdened, leading to burnout. The role of Scrum Master in the group comes in handy when a time like this by removing unnecessary tasks and bottlenecks hence make the team refocus and have more time to deliver their works.

3. How can teams that have traditionally worked alongside each other, but not together, suddenly adopt a model that encourages them to contribute to a single conversation across every stage?

They act as a united team with shared goals and unified product vision. Either of the teams does not have separate functions. Everyone’s working together to reach a shared goal.

Part 2: DevOps Tools — To Build vs. To Buy vs. Shiny New Tool

1. How should teams decide what DevOps tools to build in house and which ones to buy?

Before the team choose any tools for their DevOps team, the following criteria need to be in place first;

Define all issue/problem and goals

Defined all your problem and issue your team has and what you to achieve in the future.

List of existing resources/tools which can solve all issue you listed.

List all the existing resources and tools you have and come out with a possible solution toward each issue.

Know your team capability and budget.

Not each possible tool or solution that you listed you able to apply or implement in your organization. Your budget allocation also plays a significant factor to choose your toolchain.

In short, your tool of choice should consider below scenario;

Criteria to choose your DevOps Tools.

2. How do you handle the ever-increasing number of new DevOps tools?

By having DevOps toolchain metric, which Toolchain metric consists of clear each of your tools, its purpose and function. Thus, the team can handle whether to migrate to new devices or not. If there is a need to change or buy new tool due to the tool’s end of support, hence you need to handle by migrating to new tools.

3. How to resist or handle the temptation of using new shiny tools out there?

With your toolchain metric, it can help you to keep your team sane and avoid the unproductive, unnecessary tools. By focusing what your business goals and DevOps goals, hence you will able to avoid the temptation of using new shiny tools. Here some tips to avoid the temptation of new shiny tools;

Commit to your DevOps goals without getting sidetrack:

It would stop wasting time by quitting a half-finished project before you see any result or progress. The only exceptions to this rule will be if you find that your project starts costing you more money than you originally expected or if the conditions in your company or the world have significantly changed enough to minimize the efficacy of the project entirely.

Feasibility and sustainability of an Idea or Tool before using it:

Reach and think if your idea will make the most of the resources of your company. Every successful enterprise needs a viable business concept and a realistic plan. You can spend a short amount of time doing Minimum Viable Product (MVP) or demo before fully implement it in your current landscape. When you perform a feasibility report, you will have the opportunity to find answers to critical questions that allow you to determine the value of the project and to assess the likelihood of success or failure in the projects.

Always ask yourself: Will your new idea/tool/project add to the product’s customer experience (UX) :

Your business success starts with your customers, and the first move is to put yourself in the shoes of your customers. Consider the additional benefits your customers receive from your new ideas/tools. Perhaps finally your new idea will save your customers some time, energy or money. Or maybe it will make your company more productive. Begin by considering the value you add to the experience of your customers so as to strengthen the “customer first” approach.


You can have a small team for DevOps team regardless you are a big organization or little, you need to start doing it rather than stress out to find the perfect structure for DevOps team, you also can convert your current team to become DevOps mindset and building a great team from it. DevOps not only about tools, as long as your tool meets the DevOps culture and ultimately solve your problem you can survive with it. The temptation of new shiny tools or enterprise tools for DevOps you can handle it by having correct Toolchain metrics and proper tools for your products.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Najib Radzuan

Najib Radzuan

DevOps | DevSecOps | Global DevOps Ambassador | CDF Ambassador | Digital Transformation []