This hang-up with JavaScript Frameworks has been something I’ve been keen to publish for some time, more than anything to get engineers thoughts and help hiring managers and Internal HR recruiters really understand what JavaScript hiring is about.

Time and time again my colleagues and I send CV’s on to companies looking for JavaScript Developers only to hear feedback such as, “he/she does not have enough Backbone” or “Lots of React experience but we use Flux not Redux.” I do my best to overcome this objection in a professional manner without sounding too condescending, remembering I am not an engineer but a recruiter. I appreciate that as a recruiter I need to listen to what a client is using and deliver the right profile back, but come on “YOU’RE MISSING OUT HERE”!

Here is the thing, and I’m sure a lot of good engineers will empathise with this, don’t worry about whether someone has Backbone, Knockout, Express, Ember, Underscore etc etc. but consider whether they have sufficient programming experience in the JavaScript language itself, particularly functional and object-oriented approaches? Have they used an MVC framework in the past? Can they write hand-coded JavaScript from scratch? What is their problem-solving ability like?

The developer who tries to learn every framework to keep up with the latest trend is not as valuable as the specialist JavaScript developer who knows JS inside out. Of course it is important for engineers to keep abreast with the technology and not to get stuck in their ways but it’s about knowing the core principles first and foremost.

There are a lot of full stack PHP developers over the years that I have tried to place with organisations looking for JavaScript Engineers only to be rejected but now find themselves in senior JS positions because they knew their language and they knew their frameworks. All they needed was the documentation and a little bit of time and they grasped it far quicker than the jQuery hacker who never went to University or who never learned JavaScript.

A framework will be chosen to fit the purpose of the project.
William ExcellDirector – Tiro Partners

Interestingly enough I have actually started to see a recent (albeit mini) trend away from frameworks in a few large companies. I’m not saying companies are moving away from frameworks but when you look at the likes of and Zoopla ditching frameworks in favour of vanilla JS on the client side it makes you think what’s up and why? This is mainly due to the SEO implications (not having to cajole Google into parsing and indexing an SPA built using JavaScript) and mobile file size implications (not wanting to force mobile users to download massive amount of large JS files to render site). In turn this has meant moving back towards more server-side rendering (NodeJS) using templating languages like Handlebars and Pug. This means huge rendering speed and a much more simplistic stack.

A framework will be chosen to fit the purpose of the project. This may mean a top class developer might not have worked with frameworks such as React OR Angular because the project has dictated it’s not right but he is going to learn it pretty damn quickly given the chance because ultimately he knows the core principles. I do appreciate that some JavaScript frameworks do not have the same architectural paradigm for example Angular (MVC) and React (V) which is actually a library rather full featured framework, so there may be a steeper learning curve. Or if a contractor is needed to plug a quick gap engineers would need to know these BUT long term this shouldn’t be a concern. And to emphasise my earlier point, just as everyone has assumed Redux has become the king of fluxes, there is a new kid on the bloc that has a good chance to dethrone it! MobX it’s called. You get my point now; things are moving so quickly, all you engineers, hiring managers, internal recruiters and agents, I say to you “don’t get hung-up on the JS framework hang-up”.

As a new grad I was eager to perform when I started my job in recruitment. I spent my last summer days reading around my new market (ok, maybe not all my days) which is Product. I read countless articles on all the different roles I would be recruiting for and many articles on what the Agile methodology is. However, when I began speaking to those who work in these roles I was confused.

Countless times I heard people tell me they did a mix of the two, Product Manager and Product Owner or they wouldn’t care if their next role was a Product Manager or Owner because it’s “just a title”. So my quest to understand if there was a difference in any organisation was born, and does anyone who actually works in this field believe there is a difference.

In short people do believe there is a difference but companies don’t fully understand this yet.

