A day in the life of a MojoTech Project Lead
MojoTech, like most companies, has the concept of a Project Lead. Initially, I wasn’t sure what to expect when I took on my role as Project Lead, so I’m writing this post to shed a little light on the responsibilities and expectations of the role, as I approach them. Typically my morning and afternoon look the same, so to avoid redundancies, we’ll take a look at a typical morning schedule.
The first order of business when I arrive is what I call “the rounds”. The rounds start by reading any unread emails I’ve received. I’ll sort any new tasks by priority and continue to the next stage of the rounds: pull requests. At this point, I’ll take a look at any open pull requests from the previous day. Simple ones that are less than fifty lines I’ll review on the spot, anything larger I’ll add to my morning task list. Finally, I review the tasks for the current sprint for accuracy. I’ll usually make the rounds twice daily. Once in the morning when I arrive, and once after I take my lunch break.
The rounds serve two primary purposes: the first is to bring my thoughts back to the project context; the second is to keep track of the pulse of my team.
After I make the rounds I’ll start checking things off of my morning task list. Time spent on the morning task list can vary between five minutes and all morning, usually depending on how much code review is necessary. As soon as I finish I’ll start work on a sprint ticket.
From this point until lunch my day looks like most of the other developers on the team, except that I usually have more frequent pauses. There are three reasons why I pause active development. The first is standup meetings. This happens regularly every day and is our primary way of communicating our progress to clients. My role during standup is to make sure everyone stays on point and the meeting doesn’t last too long. Anything longer than fifteen minutes is generally too long.
The second reason I pause is to respond to requests for help. I make a point of making myself easily available to answer any questions, provide advice on how to approach a problem, or act as a sounding board.
Ideally, I try to guide my team to a solution rather than hand it to them outright.
The final reason I pause is for client communications. These range from bug reports to requirement changes, and I try to deal with them as promptly as I can.
The two most important sprint processes for me are sprint planning and ticket assignment. Sprint planning is where we gather requirements and formulate tickets. Ticket assignments I do over the course of the sprint and involves matching tickets with developers. I’ll explain both of these processes in more detail below.
The primary goal of sprint planning is to go over any new requirements from the client and schedule the work we commit to for the next sprint. There’s usually a lot of discussion at this meeting. Part of my role is to figure out where the requirements are unclear or incomplete and clarify them. This is much more difficult than it sounds. I need to formulate good questions to the client that maximize the amount of clarity gained from the answers. Sometimes I fail at this and we end up wasting time. Even when this happens, however, I learn something valuable regarding what works while communicating. The other part of my role is to explain tradeoffs and technical ramifications to the client.
If a feature or solution can be implemented multiple ways I help the client to make an informed decision by making sure they have as much information as possible.
After we’re satisfied with the clarity of the requirements we stub out the tickets, estimate them, and commit to a certain amount of work for the week. Throughout this whole process I’m taking notes, and I use those notes to flesh out the stubbed tickets later with any relevant information.
Assigning the tickets we create during sprint planning correctly is very important. This is contrary to normal Agile methodology, however I’ve found it easier to optimize for team efficiency, morale, and growth to assign some tickets to specific people. I have several factors I need to optimize when assigning tickets. At this point, I don’t usually optimize for sprint completion. If we did sprint planning well we should have accounted for any variance in developer speed. Primarily, I optimize for learning opportunities. At MojoTech, we place a lot of value on developer growth. >A big part of growth is having opportunities to grow, so I’ll try and make sure that each developer gets, at least, one ticket that’s out of their comfort zone each sprint.
I assign tickets continuously as other tickets are finished. This leaves room to react and change priorities if something goes wrong.
As the project lead, I prioritize my team’s growth over my own. I’ll often take the menial tasks so that my team can tackle the more interesting problems. This also leaves me relatively free to step in where needed and help solve those problems or pick up any slack if something goes wrong.
It can be surprising to learn that I don’t do as much active development as the rest of my team, but I’ve found that on my current project I spend about half of my time on active development and the other half is divided between interfacing with the client, mentoring, and the various other tasks associated with managing the sprint and team.
While I miss the development at times the other responsibilities often make up for it. Mentoring and watching your team hit sprint after sprint is a fantastic feeling!