DEV Community: Sebastian Martinez

Our Growth Framework

Sebastian Martinez — Thu, 05 Dec 2019 14:29:58 +0000

You know the saying: A company is only as good as its employees. If you’re in agreement, it’s a no brainer that the best investment you can make as a company is to create an environment that fosters personal and professional development.

During our initial years while the team was still small, there was no framework in place and people's growth trajectories emerged in a rather organic fashion. As new people came onboard, there was a growing feeling that we needed to shed more light on the matter.

Over the past few months, I’ve spent a decent amount of time thinking about the way in which people advance their professional careers while at WyeWorks, how that aligns with our values, and the role our feedback process plays in all that.

Today, I’d like to share with you what we as a team came up with in order to start facing this challenge.

How we understand career development

We started by asking ourselves why we wanted to work on this, and the answer quickly came to the surface: We want to help people grow. That alone was the fundamental principle that shaped our framework. We wanted to focus on our teammates’ strengths and how best to help them reach their maximum potential, thus moving away from the more typical performance evaluation approach that most of us were used to in previous jobs.

After some serious reflection, we concluded that we understand growth as the journey through which someone becomes their best self, be it by learning new skills as well as perfecting existing ones. Hence, the purpose of our framework has to be to facilitate that journey.

Why we don’t stick to traditional models

With that goal in mind, traditional frameworks quickly fell short since they’re primarily concerned with assigning someone a level or categorizing them in a ladder of some sort. We think that this not only constrains people’s growth to certain predefined boxes, but also frames professional development as a competition rather than the journey it should be: with its ups and downs, and more importantly, one that allows for lateral moves in order to experiment other areas.

It would be preposterous for us to consider every possible path our engineers would like to take and prepare a set of career tracks or roles accordingly. Even if we were able to do this, in the pursue for credit people will do precisely the actions we define and we’d most likely end up with a team with homogenous skills rather than one that taps into their naturally diverse talents. That would simply defeat the whole purpose of what we were trying to achieve.

We needed to create something different.

What we’re doing right now

Growth at WyeWorks begins from day one, when you are expected to acquire the necessary skills to perform the job you were hired to do. For software engineers, that means learning the technologies and processes we rely on in order to deliver the quality we aim for to our clients.

As time goes on, we start having frequent conversations with each and every one on the team about their interests, goals and ambitions. For that purpose we created a dedicated group of coaches that will help unveil what they really expect their life to be like in the near future. We found this to be the hardest part of the process to be honest. Once people envision their future selves, our coaches’ role is to guide them through the action steps and development of the necessary skills required to get there.

This means the most important contribution we can make is not pushing what we think is best onto our people, but instead concentrate on listening. We must listen. Our job is to expose and elevate those internal motivating factors, and then let them experiment with different projects that will help them to build the skills they are intrinsically motivated to master.
Moreover, such skills don’t necessarily have to fit into a box or a position. There may be people who want to become experts in DevOps (and will have to gain the knowledge and capacity to work well under pressure), others might want to ensure clients are happy working with us (requiring the development of high levels of empathy), and some might want to teach and train newhires (meaning they’ll have to improve on their patience and communication skills). Sometimes, more often than not, it might even be the same person. For us it’s just as important to have people on our team who develop deep into certain skill areas as well as generalists, providing us with a robust and flexible team at the same time.

As a company this obviously has its challenges. We must first of all be willing to invest the time and money needed to give people the chance to explore outside of their confort zones without compromising on the level of service we provide to our clients. To that end, we have in-company time that anyone can take advantage of, as explained here.
We also must be as flexible as possible to empower people to develop per whatever path they prefer while figuring out how we can utilize that talent to everyone’s benefit. And when that's not possible, we must be humble enough to recognize that they might be better off somewhere else.

How do we measure progress?

You might be asking yourself how we measure progress and perhaps even how we tie all this in with salary. The answer is easy: we currently don’t include compensation into the equation. It was a problem too challenging to tackle for a first version of our framework and we feared we might end up incentivizing unwanted behaviors. Besides, studies have shown that the positive feelings associated with getting a raise are only temporary, and that long-term satisfaction is much more closely tied to personal development and a sense of accomplishment.

Therefore, the only metric we care about and measure at this time is personal growth. We do this by simply asking each employee whether they feel as though they’re constantly growing or not. That’s what really matters to us.

Obviously, this doesn’t mean we don’t give people promotions though. We aim to pay fairly and in line with the market, but (at least for now) that process continues to be separate and somewhat subjective.

Conclusion

To us, success is to inspire companies and individuals to build great software in a sustainable and joyful way, enabling business to flourish while people grow to become the better self. This means becoming our best selves is part of our very definition of success, and what I covered here is one of the mechanisms that help us achieve such goal.

Having this mindset of being continuously improving our capabilities is what allows us to stay relevant over the long term.

What makes a great software engineer great

Sebastian Martinez — Wed, 23 Jan 2019 14:01:35 +0000

Today I woke up wanting to start a discussion about what it takes to be an awesome software engineer. I constantly see recruiters evaluating candidates solely based on their programming skills. Hence, most developers focus only on learning the latest programming language out there. Is that all it takes? Here's my two cents on the matter.

First, I’d like to mention that I have 12 years work experience and over those years I’ve moved from developing software, to mentoring others, to hiring new candidates, to coaching those people on how to form high-performing teams. What follows is based solely on my experience; it's not my intention to present this outline as the only way to succeed. Heck, I still have a lot more to learn and might just change my perspective next month!

