Powerful Reasons Why Goal Setting Is Important
12 October, 2021
When I was at the Institute for Disease Modeling, I managed a team that owned multiple domains:
- Web apps team
- Internal tools for research scientists and
- Data Services and Data Science Pipelines.
I had difficulty driving forward work quarterly with so many different priorities and daily interruptions.
Another obstacle that we faced was, we were responsible for driving forward work that would support multiple research scientists such as workflow tools and interactive dashboard maps, and these projects were vague and complex. For example, we had research scientists that wrote code in Python or R, and they needed a way to run their code on the cluster. In order to do this, we needed to be able to create Docker images with all the packages or libraries required to support running the code in either Python or R.
What I did to solve this was, I worked with my teams to define quarterly goals to define specific milestones and measures. To do this, I built relationships with each of the research teams and was able to identify straightforward projects. We all had quarterly goals that those research scientists had to meet because we had to present our research quarterly and reach specific milestones monthly in order to meet these deadlines.
For example, I identified three different research scientists with three different projects, but they were trying to do similar things. We were able to build a prototype to create a solution that worked for all of the projects. At the end of each sprint, the research scientists could do something with what we were delivering. They were unblocked, and their actual work was able to move along faster. In the past, the software engineering teams would have six-month-long projects and weren't able to deliver features that were usable by research this quickly. This new approach worked well.
On our goal pages on our wiki, we had milestones and our tasks were tracked in GitHub to complete these milestones. This way, through the week to week, we worked and drove towards our releases. When the team did a release, we delivered it to the research scientists. There they would be included in the feedback loop as they were part of the testing. They started thinking about whether this feature did what they needed to do and whether it was easy enough to use. We iterated on it and waited for them to give us feedback. Then we would add additional tasks to make it a lot more streamlined for them. At least they had something they could get started with instead of having to wait for support for their workflows.
The team brought up the challenge of being able to support all three projects at once. So I helped them dive in to understand all project needs, but identify priorities. The priorities depended on where the research scientists were in the process and the research they were doing. One scientist was further ahead; he needed help immediately, so we prioritized it in that sprint. The team broke out tasks to tackle different parts of the solution. The whole team was working together. One person was more responsible for the front-end work while someone was for the back-end work. When figuring out how to solve a particular challenge that blocked the team, I paired team members to work on it together. I found that sometimes when people were taking more extended time, they ended up needing more help. When they worked together, they could complete work faster and then break off to continue their other tasks.
- Set goals: Instead of imposing a top-down approach, include your staff in goal setting as much as possible. This method originated from one of my team's tech leads, so I attempted to collect as much information as possible up front, such as establishing contacts to find out who might utilize this as a significant help. The leads gave me positive feedback on this approach that helped to speed things up. In the past, we usually did not operate this way. Having the use cases needed to develop code sooner speeds up the process. Goal setting has a positive impact on the team's ownership and engagement. They understood who they were doing this for, why and what exactly they needed to do, and the end result.
- Prioritization: There was a point where I had three people all at once wanting our support. How do we figure out who we first start with because we cannot do it all at once? The team found it helpful to see all three use cases at once because it helped drive the design decisions. Then, once we understood the requirements, we needed to prioritize the research scientists' particular projects to automate and where to focus our efforts.
- Workflow: We were able to automate the workflows for each research scientist more quickly. The team felt the impact we were making with much more effectiveness. They felt and understood that we had unblocked the research scientists to continue their critical work and speed up their workflows. What took weeks for them to run their pipelines, now took hours. They knew that people would want to come and use it because it worked. They did it much faster than they initially thought. It was projected to be a six-month project and ended up being done in two weeks, and then adding on additional requirements and features from there. With bringing on the first three research scientists' workflows, we figured out most of the requirements and already figured out all the pitfalls we possibly would hit. We met most of the conditions that anybody needed for this whole workflow to work.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.
Site Reliability Engineer at Skillshare
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.
Adi Purwanto Sujarwadi
VP of Product at Evermos
James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.
Head of Product at BT
Albert Lie, former Founding Engineer and Tech Lead at Xendit, shares his annual performance review process implementing principles from the Ikigai framework into regular check-ins.
Former Tech Lead at Xendit
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.