We cannot stop disasters but what we can do is to avoid or prepare for one.
Working closely this quarter with different projects and teams has gotten me into a new routine, thrill, and reflection. Projects on their own have different features and ideas that get pushed into releases each week, ideally. Teams on another hand, work on their target goals per week, and individuals under it want to achieve something on a daily basis. In between this repetitive course, we encounter some hard blocks that put a project or team to a test. A project’s survivability depends on how resilient we are in dealing with issues and reflecting on what needs to be improved for a better next release week.
Below are some things I’ve seen throughout a project cycle that hinder it from getting pushed to business expectations.
Transparency – when working with developers they tend to be robotic: take a task card, develop, test, push, approve, check, move card —> boom done, no extra words needed right? Fast and efficient. Here comes the hard part of our introverted pattern: the more you grow into the role the faster you do things. Now we need to slow down again and do things we usually avoid like documentation, writing steps, talking to peers/seniors, communicating with other teams. Communication throughout each thing you do is really tedious to squeeze in when you’re in the zone, but it makes the process more transparent and how you did things gets more recognized, it can also be acknowledged by team members which in turn gives a morale boost to how efficient and strong you are as a core team member. So communication in form of writing and speaking can really help push and see the commitments of a person into a team or project.
Overcommitment and Under-commitment – as developers, we tend to overshoot our goals sometimes, I mean that’s not a bad thing to be optimistic and think of better ways ahead but that’s a lot of energy and time wasted on something that might be rejected. Under-committing, on the other hand, is a much safer road compared to overcommitment since it gives you that small increment towards bigger targeted goals. To keep it simple just have something compact then ask for feedback and then work again on another batch of increments. Clarified goals and making it smaller / simpler for an easier push (the same applies to PRs).
Let it be & technical debts – now above we mentioned to keep things simple but on that account we do acquire technical debts from time to time. We let things be for now and process what we can move forward to in the meantime. Hence, these technical debts accumulate over time and people do tend to forget about them until those debts create a ripple on the entire development process. The best way to address it is to list and discuss it on a weekly basis, review what you have postponed at the moment and reprioritize it later if it still has no impact on the current and next phase of release.
Too Focused; Less Attention – while team members are in their zone routine, they often get stuck on one thing every now and then. That’s why communication is important for them to address the issues that block them from their progress. A lead role must also take an initiative to unblock these members and address it better instead of saying “let’s just focus on pushing this thing right now” when in fact it has been dragging someone for days/weeks. There may be core processes here like data analyzed improperly or flows that aren’t getting through one another, bigger scope, unforeseen impacts, etc. If something is drawing too much time on a core member without getting any progress then it’s better to sit and give it attention as to what really is happening in it that needs to be addressed.
No Compromise is a Compromise – team negotiations should be part of the process. People tend to just take everything that is given to them only to realize later the issues they face when something is already in development or close to production push. So in the early stages of planning, it is better to give some feedback and thoughts on how a release or feature gets implemented. It’s okay to say we cannot do this but let’s just do it this way instead and present better ideas if you see something that will hinder your goal targets. Accept feedback and give feedback because silence in a team is deadly.
Who do you call? – identifying roles in the team is very crucial especially if you have juniors inside these team setups. Juniors rely mostly on senior or lead roles for major decision makings and getting approval of their PRs. Establishing a fallback lead role if the main one is not available also helps to get these new guys settled in faster so they can just work their way up the ladder with how they communicate concerns, issues, clarifications. One scenario that happened was that the lead role was not around and neither was the line lead, so the data structuring got stuck with juniors and mid-level. Decisions were not happening in the team immediately so it blocked major progress to the release. It’s definitely better to set a fallback person into teams if ever they run into situations.
Red Light, Green Light – with all blockers happening across releases much like in the popular Netflix series (Squid Game), green light makes the releases move fast. What happens in between blockers is a red light in team personnel, and if nothing moves when something is blocked that’s a dead spot for a release. What we should do in blocking states is having a nonfunctional to do tasks, improvement work or having personnel do sub work on another project. That way some movements are done incrementally across boards and behind releases that will improve later on implementations.
With all pointers listed above, these are just a few that we’ve experienced and thought of in this quarter’s retrospective. There is still a lot of room for improvement on how we handle teams/projects and despite having setbacks and overhead in each development-release cycle we always reflect on it and improve our workflow for the next cycles to come. Change is inevitable, so it’s good to have reliable teammates as we face the quarterly challenges.
More from
Management
Challenges of remote hiring
Jade Wahiman, HR
Resiliency vs toxic positivity
Jade Wahiman, HR
Dare to Suck
Omar Parvez Khan, Venture Partner