Chaos. My first tech job was at a great startup. It was fast paced and exciting, lean and mean and sometimes clueless about getting their act together. It’s a startup, doesn’t that mean chaos by definition? There were many hurdles to overcome. Aside from raising money to keep the boat afloat, there was a product that needed defining, features that needed polishing and ideas that needed to be propelled from conception to execution. One of the interesting challenges was getting all of the teams in sync to release a feature. Even after the feature was well defined, things often took more time than expected to reach the users. A typical example would be a case where Product planned a new feature, then handed it off to Mobile, who needed assets from Design and support from Server. Mobile time estimate for development: one week. Actual time taken until the feature was ready: five months. Why? What took so long? I don’t know how I feel about a Freddy Krueger Lego man Well, Design was busy preparing a deck for the next round of funding and Server was implementing a new storage mechanism. Three weeks later, Design completed the UI assets. Two weeks after that, Server began implementing the feature. A week later, Server and Mobile began integration. Bugs were found and fixed. Product got a version to review, and wanted some UX changes. QA got a version, and found some functional issues. More Mobile and Design time required. However, Mobile was now working on a bug fix sprint for production crashes. Design was redoing the website for a makeover. Two weeks later, Mobile implements the code changes. Integration with Server is now broken and requires more work, however Server is refactoring and using a new platform which is trickier than estimated…. Okay, you get the story. Problem: Not all of the teams had the same priorities. Solution: Make all of the teams have the same priorities. There are many ways to address the issue of getting all of the teams in sync, but I’m going to focus on the approach that we adopted for a while: feature teams¹. What is a Feature Team? Everything is Awesome! With some inspiration (and desperation), our founders decided to try an experiment: Define a feature (or topic) Form a mini team by choosing a person from each platform needed to complete the feature Assign a leader Put them all in a room together Give them a silly name and t-shirts (optional, but recommended) Let the magic begin! The proposed new workflow was meant to align the relevant players and make sure everyone was working on the same thing. Having all of the team members physically sitting in the same room made cross platform communication seamless and also made it possible to make changes quickly. There were individuals who weren’t assigned to a feature team who remained in their “home base” to work on non-feature specific tasks. Designers were scarce so they also weren’t assigned to a specific team, and they divided their time according to the urgency of the proposed feature (or the team lead they liked the best 😜 ). Our Motley Crew I was chosen to be a feature team lead. My team had two iOS developers (one of them was me), an iOS QA engineer, two Android developers, two Android QA engineers, a server developer, a product lead, and a data scientist. We had our own daily standups and worked together to ship the features as best and as fast as we could. It was an exhilarating time. We moved fast and created things. We had more opportunities to influence the features we worked on. We had open channels of communication with people on teams that we previously hadn’t had much to do with. We had a little more autonomy and flexibility with our tasks. We cut through a whole lot of bureaucratic red tape and shipped quickly. Granted, there were hiccups. Some feature team combinations worked better than others. There were a few people who switched teams after we started (yay! I got another Android developer!) but overall I think that the experiment proved itself for the stage we were at. Personally, I identified with the concept, and enjoyed being a feature team lead very much, despite the added pressure and responsibility of managerial tasks. I remained very hands-on and was responsible for delivering my code, along with leading and coordinating a group of talented individuals. I experienced a true sense of ownership for every feature that was shipped. I definitely felt that there was far less friction in getting things done. I had direct access to everyone and was able to effectively remove blockers. At some point, the feature teams were disbanded and we all went back to our home bases (iOS FTW!) to focus on a very different company wide effort. (Did someone say pivot?) Experiment complete. My verdict: . Success Faster. Fearless. Feature Team. Startups need to move fast and be disruptive. The unplanned delays caused by features not being shipped on time have the potential to tank a company. One of the great things I found about working in a young startup was the flexibility of the rules and workflows, and the willingness to try something new. Will the approach work for everyone? No. But then again, does anything? Also no. These are some concrete scenarios I can think of that would disqualify the option of feature teams: Workspace limitations, such as a cubicle farm or tiny offices or any constellation that doesn’t allow people to sit together comfortably and collaborate. Manpower limitations, such as a team with only one product manager, one backend developer and a dozen front end developers Lack of management material, for a team with no leader is just a herd of potential, headed towards nowhere Product limitations, such as working on a project which doesn’t lend itself to being divided into small units of defined work Strong opinions, strongly held, by the decision makers in the company, who refuse to try out something unfamiliar I’m sure there are many others, but those are enough reasons of why trying the feature team paradigm isn’t always an option. In my opinion, the concept of having a feature team where all of the stakeholders work together makes a lot of sense. I don’t think it’s necessarily the right answer for every type of company, or every stage of a company, or even for everyone in a company, however it certainly proved to be an effective way of getting all parties simultaneously focused on the same goal. It’s important to keep adding tools to your workflow toolbox, and the idea of feature teams might work for your situation and be a powerful tool to help you and your team get your ideas to production faster. Hopefully, this has given you an idea or two! Go forth and create. Beautiful Production Features, Built in Harmony

Harmony

How to Get Everyone on the Same Page

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Top Differences Between Tags and Branches In Git You Must Know

3 Habits that Stifle Product Execution According to a Product Expert

A Guide to Minimum Viable Products for Fractional CTOs

Beauty Has Been Destroyed by Usability

Cross Functional Collaboration and How to Handle its Challenges

Top Differences Between Tags and Branches In Git You Must Know

3 Habits that Stifle Product Execution According to a Product Expert

A Guide to Minimum Viable Products for Fractional CTOs

Beauty Has Been Destroyed by Usability

Cross Functional Collaboration and How to Handle its Challenges

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps