The practice of no-code is becoming one of the growing tech trends in software development, and as a Nearshore development software company, here at Scio we take a look at what it could mean for our industry, and where the future of digital applications may be headed. Enjoy!
From the very beginning, computers had the power to make our life easier as long as we knew how to speak in the same language as them, but as these machines became common in our daily lives, the way we interfaced with them changed, and little by little the prospect of building programs and products through them started to be, more inclusive of more and more people getting involved. .
A good example is the simple act of editing a text document on a computer; nowadays it’s as easy as opening a word processor and start typing, but there was a point in time when you needed to understand special commands, known then as “control codes” (the grandparents of modern mark-up code) to produce a legible, well formatted document.
Things like margins, font sizes, and line spacing had to be manually calibrated before you could write anything printable, so the practice of writing in a computer was out of reach of most people until the arrival of WYSIWYG, an acronym of “What You See Is What You Get”, which is a system that simplified this process, showing you the end result of a document as you worked on it.
In other words, there was a point where we understood the need to adapt the use of a computer as a tool for common people, offering the ability of accomplishing things, like writing a text, making a presentation or even creating a website without having to go through the lengthy process of learning code.
WYSIWYG was a huge step into making computer software friendly, and today we can consider it one of the first examples of “no-code”: the ability to create digital objects in a quick and simplified way, which now seems one of the biggest trends in software development. However, what would a future with a “no-code” ethos be like?
A growing demand
Today, you can think of “no-code” as a way to program websites, mobile apps, and games without using codes, scripts, or sets of commands. There are many no-code development platforms out there that allow both programmers and non-programmers alike to create software through simple graphical user interfaces instead of traditional line-by-line coding, and they are becoming more common day after day by virtue of their simplicity.
“No-code is simply an abstraction layer over code. Meaning, it takes the fundamentals of code and translates them into simple drag-and-drop solutions — allowing creators to build modern apps and websites visually. A no-code development platform can deliver all of the functionality of HTML5, CSS, and Javascript, but you don’t have to know any of these programming languages to jump in and start building,” indicates Webflow, a provider of such platforms.
Although low/no-code (LCNC) has been around for a while, it’s only recently that the software development community is taking notice. In 2018, Gartner predicted that by 2024, «low-code development will be responsible for more than 65% of application development activity«, and software development research firm Forrester has called low-code «the most significant trend affecting software development today.«
The result is that today many platforms provide ways for users to create their own solutions, and developers have found it easier and more convenient than ever before to use them, in order to satisfy a growing demand from customers who want software quickly without having any hassle or stress attached.
This, in turn, has led companies across all industries to not only develop these types of products but also hire people specializing solely in developing computer programs through no-code platforms — a trend known as “shifting left” by some industry veterans due to its increasing popularity among younger generations.
However, what’s driving this no-code movement? There are a few factors, and the main one is the increasing democratization of software development. In the past, programming used to be a dark art, known only to a select few who were brave enough to learn its secrets and understand how to apply them effectively. But with the rise of no-code platforms, the barriers of entry for software development are now much lower, and virtually anyone can create software, regardless of their coding ability. But what does this landscape look like?
The democratization of software development
If you are part of the software development industry, you have seen it: the demand for software developers of all kinds has skyrocketed during the last decade (especially when you factor in the sudden need for technological solutions after the beginning of the Covid-19 pandemic in 2020), so to satisfy this demand, many platforms have started to offer low-code/no-code alternatives that let people without prior experience in programming to create their own software; a sort of “Development-as-a-Service” (DaaS) paradigm where software development is increasingly accessible to the masses.
“This, obviously, has resulted in the increasing popularization of digital solutions for businesses and entrepreneurs of every kind, who now are seeing the technological barriers of the past start breaking down, giving the chance to most people to “leap ahead” and participate in a world where software is increasingly critical to success, giving them the ability to develop some basic software to suit their needs”, said Luis Aburto, CEO and Co-Founder of Scio, about this new trend.
However, this democratization, although desirable and necessary in our modern, technologically-focused world, also comes with downsides that most enterprises should be aware of. And first and foremost is: how does innovation work when an organization depends on quick, ready-made solutions for its unique challenges?
“Low-code tooling does not replace the need for traditionally-built enterprise applications. There will always be needs for pro-developer built solutions such as critical APIs, low-latency, high-performance web applications, or even native mobile apps”, says Software Architect and Vice-President of OneStream Software, Ryan Berry. “Low-code tooling builds a bridge to allow the business to enhance portfolios of both commercial off-the-shelf and in-house built applications, allowing citizen developers the ability to rapidly build applications such as input forms, data validation applications and remote monitoring or management tools.«
And although this is an important step toward digitalization, software development is much more than just building a product; compliance, scalability, security, and even the need to touch all the points of an organization to make sure the product is actually achieving a goal is not something that can be built with a few clicks in a platform. Ultimately, even no-code solutions require expertise and management to ensure success in a project.
Security, in particular, is the bigger concern with the rapid adoption of DaaS and NC/LC software, where depending on a single platform, accessing sensitive data can be a trivial task. “One problem with some low-code and no-code platforms is that end-users are sometimes in a position to make decisions about configurations, permissions, and access controls. […] There are inherent risks in how customer data is siloed and partitioned in these platforms”.
This has given rise to the (very cool sounding, if we are honest) concept of “shadow IT”, or “the use of IT-related hardware or software by a department or individual without the knowledge of the IT or security group within the organization. It can encompass cloud services, software, and hardware”, as defined by Cisco. Because with the increased offer of platforms, services, and apps that could help to simplify a project, comes an increasing comfort in using such tools without proper vetting or research. The result is an IT or security department left in the shadows when trouble comes.
“With the consumerization of IT, hundreds of these applications are in use at the typical enterprise. The lack of visibility into them represents a security gap. Although some applications are harmless, others include functionality such as file sharing and storage, or collaboration, which can present big risks to an organization and its sensitive data. IT and security departments need to see what applications are being used and what risks they pose”, continues the same organization.
No-code: An imperfect solution?
Despite its challenges, the rise of no-code is inevitable, but that doesn’t mean that “traditional” programming is going away. Although no-code platforms give people a starting point to build and digitalize their own ideas, it has its limits. As we mentioned, innovation and scalability are difficult to achieve with these tools, and every organization, sooner or later, faces unique challenges that sometimes cannot be solved with “one size fits all” software solutions.
“Since low-code/no-code platforms are optimized for simple use cases, employees or practitioners must work within tight, platform-specific constraints when problems arise. Tools with limitations will produce limited results”, indicates the IT journalism site Ciodive (no relation).
Custom-made, proprietary software built to the specific needs of an organization or market will always be the better option in the long run, especially as organizations mature and specific expectations have to be met, so what “no-code” solutions offer is a way to bridge the gap between programmers and non-programmers to build better products as a whole.
And even then, today the options to build or expand existing products are more vast and convenient than before. Nearshore development, for example, offers a way to bring expertise to an existing project within the same language and time zones, making the prospect of developing software and testing ideas easier than ever. Although the solutions offered by no-code platforms are a great way to bridge the need between technology and practicality, there’s still some UX, UI, and expert development insight needed to create flexible, scalable, and cost-effective solutions that meet their specific business needs. So if you’re looking to get ahead of the curve, contact us today, and let’s talk about how we can help you embrace the future of software development.
The Key Takeaways:
Software development is going through a democratization process that allows non-programming people to digitize and use technology to their advantage.
The biggest expression of this is “no-code”: the ability to create software products without the need of coding.
Although this is a solution that works for many, it’s not the end all of software development, as there are many areas (like security, scalability, compliance and so on) that are limited with a no-code solution.
Today, however, options like Nearshore software development offer a way to bring the expertise necessary to create and develop software when an organization is mature enough to do so.
Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies to help you reach new heights. We have been developing since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – we’ll be happy to help you achieve your business goals.
Untangling how deeply our life changed during the Covid-19 pandemic will take a long time, and while we are still dealing with much of its aftermath, the process of planning the future doesn’t stop, even if we aren’t quite sure of what’s next for the industry.
“You can’t just link years of experience to the number of different technologies you may know. Being a Senior or Lead developer includes soft skills.”
— Helena Matamoros, Human Capital Manager at Scio.
When it comes to the difference between junior and senior developers, drawing a clear line of separation is more difficult than you would think. On one hand, a developer with two or three years of experience could still be learning the ropes of different roles, while on the other, a developer with between 5 and 10 years of experience keeps learning new frameworks and technologies every day. So if years of experience alone aren’t the most reliable metric, what concrete characteristics differentiate between a junior and a senior?
This is an important question because determining where you stand is the first step to knowing where to take your career and how to make it happen, even if you find that an answer is not as easy to find. Forbes magazine in this article, for example, begins by analyzing knowledge as a metric of seniority:
“Career growth in software engineering (and many other areas) is determined by the depth of knowledge and the breadth of expertise. A project can scale both horizontally, and vertically – which requires a different set of skills and experience in practical applications following both patterns”, notes the article.
However, defining what this “knowledge” means and entails goes beyond mere technical proficiency; how both kinds of developers handle a project, their approach and the outcomes they offer have as much weight as everything else: “In practice, a senior developer […] can assess the risks, ask the right follow-up questions, determine the right workflow, analyze the possible bottlenecks and deliver a stable solution. A junior developer can solve a limited set of problems with a smaller subset of alternative solutions.”
Just like playing tennis
This concept of knowledge reminded me of an interesting essay about tennis that can help illustrate this idea more easily. Called “Loser’s Game”, and written by investment consultant Chares Ellis, this text evaluates the difference between professional and amateur players, sheding a light on the psychology of a person trying to master a skill.
In short, a professional tennis player wins by earning more points than their opponent during a match (playing a “winner’s game”), which seems to be a sensible strategy for a competitive sport. However, it comes into focus when you learn that an amateur player has the exact opposite attitude: they try to win by losing fewer points than their opponents, playing a so-called “loser’s game”.
In other words, a professional tennis player tends to be more offensive, risking more for higher rewards. An amateur player is more defensive, setting on “safe” strategies that result in fewer risks and thus, lower rewards. And this mindset comes from both players having very different perspectives on the game: a professional plays long term, focused on the final result only, while an amateur focuses on each play, paying more attention to the short term gains.
Translating this to software development, we can say that a professional focuses more on outcomes, or the final result of the development process, while the amateur deals in outputs, or the result of each individual step of the project, and one of the key steps in the path of becoming a senior developer (or tennis player, for that matter) is recognizing and overcoming the difference between both approaches.
“Senior developers realize that software is very complex. It’s not possible to identify all the requirements upfront, they will change, there will be more requirements found, and know the project is not likely to hit the deadlines, or the software will be wrong on the early iterations. This isn’t because of bad development, it’s because of the creative process of creating software. Junior developers take “wrong” software personally, even if creating the wrong software is the path to creating the right software”, explains the blog ITNEXT in their article about this topic.
This, more than anything else, is where a line can be drawn indicating the difference between Junior and Senior developers; beyond just knowledge (which informs every individual approach), the way both types of developers conceptualize development, as well as how they collaborate with the rest of the team, is the threshold.
“This question is somewhat difficult to answer”, says Helena Matamoros, Scio’s Human Capital Manager, when presented with the question of how Scio defines the required seniority for different positions. “You can’t just link years of experience to the number of different technologies you may know. Being a Senior or Lead developer includes soft skills, such as leading teams, supervising the work of others, assigning tasks, reporting statuses, and visualizing obstacles in development, among other things. If you have been a developer for 10 years without these kinds of responsibilities, at least for Scio, you cannot be considered Senior.”
A quick start-up guide to seniority
Following this logic, then, we can begin to define a junior and a senior by the level of autonomy they can have during the development cycle of a product. This autonomy can include everything from technical knowledge (that is, how much supervision a given individual needs to complete a task), to their capacities to see the full picture of development (especially what concerns decision-making and direction of the project), so we can go back to the framework that the “Loser’s Game” essay defines for tennis players, as well as the characteristics defined by Helena, to start painting a broad picture of both types of developers:
Junior Developer:
Requires a higher level of support from their teammates.
Avoids making decisions without consulting superiors.
Weights risks in terms of outputs.
Prone to fixate more on the features of the product rather than its value as a whole.
Consider their mistakes a failure to avoid at all costs.
Less than five years of experience in a professional setting.
Senior Developer:
Requires a lower level of support, and may bring it to their teammates.
Is capable of analyzing the project and making their own decisions about its direction.
Weights risks in terms of outcomes.
Tends to consider more the value of the product as a whole.
Considers mistakes as a normal part of the process, and learns from them.
More than five years of experience in professional settings.
The last points in both definitions are included because even if the experience doesn’t dictate seniority, the skills necessary to act with autonomy, technical expertise, and leadership need time to develop, so engineers, programmers, and developers with a few years in their resumes are more likely to have the practice necessary to master this level.
This, however, is not a definitive list of characteristics, but an assessment of the behaviors that result from experience developing software, and it doesn’t even go into depth about the skill sets and knowledge that come from years of collaboration to bring the perfect outcome.
What we are trying to convey is that technical know-how is just the starting point; in collaborative environments where a team works with a client to achieve a specific goal, honing soft skills, getting comfortable with mistakes, bringing every learned lesson to the next project, and knowing how to manage expectations, resources, time and outputs is what a Junior developer needs to take the next step in their careers.
After all, growing as a developer is similar to growing as an adult; responsibilities get more important, you start paying attention to things you didn’t before, and before you know it, you are making your own way in the world. So what’s the next step you want to take?
It’s easy to see the idea of success as a default goal, something everyone should be looking for in any endeavor they start. And while it’s true that always looking for a specific destination is part of our nature, what does success mean? Because when we talk about success, it’s easy to forget that it never looks the same for everyone.
Truth is, success comes from a very personal place for most people, where our experiences and expectations shape the way we work and collaborate, and the specific things we choose to focus on. That’s why at Scio we believe that a good organization leaves enough space to let every collaborator reach success on their terms.
So what is a success, then? As we were curious about what drives each of our developers and engineers, we sent a survey to all the Scioneers to ask this very important question: what does success look like to you?
Success is different for everyone, but what does it look like to you?
The importance of balance
“Success is feeling in control of my personal life”, states one of the responses we got. “Being able to feel like I’m doing something valuable, having the strength and motivation to continue doing the things I love, and also being happy with the ones around me.” This image of success, for example, points out the important balance between work and personal life, one of the core values of Scio regarding their collaborators. We consider this is an important topic because developing software is as much of a creative endeavor as a technical one, and having people who keep healthy boundaries is crucial to always arrive at the best outcomes.
To this end, fostering a good culture of collaboration and camaraderie is the best approach to ensure that a project is completed successfully, as it can also mean that your work doesn’t go unnoticed.
“I like that Scio’s culture promotes the gesture of congratulating the team, both individually and as a whole”, says another of the answers we got.“I like the post-mortem charts we have about our successful projects, where they make sure all the team knows we are aware of their achievements. We even have social meetings to celebrate successful goals, which I think it’s a good idea. So let’s continue promoting the gesture of congratulating our teams for their achievements.”
This is one of the examples of the ways Scio tries to maintain mutual support in everything we do, and something as simple as notifying everyone that a team has achieved a goal, or having a group call to just chat and relax, goes a long way toward it.
Success beyond the office
However, for some, success transcends the workplace and instead focuses on how it affects a collaborator’s everyday life. “Having my own home, seeing my kids happy, and maybe even running a marathon in another country is success” was one of the answers we got, as well as “Feeling full, and having yourself, your family, your significant other, your mind, your work, and your world in balance” and “Being able to do what I like in life and enjoy every second.”
This topic keeps coming out because a clear balance between work and personal life has been increasingly desired among both developers and companies starting to embrace the advantages of remote work and hybrid collaboration models, so making sure a healthy equilibrium exists is one of our core values here at Scio. “Feeling happy and comfortable with where you are”, another one of our responses, sums it up very well.
We understand that, due to the nature of software development, sometimes keeping this balance is tricky, even if Nearshore companies like Scio offer plenty of flexibility and options to work, so taking the steps to ensure that our collaborators can define success beyond the needs of a project goes a long way.
This also ties with another concept that many developers find attractive in any workplace: the chance to learn and grow as they work, which seemed to be a focal point in many of the answers we received. “Meeting the objectives and goals, keep the things I learned, as well as learning from the mistakes to improve”, and “Creating something of value that has a positive impact on the people you care about” get to the point of it, as a successful person might also be one that learns, grows and creates useful things from the work they do.
“Looks like having a clean conscience, lots of self-caring, not reserving everything to myself, feeling useful, achieving a wisdom state” was an unexpected answer. A lot of people can see success in purely personal terms (i.e. “how I feel about this thing I did?), so creating an environment where collaboration and personal growth are on the same frequency tends to deliver the best outcomes.
The success of living well
And last, it’s not a secret that many go into software development because it’s a very in-demand field with lots of organizations to choose from to collaborate with, and compensation is always important for anyone looking to join an organization that shares their values. “For me, is to be financially stable enough to give my family a better life, while also being happy in your job and what you like. To be successful is also to be recognized in your work and know that you are an important part of your company”, reads one of the answers, highlighting success as having the means to support your loved ones while also working on something you feel passionate about.
“For me, success is when your lifestyle and quality of life improves significantly and money isn’t an issue at all”, continues another of the responses. “While also achieving your personal and professional goals, feeling full and happy. Then you have a balance of these ‘pillars’ and yet you are further away from where you started.”
As we reveal more responses, we can start to see that “success” is, at the end of it, directing your life in the way you want to, down to every detail, as this answer manages to explain beautifully: “For me, success has many shapes. From small achievements to the greatest goals, success can happen anywhere, in any place, both in our personal and professional lives, in the financial sense, or even with the people around you”, trying to get across how success is present in our daily lives.
“Even in defeat, we can see success in learning something, feeling good about it, making ourselves proud, and gaining more knowledge in return. If we see it like this, anything we achieve is a success.”
So what do you think? How do you personally define success and how does it get reflected in your personal life? Is it something concrete you work towards every day, or a state of life you want to achieve? Because no matter what your definition of success is, at Scio, we are willing to lend you a hand and achieve your best possible outcome.
“Are you an office person, or a home person?” might have been a weird question to ask in a job interview a couple of years ago, but as our relationship with jobs evolves, we begin to understand the different ways people see work, which have an immense weight in the ways we relate and engage with a particular organization.
Let’s think back for a second and ask ourselves: since the pandemic began, what was the biggest difference we felt working from home? It’s not difficult to imagine that everyone had a different reaction to this change: some found themselves missing the interactions of the office, while others found that working from home was an ideal arrangement, and a third group looked for a middle ground working at the office some days, and from home the others. So the question is: do you have a preference? Does that impact your work?
“The equilibrium between productivity and presence is one of the hardest to master in business”, mentions this Forbes article analyzing this situation. “We often think of ourselves separate from the environment, the system, the culture, the work. In reality, there is very deep interconnectedness to our being.”
In other words, the environment in which we collaborate affects the results we have and is clear that people, as individuals, have personal preferences in the ways they work. And if that conclusion might seem obvious, it seemed to need the upheaval of a pandemic for many companies to start harnessing this newfound approach.
“It’s a shift away from the one-size-fits-all approach of the past, where the work is designed (complete with open-plan offices, fluoro-lighting, 9:00 am starts and a five-day workweek) and then people are squeezed into it”, says an article published by the news network ABC. “But one size never really fits all.”
This gives us an idea: is it possible to ensure that a collaborator can have more control over the conditions of their work? Yes, and it’s becoming a topic of discussion everywhere, especially in Tech, where disruption of the status quo is the name of the game: Hyperpersonalization.
The rise of Hyperpersonalization
How do you prefer to work? Where? When? Why? Everyone has a different answer to these questions, so collaborating in an environment that takes them into account makes all the difference in our productivity. In software development, for example, this was already a trend before the pandemic, with things like having the option to work from home one day a week or offering different hours depending on personal preference becoming normal.
However, the pandemic came to be one of the final blows at our traditional “office hours”, with a big percentage of people discovering ways to work that they really couldn’t consider before, changing the way many organizations collaborate with employees.
“In the past, workplace strategists were able to assign flexible working ratios based on a team and its primary functions. With the mass-scale adoption of hybrid working, the preferences of employees coming into the office have become hyper-personalized. We can no longer assume an employee or team will be in on specific days due to their job function or demographic”, indicates the blog The Pulse about this trend.
And it’s easy to see how these circumstances might define the outcome of any given project. After all, are your most productive times the same as everybody else’s? Is your home the best place to get things done? Or do you like to be at home, but also have the option of an office for important meetings or access to better infrastructure if you need it?
“Hyper personalization is usually associated with marketing products and services to individual consumers — think about how Netflix builds up a profile of what you like to watch and uses that to suggest content to you or the way Spotify serves up new songs based on what you’ve listened to before — but it can also be applied to the workplace”, continues the ABC article about the topic. “The pandemic gave many workers a chance to dip a toe into the hyper-personalization waters.”
However, what does hyper-personalization actually look like in action? Because we must keep in mind that this concept encompasses lots of different elements, ones that go from the business you are working from, to the individual interests and affinities of each developer and collaborator.
“I’ve been part of some very long projects”, says Carlos Estrada, one of the Lead Developers at Scio. “And one time, after six or seven years with the same client, I told Rodimiro [Scio’s Service Delivery Manager and Co-Founder] that I just felt in a rut, doing the same thing every day. He understood and said he had a couple of projects I could help with during my “dead” hours at Scio. I liked that openness, and it helped me explore other types of tasks that I was interested in.”
As this anecdote shows, “hyper-personalization” doesn’t have to be a complete upheaval in a company; just being listened to and working with an organization open to making changes by offering options for different types of people, can go a long way. To this end, that same ABC article we quoted earlier gives us some questions to consider and discuss hyper-personalization, and define where you want to direct your career:
When and how do you work your best, and in what environment
What you find engaging and meaningful
Where your strengths lie
The ideal place of work and your desired mix of responsibilities
For example, while Scio is a Nearshore company with developers all over Latin America, which are permanent remote collaborators, for those locally in Morelia we plan to implement a “hybrid” model of work, where the week is divided between home and office days. Also, we offer different start and finishing times, in case you prefer something different than the traditional 9 to 6, and three days of PTO in case you need to take time off for any personal reason, among other options aimed at our collaborators as individuals who have different affinities and preferences.
“When it comes to creating the right culture of an organization and/or building an attractive brand, the question actually becomes how do we rethink our existence, policies, and structures so that it can reflect (as authentically as possible) some of our deepest values, ways of connecting and working?”, concludes Forbes.
And this last question is at the heart of it: the ways we connect as individuals with our jobs matter, so choosing an organization that understands, respects, and tries to implement measures to give collaborators some freedom to work as they see fit is invaluable to foster a healthy, engaged culture.
A software developer is a person who likes to learn as a trade, try new things, look for different approaches, experiment with new languages, and be part of a community that exchanges information, knowledge, and tips. Especially today, with our world more driven by software than ever, the possibilities look endless, so to choose a place to apply your skills is also to choose a place that gives you something in return, like the opportunity to learn and teach everything you know.
Such places brew communities that go beyond the workplace; it creates a culture of sharing that benefits everyone in the organization, from programmer to programmer, from team to team, and from partner to partner. Encouraging this mindset is one of the main goals of Scio, and for close to ten years now, our organization has been focusing on an approach in which every one of our collaborators can set their goals, work towards them, and grow.
However, what does this process look like? What do we offer our engineers, and every collaborator in terms of growth, no matter if they are just starting their careers or more seasoned veterans looking for a new challenge?
The joys of learning
“I was in my last college semester when Luis and Helena came to my school to give a talk. They were looking to open positions for interns at Scio for the first time, and a teacher encouraged me to apply”, says Carlos Estrada, a Lead Application Developer and member of the Coaching Committee at Scio. “And 12 years later, I’m still part of this company”.
His story is not an uncommon one, but it helps illustrate the approach of Scio to its collaborators. “I am a Systems Engineer specializing in Networks and Web Technologies, which was mostly about handling cables and connecting routers, and when I joined Scio as an intern, I realized I had some gaps that I wouldn’t have if I had chosen Software Engineering. A lot of the concepts I wasn’t familiar with, like SCRUM or Unit Testing, I had to learn as I collaborated on my first projects.”
The realization that school maybe didn’t teach us everything we need is something we are all too familiar with, but you also eventually realize that our learning process never really stops, no matter if you are a Junior, Senior, or Lead Programmer. As we mentioned, around the time Carlos joined our team, we also started developing a way for our collaborators to share and obtain all the skills they wanted: Sensei-Creati, our coaching and workshopping program where every Scioneer can share and grow their skillset.
“Sensei-Creati is a mix of both coaching and mentoring, where we offer support to help you grow as a collaborator. It’s a whole exchange process between the Sensei (Coaches), and the Creati (Coachees), where we create a culture of help and mutual support in every aspect”, explains Yamila Solari, Co-Founder, General Manager, and Coaching Leader at Scio. “A Creati approaches a Sensei, and if the Sensei accepts, the Creati starts a process to learn what they are interested in, choosing which technical, soft, or personal development skills they want to improve. After all, the Sensei may have completely different viewpoints or experiences, which allows the Creati to expand their options and vision.”
The advantage of this program is that it is not directed only to junior staff looking to “level up”; anyone can be part of the program, be it as a Creati or as a Sensei, no matter their level of seniority. “If someone in IT is interested in Quality Assurance, they have the opportunity to add that to their skill set through this program. Scio’s not an organization that only values your current skills; we want you to grow as a whole, and if that’s what you want to work on, we can gladly help you”, continues Yamila about the goal of the Sensei-Creati program.
The only requisite to becoming a Sensei is participating in the program as a Creati beforehand, and then taking a short course on coaching to teach you the best ways to share your feedback, opinions, and advice. “Coaching is not telling people what to do; it’s helping them to do what they want to do, with no judgment and through active listening, offering empathy and a communication space focused on strength to emphasize how it can be used to overcome challenges”, concludes Yamila.
The joy of teaching
“Even when I didn’t know the theory, I was practicing and learning new skills, which is something you need to do a lot in this industry; every month or so, it seems like a new version of the framework you were using comes out, and you need to adapt to it quickly”, continues Carlos.
This is true; as an industry that’s always moving forward, any programmer and engineer passionate about their work will look for ways to keep updated, experiment, and apply any new skill they get. “We still have interns [now called Apprentices], and I always make sure to tell them to choose their specialization carefully and choose what they want to do, to avoid making my mistakes.”
Due to his seniority, Carlos eventually was invited to be part of the “Coaching Committee”, tasked to bring their input to everything related to the developers at Scio, like reviewing the performance of developers to give promotions, designing technical tests for new candidates, or in the case of Sensei-Creati, developing more workshops oriented for the more senior staff. After all, the Sensei-Creati program aims to be interesting for everyone, and having the point of view of someone with as many years of experience as Carlos is invaluable.
“I remember how nervous I was when I started to become a coach because at the very beginning I didn’t know how to be a mentor. However, the first time a Creati approached me to learn a technology I knew, we hit off quickly because we shared the same interests and affinities, and with my first apprentices, the code I was showing them was bugged and I had to fix it overnight, which also taught me to prepare myself better. After that, with the help of Yamila, you get the hang of it, and now I have tons of apprentices and Creati that I know how to help in everything they need”, Carlos tells about the experience of becoming a coach at Scio.
This is a cycle of learning and sharing that still drives much of the community of software developers in the industry, and one that Scio wants to keep encouraging. “I like to think of our profession in terms of brotherhoods. We are in the same business, we see value in cooperation, and we are colleagues. We always consider new points of view, and stories of success and failures are the prime currency for us”, says the Argentinean blog Pienso Luego Pienso about the collaborative nature of programming. And that can’t be truer; curiosity is what drives software, and every innovation is built over a shared knowledge.
“Coaching in Scio started about 10 years ago, as a way to facilitate the work of supervisors and evaluate the performance of people. That was our more traditional approach, which didn’t work the way we wanted until we came to realize that people only learn when they are open to it”, continues Yamila about the development of this program. “So after many iterations, this program became voluntary and without a supervisory element to it. It’s a lot more powerful this way because nobody is telling you to do something, you do it because you want to”. And will keep being the goal here: becoming a place that goes beyond a job, into a place where you can focus on yourself as a developer, a person, and a collaborator eager to learn more.
There are a lot of opinions about the best possible way of measuring productivity, but that can bring us to another question entirely: why measure it at all? In this second part of our interview with Adolfo Cruz, we dig into the reasons why measuring productivity is important for any organization.
By Scio Team
If you are adding value for a client during a product’s development, creating something they can use to attract more users or increase their profits, you may say the time invested in the process was productive, but how do you measure that? Can it be done?
Productivity can be witnessed, it happens right in front of you when a team is making progress, but translating that into data is not an easy task; it takes a lot of time and effort to get right, and it might take focus away from the resulting product, ironically affecting your productivity.
It’s similar to that quantum physics phenomenon where you could change the outcome of something by observing it; all the effort invested in getting exact numbers to measure productivity could make you neglect stuff that has value for the product developed, so you need to be very careful in how you implement measurements to not interfere.
So this begs a very important question: why measure productivity at all? You can see people in the software industry questioning that, going as far as suggesting it’s unnecessary, but we disagree. At Scio, we want to know if our engineers are offering real value to our clients, which is very important to us even if sometimes we use subjective, case-by-case measures to do so.
Measurements impact the way products are being developed
Reaching a standard that applies to everyone is complicated, and if you add the fact that some people may be working on different projects and products at the same time, with different challenges and rhythms, you get variables that complicate things further, so we guide ourselves by the idea of “We are productive if we add value to a business”. It’s a given that achieving working software is delivering promises, so it’s more about how a client feels about the products you are making.
The problem is trying to approach this with objectivity, but doling out numbers can have unintentional consequences; developers can over-focus on raising their numbers because the important metric seems to be proving your value with high stats, so it ceases to be a team and instead is just a collection of people making their figures go up. Metrics can bring improvements, but you also need to consider their context to make them helpful, which is why it’s difficult to find a universal solution to measure productivity in software development.
When we are in charge of managing a project, productivity is more focused on avoiding red flags instead of checking who is less productive in any given team, measuring it to avoid deviating too much from our goals; it’s easy to fall from a cliff if you aren’t careful with that. We are not interested in using metrics to know if everyone is achieving some arbitrary standard, but rather steering a ship, looking at the productivity of the team as a whole.
To this end, it’s useful to register the progress of every project and map them out to find general trends rather than trying to get exact figures. Robert D. Austin, the author of the book Measuring and Managing Performance in Organizations, said that unless you can measure 100% of something, there’s no point to measure anything at all, but in most cases, you don’t need to have every single data point, just an educated guess about where the project is heading, helped with some metrics that give a clear perspective.
This can be seen in the sprints. With information about how many story points (the metric used to estimate the difficulty of implementing a given improvement) are completed, how many issues surface, how many are solved, and comparing it with past efforts, the red flags are obvious. If the team completed between 5 and 10 story points in a sprint, but only 1 or 2 the next one, you need to dig into the process; you might find some challenges nobody saw coming and had to be solved to move forward, and you didn’t need more than knowing past productivity to compare.
And often, if you are using Agile Methodologies, the team is the one that realizes when someone is struggling or is free to help and correct the issues themselves. A good team can manage itself, keeping productivity up without needing someone to check their progress daily. This also results in the quality of the product being directly embedded into the productivity of the process, as the team should already know at this point what needs to be measured to plan with the amount of flexibility necessary to succeed.
We help your team deliver more value to the business.
In software development, we could measure how many Final Users are aware of a specific feature, how many support tickets are being sent, how many things are misunderstood, or which things are not working as intended, converting it into data to know if there are issues during development, but you still need to take some subjective measurements, like conversations with the clients to know how they feel about the product, to give context to this information.
That’s the impact we want to have on our clients, and more often than not, they start seeing the benefits of these processes. They take the time to plan their sprints, properly assess the project, and address issues, especially with not very experienced clients, whom we show what a good software development cycle looks like.
After all, developing software is closer to creating art than manufacturing an object, so the question of productivity is similar. Just like writing a novel, it’s hard to estimate exactly how long each step is going to take because human beings are bad at estimating time and effort in the long run.
We take the time to understand your business and create custom software that helps you grow.
As we know how quickly things can change in a short amount of time, Scio typically plans short-term goals (between 1 – 3 months) and mid-term goals (between 6 – 12 months) at most when we work with our clients during the evolution of the product, in order to ensure it has enough room to grow naturally, focusing on the steps we need to reach a desirable outcome, and even then it’s a challenge to keep every detail under control. There have been occasions where we have to overhaul plans to finish a project in the timeframe we set, and in those situations, the final product is different from how we first envisioned it because of the natural evolution that a project goes through.
So planning way too into the future is highly risky, shorter steps with a clear idea of every milestone is a method that has shown us the best results to develop a product, which is one of the principles of the Scrum methodology; working with iterations that have defined starting and ending points, and progress is registered at every step.
And even then you can get slightly different results every time. Sometimes a team is very well attuned and can build things faster than a team mostly composed of new developers, or engineers who had never worked together before, so obviously they took a little longer, which is why Scio evolved to focus more on the value we are delivering to our clients, involving them more in the process, deciding together which features were more valuable, and the priorities to establish.
After all, always having the option to say “Okay, let’s stop for a bit, reorganize, plan better retrospectives, and find areas of improvement” depends on knowing your process back and forth, and that’s why measuring productivity is important.
Measuring productivity is hard, but it’s not impossible. It takes some general metrics and subjective questions dictated by human behavior that are never objective. That’s where Scio comes in – we design teams that fit with the culture and practices of our clients, ensuring that no matter what, we always have the necessary perspective to achieve a successful engagement. If you want help measuring your engineering team’s productivity or just need someone to bounce ideas off of, send us a message. We love talking about this stuff!