The difference
To me a Product Manager is much more the voice of the customer. Their role is more strategic and broader than a Product Owner; they oversee the product, understand the market, the users and often help create the product from a blank slate. They look after what is to be delivered. A Product Owner, however, is more, tactical. They are much more involved in how the product will be delivered and hold responsibility for the backlog.

The above isn’t just from reading around, I started to ask many Head of Products in my network what they thought the difference was and they answered very much like the above. So why wasn’t this being transferred down? Why weren’t organisations separating the two?

The answers I got was size. A small company will only employ one person, often neither the funds nor the work load to warrant two, and often the Product wasn’t evolved enough to bring in two. So I guess it makes sense to have one employee owning Product and performing the two; it’s tactful, strategic and manageable. Also BA role can be aligned with a product owner and responsibilities shared that way.

Complexity of projects was another point raised in a discussion. I guess this is similar to size. If the project isn’t that complex does it really warrant a Product Owner and Manager when someone could take on responsibility for both and not be maxed out? The definition of a product as well was suggested as another factor in a company’s ability to separate the two roles.

Another point raised within a discussion that may help answer this question is that not all companies are fully agile yet and some (in my eyes) just don’t get it. Buy in from all stakeholders and departments is key for a fully agile environment and not all companies are there yet. So why would we expect them to implement all the roles correctly? It’s unsurprising the roles are blurred when really the overall concept isn’t implemented correctly.

On the other hand though, Product Owner is just a term that has emerged from the Scrum methodology. Therefore, if a company doesn’t use scrum there is no need for a Product Owner. If the company is small maybe it would benefit from a Product Manager playing both roles in a Scrum set up.

I guess my next question will be, is it necessary to differentiate the two roles or simply let the companies do it how they want? There are many roles that have vastly different names in different companies should this be an exception?

To sum up the discussion, bottom line for me is: job title matters a lot less than what a company puts in the job spec. So, to really understand what you’re recruiting for looking into the company structure and their process is vital.

Any job that you are passionate about consumes you. You think about it all the time and are constantly creating hypothetical situations in your head that revolve around your work. My girlfriend recently brought this to my attention and even accused me of becoming boring due to my new lack of variety in conversation. Of course, being mortally offended, I endeavoured to try to and shut up shop on our weekend away to Rome and to enjoy the outstandingly culturally and historically rich city I now found myself in.

However, due to the journalistic prowess of the easyJet inflight magazine the ‘Traveller’ a mere 30 minutes into a work free weekend I found myself (through no fault of my own) reading a truly interesting article about Patrik Arnesson, the CEO of Forza Football and his product journey. Those un-aware of the powerhouse app that is Forza Football, it’s essentially the all encompassing go to guide for football fans, providing in depth info and content from 800 leagues around the world. The core message of the article: ‘get your core product right before adding fancy stuff’.

My mind was racing, this was an issue recounted to myself over a number of coffees and lunches with product people across a number of different industries in different levels of seniorities. Client and candidate side most couldn’t deny or fight the almost seductive nature of the early stages in the Product lifecycle.

Candidates were looking for new opportunities because the company they had worked with from ideation to fruition, were now at the stages of maintenance and improvement. ‘Where was the fun in that?’. My understanding of this dilemma was that those early lifecycle stages provided a real opportunity for creativity, an open road that could and would change. When I ask candidates what they want from their next role the most common answers I hear are: ‘I want to make an impact… I want to be able to learn and grow with the product… I want to work in a truly innovative and agile environment’. I believe these characteristics are very much definitive of a product manager, I’ve never had a client ask for a slow-paced product manager with a distinct lack of creativity. That being said, those innate characteristics create the very problem being discussed, the best and most prominent product people were those who wanted out when the product got ‘boring’. A period that is crucial in determining the success of the product as a whole.

