Scaling “high-growth” start-ups in fashion

50% annual growth: How did we do that? This is the original draft that was published at http://www.netcentric.biz/blog/2016/08/50--annual-growth--how-did-we-do-that-.html

I joined Netcentric when there were 12 people in the Barcelona office. Back then, the expansion plans called my attention. The market was vibrant and Elian and Dominik convinced me that Adobe had a great vision for AEM (back then called CQ). They wanted to grow to around 50 people in one year. Today (after three years) we are a team of 250 people in four cities and continue with the same goal of growing and keeping the startup spirit. Adobe has expanded AEM to become the keystone of the Adobe Marketing Cloud and the demand for the product keeps growing. In this atmosphere, growing is just a side effect of the market.

However, growing at a 50% pace during the last three years was not easy. You may wonder, How do you structure the company to be able to respond to change? How do you attract and keep talent? What kind of skills are necessary? And how do you develop them? If you are interested in finding out, keep on reading.

There are different types of entrepreneurship visions. There is one kind of entrepreneurs who focus on a local market, small team, and limited growth. They want to continue doing what they love. Probably their main driver to start a business is their need for independence. These guys hate having a boss and their contribution to the overall job market ranges between 15 to 40 people.

On the other hand, there is a very small set of entrepreneurs who aim high and big. These guys create companies that represent a disproportionately large contribution to net job creation. They are fans of Larry Page and Jeff Bezzos. John Haltiwanger and other researchers call them “high-growth” firms (companies that are adding jobs at a rate of more than 25% percent a year). These are the companies with huge impact in the economy and in innovation. As Andy Groove summarized in a 2010 essay about job creation:

Equally important is what comes after that mythical moment of creation in the garage, as technology goes from prototype to mass production. This is the phase where companies scale up. They work out design details, figure out how to make things affordably, build factories, and hire people by the thousands. Scaling is hard work but necessary to make innovation matter.

Scaling is not easy. To make it right you need to invest in things that are not needed at the present but that become crucial in the future. You have to assume risks and shoot for the sky. You need to trust the people you recently hired and give new responsibilities to everyone (yes, everyone). The people you hire have to be motivated to take on new challenges and work under chaos. People and the company mature by the necessity of getting things done. And of course, you have to be successful in growing and delivering to your clients.

By the way, a great part of the “you” mentioned in the last paragraph, is meant for Netcentric’s board. The board members have been critical in scaling the company by using one key motivation: trust. They trusted us with recruiting, training, building technological infrastructure, rewarding programs, and everything that would take too long for approval. Why hire smart people if you have to tell them what to do, right?

That was another key factor:  if you want to increase motivation, hire motivated people. There is no easy way around that. “Recruiting is the most important activity that I do everyday”. I agree with Eric Schmidt.  Recruiting is key.  I have to admit that we are elitist. Our hiring process is not easy. We have at least three rounds of interviews. We work on problem assignments and have a hiring committee. The selection criteria is strict and explained to everybody who participates on hiring. This approach based on having a sound system for hiring motivated people has definitely been one of the key successes of scaling.

As an employee, I have many challenges and fears and, luckily, the former surpass the latter. The people whom I work with are eager to take on new responsibilities.  There are opportunities for trying new roles in the company, like front end, business analyst, project manager, and system engineering abound. I can create my internship in any of those areas even if I am not part of that discipline group. People proactively create new career pathways, propose new ways of doing things, and are key in pointing out deficiencies.

To help the company grow, coaching becomes a day to day activity. Coaches help others in their professional growth via quarterly, half-year, and yearly appraisals. There are roles such as coaches, buddies, and advocates. Coaches help career development. Advocates support needs and collect overall feedback received. The buddy program helps with the onboarding. And the process of onboarding was revamped to reduce the learning curve by introducing newcomers to how the company operates and review the different careers.

