The R&D lead role at ISVs and its evolution

From my experience as Microsoft ISV lead for France and from my experience at SoftFluent working with software companies or investors, as well as per my active role in the French ISV association, I have been continuously in contact with both CEOs and their R&D lead. Whether you name him/her (I will use a feminine in the rest of the article) VP R&D, CTO or technical director depending on the size of the company, the person leading the Research & Development effort inside a software company plays a major role.

The importance of the R&D leader

Why is the R&D lead so important for ISVs? Simply put, the R&D department bears the responsibility for the long-term success of the company. Whereas the sales department is primarily focused on short to mid-term sales execution, the R&D department is supposed to build the next generation of products that will make the company successful in the future.

Of course, one could argue that the sales department is even more important, because if you do not financially survive, it does not matter whatever you prepare for the long-term. But ISVs that are just selling without managing their R&D will be swept away at the next technology wave, even if with the best sales team, and especially with the pervasiveness of Internet and the emergence of “Software as a Service” models.

Don’t get me wrong, I don’t want to underemphasize the role of sales departments, because the more you are able to sell in the short-term, the more investment you are able to make into future products. But if you do not have the right R&D team and leader to properly leverage this investment, you are not preparing the quantum leap that you may hope to achieve.

Additionally, CEOs are usually already aware that they need a good sales team, but underestimate the very specific profile they need for driving R&D, a profile that seems harder to find by the way.

According to me, it seems harder to find a good R&D lead than a good sales lead. ISV CEOs asked me countless times for advising them a good hire for R&D management, either at the top level, or for managing a team of developers. In both cases, I found the answer to be hard, as I know this job is probably one of the most challenging – though one of the most interesting for sure!

The reason why this job is hard lies in the fact that this role requires various – and often opposite – skills. My conviction is that being a good R&D manager requires technical expertise (for sure), management skills, but also strong business acumen and communication skills. And this will be all the more the case as I will explain in this article.

ISV Challenges today and what this means for R&D

Before trying to focus on what makes a good R&D manager, I would like to recall a number of key market trends that characterize the evolution of the software sector, as described by market analysts:

  • Accelerating pace of evolution,
  • Platform fragmentation including mobile devices,
  • Middleware standardization, leading to increased specialization (horizontal or vertical),
  • Internationalization and competition at the worldwide level,
  • Industry move towards Software as a Service and cloud-based models.

These challenges translate into specific challenges for the R&D:

  • Ability to keep up-to-date with latest technology standards,
  • Building differentiation based on relevant business scenarios,
  • Support for global and multicultural applications,
  • Web-based delivery models including closing the loop with customer usage and support,
  • Delivery aligned to shorter cycles of innovation.

What it takes to be a successful R&D manager

Of course, there are a couple of stable elements that have always been critical for managing an R&D department. First, the R&D lead must have strong technical skills to properly develop a professional engineering process to build products and have the legitimacy to drive developers, no question about it. Second, she must be a good manager, in all the classical dimensions of management, and especially in building teams, as technical developers are often positioning themselves in mutual competition. These two elements used to be critical to R&D managers’ success and I expect these to remain as relevant in the future.

But, as a matter of fact, my conviction is that you also need someone with strong business acumen and communication skills to drive the R&D effort. The good news is that this acumen can easily be developed by working jointly with the sales and marketing departments. But to do so, it is critical that the R&D manager develops communication skills, takes the relevant posture and really wishes to understand the specific business of the ISV and the faced challenges.

In our experience, without proper management, business and technical people tend to be like oil and water in a glass. They do not naturally meddle with each other. How many times did I hear technical people criticize the sales discipline? And how many times did I see sales representatives consider the technical staff as pure resources that should be aligned only to their own top objective?

Now what you need for short cycles of innovation is a real interpenetration between the business and the technology. The most relevant innovation, whatever business you are in, occurs when the technology directly serves innovative and valuable business scenarios. And to build these relevant scenarios, it is critical to have a positive and permanent cooperation between business analysts, sales people and R&D. And very often, the R&D lead (or her team) is the only person whose technology knowledge is sufficient to imagine the innovative solutions to create. And this cooperative process should be permanently sustained, even if it sometimes requires adjusting product plans to leverage a business priority opportunity.