The article touched upon a number of blunders and the consequences that arose from the company chasing the glitz and glamour of creating new features and ‘fun stuff’ over choosing to continue the build on the core product. Essentially, they wasted a huge amount of time, manpower and effort creating things that it turned out the public didn’t want. Their numbers didn’t go up, and they realised after 2 years of creating these new features the true value in getting the core product right. Fortunately for Forza, the app was successful enough to survive those 2 years and is now the second largest football fan app in the world. As I mentioned the article reflected many of the opinions and feelings of my own clients. However, it did make me wonder, how many products don’t survive? How many don’t realise the importance of getting the core product right in time or even at all?

It’s good to learn from your mistakes. It’s better to learn from other people’s mistakes.
Warren BuffetInvestor, tycoon and philanthropist

Learn from other people’s mistakes
Warren Buffet said it well when he said “It’s good to learn from your mistakes. It’s better to learn from other people’s mistakes.” But maybe Jim Rohn said it best when he agreed ‘it’s good to learn from other’s mistakes’ and added ‘it is BEST to learn from other people’s successes.’ If a Product team find themselves at the crossroads, one way leading to Core Product (a well maintained and fairly straight road) the other winding out of sight towards new features and possibly adventure. My advice, listen to Warren Buffet, listen to Jim Rohn, learn from others who have also found themselves at the cross roads. Chose the core product path, build a home, resupply, and if/when the time is right the pathway to new product functions and excitement will still be there for you to explore.

If you are a start up with a new idea, you are working passionately and furiously to create a new product that is attempting to solve a problem, therefore it’s so important to make sure you remember the problem you set out to solve and that the solution for that problem was your core product. Not the extras you want to add. If all the hard work pays off and the product takes off successfully, the core product is the reason why. It works, the consumer likes it, you are getting sales, downloads, hits, whatever the success metric maybe. Whilst that initial success feels incredible (and quite rightly too) it will count for nothing if the success isn’t sustained. That’s why ensuring your product is scalable, stable and continually satisfying the market’s changing needs must be the overarching goal for any product. Without that stability and sustained success, you don’t have a working product and certainly won’t be excited about going back to the drawing board to make it work again.

For a candidate in this position my advice is fairly simple, although it may seem as though you have achieved what you set out to achieve, you paid your dues and have now seen the fruits of your labour. The real challenge may come from ensuring that your now successful product remains on course and reaches the trajectory. Don’t jump ship, it’s almost like spending two years toiling to build a house and then not sleeping in it. The product will again reach a place where you can afford to consider new features and other shiny add-ons.

And there you have it, a humble Product recruiters’ opinion on a prevalent issue in the Product Market. I hope it resonated with you in some way, and would love to hear about your own experience with this situation.

Thanks for reading. Please don’t hesitate to connect and see how we could work together or drop us an email at

Those who know me will be aware of my ambitious nature. On the whole I embrace challenge and every opportunity to reflect on a personal or career capacity if it facilitates growth. I see this partially because of my previous career, whereby I was held accountable for decisions that could ultimately directly impact the lives of vulnerable children and families. Where reflection and the ability to be honest and self aware stood at the core of best practice and personal growth.

With this in mind I felt the need to stay true to these principles as I write this blog at 02:21am and be honest with my network on how I have battled with having a fixed mindset a great deal for the past couple of weeks, particularly as I commenced my piece on Growth Mindset Vs Fixed Mindset. Ironic. Right? …Great timing!

To add some context; two weeks ago, I enjoyed a project management meet up thanks to DPML and guest speaker Chris Davies. At this time, I was embracing every opportunity for growth and most importantly I believed in my ability to grow my knowledge on the PM, Scrum and Agile market. Subsequently deciding to demonstrate my efforts by writing an article: and I do enjoy a good article!!

What happened?
I then avoided putting pen to paper or rather, finger to keyboard (which is slightly more fitting in today’s digital age). What’s more, I began to get defensive and take feedback on the topic from my colleagues and directors personally. To be honest, I wasn’t developing on any level at all. Remember this example. I will park it here for now.