None of this was easy to achieve. None of the processes was set up from the beginning. Many mistakes were made. However, we follow an iterative approach. Our feedback loop is very short and when something does not work, it stands out immediately. People are very active in voicing concerns, in getting involved, in feeling part of the company. And that makes a difference.

I look back and do not regret my career change after working for the status quo. Netcentric continues to become more exciting every day. The fast pace and capacity to deliver our business goals is a key driver and magnet. And yes, besides all that, there is free coffee. Send me an email to mario.rodriguez@netcentric.biz if you would like to check it out.

Others ask for experience, we want your passion

Should experience be a predictor of capacity? I think Guardiola would object. This is a good story about an experiment going terribly right: the Netcentric Academy

(this is the original writing that was published here)

A year ago, the Netcentric director from the Barcelona office approached me with a crazy idea (he usually does that during the summer). He said: “Let’s get graduating students from the university and train them to become backend and frontend developers in three months.” He was really optimistic and certain that it would work. I, on the other hand, thought the dates were aggressive. Additionally, nobody had done it before and, as new experiences go, uncertainty gives away to fear and rejection. Several colleagues also feared getting inexperienced youngsters with no professional experience into our offices without being able to place them in projects facing the client. I am glad to tell you this is a story has a happy ending.

So we did not have much time to prepare. I was myself doubtful it was even possible. However, this is Netcentric, and we do things differently. We set to define the classes that were going to be taught, select the professors that were going to teach them, and the plan to follow. The first major obstacle was the opportunity cost in getting our own developers to teach classes. Therefore, we came up with a solution: let’s leave it open for the students to do their own project. The rest of the time, the students will receive a basic introduction to our building blocks. This decision turned out to be the key of succes. The project was the best part of the academy and allowed a good assessment of motivation, teamwork, and learning.

Things were not easy, though. From the start the resources were limited. Students were mostly gone for the summer. We did not even have office space to teach the classes, so we had to rent tables and chairs, and review the planning in sudoku fashion to align everybody’s requests. It was challenging but it worked. Each Netcentric person I approached showed his/her pride in what they do and willingness to participate.

Today we have more than 20 bright developers that have been onboarded into the company and with a high level of satisfaction from both the tech leads and the developers themselves.

It is not only passion that we asked, of course. Those selected showed a potential for deep analytical thinking and fast learning. They worked under little supervision and were able to be motivated and deliver high quality work in their projects. At the beginning, we debated much about motivation. Were those guys be able to attend a full 8-hour day of classes? Should we have a 6-hour day? Should we include motivating videos from code.org? Reality sometimes is better than fiction and the students did wonderfully, even arriving an hour earlier to have their daily stand-up and staying late to finish their work.

Several times I have asked the students who participated what was the factor of success. I would have never thought possible that level of commitment. The answers vary and everybody has their own reason. However, the most common response is that they wanted to prove how much they could do. I hope society in general would do the same: give a chance to the youth to show what they are capable of. 

Why Software Maintenance Projects Matter

Software developers can be divided into two groups: those working on maintenance projects and those working on new projects. Those in the first group are practical and work under pressure to apply solutions to current problems. Those in the second are more theoretical and have flexibility to take decisions, because their problems have not appeared yet. It seems that everybody wants to be part of the second group but a closer look reveals some interesting facts.

Having a white page to start your design is very attractive to any engineer, architect or creative writer. However, after more than 10 years in the industry, I believe maintenance projects are where you really learn. They are the only place where you can put your design to the test (and by test, I mean the real environment stack, real user base, and real evolution of the product).  And I am not blaming the good architects who designed the system that you inherited. It is impossible to predict the future (even if you are Steve Jobs). There is no magic pill for a design of self-evolved systems (at least not yet). That is why the world requires developers like you with enough insight and vision to identify the root causes of problems and come up with good solutions.

Designs in maintenance projects are tested in real time. One of my first experiences was working on a database connection pool for a bank to handle the database connections. With 50,000 users logging in the morning, the system had to work because if anything went wrong, the connection pool exploded. Not only that, think of the client sitting by you and, if solution A does not work, you have no option but come up with something better. Unlike the design team who worked on theoretical scenarios, you have the real experience to cope with. And this reality includes evolution of hardware, software, dealing with 5 years of data… all that fun.  