In today’s fast changing world, it is also becoming impossible and economically inefficient for any R&D to try to invent its own solutions to any problems. On the contrary, as the need for speed increases, it is very likely that successful R&D departments will be the ones able to leverage external innovation, by buying components or licensing technology, and also able to leverage external development resources where appropriate, including potentially OffShore if it makes sense. Leveraging the web as a source of information for both technological and market trend information is also a key differentiating opportunity between R&D managers.

SkillEvolution

Schema #1 – Evolution of the R&D manager skills

So where past successes partly resided in having a strong process orientation and stable product plans to fit into long-term schedules based on a specific home-made methodology and toolbox, it is now time for the R&D lead to act quite differently. She should stay up-to-date with new technology opportunities, sorting out the hype from the real important elements that can be leveraged in the context of the ISV, depending on its specialty and the challenge of its business sector.

This work being done, the R&D lead should not be shy in leveraging external partners, either to embed innovative pieces of software that will make his R&D more competitive (and this is also an area where the R&D lead should develop business acumen), or to strengthen its development team to accelerate product delivery or buy specific skills. Signing strategic partnerships could be a key leverage factor in going fast and allowing parallelism in innovation.

She should be as comfortable with sales or marketing people as she is with technical people to act as a bridge between the departments and leverage the field and marketing knowledge to create the innovative solutions that will build the company’s future success, either by her personal involvement or by fostering this spirit inside the R&D department.

As software development gets more and more industrial, it is also critical to seize the opportunity to leverage the technology to change the development process in itself, adjusting the methodology to a fully industrial approach, both in terms of organization and tools.

We of course have a strong position about tools at SoftFluent, because this is one of our major value creation axis through CodeFluent Entities software factory. We are convinced that, whatever your own recipe is, automating your development is a huge leverage for creating value.

Doing so, the R&D lead will be closer to deserve the title of “Chief Technology Officer” than the “Chief Technical Officer” which I find too restrictive.

Possible R&D manager failures

The first and most common risk for R&D managers is to fail in managing the "product roadmap", a tricky process that requires balance.

On one side, we find R&D managers that are totally driven by customer requests and do not build real "product plans". This way of acting leads to a fragmented offering whose complexity grows exponentially with time and the absence of a real product.

On the other side, one can find R&D managers that put excessive rigidity in product planning. Of course, it is not a good idea to deeply modify product plans while in development phase. But being able to get some flexibility about the plans and to manage change should be built into the R&D methodology. Otherwise, the price to pay might be an offering which is not aligned to market needs.

A second risk is the NIH syndrome. The “Not Invented Here” syndrome is very well-known in software development and has prevented a lot of teams from leveraging major opportunities. External technologies are rejected, the R&D people finding a lot of more or less valid arguments to explain why they can do better, sometimes even unconsciously. This results in suboptimal time to market, as well as excessive cost. The team ends up with people mentally focused on technology whereas the need is to get a team that understand the drivers of their vertical market.

A third risk can be a lack of curiosity. If the R&D lead is not really interested by the business, it might happen that developers stay with what they know, just because they are comfortable about it. R&D lead really needs to have a desire to permanently evolve, read about new technology, test it and understand what is useful for the company’s business and what is not, including what may change the rules of its software development process. Otherwise, the innovative scenarios will emerge at competitors first and the company will be swept when a major technology wave arrives.

Table #1 – The 3 critical skills expected for the R&D lead

Critical Skill

Skill

Profile

Failure symptoms

1. Ability to bridge business people to technical people

Business knowledge and acumen

Openness

Curiosity

Communication

Difficult dialog between sales/marketing & R&D departments

Need for excessively formal specifications

Full waterfall-oriented and rigid process

Reluctance to change

2. Manage technical teams to deliver high quality products through an industrial process

Software development experience

Real developer experience

Rigorous engineering approach

Leadership

Product development going round in circles

