How to effectivley lead and take ownership of a project
Background : I recently started my first job as a new-grad at a Big-tech company (3-months in). I was assigned a project to work on led by a senior engineer but ended up working on it independently as he was busy with another feature ramp-up, so I ended up taking all the responsibility.
Question : I've completed the design and currently a couple of months into the implementation, so there are many things that were done well so far. There are a few areas I can improve in however, and would like some thoughts there :
- The project is still in its early stages so there aren't many features. But I'd still like to keep stakeholders updated and get them excited to gain some visibility into whats being built.
- I obsess about the quality of the work / code being written that sometimes it reaches a point of decision paralysis, where I'm afraid to take action / build in new features. A lot of the uncertainty arises due to concerns about my lack of experience (which I sometimes fear could lead to sub-optimal work)
- Since I'm working on this project totally on my own, I feel things can get a little siloed (ie : I'm the only person writing code and working on this project and have just 1 person reviewing my code).
Any thoughts on how I can address some of these issues ? :)
Discussion
(2 comments)- 28 months agoSoftware Engineer @ Taro, Pinterest
The project is still in its early stages so there aren't many features. But I'd still like to keep stakeholders updated and get them excited to gain some visibility into whats being built.
It's great that you recognize the value of project visibility. You can invite the stakeholders into a Slack channel or equivalent where you can share updates about your project, ideally with screenshots/gifs.
I obsess about the quality of the work / code being written that sometimes it reaches a point of decision paralysis, where I'm afraid to take action / build in new features. A lot of the uncertainty arises due to concerns about my lack of experience (which I sometimes fear could lead to sub-optimal work)
You ideally want to try to bias on action because you'll be able to get more reps in and gain more experience quicker than if you obsess over something small. If you are a new grad that has just started, you have a lot of leeway to make mistakes. The mindset should be to move fast so you can get those mistakes out of the way quickly, which in turn allows you to ramp up quickly.
You mentioned being "afraid of building in new features". Ideally, the list of features should have been decided beforehand in a design doc. This will help with any scope creep and free you from the decision paralysis so you can just code.
Since I'm working on this project totally on my own, I feel things can get a little siloed (ie : I'm the only person writing code and working on this project and have just 1 person reviewing my code).
This might be the nature of the project. Since you just joined the team, you should try to have regular 1:1s with your other teammates to find out what they are working on. It could be a leading off point to decide what you want to work on after this project. It's also a great way to build relationships with your teammates.
- 1
8 months agoFounder of Expanded Skills • Former Head of EngineeringThe project is still in its early stages so there aren't many features. But I'd still like to keep stakeholders updated and get them excited to gain some visibility into whats being built.
Offer to host an event to present some aspect of your project. It can be a training covering lessons learned that's applicable to other projects or walking people though the journey leading up to a milestone.
Work on a 15 second pitch to cover the gist of what you're working on and why it matters. Be prepared to go deeper if people signal an interest to know more (i.e. ask follow up questions). People will often ask in hallway conversations or at the start of a 1-1 meeting. This is usually overlooked, but adds up quickly over time.
I obsess about the quality of the work / code being written that sometimes it reaches a point of decision paralysis, where I'm afraid to take action / build in new features. A lot of the uncertainty arises due to concerns about my lack of experience (which I sometimes fear could lead to sub-optimal work)
The mindset required is to ship v1 as early as possible. You want to fully close the feedback loop and the only way to do that is to put something out into the wild. If your confidence level is not too high, you can ask for feedback from others in a contained setting. Since you only have 1 reviewer just let them know which aspects you'd like them to channel their feedback towards. Proposing to get more eyes on it if it's unresolved after the initial review is natural and will get you more visibility.
Regardless you'll need a first draft to accomplish this (people are much better at critiquing something that exists vs. thinking about things in the abstract).
I love the saying "you can't steer a stationary ship".
Since I'm working on this project totally on my own, I feel things can get a little siloed (ie : I'm the only person writing code and working on this project and have just 1 person reviewing my code).
Examine what impact your work has downstream and what dependencies does it have upstream. Go 1-2 layers deep each way and you'll usually find something interesting, which is the starting point for an interesting conversation with whoever is working on that. It helps contextualize your work in the bigger picture, so it doesn't feel like you're working on an island. In an large enterprise, Big Tech included, every small component is part of a larger ecosystem.
Following your genuine curiosity and good things will come.