It is also on maintenance projects where you gain the trust (or not) from a client. Being close to the end users and primary stakeholders (including those who paid for the software) gives you an opportunity to show them your capacity to solve problems and even predict them. If you are good, you help shape the future of the organisation, eliminating all the daily headaches that they suffer. Learn to listen to the client and end-users. It will make you stand out among the rest.

So, make no mistake the next time you are assigned to a maintenance project; there is plenty to learn from and gain experience in. You will benefit from it more than you think.

How Users Adopt Products

In one of the companies that I used to work for, a group of very smart engineers decided that we needed to opt for a unified development tool for all developers. There were two tools in the market: product corpX and product rebelY. Since they had invested some time and plugins to refine corpX, they wanted to force its use. They had little success on adoption rates. They claimed that some of the problem was in those badass users of rebelY that kept convincing the rest of the team to shift. These badass users were evangelizing the features, they were forming groups of users, they were showing off their results, and even they were wearing proudly political propaganda of the rebelY product (wearing t-shirts and other pride items). Those rebels were resisting and were winning the battle. So they decided it was a moment to force the good in them.

The reaction in itself seemed to me motivated more by emotion than reason (or data), so I decided to write what little I know about product adoption because my friends were going in the wrong direction.

A key feature to highlight is desirability; or said in other terms, that thing that we want and don’t have. Desirability is what drives people to product love. And product love is blind and passionate. It makes users make comments about how they feel empowered by the product. And eventually, those comments reach us, our friends, family members or colleagues. “Can’t believe Marco can do that in one click”. Marco is cool we think. I need to get it (the tool not Marco).

And yes, we really believe more what those close friends say or do than any other corporate advertisement or political propaganda. So what inspires people to make those comments? The answer is simple: Users do not evangelize to their friends because they like the product, but because they like their friends (and the company they work for) -- to quote Kathy Sierra. Users enjoy the bigger context not the product. The bigger context is to create good software and be productive. And results tell the story: "I can create a test in a fly!" "See how Marco can search the repo!" "I can catch bugs before they happen". All of that makes me a better developer so I want to share that with my friends.

The problem is that these badass users are so empowered that they do not shut up. They continue talking. But what is worse is that they do not need to talk. People see the way they work and the results that they are getting. That is even more powerful. They are getting better results.

My claim is not to treat people like puppies. We are rational people making conscious choices. We like to have tools that empower us. And developers need to always think in the big context. The result of the initiative, as in any European movie, is left for you to figure out.

Convert a JAR into Bundle

Personal notes on how to quickly create a bundle based on a list of jars or other dependencies. It uses the content-package and embedded maven configuration to easily deploy the bundle.

Normal and Painful Way
The most difficult way is to follow the standard way and create a manifest file with all the description available. You will also need to figure out the dependencies of your bundle. This blog will show the easy way to package a bundle with all the dependencies that you need.

Step#1: Easy Way

The project is quickly created by the classic mvn archetype. The idea is to follow the structure. 

myprojectlib/depency-pkg-libs

where myprojectlib is the root project and depency-pkg-libs the module with the declared dependencies. We will not include any other code into the folders. Also for the purposes of example, we will use the JUnit Sling Testing on the server side. This bundle is not included in the default distribution and requires JUnit as a dependency.

Step #2: Create the First module

mvn archetype:generate

Make sure you create a basic maven repository with the pom project as root.

In our case the  myprojectlib will look like:

<packaging>pom</packaging>

Step#3: Create the  Content-package

Create a package depency-pkg-libs inside the root directory. Make sure you change the packaging so that it becomes content-package

<packaging>content-package</packaging>

Step#4: Add Embedded List

To your list of build plugins, add the content-package-maven plugin