Software deployment issues because of the variability of customer environments

Disconnection between R&D manager & teams

Offering built by aligning customer requests without a real strategic vision

3. Leverage external innovation and seize opportunities

Partnership contract management

Creativity

Communication

Humility

NIH syndrome

No third-party component leveraged

Limited partnerships on the R&D side

Inability to scale out the R&D effort

To maintain the proper culture in their R&D department, ISV CEOs should proactively:

  • Monitor their competitors and hire people from other companies in the same sector,
  • Send R&D people to customers when relevant, not only to solve issues, but also to make sure they see real world contexts of what is happening on the market,
  • Involve field resources like consultants or pre-sales engineers to work with the R&D on some specific projects to break silos,
  • Challenge their R&D department about looking at third-party opportunities on the market like existing software components or partner modules,
  • Regularly leverage external resources with strong expertise in software development to assess the R&D maturity in terms of organization, processes and technology skills.

In the end, the needed reactivity and innovation is just a consequence of having one foot in the R&D and one foot in the business, so involving the R&D manager with the business should be one of the key lessons of this article.

And, to come back to the oil and water comparison, just remember what happens when you shake the glass, it should certainly give you a good hint to the solution!

Daniel Cohen-Zardi

SoftFluent CEO

Developeronomics: a very necessary debate!

Last month, I read the Venkatesh Rao’s article about Developeronomics, a new word invented to underline the huge value that can be embedded into a single valuable software developer. Leveraging the idea that made Freakonomics popular, the author emphasizes the endless need for more and more sophisticated software and argues on the very active talent war on the market, both for large technical companies and for active startups. Then he advises anyone with some surplus capital to invest it in a brilliant developer as you would invest in stocks or in good wine. By the way, wine certainly was a good financial investment to make before the 2008 crisis, but this is yet another story.

Basically, I tend to agree with the idea developed in the article; especially regarding top developers that in my experience can produce more than a typical team of 10 average developers… provided the team has the skills to overcome all the technical challenges. So it is always a better choice to have an over-skilled developer rather than an under-skilled one. It’s much more inexpensive in the end.

When I was working at Microsoft, I had the chance to hear Bill Gates tell the Windows NT story and how he hired Dave Cutler from Digital to do the job. When Bill asked Dave what the optimal team size would be, Dave’s first answer was "1". Then he added, "It is the optimal for efficiency but if we need to deliver within a reasonable timeframe, let us build a team of about 10 very good developers".

This is totally consistent with our own observations on the field. Still, people who have never written software themselves keep reasoning in man-month logic as if the man variable in this expression were commutable. And unfortunately, many people making strategic decisions about software development have never developed themselves.

This led to the huge "off-shore" trend that no one is really able to confirm as successful. I deliberately do not qualify this as a global failure, as I am lacking reliable data to validate that off-shore as such is a failure, but I am also lacking reliable data that demonstrates that it really works. The point here is that we are lacking a key metric about what has been produced (in value, not in cost) so we could really compare results, not expenses. I will post more in the future, on both software development measurement and off-shore, because these are also key topics.

Interestingly, Jesse Jiryu Davis posted a valuable reaction to the article that extends the discussion in my view. In the process, his "It almost never works" demonstrates at least that you cannot succeed with mediocre programmers (them being off-shore or not).

His other interesting major comment is his "Each year we write software that prevents us from having to write more software". That clearly strikes a chord to me. This is the history trend that everyone has to consider, but my personal opinion is that the opportunity to get more "out of the box" solutions also creates the need for more software. This is as infinite as the knowledge of the world and I cannot really imagine the day when we say "Ok, we are done with software development, now let us just maintain the worldwide code base!".

This is why our CodeFluent Entities approach is not to replace developers, but instead to allow them to go a mile further by automating the repetitive tasks for them. The idea is to let the tool do the tedious work so we, developers, don’t have to do it.

To conclude, software developers always have to adjust their skills to ever-improving tools and technologies. This is part of the fun and the value of this job, and these are the guys that I typically want to invest in.

Daniel COHEN-ZARDI

