5 reasons to have someone leading a project
5 reasons to have someone leading a project
Without creating a knowledge silo and alienating your team
There’s nothing more painful than starting a task, only to realize it’s blocked.
This happened to me last week.
We had discussed 2 options to release a feature. We agreed verbally on going with option A/. When I picked my task, I realized we had moved toward option B/. My task didn’t apply and we were missing some other tasks.
There are a lot of decisions made in the middle of projects.
It’s not enough to write a technical design and align it at the beginning.
The project needs a dedicated Point Of Contact (POC).
In this post, we’ll see how to have a POC for your projects to ensure a smooth delivery
👑 Reasons to have a well-defined POC
💬 Project planning and coordination
A designated POC can start communication with dependencies from the beginning.
If you push this to a task in the sprint, once the conversation starts it will block the task until finished. Instead, parallelize async communication by starting them early on.
This POC will also have the big picture of the timeline.
The other engineers are busy getting the context of each project to deliver their tasks. They can’t consider all the tasks in the backlog of this project.
With a designated POC, this engineer will realize if we are missing tasks. The POC will estimate the timeline and will track progress to ensure delivery on time.
🗺️ Technical direction
The POC ends up being usually the person who designs the technical solution.
Every project needs someone to put a technical proposal that others can review. Otherwise, the result is a Frankenstein of a project. Everybody did what they saw best in the narrow focus of their task.
Reviewing code and proposals is a shared responsibility of the team. But it’s a single person’s responsibility to take the lead in writing an initial proposal.
🔥 Risk management
A designated POC can flag risks because they have the big picture.
Otherwise, you’d just find out that you didn’t meet your timeline. You’d just find out that something broke in production on an edge case.
It’s not only about preventing that from happening. It’s about identifying that it’s a risk and making a well-informed decision
👔 Communication with stakeholders
With a clear POC, Product Managers know how to reach a team. The communication between product and engineering is not lost and dispersed across engineers.
Otherwise, requirements will come without feedback from the engineering team.
The initial requirements usually describe an ideal scenario. It's hard or impossible to achieve with the reality of the code. An engineer clarifying the requirements and providing feedback will disambiguate the project.
It’s like in interviews, you don’t jump into solving the problem directly. First you ask clarifying questions to understand the requirements and constraints.
🌱 Mentoring and support
The POC is someone to share knowledge and ramp up others so they can take on any task.
This person is the one with the most context in this particular project, so everybody knows who to ask.
This ensures the team builds their knowledge as the project advances. Everyone can take tasks and learn by doing.
🏰 Don’t jump to the opposite side
A “POC” becoming the only one who knows about the project is the same problem with a different hat.
This can provide the highest speed in the short term.
This person can work 5 commits ahead of the commit they send in a PR. This person isn’t context-switching between different projects and has the big picture.
However, the team will grow disconnected from the project, and this person from other projects. Reviews will get longer because people have no context. Engineers are not confident going on-call because the project is a black box for them.
I have seen this happening multiple times, on different people.
In this scenario, managers set up everyone into a room to do some knowledge sharing.
But sharing knowledge with some diagrams is some knowledge that doesn’t stick. There’s no better way than learning by doing. It’s more efficient to onboard people as we develop the project than trying to get them to learn from a distance.
By doing this, the team loses the short-term benefits of speed we perceived. It was an illusion.
You have to find the balance between zero ownership and having a knowledge silo. Besides the knowledge, having a single point of failure is a risk. This engineer going on vacation or leaving puts everything upside down
🎯 Conclusion
You’ll never be “right” on this topic. It’s a never-ending readjustment to balance short-term speed and knowledge sharing.
My takeaway here is to set ourselves for success by putting some constraints.
Assign a POC for a project and get all tasks to the sprint unassigned so everyone can take anything. With these conditions, adjusting direction is briefly touching the steering wheel. But you won’t need a 180-degree turn.
Everyone understanding all the projects. Everyone feeling entitled to pick any task in the sprint. Everyone being confident going on-call.
This may sound idealistic but it’s the vision we have to work backward from.
🗞️ Other articles people like
👏 Weekly applause
How Facebook Scaled Live Video to a Billion Users by
. The hard part is not making it work. It’s making it work on many devices with different network bandwidth and in all locations of the world.How this Googler Got the Highest Rating Twice! by
and . No matter where we are at our career, the next step will be a challengeTimeless skills in Software Development by
. Technology advances and changes. But there are things that won’t change. That’s all about human collaboration
Thanks Fran for sharing this, I never heard about this role before.
So basically, have someone oversee the development both technically and and how it's connected to other parts of the system. Also raise concerns for other teams if your team has dependencies, but don't do the work instead of them?
If I got this right, we have a POC on our project, or more of them. 😃 It looks like it's split between our Team Lead and his Manager, but we're a much smaller organization than Amazon, so I guess that makes sense—if POC roles can be split.
When no one leads, the dots aren’t even connected. Everything is just swinging in the dark. It sucks so bad to be in that situation. And it is even worse when actual leaders are prevented from actual leading, forcing what would be high performance teams to feel like total failures. It is important to have good leadership. Poor leadership is a nightmare.