Chapter 13: Roles and Responsibilities

Organization Structure

Before taking on a new role in an organization, we must first understand the expectations for the open role or opportunity. This allows us to better align our daily tasks while also gaining a better understanding of the organization’s reporting structure. Part of this understanding includes the knowledge gaps we will have about the organization and how it functions.

Reporting Structure

The reporting structure refers not only to whom we report but also to which managers members outside of our team report to in the organization. It’s important to understand direct reports so that we can ensure we keep our tasks prioritized and ensure on-time delivery of assigned tasks and project work. You may be asked to do something by another manager outside of our team, and the project could be important, but it will need to be managed based on your current project priorities. We can level-set these projects by discussing them with our direct reports to ensure we stay organized and focused on what matters.

Once we are hired, we will have tasks provided by our direct reports, but I encourage and challenge you to have a secondary agenda. During the first two weeks of your training, to gain a better understanding of your team’s structure and projects, review the organization chart and collect links to supporting documentation for all the applications your team is responsible for and maintaining. Then block time on your calendar to read through the documentation and take notes where you see gaps in your knowledge. After that, schedule time with a senior developer, subject matter expert (SME), or someone with in-depth application knowledge for a 30-minute question and answer session. This will put you ahead by about 2.5 months compared to others who may have joined the organization and are still learning through the trial-and-error method.

By reviewing the organizational chart, you should be able to determine who the most senior person is on the team. By reading documentation or at least knowing where to find answers to your questions and studying system architecture, you can ask how and what questions to close the knowledge gaps. When you are new, you have time that you will likely not have after your hire date; use it wisely. Take advantage of this time to read, review, and ask a lot of questions to get up to speed with other members of your team. This will provide an advantage and accelerate your learning and growth within the organization. These steps are repeatable no matter what role you embark on in the future.

Direct reports or Reporting Managers could be Project Managers, Directors, Managers, or Supervisors. This is largely determined by the type of teams we are on and what the team is assigned to work on. We may meet with them daily, weekly, bi-weekly, monthly, or quarterly based on the organizational needs. They will be responsible for assigning work to us and prioritizing assigned tasks. This is normally done through stand-up meetings that help discuss ongoing project work. The frequency of the meetings is determined by the type of project we are working on and the department leadership. Stand-up meetings allow us to table problems, challenges, and work completed for a given project. We should use these meetings to ask for help when and where we need it. A typical report might sometimes use the 3x3x3 rule.

3x3x3 rule

1. 3 Accomplishments from the last week
2. 3 Things we are working on in the current week/sprint
3. 3 Potential Problems/Concerns for the current week/sprint/Or any blockers

This rule provides a framework for how I would capture work and report during a typical two (2) week sprint/stand-up. Going into a stand-up meeting, we should ensure we have a clear understanding of what is expected of us and the task we are reporting on and action items discussed about during the current sprint. If we are not clear on concepts or ideas, we should annotate them and find out who is the best person to talk to after the meeting. Once we identify a person or group, we can start to ask questions and determine if we need to triage our problem to an internal team lead or manager.

Problem Escalation / Triage

Problem escalation/triage is a process that is defined differently for each team. We should find out how problems should be moved between teams before we hand them off to another team. We should also do our due diligence to address the problem, add notes, document steps taken, and how to create tickets for external teams before escalation of an issue. Lastly, Due diligence may vary based on the problem type but at a minimum, our research should include but is not limited to:

• Screenshots
• Links to troubleshooting documentation used
• Customer Name
• Problem Description
• Steps taken to resolve
• Escalation team and reason for escalation

There are other variables that should be considered when creating a problem ticket that will be specific to the company or teams we are working with. It is wise to make ourselves aware of how the team operates and how information flows between teams. It is also important to understand how our team currently handles incoming requests, where to find supporting documentation, how to escalate issues, and when to escalate an issue during our first few weeks in the organization. With these foundational principles, we should be able to become self-sufficient in fewer weeks than normally allotted for new hires.

Ticket Follow-up. We may need to follow up on tickets we submit to ensure the problem was handled, closed, or if any additional details are required. It’s also helpful to tie issues together if another customer calls in about the same issue. We can combine the issues and centralize ongoing reporting on the same issue instead of creating duplicate tickets. Many ticketing systems will have a unique identifier (UID), a numerical value that allows us to look up tickets we have submitted. They often also include the ticket status and person working on it in case you need to reach out to them via a chat messaging system.