The Key’s Role

by | Jul 6, 2021 | Masterprint, Team Members

key·stone
/ˈkēˌstōn/noun
noun: keystone; plural noun: keystones
a central stone at the summit of an arch, locking the whole together.

In any good team, there is one indispensable person. While the Reps help get the client’s vision down, web build the website, the Admin ensures we get paid, and the propagator’s research content, the “Key” is the person who manages them all. Once a project is handed over from a blueprint, the Key is the person responsible for the completion of the project.

Every day a Key should start checking for emails, texts, or messages that are relevant to his projects. He should open the project management software and review new messages, and then meet with his team to make sure they are following the blueprint and project template.

Monday Morning Meeting

The Key or the owner will usually coordinate the Monday Morning meeting.  This is a two-hour slot of time that is designed to make sure all teams are on point.  Prior to the meeting, the Key should be up to date on all the issues that occurred during the weekend.  The opening of the meeting might be a state of affairs from the owner, or the group might jump into the emails.

Email Review

This is primarily to update the team on any fires. It is not necessary to review every email, just those that are high priority. Many emails will be discussed in the projects.

Project Review

It is important that the Reps, Key, and Owner are here. The point of the entire meeting is to make sure that ICHRONstudio is communicating its build team with the client.  All projects are reviewed, and the Key is responsible to give the Status of the build, the hours spent, and projected hours remaining. Reps should note the status updates for their weekly calls.

Sales Split

Depending on the size of your team the next step is for the sales team to take over the meeting. The Key is no longer needed and can leave the meeting.

Initial Handoff

The first thing that happens in a project is the Sales Representative needs to fill out the Blueprint to officially “hand-off” the project to the Key (and Admin, especially on larger projects). Once that happens the Rep will still update the client, and continue communications, but will no longer be responsible for the build.

The Reps will walk through the blueprint and meeting notes with the client. Communicate timetables and deadlines and all products sold and discuss the client demeanor and expectations in tandem with the Admin. The Key is responsible to set up the project and either set the calendar or work with the Admin on deadlines.

The Key should also have direct communication with the client from this point forward. A supplemental email will be sent (either by the Key or Admin) with links to upload content or join any project management software.

Daily Expectation

The key should know at any given time the status of a project, and a general expectation of delivery. They should know how many hours have been spent in the week for Webdevs and have an estimate of how many more will need to be spent to complete the projects.

They should be willing to contact a client with updates and to answer any questions about the build. Sometimes a quick phone call is more efficient to get important information or feedback from the client than several emails.

Project Expectations

All projects should meet the template milestones set in the project management software. They should be completed before or by due dates.  Keys are also responsible to troubleshoot. This is a huge responsibility and can often have serious consequences for a project. Keys are empowered via the fifth rule of ICHRON to GSD any problems.

The Fifth Rule is: The Key is always right until they are not.

The person that must answer to the owner when a project fails is the Key.  They are the ones that are putting their job on the line when something goes wrong, and they must troubleshoot it. Because they carry that weight, props, admins, webdevs, and sometimes even owners will need to defer to their decisions.

They may eventually be proven to have made a bad choice, but in the middle of an emergency is not the time to call them out. When you become part of the team you accept this fact.

Troubleshooting an issue in technology can be time-consuming. We use the iterative method: Process of elimination. Websites are complex and intertwining structures that can have many points of failure.  Trying to find a single point of failure amongst them is the needle in a haystack.  Using the process of elimination, we can usually find the issue.

There are no real “rules” to troubleshooting. It’s a combination of experience, understanding, and luck. In a crisis, you will use these attributes to begin your analysis.  A team member might “Know the answer”, but it is the Key’s choice where to start and where to go next. Keys are “right”, so they can find the problem, repair it, and move on. This process could have them being “wrong” many times before a solution is found.

End of day

At the end of the day, the Key is expected to check for new calls/emails that were missed, provide updates to the Owner or Admin, and double-check all webdevs work.

The Key should have a running list of tasks or notes for the following day. It is not necessary to update it with individual projects – it’s usually for CYA and Double checking (did that last update get done on the mockup?). Any urgent tasks or clients that didn’t get responded to at the end of the day automatically become a high priority to address the following day.

End of Week

On the last day of the week, the Key is expected to create continuity from the weekend to the week start. Too many times a weekend clears out all intentions and ambitions so that Monday is a baffling experience. Ideally, he will use the Overnight log to note an overview of the project status for the owners, and individually review each project, and have coordinated with the webdevs.