As the CEO of a software company, a huge amount of your time and effort is focused on scaling up your business. But as you achieve success and grow, the challenges you might have faced with software development in the early days can become magnified exponentially. As your company gets bigger, it’s essential for you as the leader to make sure your processes and culture are getting better.
Bigger doesn’t always mean better when it comes to software development and innovation. As CEO, your software R&D team doesn’t just need more people; you need a truly agile framework and a collaborative company culture. You need to empower your software engineering teams to innovate while working more efficiently and feeling more fully engaged, invested, and valued in the process.
The bigger your software company becomes, the more important it is to embrace a software engineering strategy that will help you use your company’s resources more efficiently, minimize risk and maximize ROI.
As a software CEO, you need to build, retain, and manage a team with a mix of different skills and engineering disciplines, and empower them to deliver high-quality products in the least amount of time, at reasonable cost and with limited risk.
Changing the culture of your software R&D team can help you accomplish all of these objectives. Let’s look at a few key principles to keep in mind as your company grows.
Engineers are Not a Commodity
As software companies grow and scale, sometimes CEOs make the mistake of just hiring “more people” and assuming that “more bodies” equals more productivity or growth. But engineers aren’t a commodity. Headcount for your software engineering team doesn’t matter, because the difference in capability and output of one engineer vs. another can vary by 3-30x.
Don’t assume that more people equals higher quality, faster velocity, or faster time to market. It all depends on how you utilize your team. Unless you have strong processes, a clear product roadmap, and a collaborative team culture, simply boosting headcount will often be counterproductive.
Embrace Diversity of Software Engineering Skillsets
There’s no such thing as a full-stack engineer. They do not exist in any usable form. Software companies, especially as they scale, need to build a team with a diverse range of engineering skill sets and specializations.
Think about what it takes to do physical product development, like building a widget or manufacturing a car. It requires many different engineering specialties. For example, earlier in my career, I used to work in a 24-7 manufacturing facility for Motorola building linear power amplifiers for cellular base stations. That experience showed me it takes a variety of engineering disciplines to make physical products: mechanical, electrical, software, manufacturing, quality assurance, and test engineers. Only by effectively bringing together all these disciplines enables you to develop, build, and ship a quality product that won’t get returned, and do so at a price point and with a timeline that the market demands.
This approach translates directly to the software world. There are natural talent divisions among back-end engineers and front-end engineers, web engineers building web applications, mobile engineers building mobile apps, and API engineers who understand APIs.
Don’t assume that different types of engineers can solve every type of engineering problem. For example, if you ask a back-end engineer to build a web application or a mobile application, it will take them 10x longer to get the job done because that’s not their natural talent. In the same way, you wouldn’t want a mechanical engineer to design your electrical circuits.
Bottom line: there are natural specializations in software engineering. Understand and respect them.
Do “Concurrent Engineering,” Not “Over the Wall” Engineering
When a software company wants to build a new product, they often use a sequential approach. They start with product design and then have the back-end (or front-end) engineers do their thing. Then they hand the back-end design over to the web engineers, mobile engineers, and API engineers.
With a sequential approach, you take the product in stages through these areas of specialization, and then at the end, you have code. Congratulations – you’ve manufactured a product!
Then you hand over the product to your QA team, and they uncover lots of issues and design problems.
This is the problem with the sequential approach, also known as “Over the Wall Engineering.” The product gets handed “over the wall” from one silo to the next. With this method, issues don’t get discovered until it’s too late – driving up costs and increasing your risks.
Here’s another old adage from manufacturing: “You cannot test quality into your product.” Quality needs to be designed and built into the product along the way, so you’re not finding problems when it’s too late to fix them. In the automotive industry, there were innovators like W. Edwards Deming who integrated lean manufacturing into engineering. You need to think like Toyota and create a high-quality product at the lowest cost. To stay competitive, that’s your job as CEO. But designing before you build is still considered a novel concept in some software circles.
Instead of Over the Wall Engineering, software R&D teams need to adopt another concept from manufacturing called “Concurrent Engineering.” This is a method of engineering where multiple project phases happen simultaneously. Concurrent Engineering can help significantly increase productivity and product quality, while reducing project risks and costs.
Concurrent Engineering involves:
- Assigning a Product Owner: Every new product needs to have a Product Owner. This is someone who understands what the product needs to do and what it needs to look like to deliver value to customers. The product owner is accountable for keeping the vision in sync and making sure everyone is hitting that mark.
- Creating a Matrix Team: Instead of handing over the product from one silo to the next, your process should include a cross-discipline product engineering team. This team should have representatives from across all engineering disciplines. You should also include QA, UX design, marketing, sales, and customer support. Together, this group can build a high-quality product, on time and on budget, that meets the needs of your market. That is how you win.
The Product Owner needs to guide everyone to maintain the vision and make sure that the quality gets built into the product, not “tested in.” You need all of these voices on the same team on a continuous basis so everyone takes ownership of their piece throughout the product engineering cycle.
Benefits of Concurrent Engineering
Concurrent Engineering leads to a huge reduction in risk, cost, and time. The multi-disciplinary team creates a higher quality product that is ready to sell. This brings even more efficiencies and benefits, including:
- More accurate estimates. If you’re halfway through the engineering cycle, you can believe in the estimates from your integrated team; there are fewer surprises.
- Better planning for product launches and go-to-market. You can prepare for the product launch with your marketing team and your sales team can have the financial model figured out earlier in the cycle. No more “I’ve got this product, now what can I sell it for.”
- Better customer experience. Your customer support team will be ready for onboarding and provisioning as they prepare for rollout.
- Better product road mapping. You need the support of everyone in the organization, and you’ll get more predictability with this approach. Everyone is in sync on what needs to be done.
- Healthier, happier software engineering team. Concurrent Engineering gives you the real-world benefit of making sure your team grows and becomes more capable and agile across the board. This approach keeps people happier and more engaged. Their opportunity for individual success is higher, their stress level is lower, and there’s a better sense of shared responsibility and ownership.
Concurrent Engineering also delivers powerful benefits for your company culture and teamwork, because it helps you break down silos and get rid of finger-pointing, inefficiencies, and misunderstandings. With a Concurrent Engineering approach, solutions can come from anywhere – sales, marketing, product owners, or engineers with diverse skill sets and perspectives.
In organizations that have embraced Concurrent Engineering, there’s greater transparency and true teamwork. Everyone has everyone else’s back, and it’s quite effective.
Unlock Better Long-Term ROI in People and Technology
With Concurrent Engineering, your team can be more productive by working on a few projects at the same time, while minimizing risk and maximizing return. By giving your software R&D team better predictability and efficiency, Concurrent Engineering can also enable you as the CEO and your finance team to think long-term about achieving ROI on your software product investments.
With Concurrent Engineering, you’ll have better transparency and predictability on what the financial model means to the business, and how much you can afford to invest in product engineering and marketing. For each new product, it will give you a clearer sense of IRR on the investment, while reducing the risk of that investment.
Concurrent Engineering is a choice. It costs you nothing to do it this way. But if you choose to organize your software R&D process with Concurrent Engineering, you can make big improvements in the efficiency and cultural cohesion of your company. And you can start having more productive conversations about big-picture plans and long-term investments.
As the CEO of a successful, grown-up software company, it’s time to have grown-up conversations. You’re not bootstrapping in the garage anymore. You can’t just turn to your one Golden Child software developer and ask them to work 90 hours a week to crank something out. You need to build a healthy, sustainable dynamic for your team. You need to think farther into the future and make longer-term decisions. You must plan in years, not just months or quarters.
Modularis helps enterprise software companies do all this while implementing PlatformPlus®. The CEOs we work with are spending 50% less time managing software R&D, and more time planning for growth.
“The stuff we were able to accomplish with Modularis was surreal; it was mind-blowing, actually. The things we’ve already mapped out for Q2 are things we were previously told couldn’t happen.”
– Larry Caldwell, CEO of truDigital Signage
Ready to have more grown-up conversations about software R&D?
Don’t just survive – scale. In as little as 10 minutes with me, I’ll show you how Modularis can help your company transform your software engineering strategy to minimize risk while maximizing your ROI.
Is Your Software R&D Process Delivering Enough Value? Find Out for Free! Do you feel some disconnects with your software R&D team? Before you get started with a new software product roadmap or try a new software engineering approach, use our free Tech Leadership Scorecard.
This Scorecard will help drive discussion and foster better alignment and understanding. Try it for free! Get the free Scorecard.