<groupId>com.day.jcr.vault</groupId>

<artifactId>content-package-maven-plugin</artifactId>

In the list of embedded element add those dependencies that you need. In my case, the junit.remote:

<embeddeds>

  <embedded>

     <groupId>org.apache.sling</groupId>

      <artifactId>org.apache.sling.junit.remote</artifactId>

     <target>${package.root}/install</target>

  </embedded>

</embeddeds>

You should also add the same artifacts listed in embedded to your list of dependencies. Otherwise those will not be installed.

     <dependency>
          <groupId>org.apache.sling</groupId>
          <artifactId>org.apache.sling.junit.remote</artifactId>
          <version>1.0.6</version>
          <scope>provided</scope>
      </dependency>

Actual Code
You can check the actual code from bitbucket. The meat is in the pom.

• https://bitbucket.org/sparktronics/coquette/src

References

This blog is based on the following resources.

• The maven archetype for CQ5.6
• Content Package Maven Plugin

Retrieving Service from Request

Quick way to retrieve a service from a slingRequest

private <E> E getServiceFormRequest(
final SlingHttpServletRequest request, Class<E> serviceType ){
        final SlingBindings bindings = 
(SlingBindings) request.getAttribute(SlingBindings.class.getName());
        SlingScriptHelper slingScriptHelper = bindings.getSling();
        return slingScriptHelper.getService(serviceType);
    }

Date Range Query Medicine for CQ AEM

One of the most annoying features of xpath queries is the performance problem of date range queries. QueryBuilder tends to perform badly. You can see Marcel's presentation in AdaptTo if you want to know the details. Thus, when faced with this problem, there are several alternatives:

• modifying the granularity of the dates,so that you select up to the day and exclude hours/min/secs
• using a node structure in which the date is saved as the path; for example,
• yyyy/mm/dd/my_content_node
• or converting the date property into a long 

I am going to focus on the third one: ways to convert a date property into a long property.

Approach
The basic idea is to leverage the JCR Observation offered in AEM to add a property of type long each time a property of type date is created or modified.

First I created my own namespace (thanks this notes) by just going to

http://<host>:<port>/crx/explorer/nodetypes/index.jsp

I selected my own namespace netval so that there will be no conflicts with existing properties. 

Then I registered my class DatePropertyEventListener that implements the EventListener interface. The class needs to use the @Component annotation. You have to register for the event listener in the @Activate method. Make sure you get the ComponentContext in the activate method in order to register for the event. 

In my onEvent I used the EventIterator to get the property. I then filtered those properties that are of type date. Conveniently the Property class can return almost any type of value being String, long, Calendar, etc. In my case I needed the value as a long. 

Once I have the value, I can set it in the new property that has netval as the namespace and the name of the property in order to avoid collisions. For example, if the attribute name was activationDate the new attribute would be:

netval:activationDate

Code
The first thing is to register and de-register the event listener in the @Activate and @Deactivate methods. 

A quick look at my DatePropertyEventListener class reveals the following. The observationManager and admin session are class attributes. They will be used in the @Deactivate  nd Activate methods. It is in the @Activate method where we register the event listener. 

observationManager = adminSession.getWorkspace().getObservationManager();
observationManager.addEventListener(this,
Event.PROPERTY_ADDED|Event.PROPERTY_CHANGED,
                "/content/news/", // absolute path
                true, // isDeep
                null, // uuid
                null, // nodeTypeName
                true // no local
        );

Note that the absolute path is restrictive to the root path of your content. I highly recommend being as specific as possible in order not to receive too much noise.

The onEvent it is easy to get the date property

        while( eventIterator.hasNext() ){
            final Event event = eventIterator.nextEvent();
            if(PropertyType.DATE == getPropertyType(event) ){

Caveats and Warnings
This procedure should be disabled for operations that modify many nodes, like during a migration of content.

A suggestion is to have a producer-consumer data structure (like LinkedBlockedQueue) that will allow you to process the events more efficiently.