Growth Mindset Vs Fixed Mindset and Project Management
A very wise and influential woman in my life often reminds me: “Sara you don’t know everything and you will never know everything” (Mother, 1993 – present).

All be it this is usually introduced mid argument! On a serious note, another influential woman particularly in this field echoed (Dweck, 2006): “Individuals who believe their talents can be developed (through hard work, good strategies, and input from others) have a growth mindset. They tend to achieve more than those with a more fixed mindset (those who believe their talents are innate gifts). This is because they put more energy into learning and developing.”

Within the PM field and specifically in the context of scrum and Agile; although careful not to lose the interest of those who don’t specialise in these methods. My understanding is that Agile approaches naturally require practitioners to be focused on continuous improvement, which alone implies a growth mindset because you are always looking for new innovative ways for improvement.

Well that was simple. What is all the fuss about? Agile = growth mindset.

If only!
The reality is, we are dealing with the management of human beings and we are complex creatures. If we think about each member of a team and their individual mindsets which are shaped by a combination of their beliefs, attitudes and ideas. As a practitioner hired to manage and support this team, you must possess the ability to recognise the impact of underlying cognitive factors on this person’s ability to work within an agile way. What is your view on this?

Tapping into my Social Work experience, I am making direct links between Albert Ellis (1957) “ABC Model of CBT” and growth and fixed Mindset.

If we go back to the beginning and the example of my recent mindset. On the spectrum of growth to fixed mindset, I felt I was moving ever further towards a fixed mindset. Dweck (2006) encourages me to consider the triggers to my fixed mindset. I concluded:

Setbacks – Typical in recruitment as it is a roller coaster career. However then viewing these as impassable roadblocks rather than a setback.

The ABC model (Ellis, 1957) points me towards considering that it was neither a person, event or situation that caused me to feel “stuck” and unable to bounce back. It was rather my interpretation of the event and my belief system. Subsequently leading me towards feelings of avoidance, defensiveness and lacking belief in my abilities – A FIXED MINDSET.

It is worth pointing out, those in the Agile and Scrum field are not necessarily trained in CBT or related therapeutic practices and in no way, are required to be. However, I am of the view it is imperative to consider the psychological element because of its direct correlation with each team members’ behaviours and mindset.

The organisational context
Finally, where do you feel your company sits on the spectrum of having a growth and fixed mindset and how does this impact on your team? After all, doesn’t teamwork require a growth mindset?

After reaching out to my network in preparation for my article, I entered many discussions around the role of the organisation in driving a growth mindset and reducing fixed mindsets. Differences in mindset may affect broader issues including how employers focus on hiring staff. Employers that hold a fixed mindset may focus more on investment in high ability employees and correspondingly invest less in professional development and ongoing training. Does this sound familiar?

Still, the advice from such a great bunch of practitioners in my network working with mindsets daily, echo the need for organisations to consider the following when striving for true growth:

  • Encourage the recruitment of talent and those with developmental potential.
  • Recruit managers who demonstrate a growth mindset.
  • Drive innovation Develop a culture where learning is valued.
  • Consider the value of cross functional skills and breadth as well as depth of knowledge to increase flexibility of your company.
  • Support Cross-functional collaboration.

To conclude I want to reinforce to individuals and companies in my network, the benefits of reflection, self-awareness and honesty in addressing mindset. By adopting these three principles within a supportive team I was able to build on my resilience and regain belief in my abilities – GROWTH MINDSET!

Mindset is of course a spectrum of which we all are constantly moving within of which I could keep writing about for a considerable amount of time, but I won’t. The content of my article is also always open for discussion and as a specialist in PM, Agile and scrum recruitment, I am eager to continue conversations on this concept with both individuals and companies in this field moving forward.

Get in touch; let’s build something successful together!

Dweck, C. S. (2006). Mindset: the new psychology of success. New York, Random House.
Ellis, A. (1957). Rational Psychotherapy and Individual Psychology. Journal of Individual Psychology, 13: 38-44.