The Start-up Founder’s Guide to setup a Software Delivery  Team
Thanks xebia

The Start-up Founder’s Guide to setup a Software Delivery Team

Software delivery is a continuous process that involves continually identifying new user needs, analyzing them and implementing solutions. To do this efficiently, you need to have a strong software development process in place. That is why so many tech startups are implementing DevOps practices to streamline their software development processes. There are several key principles of effective software delivery that you should keep in mind as you build your company’s infrastructure.

I’m giving you an overview of the most important elements of software delivery and the specific considerations for a startup founder who wants to implement Software Delivery Services in their Organizations. You need an expert to solve this for you.

Why focus on Software Delivery?

Software delivery is the foundational pillar of modern software development methods. It refers to the processes, tools and practices used to release new software versions into production. However, while the importance of software delivery is widely acknowledged, its implementation poses a challenge for many organizations. The underlying principles are often not intuitive for start-up founders and C-level executives who are not necessarily tech-savvy. With my vast expertise in this particular segment, let me help you understand why software delivery is important, what challenges it presents to start-ups and how you can implement it effectively in your organization.

In software development, the delivery phase is where you get your software from the build step to your customers. The challenge for many start-ups is that this phase often requires more effort and time than anticipated. Try to tackle it as early as possible, because fixing bugs and other issues after launch will take a lot of time and resources.

To avoid ending up with a buggy product that drives away users, start thinking about software delivery early in the development process. You don’t have to be an expert in all of these topics right now, but keeping them in mind now can help save you lots of trouble later on.

At 1-10, of team size ?you’re young, initiated and excited

At this stage, the chances are you are beaming with ideas but in all probability, yet to figure out a better way for efficient deployment. Simplicity is key to moving forward. Make the most of the small team you have. Bring processes in place and be thoughtful of a long-term roadmap. You may wait before you put it to action. But having a roadmap helps bring operability from day 1. Make sure your code is traceable from the very first build. My key recommendation is to have Continuous Integration and Continuous Delivery (CI/CD) in place straight away. This can help you stay miles ahead in your growth at a later stage when you can afford the best tools.

I’m sure you’ll be tempted to copy the big players in the industry, but NEVER attempt that! Your margins are your priority and make sure you manage that from day 1. The other two things to avoid are complex elements in your code and complicating the process. But you can definitely consider automation at this stage.

At 10-20 of team size ?, you ought to find the market fit

Right now, it’s ok not to have a single resource dedicated to handling code efficiency. Typically, the entire team is contributing to this cause and that’s fine at this stage. In a way, it helps build efficiency in the entire team. They all will watch out and over time, it becomes a culture. The key focus at this stage should be finding the product-market fit. Once you crack this, you can move ahead. I know it’ll be tempting to build services around this time. But steer clear and focus on bringing out the product that fits your market. Adding services at this stage could bring along a host of complex decision-making and trust me, you’ll be better equipped if you wait for a little more.

At this stage, your focus should be to avoid adding complexity with services and other elements and bring in more efficiency without breaking up into teams. Personally, I would ask you to start getting your Engineers to face the clients so that they understand the requirements better.

Being operationally aware from day one ensures that the codebase is built in a way that’s easier to operate, which in turn allows the company to more easily scale.

At 20-50, focus on code standards and automation

You may hate me for enforcing standards in coding now. But you’ll thank me later when you relish the fruits! This is the right time to automate. You can thank me now for suggesting CI/CD earlier. From this stage onwards, CI/CD will help reduce the complexities of automation to an extent. You may use free tools at this stage so that they don’t add to your costs and yet you benefit. What you shouldn’t consider is a code rewrite! There are other things to focus your resources on. You may tweak as necessary but a complete rewrite is a NO. You’ll be wasting a lot of time unnecessarily. Don’t assume that your entire team understands the context. You may enforce it using CI/CD. Get your team to understand the context so that they code better. Your test documentation can get handy here. ?

It’s quite obvious at this point if you’ve got the job done: customers love you, you have more funding, etc. At this point, you’re transitioning from an exploratory start-up to one that needs to support and scale. As your team grows, so should your tooling.

At 50-250 engineers, you’re big!

This is the time to focus on consistency, standardisation and replication. Check each service for consistency, standardize your code and deployment process and replicate for other services. This is the right time to have dedicated people or teams for efficiency, experience, tooling and other important aspects of deployment. Each team can focus better that way. But make sure there’s at least one common team or resource to connect. This will make sure that the requirement is clear and the standards are maintained across the project consistently. If you are able to inculcate product ownership as a culture across teams, you are doing it right. That said, don’t let loose your teams independently. They still have to work together as a single team to come out with products and services that resonate with what your clients want.

CI and CD are the most powerful and important practices in modern software applications. They can save you time, money, and oncological emergencies. CI and CD tools are the easiest to set up and have the greatest cost-to-benefit ratio. By adopting these practices, you get a huge edge in getting your product to market.

At 250 & above , you’re growing!

This is the perfect stage to invest in the right tools, processes and systems. With this large team, personal supervision wouldn’t work and you better have a solid process and system in place to take care of the standards. It’s also time to consider the technical debt and have a plan in place to clean up the mess accumulated over time. Personal relationships don’t work much now as you have more teams focused on specifics and rely on automation and tools. Another thing that doesn’t help, is trying to fix the legacy bugs rather than focusing on day-to-day affairs.

At this scale, it’s time to be proud of your growth! It's an amazing feat to achieve. Others are on their way to reaching your scale and more already there. Everyone has their own journey and has found their own equation. So, don’t get overwhelmed by how ‘the other’ seems to be working. Figure out your own equation to move forward. You have come this far with one. Focus on building tools, systems and processes that you know can help. Continue the CI/CD culture you implemented earlier on. Scale-up when you feel that’s necessary.

As you begin to scale, your biggest worry is that you’ll get too big, too fast. This is where “The North Face Fallacy” comes in.
The key to understanding the optimal approach to software delivery is to look at the perspectives of product management and development, as they are the ones who both own and benefit from delivery, making them uniquely positioned to influence the decision-making that can help you make the right call.

To sum it up, I am highlighting some important steps you can focus on:

·??????Define a solid software delivery process

·??????Reduce variability with automation

·??????Be transparent about risks and trade-offs upfront

·??????Be flexible for late changes

·??????Give importance to user experience (UX) and user interface (UI) design

·??????Produce high-quality code

·??????Test everything you can

·??????Ensure software quality assurance (QA)

·??????Implement continuous integration and continuous delivery

·??????Estimate the effort for your software delivery process

·??????Deliver by feature, not by step

·??????Define your software delivery strategy

·??????Don’t roll out too early

·??????Don’t release with known defects

·??????Learn from the feedback you receive

It will be interesting to know what stage of growth your software company is in and the key points that helped you get there. If you do resonate with my points, I’ll be happy to know. If you have a different story, do share.

Rahul Agarwal

Cofounder @ Finnup| Debt marketplace

2 年

This is really a detailed guidance. Thanks Sreeram Gopalakrishna

要查看或添加评论,请登录

Sreeram Gopalakrishna的更多文章

社区洞察

其他会员也浏览了