Powerful Reasons Why Goal Setting Is Important
Software Engineering Manager at Curative
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.
Be notified about next articles from Mary G. Fisher
Software Engineering Manager at Curative
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.