Senior Engineer: How to lead a project
Some engineering projects require weeks to complete and the more senior you get, the bigger is the chance you will end up being responsible for one sooner or later. This article will give you some tips on how to organize and orient yourself in order to deliver it successfully.
Know before you go
Imagine you have to refactor a big app from a prototype-like spaghetti code into something that is flexible and testable. Imagine there are no people left from the original team and you are the company’s best bet on seeing it through. You clearly need a plan on how to break this task down into smaller pieces.
In case you were thinking about having a plan in your head — consider the following: writing things down frees up your mental capacity, structures your thinking and improves your communication. It also allows you to inform many people at once by just sharing a link, saving you time on talking to each one of them. Documents these days can also be commented on, making them an invaluable tool for getting feedback. And things in your head? I bet you have already forgotten what is the title of this article and there will be many much smaller details you’ll have to take into account in your project.
But how exactly do we write a plan? Let’s start from the initial, Overview stage.
Overview stage
Create a document and write down the Starting conditions, the Goal of the project and a list of Risks that you see. Add a Table of Contents so that the document is easy to navigate.
Think about you current state of affairs and jot it down, perhaps after dumping all your concerns and frustrations on paper, the true Goal of the project will reveal itself.
Should you still have a very vague idea of what the Goal is — consider who has a problem that you are trying to solve? What are the needs satisfied by it? Why is it necessary to act now? Don’t be afraid to iterate multiple times or to go too wide at this stage, you can start from something like “Refactor the app” and end up with “Adapt the app architecture for frequent releases and maximum stability”.
After you get some general understanding of the situation the first Risks of the endeavor will become visible. You don’t have a UI designer? Unfamiliar with the technology? Write it all down. After risks are all accounted for, we will need very particular actions that will help us to mitigate them. For example “Restore from backup” could be a valid action for a “Corrupt database migration” risk. What we will end up doing will be a very light version of something called risk management.
Now that we have our Current State, Goal and Risks set, we are ready to start answering the question “How do we get there?” in the Analysis stage.
Analysis stage
Break down the Goal into a list of Objectives, meeting all of which would mean the success of the project. Define Steps to reach each one of them, assign ballpark Estimates and the order of execution.
Objectives are ultimately an answer to the question — what does it mean to reach your goal? Personally I think that great objectives should satisfy SMART criteria. A goal like “Modernize the app” can translate into the following objectives:
- Architecture supports multiple teams working on it simultaneously
- Crash-rate is less than 0.5%
- It takes less than one hour to release a new version
- Time to market of a new features is 2 weeks
When you set your objectives well, steps you have to take to reach them should seem obvious. Outlining them and putting them on paper ideally will make you feel like accomplishing the Goal is just a question of time. But how much time? Now we’re talking estimates.
Estimates don’t have to be precise, they don’t even have to be about time you spend on a task (even though I personally prefer time estimates). Some say they are there to exert pressure on you, however it’s not the biggest reason for their existence. They are there to provide the company with a rough idea on what to tell clients, customers, partners for budget planning reasons.
To quote Joker — “ Nobody panics when things go according to plan”, so it’s always a good idea to build in redundancy in your estimates. If you would like in future to get more resources or have more freedom of action, it should be your priority to only make promises you can keep and be honest when you have no idea about how long something will take.
If your project takes weeks to accomplish anyway — there is no shame in rounding an estimate up. Think about your own sanity and well-being first — the company stands to lose much more if you burn yourself out and leave, than if you’ll be late by a couple of days.
Prioritization stage
Collaborate with other team members and stakeholders to assign priorities to various objectives. Balance the needs of the company, the team and the customer.
Any project has it’s stakeholders — people interested in it’s success. With each passing day their interests might change and so will change the priorities of certain objectives that you are trying to meet. No single person in the company truly has a full picture in mind, so you should make up for your own gaps of knowledge by proactively asking for help and accepting it whenever it’s offered.
One of the more popular models of prioritization is called RICE, you can read about it here. After you do the initial evaluation, it it’s worthwhile to take another look at your plan. Should the project be done in stages? Maybe it needs a reduction of scope? Maybe an increase? It is necessary to share your preliminary findings with the stakeholders and to keep this communication channel open from both sides. Just be careful not to overdo it. Draw firm lines between your work and your life or else you’ll be answering messages on Friday nights and you don’t want that. I hope.
Once you have your plan finalized, you can consider the Kick-off part of your project finished. Yes, it was only the kick-off part. Welcome to Iteration stages.
Iteration stages
Work on the project for a set period of time and have a checkpoint. Revise the plan with the knowledge you have obtained. Communicate changes. Repeat until done.
In high effort and high uncertainty projects things usually don’t exactly go as initially expected. Luckily for you — projects also never fail completely for as long as you learn something in the process and make use of it.
For example: in SCRUM methodology the team has regular stand-ups to surface new issues, demos to celebrate progress and retrospectives to adjust the team’s processes according to the situation. There are many books written on how to address the inherent complexity and unpredictability of software products and I would recommend you reading more on Lean Startup and Agile Methodology when you have time.
Postscript
Gather feedback from your team and stakeholders, share key learnings with everyone involved and celebrate.
Big projects are difficult and everyone knows that. Sometimes they don’t have a definitive end, merely a change of scope. Sometimes they hit hiatus and then are picked up again when priorities change. Still it is very important to put a lid on a particularly long project and don’t be shy to celebrate it like you mean it.
Have a final demo or a release party, think about everything that you’ve learned, everything that went well and will go even better next time. Tell the stakeholders and your team members how grateful you are for the opportunity to work with them and go, spread the word of your success and your learnings around to help the others to successfully reach their goals and learn from your mistakes.
The approaches you see described in this article can be applied to anything, including your personal development, family trips, business ventures and I hope you will find them useful in more ways than one.
Have I missed something? Do you have an important insight to share? Leave a comment below. I will be writing more on leadership and mobile app development, so if you like the article — follow me on Medium or add me on LinkedIn.
