I'm Giving My Two Weeks Notice

With these words we lost our project lead and arguably the most skilled and experienced of the developers currently at the company. Losing a team member in any project has an immediate impact to both productivity and team morale. In this case, it felt like the meteor that wiped out the dinosaurs had just dropped into the middle of our team.

We had been tasked with replacing a legacy system in charge of managing the products available in our various e-commerce platforms. This was a massive undertaking, affecting at least three separate platforms and another two internal systems. With no out-of-the-box solution that could meet all our needs, we had decided to start work on our own product management system.

With no team lead however, we were rudderless and were quickly reaching the end of development on the first set of planned features. We had a non-existent UI, no integrations with our current systems, and a list of functionality requests a mile high. Some of us wanted the whole project scrapped as collateral damage of the lead’s departure, freeing us from obligation and an even more daunting workload.

But the project wasn’t scrapped. Instead I was asked to take over as lead and manage both product and team. We eventually delivered a complete project, but to this day I regret large parts of the the software we delivered and the winding path we took to get there. I’d like to share some advice for new team or project leads, in an attempt to help you avoid the guilt of a job poorly done.

Stop

As soon as the news of the departing team lead broke, all development of new features on the project should have stopped. This is a scary thing. Driven by deadlines and business expectations, stopping work, even for a day, can feel like signing your own pink slip.

After such a drastic change, project scope must be evaluated, and that can’t be done if everyone continues to work without a break. Deliverables and timelines will be affected – no matter what you might tell yourself. You might hit your original deadlines if you ignore this advice, but you’ll pay the price of long hours and poorly developed features. If you “feed the beast” by making sure everyone has something to work on now – you risk building products full of unused features and spaghetti code.

You’ll have gaps in your knowledge of the project state and various features that others are working or have worked on. Depending on team and management dynamics you might not have had any contact with product owners or end users. Without comprehensive knowledge of the product’s current and desired states, you’ll end up building something that no one wants.

Understand

You most likely haven’t been present at higher level planning meetings, or worked directly with the end users. Talking to the stakeholders of the project, the end users, and anyone who sat in on planning meetings should become a top priority. You will be held accountable for features and needs that are “must haves”, whether or not they were recorded anywhere. You have to become a detective; one that is trying to prevent the murder of a project by finding all the hidden features and requirements.

Take the time to understand what your teammates are working on (hopefully you’ve been doing this already). Look at their past work and try to gauge skill level. Learn how they feel about the project, their concerns, and suggestions for how things might continue. Skipping this means you have no way of judging which of the originally planned features your team is actually capable of delivering, much less what a reasonable deadline might look like.

A happy side effect of this research, and what is hopefully genuine listening and understanding, will be the relationships you gain with those involved in the project. These relationships will prove invaluable when it comes time to make hard decisions regarding project timeline and features. When someone knows that you understand and empathize with their unique problem, they’re more likely to consider your suggestions and input.

Learn

You’re going to wake up with nagging questions or concerns about the project – don’t ignore them. Bring them up with your team. Even if the answers are mundane, you’ve at least removed the stress of not knowing. More often than not, asking the question or voicing the concern can uncover holes in both your knowledge and in the project itself.

Find someone to listen to you as well. Be open and honest with them about the state of the project and how you feel about it. Share concerns and, if appropriate, ask for advice. Don’t underestimate or undervalue the insight that others might have regarding your work.

My last bit of advice is this: You’ve never screwed up so badly that you can’t learn from your mistakes. Take the time to look back and, like me, figure out what you could have done differently. You will become both a better developer and a better human being because of it.