Buckets of stuff

Where to spend your R&D $'sI had the good fortune to attend the first Product Camp in Vancouver this Saturday. I was delighted that Sage was a sponsor for this event.  We have a pretty low profile in BC considering we are one of the largest technology employers in the province. The quality of presentations was a little mixed but I will definitely sign up again next year. For me the pick of the bunch was a session I attended on categorizing R&D spend by a VP of Product Management at McKesson.  This post is my interpretation\understanding of some of the key ideas in the presentation “Buckets of Stuff.

The two key hypothesis from the presentation were:

1. If you can effectively explain how much money the R&D work will cost you are far more likely to secure the funding you need to be successful.

2. To maximize the productivity of your R&D spend you have to a solid understanding of how much of your money you spend in various categories.

He identified several key categories you need to know about:

Really new stuff

This is the amount of your R&D revenue spend that you allocate to work on innovation or new products. His example was that Apple may not spend more as a % of total revenues on R&D than their competition.  They do spend a much higher % of their R&D budget on new product development though. The result, a series of innovative and user-friendly products that helped them become the largest tech company in the world. The corollary of course, is that if companies don’t spend enough on innovation or new product development they risk losing access to new exciting growth markets that constantly emerge in the hyper competitive technology world.

Stuff to keep your existing user base

This is the amount of your R&D revenue spend that companies allocate to keep your existing customers. For example, a key strength of Sage is our massive install base of 2.3 million small and medium size customers in North America. We need to make sure we continue to deliver new features in strategic products. For customers on sunset products we need to deliver robust and easy to use migration tools to strategic products.

Stuff to keep selling your existing products

The SMB business solutions software market like many others is becoming increasingly competitive. We need to invest in compelling new features in strategic products in our portfolio to attract new customers. A great example of this is the new Connected Service Strategy currently being evangelized by senior Sage leaders. These new services up in the cloud allow customers to maintain control and leverage the deep functionality of our on-premise desktop applications like Sage Accpac. The first of many connected services for Sage Accpac is Sage credit card processing is scheduled for release imminently.


What most people outside of R&D do not realize is the amount of money and resources (taxes) required to compete in the market. Great examples of these “taxes” include operating systems upgrades or compliance issues. Once Windows 7 is released the perfectly reasonable expectation of our customers is that Sage will deliver products to run on this platform (amongst several others). This is more expensive particularly in terms of QA testing resources than most realize. QA can never test all aspects of a mature product on any operating system. A comprehensive audit is required to ensure the product performs at an acceptable level and is not released with a plethora of bugs that would undermine the brands promise of superior quality. After the financial meltdown of 2008 there has been an unprecedented surge in regulatory requirements which keeps customers on software assurance contracts but is also becoming increasingly expensive to maintain in terms of R&D resources.

Integration\OEM stuff

This can often be another form of stealth tax for R&D organizations. For a variety of reasons many integrations or OEM products do not deliver the revenue projections promised. The net result is that costs continue to be incurred to maintain this “stuff”  in future releases without the revenue to support them. R&D departments face a prisoner’s dilemma type challenge. R&D leadership must often choose to absorb the cost of ensuring quality of this “stuff” meets the quality of the core product because the “other player” does not have the incentive or technical capacity to do so OR take the hit to the brand and accept lower quality. (I don’t mean to suggest this applies to all OEM\integration products)

My personal conclusions

  1. The stereotype that many folks in R&D are trapped in the inward looking “not developed here syndrome” exists for a reason. It is often true. It is often not though. We (R&D) don’t do a good enough job of surfacing the “taxes” and hidden costs in our work when we have legitimate concerns.  The more R&D pay in taxes the less resources we have available to go after the high growth opportunities.
  2. R&D folks need to move past the “entitlement” mentality as well. We are not owed a job. Our focus must be to deliver value to the business that pay our salaries. A great way to do this is to understand our company’s strategy and upgrade our skills to maximize our productivity. ( Staying relevant in the technical labor job market happens to be a huge bonus incentive as well!)
  3. We need to do a better job of highlighting the opportunity cost of technical and quality debt. R&D’s ability to rapidly respond to market pressure is severely restricted the more debt we are carrying.  A principal developer recently sent me a blog called Bad Code isn’t technical debt, it’s an unhedged call option which explains this concept well.
  4. We need to work closely with and support PM identify the really attractive opportunities that will bring in the big bucks. R&D developing products in isolation without a clear understanding of the potential profit is a recipe for self-destruction. No profit opportunity, no R&D budget to justify…….

Culture change

I have been fortunate to work with many teams over the years in a variety of functions including Customer Support, Operations, Project Management and most recently R&D. The most exciting time in a team’s turnaround is when they start to sense the possibilities of what high performance could really look like. It’s intangible but very real. I got that feeling this week in Accpac R&D after the management team hosted a week-long internal conference for our department to discuss agile best practises and how we plan to organize ourselves for our next project.

In hindsight we provided insufficient training to our staff when we originally transitioned to Agile. This cost us dearly in terms of effectiveness and productivity. As I have mentioned before agile is really a set of principles and best practices rather than a rigorous methodology. The focus is always on self-improvement or Kaizen to use the Japanese term. With this in mind, we have acknowledged our mistakes and adjusted accordingly. The management team has invested heavily in training for our staff in 2010. For example, over 50 employees have become certified ScrumMasters; 30 have become certified Product Owner’s this year. Training is scheduled to help staff better test in Agile in December. Most importantly we will ensure that regular training opportunities are available to staff as part of operational rhythm in 2011. Everyone’s hard work, energy and commitment have ensured that the team’s understanding of agile has risen to a new level and provided a solid foundation for future learning.

