Feature ownership — a more efficient way to bootstrap new developers
No matter how promising a new role looked, I was never impressed with the first few weeks on the job. That was until Photomath, where I was greeted with Feature Ownership.
I would usually be given a brief intro to the team and would then be left on my own to explore the never inviting new codebase. There I would exercise in recognizing patterns in unfamiliar object-oriented landscapes, hoping to find some I could later apply. I would do the same with new colleagues, but that task is far more non-deterministic in comparison. They would assign me introductory issues to ease me into the project. Those either inhabit unsavory parts of the code that no one dared touch in years or are so inconsequential that others never bothered to solve them. Other times they would define my task in such great detail that my solution required no engineering prowess of my own.
On stand-up meetings, I would listen to struggles and achievements of others and could not partake in decisions or the excitement. To add to the feeling of isolation, they would sometimes assign me work on a forked git repository, so as not to contaminate the real project with my rookie contributions.
I suspected the companies never hired me for who I was at the time, but rather they were counting on the arrival of my future self: that is the familiar colleague they expect, want to work with and can rely on. But do we really need to wait? Is my present self really that unreliable?
Despite my cynical expectations, my arrival at Photomath as an iOS developer was a little different.
Very early in the introduction period, I was given a full feature to work on and it made all the difference. I was assigned work on a new UI-heavy feature of creating the interactive slider for our Animated Tutorials. They gave me a specification, outlining the end goal, but not the full blueprint of how to get there. Rather than just follow along, I was encouraged to improvise and create. I partook in prototyping, discussing and redefining of the feature to make it not only simple and fun to use, but also technically viable.
This proved really engaging, as I wasn’t put on the sidelines and was actively working with people from other teams to tackle the challenges. I also quickly got to meet my work environment, which proved incredibly helpful in the current remote work / covid climate.
And after a lot of back and forth, scraped implementations and multiple attempts to decipher the lacking Apple documentation, my first big ticket was resolved and a new chunk of code was contributed to the project — one that I felt proud to be a part of.
And so the vast unexplored codebase became a little less scary, and the foreign workspace a bit more familiar. Having that initial challenge solved I was ready to tackle upcoming work with a bit more ease, feeling more like a contributor and less of an outsider.
That’s not to say I made no mistakes along the way, but my team was fast to correct me. For instance, my teammates’ remark that “done is better than perfect” was definitely warranted. I also made an error by using two separate touch event APIs that I shouldn’t have (thanks again Apple docs) which luckily introduced weird side-effects before the feature was public. But I am glad for those mishaps, as I am now better suited to avoid them in the future.
Why Feature Ownership Matters For Onboarding
- Newcomers begin to contribute and cooperate with other teammates sooner
- Experienced developers appreciate a high-stake challenge as it reinforces the belief their work is significant
- More engaging learning experience, learn by doing instead of learning by reading code someone else wrote
- Good opportunity to assess a developer’s abilities in the new work climate
But the benefits of FO don’t end at introduction. Feature ownership is a viable strategy throughout the lifetime of a project. It is impossible for one person to know all the intricate details of the work being performed by multiple programmers over an increasing span of time, so decentralization is inevitable.
The team needs to have competent people maintaining specific areas of the project, so allow your people to fill that position from the start. And if they aren’t yet competent, build them up. Feature ownership is not the sole way to achieve this, but it is a good start. You should encourage people to think for themselves, speak for themselves and take initiatives. If you want your projects to be bold, give your people a bit more freedom and allow them to be bold. And narrow-minded leadership can be damaging for the people as well as the project as a whole.
But what if it doesn’t work?
If something doesn’t work we want to know about it as soon as possible. This is the application of fail-fast methodology to development and it translates well. Also, the best way to get to know a developer is to challenge him and see how he manages. This way you can assess his abilities and his overall level of reliability sooner. If the worker is uncomfortable working alone, you will learn how to better utilise him in the future. If he needs more training in a field, you will sooner know to give it to him. If he exceeds in a specific area, you will know where to deploy him. The new guy is surely eager enough to bring his best so why not use that to help your project?
And he isn’t the only one that benefits while doing so, everyone around him is learning as well. The new worker can bring in fresh ideas that can make you re-evaluate and update your current decisions and processes. Its not only the future colleague that will now be met sooner, it is your entire future team as well.
Things To Be Vary Of When Separating Responsibilities
Feature ownership does not equate full code ownership. Even though we have separate responsibilities, a team is still sharing a codebase and should be sharing knowledge. A feature owner should not work in isolation and should not be the only person that understands how his code works. That’s why we at Photomath put emphasis on quality code review and take our time to introduce new work to the team. This ensures others have an easier time jumping in and fixing bugs when they inevitably occur.
You should also be wary of long-term ownership, as people don’t want to be known as a one problem solver. Experienced developers will want variety in their job and the opportunity to tackle new challenges. This is why it’s important (and my team does it well) to listen to the developers and assign their work appropriately. To mitigate this problem, you could also use a more structured approach: rotational ownership or even paired programming on bigger issues, hardening your team in the process even more.
And this is obviously not a strategy that fits every project and every employee. High level ownership is impossible with people who are complete beginners in a given technology and is risky when done on a timeline driven project. But even then, try and give your colleagues a bit more accountability soon and you might be surprised with the results.
Feature Ownership Is A Win For The Employee and The Employer
Feature ownership as a bootstrapping method is working great for us at Photomath and we encourage you to try it for yourself. I propose to give your new developer a responsibility and enough breathing room so he can contribute to your project as an equal member of the team from the outset. In this way, he will have a more engaging introduction experience and he will get accustomed to the environment faster. You will also get to evaluate his strengths and weaknesses sooner so it is a win on both sides.
Feature ownership can be used for the entire duration of the project, but you must be willing to develop a working strategy to implement it properly and find a variation that works best for your team.
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” — General George S. Patton.
I hope I convinced you to put more trust in your coworkers and give early feature ownership a try. If you have a different strategy for bootstrapping employees let me know of your approach in the comments. And if you are the sort of individual that is fond of taking on responsibilities and is eager to help millions of people solve math problems — check out our careers page.
