10 or so Signs that R&D is Sick

A lot goes on in a business but this is about R&D. You should read this even if you are not part of an R&D organization. Sometimes someone outside of the R&D organization needs to spot the insanity because those in the shit in R&D can become too subjective.

Whether you are just starting out or growing an already successful company there are fewer things more destructive to company growth than a sick R&D organization. All parts of your business are important and clearly you need a great idea that speaks to a market but in this post I am going to focus on your R&D organization.

Over the years I’ve observed some traits that may indicate your R&D organization needs a health check. Some of these rear their head right after you’ve had some success and feel you need to “improve” and “grow” your R&D organization. I’m unique, so some of these may make you bristle or you may think I’m insane. Fine, but I know what works and I know what doesn’t work. These are in no particular order. I’ll try to expand each one of these into their own blog post.

1. Process over Productivity

Concentrate on producing not on process. Managers will often work on process rather than address the real problems. I don’t know why, they just do. Working on process makes them feel more important and like they are doing stuff. Process will not make up for a lack of talent, direction, customer validation, and vision. It just allows the VP of R&D to go to executive staff with velocity charts that show R&D is kicking ass even if it is not shipping product and not making customers happy. Have you spent time in meetings talking about the true meaning of a story card and what it should contain? Get a life and start producing and spend less time on silly conversations that probably don’t matter that much. Who cares if story cards vary a little. Optimize the right things. Focus on Product.

2. Technology Centric Architecture

Architecture needs to be customer centric not technology centric. If your engineers are creating overwrought architectures then they need to spend more time with customers and sales. Spend more time coding and designing quick features you can test with customers and less time on a really cool architecture. Perfect features after they have been proven to be valuable. “Build it right the first time” is BS.

3. Managers That Don’t Code Making Technology Decisions

You need leaders not managers. If you have managers that are not practitioners they should not make technology decisions. If they want to make technology decisions then they should also be responsible for doing some coding, designing, testing, or whatever area it is that they manage. If you need a bunch of managers then you may really have a direction and talent problem. Compensate your top individual contributors more than your managers. This will keep them from thinking that managers are more valued and that managing is the only career path in the company.

4. Having a “No Heroes” Attitude

Despite what you’ve heard sports teams and rock bands do have heroes. It’s okay if you do too. People try to emulate heroes and having a hero around raises the bar for everyone else. It’s okay if you have a super star that is peculiar or can be a pain in the ass. Just remember what a super star really is. A super star is NOT someone who can bully other people or quote Knuth. A super star is someone who consistently creates superior customer value quickly. I’m not really a huge Van Halen fan but ask yourself this. Which Van Halen was better? The one with crazy David Lee Roth or the one with the very manageable Sammy Hagar?

5. A Separate Bug Fixing Team

This one always bothers me. At a certain point a company feels that it is too big to have the same people that code features fix bugs in those features. The result is a development team that is out of touch and is not accountable for their mistakes. Trust me, you won’t destroy velocity if the developer that wrote a feature has to fix a bug in it later on or deal with a customer escalation. What you will have is a developer that understand the customer pain they created and be more careful to write solid and usable features in the future.

6. Customer Escalations Stop Being a Top Priority aka Big Strategy Over Customer Satisfaction

This is kind of like the above and it usually comes from the VP or management. At some point a company grows to the point where they believe they have bigger fish to fry than customer satisfaction. If you are going too slow to keep customers satisfied and work on new strategy at the same time then your organization is sick. Find out what’s really wrong in the organization and fix it. There is no better advertisement for a product than word of mouth. There is nothing more important than making sure a customer’s deployment is working. This does not mean creating one off features for customers. Don’t do that! That will give you a directionless product. Know when to say no to one-off customer requests. But do make sure your customers are happy with your product’s intended use. Always make these a priority even if you are a big company with lots of sales. Treat each customer like you did when you were trying to make your first million dollars in annual sales. Remember those days? Remember how horrified you were if a customer ran into a bug that stopped them from using the product? As an engineer you should be embarrassed when a customer hits a show stopper issue. You should not be able to sleep until it is resolved. If you don’t care that you fucked up a customers week then you are either out of touch or a sociopath.

7. The UX Team is Marginalized

Do not marginalize the user experience team. In the best case scenario UX should not even report to R&D but are a peer of R&D and Product Management. UX should be part of the holy trinity that leads a product line — Product Manager, Technical Lead/Architect, and UX. UX are not visual designers. They do not exist primarily to make the product pretty or sexy. They are essential in making sure the product provides value to customers. They run experiments, validate results, and make sure the product is useable and on point.

8. The Engineering Team has no Customer Contact

Make sure your engineers get out of the building. They need to understand the product and its customers not just the code. Once the developers loose contact with the customer things will soon go catawampus. You will have a technology centric architecture that is more than is required. Simple ways to keep this from happening is to send engineers on POC, Professional Services Engagements, on-site escalation resolution, or even sales calls. You could even have engineers rotate on dealing with a technical support issue or two every once in a while. The idea is to have each engineer know how the product is used, what business it is that we are in, and understand the customer pain.

9. The Team is Resistant to Feature Changes

This one is usually a relic from an older style of doing business. You have this when you see R&D asking for detailed product requirements or marketing requirements documents or complaining that the backlog keeps changing. In today’s world businesses (especially start ups) need to change sometimes even day to day based on customer feedback and market changes. Having small units of work that fit into cycles helps with this. If you have engineers complaining that they can’t fit a feature into a cycle then you probably have an over engineered solution. Get features out there quickly, validate them with customers before and after release, and then perfect the ones that have traction. If you are in sprint 3 and the product manager changes the features you were going to do in sprint 4 then the product manager is doing her job. If you are organized so that PM, Architect, and UX form a trinity then they should all understand why the backlog changed.

10. Tension Between R&D and Product Management

The leadership in R&D and the leadership in Product Management should be pals. If they are not pals you will soon see a rift between everyone in R&D and product management. R&D will blame PM for all the ills in the world and product will not get validated and not get delivered because of in fighting and endless debate. An adversarial relationship between R&D and PM could kill a company. R&D needs to believe in what’s it building and PM needs R&D’s support. If you are organized correctly, meaning that each line is lead by a Product Manager, a Technical Lead, and a UX Lead and they are all held accountable then this should not happen. They are team one. In other words, a technical leads primary team should be the Product Manager and UX lead she works with and not the engineering team spread across multiple products or components. Don’t fuck with PM by asking them to specify every last detail of a story. That is old school. R&D, UX, and PM should do that together.

Conclusion

I guess all of these really boil down to just a few points. R&D must be connected with the customer, work in concert with Product Management and UX, experiment with minimal versions of features first, and value productivity over process.

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s