- Automate your CI/CD pipeline. Saves a lot of time on manual work and allows your team to release multiple times a day.
- Use a monorepo. That will keep things simple, organised and transparent within your startup.
- Break all features into small, incremental changes. That enables early feedback and reduces the chances of a big failure.
- product team should break work into 1-2 days tasks
- engineering team should push their changes daily
- Use feature flags.
- engineering team won’t have fear to deploy
- you can roll out features to a beta group of users
- you can gather feedback from your team and external users faster
- you can run a/b tests and perform experiments
- Define product and engineer owners for every feature.
- to avoid shared responsibility and delivery delays
- to encourage personal responsibility and unlock all talents of your team
- Request at least one demo per week. Motivate your team to share their work early, so you can discover bugs and provide feedback before too much time spent.
- prototype → preview → beta → production — these are four demos you should ask your team to record for every feature
- every feature team should record 1-2 demos every week
- Deploy weekly and follow simple CI/CD process.
- use single branch (develop) for all development, deploy to test environment on every commit
- merge develop branch into main once a week to deploy to production
- Freeze the code before release.
- helps your QA team to test changes and ensure quality before production release.
- Don’t write many tests if you’re early stage startup.
- tests are great in the long run, but can slow you down in the short run.
This was my question since I was promoted as a Manager couple of years ago. As a person who don’t have much managerial experience in his career, this transition was confusing and overwhelming at the same time. It took me some time to figure out the messy situation I was in. As a copy – paste software developer, my initial instinct was to google my role and responsibilities. Well, there was no copy-paste model for a Manager and it sucks.
So below I list some of the items I learned as a Manager over past few years.
Father / Brother / Sister
As a software developer you always think logically ( Sheldon from Big Bang Theory), but as a Manager you need to think logically and emotionally ( Kid born out of Penny and Sheldon).
I was surprised to learn how members of your team look at you and share their personal issues with you. Team will always see you as an elder brother or father figure. They will look up to you to make critical decisions. They wanted you to stop silly squalling by team members. They wanted you to put the team in order. They wanted you to console them, when they are in deep trouble. You need to remember that some times your team members will act as irritated teenagers. To manage all these, you need three critical skills.
Gold, Silver or Shit
As a Manager how valuable are you to a company ?
As a mathematical equation, let assume
Managers value as Mv
Product of the value of all the team member as Tv
Marketing effort of a Manager as MMv
Total value of other managers in company as TMv
Mv = (Tv * MMv) / TMv
This will work only if you have more than one Manager in your organization.
Your value as a manager is the total value of your team members and your ability to market your team inside your organization. But the manager value will also depends on the value of other Managers within your organization.
As a manager, you need to make sure that non of your team members value is zero also your marketing within your organization must not be of zero value. If any of those is the case, then total value of you will become Zero.