For 2 years, I worked in a small startup with a team consisting mostly of business and development positions. Despite numerous requests, a project manager was (understandably) not within the budget. So the team had to make do without one, and it went surprisingly well! Contrary to what project managers might have you know, the show goes on. Here’s how we made it work.

Take Ownership

Be your own project manager. In the absence of a dedicated person to ensure you stay on track, you have to be at the top of your organizational game. That does mean trade-offs will have to be made — managing tickets and such requires time that can’t be spent programming.

It helps to distribute responsibilities around the team to spread the additional management load. If your team’s work is split up into several repositories, for example, each can be managed by a different person. Alternatively (or additionally), let different people be in charge of leading meetings such as daily stand ups or sprint planning / review meetings.

In any case, you need to take ownership of your work (depending on your work environment, you should probably do that anyways), which, among other things, can manifest itself in the form of the followings points in this post. When you take responsibility, you become the go-to person / specialist for the area / product you’re managing. This will create clear lines of accountability and help you and your team stay organized.

Expand Your Horizon

When there’s nobody to plan features out from start to finish, that task will fall onto your plate. This holds true in more senses than the purely technical one. Think about additional perspectives beyond a ticket’s description: Usability, Performance, Cost, Tradeoffs, Use Cases… Question everything, including, if a feature makes sense for the company as a whole.

In a competitive startup scene, there is rarely space for hierarchies to overwrite the greater good of a company, and you shouldn’t withhold questions or criticisms simply because they’re aimed at a more senior person. There are almost always many, many more parts to crafting a product or service than to just make something that’s technically functional. The more time you spend thinking and talking about these, the better your initial approach will be, and the less room for unexpected issues or follow-up requests you leave.

Plan, Plan, Then Plan Some More

As with other parts of this article, this applies to areas beyond software development: More upfront planning means less fixing and refactoring after the fact. I’m talking flowcharts, UML diagrams, sequence diagrams, user stories, and talking about all of these with your coworkers. Don’t fall prey to the instinct of being too attached to your work, though (try googling sunk cost fallacy).

Everyone should be encouraged to ask questions and raise issues so that flaws are identified and removed or designed around. If you need to redesign a feature from scratch, try to do it before it was released to production. And please don’t take criticism personal — you’re all working towards the same goal. You will not be doing yourself or your company any favors by being someone who can’t deal with negative feedback professionally. But then again, you already knew that.

The Devil Is In The Details

This essentially just reiterates previous points, but you need to keep your tickets updated meticulously. Especially in small teams, there is less room for redundancy. If your tickets are out of date, you run the risk of someone else doing work they don’t need to, or worse, shouldn’t do. Go the extra mile to check that a ticket’s acceptance criteria match expectations — discuss them with your coworkers before booting up your IDE of choice.

Patience And Speed Are The Key

That might sound contradictory, but hear me out. Things won’t always work smoothly. Small teams in particular stand out not in their ability to accomplish tasks perfectly the first time around, but by being flexible, able to learn, and pivot very quickly. If that feature you’ve spent a day / week / month implementing is not helpful for solving a problem your company cares about, then don’t be afraid to rework or scrap it completely.

Since this is bound to happen at one point or another, you may want to invest some extra time modularizing your architecture so that, when you need to, you can easily switch out one part with a replacement without needing to make system-wide changes. There are a bunch of ways to achieve that such as using a microservice approach and favoring dependency injection over inheritance to decouple your codebase. Following well-established best practices in software engineering is worth the extra effort and will save you resources and nerves in the long run.

Showcase Your Solutions

Finally, there’s a good chance your coworkers are somewhat removed from the details of your solution. It doesn’t take a lot of time and effort to prepare a few slides highlighting your approach, implementation, and most importantly the ways in which your work helps solve a problem for the company. Likewise, pay attention to what your coworkers are presenting. By reviewing the entire process with your coworkers, from design over development to release, your team will grow as a whole.

Photo by Jo Szczepanska on Unsplash

Powered by Froala Editor