Funding training opportunities sounds great but what is the ROI for the company and the employee? Put another way, why is training so critical for change management? Have you ever heard of “competence compulsion?” At work, we are all compelled to act and to make sense of every situation in a way that ensures we appear competent to ourselves, and we appear competent to others. Unfortunately, when we are learning, we can appear less than competent. An important premise in Agile is that the team are self-managing and empowered. It is a big ask to expect employees to lead effectively when most have only experienced working in a command and control environment as subordinates. The change is even more difficult when they everyone is unsure of their new roles and the “right way” to proceed. Needless to say management found the new environment ambiguous and challenging as well and struggled to provide employees the support they desired in the transition.

Training is often expensive in terms of money and time. It can be hard to justify pulling key resources off a project (especially when you are behind schedule) to take training. My experience has been that management and employee’s commitment has paid off and the payback has been huge in our department in 2010. For example, armed with new insight and confidence 20 staff recently attended the local Agile Vancouver conference. These folks (many of whom are key change agents) subsequently played an important role in bringing back many excellent suggestions to the team. Although management organized many supporting events the focus of last week was really on the employees. Employees presented their insights and ideas many of us were not familiar with. They offered personal recommendations on how we should organize ourselves. Different opinions and ideas were debated by the department together. The quality of conversation and level of engagement seemed unimaginable not so long ago.

I believe the team has acquired a new core foundation of knowledge (in Agile). This has enabled many to unleash their potential and seek out more advanced ideas to further improve individually and collectively. There is a palpable desire for change and demand from employees for more say in how our R&D organization is run. Energy is higher than I have ever seen it. There is a culture change taking place. I am proud to be a part of it and support the team in any way I can. This is what management is all about!

I recently found out I got demoted

They say perception is reality. This is often true but not always. I was amused to discover that some of our business partners thought I had been demoted when I attended TPAC recently. For those of you who don’t know, TPAC is a small and therefore unusually intimate (professionally) conference for third-party developers who build add-on solutions for the Accpac. The conference is unique from a Sage employee and partner perspective as we get to spend much more time than any other event with each other. I made a name for myself with some of the attendees a few years ago when I introduced a program called Controlled Release into the Accpac channel.

As the new Release Manager my job was to liaison between R&D and internal\external stakeholders. At the time  partners and customers were reluctant to install new releases early for fear of quality issues. Many partners prefer to have the product be released for six months to a year before they encourage their customers to implement it. The idea is that by then most of the big issues are discovered and addressed in the software by then. The Controlled Release program was designed to address this concern by pre-releasing the software to a select group of partners and customers for 6-8 weeks before general availability. We proved the software was release ready, corrected minor issues uncovered and then heavily promoted the live reference sites to prove that quality was there. It was a simple idea that we (Accpac R&D & our partners) executed well. The program was very successful in raising confidence in the product.

I was invited at the last-minute to join the partners on a cruise of the Fraser river one evening after the conference. People typically tend to relax after a few drinks. That night was no exception. Mixing business with pleasure makes it so much easier to get to know people and ultimately develop better business relationships. There are some real characters in the Accpac partner community. Don de Beer is certainly one of them! He says what he thinks. I find this refreshing. Don was convinced I had been demoted. He was curious  and determined to find out what I had done to lose my high-profile job. At first I thought he was joking. When he asked others in our group what they thought the consensus seemed to be that I had been demoted.  I was amazed and amused. (I wonder how I would have reacted if I really had been demoted.) Several pointed questions were asked. I did my best to answer them politely and truthfully. I spent around half an hour trying to convince Don I moved out of choice. Honestly, I don’t think I succeeded. Hopefully this post will do the job!

The Release manager role was a very high-profile role which I enjoyed. Although some partners viewed my transfer as a demotion: from an internal perspective a functional manager with reports is typically considered more important in the company hierarchy than a project manager. That’s not why I moved though. My experience is that too many people are only interested in their functional areas. This often leads to silos, turf wars, inefficient procedures and lower productivity. I enjoy “connecting the dots” and looking at our performance from an organizational perspective. I realized I had a great opportunity to learn more about the software development life cycle if I became a QA manager. I love managing people. I have an excellent track record building high performance teams in Customer Support. I wanted to test myself and see if I could replicate my success in R&D. My boss at the time was also transferred to QA. I enjoy working for him. I decided to join him in QA.

Eventually I would like to move to the business side. I think solid experience in R&D will be a huge advantage later in my career. As most readers of my blog know I am taking an MBA at Segal Graduate Business School to prepare myself for this transition. My ability to move to senior positions has probably been limited because I have moved across different departments in the short run. I have not done a very good job of negotiating raises when I have switched positions either. In the longer term I think the broader experience I have gained will prepare me for more senior leadership roles. At a minimum I have more employment options having proven the ability to successfully transfer skills across various roles and departments. My career decisions may not always make sense to others. I am prepared to take risks and know where I want to go though. I am the captain of my career….


Get every new post delivered to your Inbox.

Join 274 other followers