When I started my career, I was passionate about technology. Read tons of books about different programming languages, even more about abstract concepts like design patterns, and countless blog posts about specific subjects such as identifying the best approach for testing external services. You know how it is. There came a day when I felt pretty comfortable with coding and addressing the different problems I was facing and, even though I knew I still had a long way to go and a lot to learn, there was this small internal voice telling me: "You rock, man, you could even be considered a senior dev anytime now." Little did I know that was only the beginning.

Once the technical aspect of my job was under control, so to speak, I started noticing problems impacting my day-to-day in other areas. Those included things like discussing possible architectural solutions with my teammates; helping clients manage the product and negotiate requirements; worrying about the process and the many features that were already implemented but not yet deployed to production for some reason; and a myriad of other things. Once I started to pay attention and care about doing those things well, it didn't take me much time to realize the huge amount of value this could add to the end goal: being a very instrumental part in helping stakeholders achieve their business objectives. That right there was one of the first major breakthroughs I had in my professional career. Many of my colleagues work hard to achieve the best code the world has ever seen: shiny, maintainable, and bulletproof. Don't get me wrong, that's amazing and all of us should definitely aim for a codebase like that. But that alone, I realized, is a more selfish developer-centric goal, which falls short when we're looking at the whole picture. At the end of the day, the reason you're getting paid for is to make a successful product.

So, what makes a great developer great, then, besides programming?

A hungry mindset

This means being hungry to do more, to do what you already do even better; hungry to continuously improve oneself. This attitude will push you to always be on the lookout for more.

More things to learn and establish a wider spectrum of knowledge. In the software business, there are a lot of things you should have a handle on, from abstract concepts to specific skills. Having a broader range of understanding will help you pick the right tool for the job ahead of you. And this hunger should never be satisfied, since new things come up every day.

People who continue looking for more things to do almost never have to be pushed to do something because they are self-motivated and diligent. They are proactive and constantly thinking about next steps.

This mindset is key to becoming a knowledgeable person who always seeks to improve their environment and the way they work, creating efficiencies wherever possible.

Being a team player

There's a lot to being a good team player. But, if I had to sum it up in one sentence, I would say that it's about acting in a way that allows you to always put the team before yourself, constantly aiming for the greater good.

This means being humble, leaving your ego at the door. Not being too much concerned about your own status lets you share the credit with your team. When this happens, you start defining success collectively rather than individually, and the team as a whole becomes a unified, unstoppable force.

It's also crucial to be empathetic, in order to understand your teammates’ and clients’ feelings. This will allow you to better detect the nuances of group dynamics and care for those around you.

Acting as your client’s business partner

Yes, you were hired to program. You are indeed a technical person and that's your forte.

But as it happens, sometimes the biggest bottlenecks have nothing at all to do with coding, but rather the inefficient way you and your team gather requirements to build certain features. Lots of back and forth can be avoided by suggesting changes to how requirements are delivered to you. One small suggestion could save your client hundreds of dollars a month, and a lot of time.

Clients always request that features be released as quickly as possible (yesterday, even). That's just how the market works. When you focus on programming alone, it's easy to fall into the "if everything is urgent, then nothing really is" train of thought. In turn, that causes you to minimize the importance of time and build the features in the best possible way according to all that you know about good coding practices but, at the expense of everything else. That right there is a dangerous zone to be in. I honestly can't remember how many times I had to change my priorities because I wasn’t concerning myself with the business. That meant asking the right questions to better understand the purpose of what I was being asked to build. By engaging in those discussions, you actually come to understand why it's critical to release some features ASAP. Maybe the smartest move in those cases is to forget about clean code, make it work, and put it out there for users to buy. You can come back and clean up the mess later. In other cases, during those discussions you and your client realize that the best course of action is actually to never add that feature in the first place, saving everybody weeks of development time and costs.

As you can see, there's a whole other level of value you can add when creating a healthy feedback loop between the dev team and product people. That happens when you care about the business as a whole.

Having good communication skills

You work with people. In order to do your job, you need to communicate effectively with people. Period.

The sorts of discussions that you'll hold inside that feedback loop I previously mentioned require outstanding communication skills. You'll need to be proactive, ask the proper questions to get the right information, be able to even say no in some situations, negotiate possible alternatives, and so on. That might sound easy, but in all these years I've only seen a handful of people handle that level of communication with grace, especially when things don't go as planned.

You'll also need to communicate with the rest of your team, of course, in order to set clear expectations regarding your progress and sort out dependencies, to review someone else's code, as well as to ask for help or to help others. Communicating well plays an important role in bonding with your team and earning their trust. Once trust is in place, you can start having honest conversations about the best way to collaborate and how to address everyone's concerns.

To achieve this, the first step is to become aware of the impact your words and actions have on the people around you. Trust me, with good communication skills you can bring a lot more to the table.

What does this all mean, then?

I usually smile when I see people evaluate candidates based mostly on their programming credentials, side projects, or coding achievements. A solid programming foundation is essential of course, but based on my experience, programming is only one component of being a great software engineer. A much bigger skillset is needed in order to become a well-rounded professional.

Finding people with the right mentality is actually the hardest part. With that in place, any developer can learn whatever technology they encounter. That's why, time after time, I'd take a team of average coders that knows how to work well together in a healthy environment and has the right mentality over a set of individual coding ninja rockstars any day.

What does your experience say? Do you also find these things significant? What other skills or aspects do you consider important?