Background
When discussing the work I do as a Director, I often like to tell the story about my biggest undertaking to date: Smartsheet team management. While it’s not an example of my work as an individual contributor, it demonstrates the challenges and growth I’ve experienced as a director and supervisor.
Where we started
In 2018, I earned a promotion to Associate Director of Instructional Design at Columbia University’s School of Professional Studies (SPS). Previously, I had held different roles in that unit but none were related to leading this team.
Our team had previously had wonderful team leads. As we scaled up, they came up with different ways of keeping track of projects and contracts as they came in.
Our previous directors even had whiteboards that tracked requested instructional design development several quarters or semesters ahead.
However, as a new team lead and co-director, I had to determine the next steps for moving forward under the new constraints and opportunities. Some parts of our process were inefficient, and we would lose a lot of institutional knowledge when someone moved on to another role. If we lost a post-it or a notebook from a team retreat, panic would ensue.
We knew we’d be responsible for supporting, developing, and accounting for a larger batch of courses as the team grew. We had to figure out a way to understand the team’s progress and delays without looking like this whenever a contract came in:
Phase 1: Discovery & empathy
In my new role, I led a process to unpack the real issues holding our productivity and data management back. I began a set of informal listening tours with our current direct reports, all instructional designers (IDs). I set aside a good portion of our weekly 1:1 check-ins to learn more about their issues and their methods for keeping track of their projects.
Throughout that first phase, I made an effort to learn about the pain points and different working styles of my direct reports. I advocated for them and took note of the most frustrating elements of our jobs, knowing that it would impact which solution we’d choose in the end. Having served in their roles for many years across different organizations, I had an idea of what it was like; they had many stakeholders, were required to provide customer service, had to account for each assigned project and their respective deliverables needed to serve as technologists and media supporters, and manage multiple projects and deadlines simultaneously, among many other things.
But relying on my experience alone would only lead us to a solution that worked for me, but not the entire team. It was important to learn about the current needs of an instructional designer, perhaps covering experiences that I had not encountered myself. The information I learned in the next phase would greatly impact our path moving forward.
Phase 2: Set the stage for change & research solutions
After gathering information about their working styles and observing some instructional designers in meetings, I began whiteboarding different methods of tracking course projects. In my brainstorming process, I saw many instructional designers aligned in several aspects and were already successfully using cloud tools to manage their work. They had many of the same pain points and worked through those in similar ways.
They all seemed to use milestone tracking in some way shape or form but differed greatly in their methods of documentation. To begin, we asked direct reports to store their documents on the cloud (Columbia’s google suite, LionMail) instead of on their local computers, since the solutions we would explore would leverage cloud storage. Though we asked them to make that adjustment, we told them to change nothing else about their behavior for a semester. My co-director and I mentioned to the team that we would only change/test one thing at a time. We told them that we’d be relying on them to help us try out different tools based on their feedback and encouraged them to stress test the tools with us.
After surveying a few different tools and vendors, we landed on Smartsheet as being the foundation for the communication and project management system we could use. It integrated with all of our current cloud systems and we had an unused license. Using an unused license allowed us to leverage our current resources without impacting the budget. It also required little to no training for our team since it looked and acted like systems they were familiar with and it allowed me the flexibility to serve as the primary developer for the initial rollout.
Phase 3: Prototype, pilot & reflect
So I asked Instructional designers to pick one project to track on Smartsheet, while the rest of their projects could be tracked/managed using their preferred method.
After one semester of piloting, we asked the instructional designers to give us another round of feedback about their experience and the tool. The feedback this time was positive, with a desire for some additional features to make their lives easier. I asked our senior IDs to help with gathering information from the team and summarizing recommendations for me to code and implement for the next semester.
Technical specs
It’s important for me to note that a lot of this required me to learn new programming languages. While I had some experience with excel formulas, Smartsheet used different syntax and data management protocols. My promise to others, including those in senior leadership, when making the “ask” for this tool was to guarantee that the process would make it easier to provide help where it was needed most.
That means individual contributors would be able to manage the data and deliverables while the system kept track of the statuses and communication system. But moving from granular tracking to a 10,000 FT view within one system was not available with our license or even a feature offered by Smartsheet at the time. After researching Smartsheet developer libraries and coding communities, it was apparent that I could code out this logic to make the sheets work for both team leaders and instructional designers.
In all of our project templates, I coded different types of logic to help automate the management of the sheet and the system:
The logic that I coded helped shift much of the project management responsibilities onto the system, allowing IDs to focus on the relationship management and the “people” side of their roles:
- The logic was coded to determine if a deadline was missed.
- The logic was coded to mark a project as “slightly delayed” or “at-risk” based on the total number of missed deadlines and the remaining time in the project contract.
- The logic was coded based on feedback from the instructional designers.
- The logic used objective calculations to determine if a project is falling behind (i.e., if 20% of the project is delayed, the system will flag the project as delayed).
- The logic used functions that could notify a director/manager if a project falls behind (i.e., if the project is still missing milestones but the end of the project is fast approaching, the system will notify the project lead and manager).
- Sheets were designed to allow for private conversation channels between Director and direct reports.
Current day: Seek to Improve & Repeat
Learning how all of our data overlapped and determining how this data could be filtered up was just the beginning of a very long and iterative process. We improved on our process each semester. Over a year and a promotion later, I became the primary director of the team. By the end of 2019, we began using this system exclusively and have provided project management services to external units as well.
We have reached a point where our system runs smoothly and it can operate at scale. Each semester, we have enough data that we can create visual dashboards to tell the story of our team and summarize the crucial work we did for the school.
These dashboards from our Smartsheet project management system are the ones I used during strategy meetings, external team meetings, and quarterly reviews.
Conceptualizing, developing, and prototyping a solution for our team was not a short process; it involved several rounds of improvements, interviews with numerous stakeholders, debugging conversations, and securing buy-in at different levels. Additionally, the process taught me that even with the coding skills to develop a product or solution, the most important skills were my abilities to build trust and manage change. I had to build trust across my new team and with my new supervisors as I worked through the ups and downs of implementing a new process and set of tools.
In the end, I am grateful that I had trusting supervisors and supporting team members to help turn our ideas into a reality. While it was the biggest undertaking of my role during a time of change for my team, I know that I couldn’t have done it without their support.