Whether I’ve got unlimited free talent or not, I’d first think about roadmap / goals before designing my org for a tech startup.
Before you say a roadmap is too low-level details, hear me out. The roadmap is the magic that transforms vision to action.
Ask yourself, what kind of work will need to be done in the next six months to eighteen months for the organization.
You might think it’s a bit short-sighted to be thinking ahead only for the next one and a half years, but the truth of the matter is that the technology landscape is changing at a rapid rate.
If you plan and over-optimize for something that is so far away, you might struggle to build an organization that can execute and deliver on immediate goals.
Besides, it’s not like you will not be reviewing your organization structure regularly. Creating and managing a tech organization is never a one-off event; you will constantly be reviewing and optimizing your set up to meet the needs of the business.
With that in mind, think about the business goals that your organization needs to deliver and whether they are project-based or discovery-based.
A project-based work usually consists of of work where you already have a good idea about what needs to be done. For example, rewriting your software to work on a different operating system.
Discovery-based work are usually those ideas that your company believes in but are yet to be validated. For example, a shiny new feature that will potentially solve a pain-point that customers have.
The reason why it’s important to understand the type of work coming up is that different kinds of people thrive in different environments and knowing the answer to this will help you find the right people with the right characteristics.
The value of a feature can be determined by three variables:
Effort required (the lower, the better)
Alignment with company’s goals (the more aligned, the better)
Shelf life (the longer, the better)
Let’s compare two examples below:
A - A landing page that is going to take 5 weeks to build but will only be available for a week. The reason for the page is to announce a new product offering, as per company’s goals
Here is my unpopular perspective on story points. Story points are just a number. Don’t get me wrong though, it’s a good information to know for the team so that they can predict their velocity and commit to deliverables. #agile#scrum#developer#storypoints
The use of story points has always been a huge topic for debate. Some say it is useful for agile software development teams, others say it is of no use for business. Both of them are correct.
But here is where I have a strong opinion, as someone who has worked in many software development teams, both as a software developer and an engineering manager in the last two decades of my career. Story points are a bad measure for a software developer’s performance.
My take is that when you’re starting out in your career, you need to be a generalist. It will allow you to find a job quicker, get into your desired industry easier and you’ll generally have more choices.
As you get more senior in your career, you will need to start thinking about going deep and picking a specific niche.
While there is no set number of years, generally, 5 - 7 years in a software engineer role is what most engineering managers have before they take on the management path.
Some tech companies put senior engineers on the same level as their engineering managers for this very reason. Engineering management is a linear and alternate career track to software engineering.