CEO, SoftFluent

SoftFluent resolutions for 2012 on this blog

Now is the time to wish our worldwide readers all the best for 2012!

New year is also a good time to take a bit of distance from day-to-day business and make resolutions.

Last year, we decided to start sharing our experience about .NET software development and we published various articles. Meanwhile, we were busy with our product that extended its audience to more than 160 countries.

But we did not find enough time yet to cover all the topics that we would like to talk about.

So let us make the resolution for 2012 to write at least 3 articles on each of the following topics:

  • Measuring software development performance,
  • Development teams management,
  • Software testing best practices,
  • Production-aware programming,
  • Software maintenance and evolution,
  • Platform choices,
  • Software methodologies & design,
  • Leveraging third-party code,
  • Software engineering tooling,
  • Off Shore development,
  • Trendy patterns that can kill you.

Stay tuned and be patient, we are more committed than ever on contributing to debates in those areas about .NET software development.

And once again, all the best to all developers around the world!

Daniel COHEN-ZARDI

CEO SoftFluent

SoftFluent at Model-Driven Day 2011

SoftFluent was a sponsor again at Model-Driven Day on November 25th with a selected group of companies committed to evolving software development methodologies.

AlloCiné testified (in French) on how it significantly reduced its technical debt using CodeFluent Entities over a year using a step by step approach (full case study in English here). The case was strenghtened by the fact that it proved to be efficient both for the local developers and the off-shore team (located in Ukraine).

Carl Anderson delivered a short demonstration of new features inCodeFluent Entities, including its brand new modeler that has been released in October.

Since then, SoftFluent R&D accelerated delivering Visual Basic .NET support and a technical article illustrating heterogeneous technologies including Hibernate and Java code running on a Linux/Oracle environment. Those elements demonstrate strongly the benefits of a model-driven approach to avoid technology dependency.

Considering the quick pace of evolution of technologies, including inside a single vendor platform, this need is making more and more sense for who cares about the durability of his investments.

See all presentations of the event (in French)

Release management: SoftFluent’s experience – 12/12

Common mistakes as observed on the field

This series of posts aimed at sharing our experience. We detailed our own approach and how we deal with the different dimensions internally as an ISV.

But as we also have field experience in advising software companies, I thought it would be worth to also gather-up a list of common mistakes which we observed and that can severely impact the ability to master the product release management process.

  1. Linking product version to a particular customer: In the field, we see many companies claiming to be ISVs but in fact linking strongly product versions to one or a few customers. In our experience, it is very hard to keep a real product-oriented approach when you have a too strong customer connection. It often ends up in having a custom development that is too specific for the customer context.
  2. Setting too high expectations for version 1: Some ISVs also set very high expectations from the beginning, or for their new offering if they start a brand new product. Trying to address all needs in a very complete way in a first version is doomed to failure most of the time.
  3. Starting without a minimal vision of sellable product scope: On the opposite side of the spectrum, we also see teams that start without having a real vision of what minimal scope can be achieved and sold as a product. Pushed by the trendy messages about agile methodology, some people think you don’t need to know very well where you are heading to start your project. In most cases, this does not work well. In our views, agile methodologies work well when used as a delivery method inside a more macroscopic global planning process at vision level.
  4. Neglecting documentation: Because it is not very fun to write documentation, especially for developer profiles, this area is not enough covered with the appropriate quality level. As an ISV, you should never develop a feature that you are not ready to fully document. Isn’t it obvious written that way?
  5. Underestimating tests: Test and QA is a critical area for software success. It encompasses many dimensions (see our previous post about software testing best practices) and should be allocated the right level of resources and attention.
  6. Considering coding as pure low-added value production: We see some ISVs trying to apply the recipes of industry with a simple scheme saying that all the value is in the design, and that code can be outsourced to low-level service companies, those companies being local, near-shore or off-shore. It can be true for some very basic management software that is broad in coverage but very simple in the features. Still, most of the time, you would be able to achieve much more efficient results with 1/10th of the investment with software engineers of the right level, and above all, the proper level of experience.
  7. Subcontracting what is not internally mastered: I am a big believer of specialization and subcontracting. This can prove to be very useful when used properly. But there is a golden rule that I learned over time: you cannot subcontract what you don’t understand well. You need to have the ability to pilot and control the work of your subcontractors, and you cannot do this if you lose the basic knowledge of key elements. This applies strongly in all software dimensions that you might want to subcontract.
  8. Going for a technological leap without measuring the methodology impacts: I have audited tenths of projects that have fallen into this trap. Despite the platform vendor pitch that everything is getting simpler with new technologies such as .NET or Java, this is simply not true. These platforms give new technical opportunities and connection capabilities, but they are more complex and bigger than ever. An ISV switching from a traditional CASE Tool based approach (such as Progress, PowerBuilder or NSDK to name a few) is more than likely to fail his new projects if he does not measure the impact of technology change. The methodology needs to be adjusted as there are many implementation possibilities in those open platforms. Finding the right balance on many topics is more than tricky.

