Category: Uncategorized

Artificial Intelligence (AI) has been part of our working lives for long enough that we are now able to see the impact it has made in areas like productivity, efficiency and security. On Episode 5 of the Florida Tech & Growth Podcast, Paul was joined by three special guests who shared their insights on AI in their organizations.

We heard from:

Zach Wills, the former Head of Engineering at Haven

Nack Kyoo Jung, the CTO at Influur

Michael Lehmbeck, the CTO at BankUnited

about the impact of AI on software engineering, the future of junior engineering roles, and project management and documentation. Read on for their insights on AI-driven efficiency, or listen to the full conversation here.

Zach: “I think it’s incredible what we’ve been able to do with AI. For me personally, it’s changed how I work day-to-day quite a lot. We use GitHub Copilot, and we’ve found another tool that I think is actually even more powerful when it comes to delivering software, which is Cursor. It’s an AI-enabled code editor that goes one step further to do things like tab autocomplete. You can also use it to talk to your codebase in a new way, so that a new engineer can onboard incredibly fast to the codebase. If you have something that you want to build, you can talk to the software and add tests or functionalities, check for bugs, etc.—even enforce a principle. That’s rapidly increased our ability to deliver prototypes and proof of concepts, which is incredible for us as an early-stage startup because a lot of what we’re doing is trying new features, trying new functionality, and seeing what sticks.

Beyond that, I’ve also used it pretty heavily for anything that interacts with our data warehouse. We use Looker as our BI tool, and it’s attached to our data warehouse. We have to write LookML and other types of SQL to visualize the data. That is incredibly easy now compared to three years ago, because you can give it your data model rather than write the code. I personally use AI all the time for things like summaries and transcriptions. I will very often dictate my own notes and then I will ask it to synthesize my muddy stream of consciousness into something a little bit cleaner, which ultimately produces written content way faster than I could write it myself. It’s insane how quickly AI has become a cornerstone of my personal workflow, as well as something that I evangelize to the team.”

Nack: “Since we’re an early-mid-stage startup, AI definitely affects funding rounds. Since it’s such a hot topic, a lot of VCs are interested in putting money into AI, which is something we need to be careful about because, in my opinion, we shouldn’t use AI just for the sake of using AI. We need to make sure that it’s actually a tool that will help in the long run for the company. Sometimes that differentiation is hard to make because AI is such a craze. But, VCs aren’t really concerned about that.

I do think AI is going to be a more long-lasting thing than previous crazes like the Metaverse or NFTs. However, we need to be careful that, just like any other tool, it’s actually helping the company instead of just being there because you want to slap on the AI label. Right now, there’s underlying pressure to make something work that relates to AI, because there’s a better chance to get more funding in the future if we do.”

Michael: “With regards to AI adoption, I think each company has to assess what their risk appetite is when it comes to a rapidly evolving technology. Your adaption is going to be a little bit different depending upon your organization. One of the things that everyone needs to be keeping top of mind from a technology point of view is that AI is very empowering, but the underlying data that the AI is using has to be of quality, otherwise you’re going to get very misguided information. That’s something that often gets overlooked.

I don’t think AI is like blockchain, where it was a hammer trying to find a nail, but I do think that AI has very key underlying dependencies, which include your data and your ability to leverage cloud services. If you’re trying to use AI based on a private data center, all on your own, you’re going to be in a very difficult position. Companies have to keep in mind some of those key dependencies and assess how far along they are in their cloud adoption journey and how mature they are with data governance and data quality in order to be successful with AI. Otherwise, you may be setting very lofty goals and setting yourself up for failure.”

To find out more about effectively adopting AI into your organization, tune into Episode 5 of the Florida Tech & Growth Podcast here.

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 FT.com 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 info@tiropartners.com.

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! info@tiropartners.com

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.