As a conclusion, we do hope that the experience we shared might be useful to some people in the field. These are only our views, we might have missed some points and we are always eager to learn more, so we welcome any feedback on those elements.

Daniel COHEN-ZARDI

CEO, SoftFluent

Release management: SoftFluent’s experience – 11/12

Tools summary

Considering the numerous elements detailed in these discussions, we mentioned different tools that are useful to our Research and Development department.

 

Area

Tools

Roadmap Planning

Internal tool: Excel lists of modules and features

Product Design

Microsoft Visual Studio Team Foundation Server 2010 & especially WorkItems (tasks & bugs)

Development

Microsoft Visual Studio 2008/2010, JetBrain Resharper, Redgate .NET Reflector

Embedded in our product: Actipro SyntaxEditor

Documentation

Innovasys HelpStudio & DocumentX

Internal Tool for schema « DocMaker »

Testing

Rich internal tooling for UI automation

Build management

TFS Build, MS Build, Internal tooling, WIX, CodeFluent Templating Engine

Release/version management

SoftFluent.Licensing, Direct integration with our web site

Licensing & activation

SoftFluent.Licensing, internal technology for activation and obfuscation

Support

WordPress blog, YAF forums, Customer-organized dedicated mailbox

Release management: SoftFluent’s experience – 10/12

Product support

Our product support team leverages two key tools to provide you with top level information. First, the team regularly selects product features and posts an example and an explanation to draw attention to this feature on our product blog. By subscribing, you will learn a new tip almost every day, directly from SoftFluent team members.

image

Beyond this one-way information process, the support team closely monitors our forums and make sure all questions get answered in a timely manner.

If this looks like a bug, we start by trying to reproduce the issue, then if confirmed, we then escalate it to R&D. If the question is more open, or if the behavior is by design and you need to address it differently, our team may propose solutions or directions to look at. If necessary, you can also ask for paid consulting hours to help you implement a complete solution.

In the end, we get constant positive feedback about our reactivity and we work hard to maintain this level as we know this is a key factor to customer success with CodeFluent Entities.

image

Release management: SoftFluent’s experience – 9/12

Version & release management

SoftFluent implements its own license protection mechanisms, which include client and server-side tools, as well as activation and obfuscation mechanisms.

Once a build is produced, and if it passes our quality assurance tests, we make it public. This is what you can see in the client-side tool that you get when you download CodeFluent Entities. Builds with the green flags are considered valid and fully tested.

image

On our side, we have a licensing application where we can manage the builds released on the web, as well as the different information related to licensing.

This is where we can upgrade your free personal license to a commercial one for example, and modify the appropriate metadata that goes with the license. This is also the tool we use to manually activate licenses if you use the email-based option.

image

Another interesting point of our release management process is the “Product update blog”. As soon as the developer has finished a work item that we define as ‘public’, he documents the modification with a user-friendly comment, whether it is a new feature or a bug correction. This comment will directly feed the “Product update” RSS, giving you all the information about what is in a new build.

image

Follow

Get every new post delivered to your Inbox.

Join 183 other followers