DEV Community: Ricardo Luevanos

6 Attributes of Highly Effective Software Developers

Ricardo Luevanos — Sat, 01 May 2021 19:37:31 +0000

This article was part of The Rising Dev newsletter issue #7, published on Apr 26, 2021.

There are many different ways to be effective as a software developer.

What I’ll be sharing here are the attributes common to those I would categorize as “highly effective,” meaning they did the things that multiplied the efforts of their teams.

Fair warning, this isn’t about being a better coder or leveraging a specific programming language. Coding skills only get you so far; I won’t belabor this point, but I touch on it a bit more at the end.

Here are six of the things software developers do to be highly effective.

✨ Prioritize the End-User

I think it’s safe to say that most of the solutions we propose, the ideas we share, and the hills we choose to die on are products of experience.

There’s nothing wrong with this; it’s what we bring to the table when we are hired. However, my experience has shown me that the best developers usually advocate for the end-user, the customer, when it comes to solutions, ideas, and pushing back.

Code and tech are essential, but highly effective developers know that these can change quickly; they’re a moving target.

Customer needs are relatively constant. Focusing on customer needs as a razor for decision-making is a worthwhile strategy. When everyone else is arguing about code, languages, tech-stacks, and platforms, focus on the customer.

✨ Break Things Down

Good developers are filters.

They take in information, usually in the form of product requirements, and they separate the signal from the noise to figure out the best approach to building something.

Highly effective developers go a step further. They strive to minimize vagueness for themselves and others.

One way they do this is by breaking down large rocks into smaller pebbles. The smaller parts are easier to analyze and plan around.

Smaller pieces can be chunked in different ways. Effective developers understand that once something is broken down, the elements can be grouped and approached in a way that minimizes risk, cost, or the time needed to build.

✨ Assess the tradeoffs

All software developers, regardless of their level, can assess tradeoffs; but it takes a more intentional developer to do this well.

Highly effective developers keep specific questions front of mind. These questions can mean the difference between building the right or wrong things and building those things the right or wrong way.

Here are some of the tradeoff questions considered by effective developers.

Do we prioritize quality, cost, or speed; we can’t do all three?
Can we buy what we need, or buy some of it and build the rest?
What’s the opportunity cost? What gets missed if we do this?
What's the space/time tradeoff, how do we prioritize storage, memory, and processing speed?
What are the data consistency needs? Can we leverage eventual consistency, or do we need real-time data updates?

You’ve likely run across many others. Highly effective developers keep these kinds of questions at the ready.

✨ Collaborate Well

This attribute is the most important; the quality of your collaboration is encoded into the work you do—if your collaboration sucks, your work sucks.

Collaborating well can include many things, but I think the following three are at the top.

Communication: Whether written, spoken, or over a zoom call, effective developers prioritize communication. They build partnerships with other disciplines, and they nurture an open line of communication. Effective developers broadcast information so that surprises are kept to a minimum.
Active Listening: Effective developers listen to understand, not to respond. This is part of their curiosity and empathy. They are eager to know how others think and feel. They ask questions to understand people at a deeper level and partner with them to move forward productively.
Psychological Safety: Collaboration is a two-way street, and effective developers understand that the more input and feedback they get, the higher quality their efforts will be. A way to get good feedback often is to create a safe place for others where trust and rapport can be built without fear of judgment or retaliation.

Collaboration is the glue; without it, the other attributes fall short.

✨ Go Deep and Broad

As a generalist, I prefer to have a broad understanding of many things.

Having a breadth of knowledge can help you find the patterns within an otherwise chaotic world or project. Finding dependencies within the work you do quickly is often the result of broad knowledge across different code areas or a tech stack.

Effective developers can also go deep; their breadth of knowledge is augmented by deep domain knowledge or a specialty.

Deep knowledge makes you a great coach and mentor; it’s often the result of years of practice in one or a few specific areas. Consider where you will specialize and where you will go broad.

✨ Stay Curious

Curiosity is a beautiful trait to have.

It’s a barrier to setbacks and challenges. Curious people are undaunted by pitfalls and surprises because their curiosity empowers them to see unlimited possibilities.

From analyzing and vetting new tools or code libraries to pivoting focus from one mission to the next, curious people want to see what might be hiding around the next corner.

If you find yourself frustrated by tasks that come in sideways, a canceled project, or the unpredictability of your roadmap, ask yourself if you’ve lost your curiosity.

Reignite that curiosity by finding the lessons in current situations. Effective developers ask questions to find out why things are the way they are and to unearth that nugget of knowledge a new path might bring.

Why I Didn’t Mention Coding

There’s a lot to be said for being a great coder, but I didn’t emphasize this because great code won't stand on its own.

If you’re not prioritizing the end-user, breaking things down for clarity, assessing the trade-offs, or collaborating well, how good will your coding efforts really be? While bad code can ruin a project, great code won’t make a project successful.

Code isn’t a force-multiplier for your team, but the attributes above are.

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

Why You Might Be At The Wrong Company

Ricardo Luevanos — Thu, 15 Apr 2021 15:49:47 +0000

This article was part of The Rising Dev newsletter issue #6, published on Apr 12, 2021.

Whether you know it or not, you have a ‘style’ of working, an optimal mode of operating.

Most of you are unaware of your style or mode of operating. You go through your workday energized or drained, happy or unhappy, never quite sure of the reasons why you feel the way you do. If you’re not working within your style, you’re not doing your best work.

If you are aware of your working style, do you know the current stage of your company?

Companies come in all shapes and sizes, and they vary in maturity. Each shape, size, and level of maturity is compatible or incompatible with certain working styles. Energy and happiness often depend on how well aligned your style is with the stage and maturity of a company.

Let’s explore working styles and company stages a bit further.

✨ Finding Your Style

The best way to jump into this is to share a bit about my own style, my optimal way of operating.

I enjoy the unknowns, where there is ambiguity and roadmaps can only be partially mapped out. A large part of my energy and happiness comes from helping people and teams find clarity and direction.
I enjoy a variety of different work and pivoting to other areas as the needs arise. This helps me connect with more people and find the work that will produce the most significant returns.
I prefer smaller teams to larger ones. This allows me the opportunity to scale teams and find the processes and structure for people to best collaborate with each other and do their best work.

The opposite of the above includes structure and clarity. It includes well-defined work and roadmaps based on what is already working. It also includes larger, well-established teams that have found a rhythm. This might be a dream job for many, but it’s not for me.

What makes you the happiest, what gives you energy?

Think about the situations where you’ve done your best work and the conditions that have excited you most, then consider the diagram above. Where would you place yourself?

✨ Finding Your Company’s Stage

You can slice a company in many different ways, and within the same stage, no two companies are exactly alike.

Through one lens, companies launch, grow, and mature. Through another lens, companies start pre-seed, then seed, then grow with venture capital money, maybe get acquired, and eventually IPO. Some companies have internal startups or subsidiaries in various stages of development.

There are acronyms to consider; STARS stands for Startup, Transition, Accelerated Growth, Recovery/Realignment, and Sustained success—all are stages you might encounter in your career.

Feeling energized and happy with your job depends a lot on how well your style aligns with the company’s stage.

Finding alignment isn’t that straightforward. As the diagrams imply, there are varying degrees between stages, and it’s a moving target.

Do Some Soul Searching

While your style is the easier of the two to figure out, you can’t do it by hanging out at the same company or kinds of companies for too long; you need range.

Maybe you got lucky and hit it on the first try. More likely, you need to have conversations with leaders in your company to understand better the stage the company is in and where it might be going. Most companies are constantly moving from one stage to the next.

There are tradeoffs. A little discomfort due to your style and stage of the company can yield valuable insight and experience, but you need to observe how style and stage are aligned or misaligned.

Be honest with yourself. Are you at the right company?

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

How To Accelerate Learning and Level up Faster

Ricardo Luevanos — Wed, 31 Mar 2021 19:37:29 +0000

This article was part of The Rising Dev newsletter issue #5, published on Mar 29, 2021.

As a software developer, you’ve already committed to life-long learning; it’s the only way to flourish in tech while growing your career. To stop learning is to start falling behind.

Throughout my 20+ years as a developer, it was easy to spot the folks who prioritized learning and those that did not. More problematic was spotting the people who went a step further, who focused on learning to learn. They optimized how they learned to cut out the noise and produce maximum returns for their efforts—these folks are rare.

When I found these folks, I befriended them and focused my attention on learning everything I could. This not only accelerated my learning, it accelerating the number of opportunities that came my way.

Below are strategies I picked up from people and while researching how to be a more effective learner.

✨ Know What You Want To Learn and Why

It still amazes me that people are more inclined to tackle mountains over hills or boulders over smaller rocks or pebbles. Maybe it’s in our nature as humans to tackle the ‘big thing,’ but rarely will this give you the best results.

Be specific about what you want and need to learn—write it down. And be clear about why you want to learn it; what will the knowledge give you? Write that down as well. This strategy is a small system that is going to help you reduce decision fatigue.

Want to learn JavaScript? That’s quite the mountain. Let’s break it down:

I want to learn how to write “Hello World” in JavaScript to get an introduction to the language and better understand the parts of JavaScript I want to learn next.
I want to learn how to write conditional statements in JavaScript to control the flow of execution in my app based on conditions. I want to understand better the different elements and programming structures that compose an app.

It seems simple, yet most people won’t do this. They will tackle the mountain instead, never quite sure if their path is the right one, leading to frustration and discouragement.

Knowing the small thing that you want to learn and why you want to learn it creates constraints. It makes it easier to filter out the mountain of noise and distraction so that you can focus on traversing one hill of many.

✨ Find the People Ahead of You

People represent the most potent learning accelerator, in my opinion, yet most people aren’t very intentional about it.

Find the people a few steps ahead of you and share your learning goal with them. Ask them questions about how they tackled your subject. Ask if they are open to giving you feedback as you progress.

Here’s how finding people ahead of me has helped:

People learn and teach differently. I don’t always know what will make a subject click for me. Multiple educational sources, including different people, increases the likelihood that one of those sources fits how my brain works.
People with experience know what matters. The Pareto Principle applies here. People who have done the work know the 20% you should focus on, which will give you 80% of the results.
People can be part of feedback loops. Learning is like sailing; you don’t go in a straight line. Instead, you catch the wind and zig-zag toward your end goal. People with experience can help you predict where the winds will blow next.

If you only use one strategy from this article, this is the one. People are force-multipliers; never forget that.

✨ Let Yourself Struggle

When you struggle at something, your brain responds by increasing the strength of the brain signals you need to make things stick. At least that’s what some of the research has shown: The Neuroscience Behind Productive Struggle.

The hard part is that to struggle intentionally, you need to be bad at something. Most of us shy away from the things we are bad at and therefore never unlock this increased strength in our brain signals.

I’ve had many conversations with software developers who feel trapped in tutorial hell, where they can’t seem to break away from the video or blog tutorial and build something on their own. They get stuck, feel mentally blocked, get frustrated, and either run back to the tutorials or give up entirely.

Here’s the thing, that stuck, mentally blocked, and frustrating learning stage is where the work is happening. Yet few of us ever seek out this stage intentionally or surrender to just sitting in it for a while. Imagine what might happen if you did.

Read this article and some of the referenced research it links to for more. The article also has a few tips on how to struggle productively to enhance your learning.

✨ Prepare for “The Dip”

There is a thing called the learning curve, which includes something called “the dip.” If you’ve never heard of it, here’s what it looks like:

Seth Godin wrote an excellent book on this called The Dip: A Little Book That Teaches You When to Quit (and When to Stick). They explain the concept in more detail, and they describe the scenarios for when you should quit or keep going.

Successful people don’t just ride out the Dip. They don’t just buckle down and survive it. No, they lean into the Dip. They push harder, changing the rules as they go. Just because you know you’re in the Dip doesn’t mean you have to live happily with it. Dips don’t last quite as long when you whittle at them. ~Seth Godin, The Dip: A Little Book That Teaches You When to Quit (and When to Stick)

Most folks don’t make it past the dip; they trick themselves into believing it’s a cliff vs. a valley.

Recognize that the dip is coming, that it will be uncomfortable, and that mastery and expertise may be waiting on the other side.

✨ Stay Ruthlessly Consistent

I’ve always struggled with consistency. I had decided that it was better to be flexible and adaptive to the terrain instead of consistently chipping away at my goals over and over again.

I’ve changed my mind. When I think back at my successes throughout my career, consistency was the engine. I’m now embracing the strategy of consistency more intentionally; you should embrace it too.

Jim Collins is the author of Great by Choice, a book about companies that thrive through uncertainty and chaos. Jim Collins describes a concept called the “20 Mile March”, where they explain the advantage of having a focused goal that you consistently and repeatedly take action on.

The “20 Mile March” concept was about companies, but it applies to individuals as well, in my opinion. To learn more about this concept read this.

Consistency concerning a focused learning goal can build tremendous momentum; this can get you through some of the uncertainty and chaos.

In Conclusion

No matter what you’re currently trying to learn, the strategies above can help you accelerate that learning. If these learnings are instrumental to your career growth, then leveling up means embracing these strategies.

Know what you want to learn and why you want to learn it—write it down where you can see it daily.
Find the people that are a few steps ahead of you and ask questions.
Let yourself struggle, get comfortable letting your brain stretch itself.
Prepare for the dip; understand that it will get frustrating sometimes, and you’ll need to push through.
Stay ruthlessly consistent; stacking the small repeated actions is how you flourish.

Remember to stay curious. As you grow and rise, you will learn more about yourself. If you remain open to these new learnings, you can tweak and optimize the above strategies into something unique to your learning style.

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

The Meaning of Ownership for Software Developers

Ricardo Luevanos — Thu, 18 Mar 2021 16:55:19 +0000

This article was part of The Rising Dev newsletter issue #4, published on Mar 15, 2021.

Early in my career as a software developer, I received vague feedback about needing to take more ownership of my work. You may have received similar feedback, such as in an annual performance review, as I did.

When I asked for more specifics, for something actionable I could anchor to as a goal, I got the proverbial “you know, just own the stuff you are responsible for,” leaving me to figure out ownership through trial and error.

Later in my career, I got the other kind of feedback, the praise for taking ownership. And again, the feedback often came without any specifics, believe it or not. I was paying attention though, mostly since I was hoping to help others take more ownership.

A long career in software has taught me that “ownership” is a suitcase term, used by folks when they think you need to change something and not quite sure what that is.

The dynamic nature of software and teams doesn’t make understanding ownership any easier. Development teams tend to become cross-functional as they grow, blurring any lines that might have helped you understand where ownership lives. The various mutations of an agile process can blur the lines even further regarding who owns what. And yet, ownership is an enabler for getting things done effectively—ownership needs to happen.

If you can devise a strategy for taking ownership regardless of the unknowns, you are on a path to leveling up.

For these reasons, “taking ownership” is a concept that needs unpacking.

Three Strategies for Taking Ownership

✨ Contribute to the Momentum

Regardless of the size – a small task, a medium-sized feature, or a lengthy project – your work is at risk of being derailed for various reasons. Taking ownership is about creating the circumstances that surface these risks and the reasons behind them. Often the reasons include not having the who, what, when, and why clearly defined.

Who else will work on this?
What will success look like?
When should it be completed by?
Why are we working on this?

These are all questions with answers that can help reduce complexity and ambiguity. Without the answers, complexity will creep in, and you might miss your date, deliver something of low quality, or worse; your work will be put on the chopping block and cut for something better defined and understood.

I believe ownership starts during this early phase, where you can help others crystalize answers that help build momentum and ensure success. You can begin by asking these questions:

Who else will be working on this with me? Who do I communicate with regarding dependencies (other developers, testers, stakeholders, etc.)?
What does done look like, and what are the success criteria?
When does my work need to be completed so that ample time is left for testing?
Why am I working on this? How does it fit within other priorities, company goals, and the expected impact?

If you’re fortunate, you’re at a company with a built-in process for generating these answers before the work ever gets to you, but this won’t always be the case. Either way, It’s still important to ask them for confirmation.

What you are looking for when asking these questions is resolution, usually in the form of one of the following:

You have answers to all questions, and you understand those answers. Therefore you have positive momentum and have reduced risk.
You have enough answers, and the rest are either missing or not completely understood. Therefore you have some positive momentum to build upon, and your team and stakeholders are aware of the risk and have accepted it.
You have a few answers, and they are unclear. Therefore you have negative momentum, and your work is at risk before it starts. In this case, you raise a red flag and express doubt. Ideally, your team regroups and pivots to a better strategy. Or you at least agree that the impact or reward is worth the ambiguity, and you choose to charge forth and slay some dragons.

As you can see, there might be various outcomes. You and your team will analyze new information at different stages of a project and work together to devise approaches that reduce risk and help keep things on track. You can show ownership by asking the right questions upfront and surfacing the information to help keep your project from being derailed.

✨ Carry Things From Start to Finish

Most of the work you do as a software developer will be part of a lifecycle usually called the development or implementation phase. This phase is often followed by varying degrees of testing, followed by that work being deployed to production (live to the public), assuming all functions as planned. Taking ownership means more than just being accountable and responsible for your phase of the lifecycle.

Most developers who receive their work at the start of the implementation phase will forget about it and move on to the next task after their work has been code reviewed and handed off to the next phase. Except for instances where the work comes back to them for bug fixes, the work is no longer top of mind as they have moved on to the next priority. To show ownership, you will need to go a few steps further.

I believe ownership supersedes the phase boundaries in this software development lifecycle. The edges of a phase can still be respected, but they are not signals indicating you are done or free of accountability.

When you pick up the work at the beginning of the implementation phase, you show ownership by committing to the successful delivery of that work to the customer or end-user. Here’s what that looks like:

Because you contributed to your work’s momentum (by asking questions) as described in the previous section, you know what success looks like as well as the agreed-upon timeframe. You show ownership by proactively communicating any blocker to completing your work against the given success criteria and agreed upon timeframe; you don’t wait to be asked.
When you submit work for review, a code review, in this case, you show ownership by reaching out to the reviewers and confirming any needed context is presented to help inform them of your work’s details. You also captured this context somewhere through documentation. You show additional ownership by checking in and ensuring your work is reviewed promptly. If more time than usual passes by, you speak up and inform your team of the potential risk.
After your work has been reviewed and is promoted to the testing phase, you show ownership by reaching out to testers to confirm they have all the context needed to test your work correctly. You express that you are available to them should any questions arise, and again you check-in to ensure your work gets tested on time, and you speak up if things take longer than usual.
When your work has been tested and confirmed to be working as needed and finally deployed to production and live to the world, you show ownership by reviewing and ensuring for yourself that everything functions as you intended. If you see any deviation from what was intended, you speak up. The difference may be an indication of an underlying issue or bug that needs attention.

These four items above are part of ownership. They allow you to account for the progress and current state of the work you took responsibility for.

✨ Create Long Term Impact

Creating a long-term impact is one of my favorite actions related to showing ownership. In my experience, few software developers think about long-term impact since they have often moved on to another role, team, or organization for it to affect them.

Nothing screams ownership like doing the things that will help others in the longer term after you have moved on. It’s one of the fundamentals of leadership; how things play out and unfold in your absence matter.

You show ownership here by considering how your work, and everything relating to it, can enable others in the future. The best way to create a long-term impact is to document and share:

The discussions and rationale that went into your approach to the work you did. Doing this will help others expand on the work in the future.
The gotchas, the brittle parts of the work that may provide clues to bugs or errors. Doing this will help others troubleshoot anything related to your work should issues arise later.
The operational and maintenance requirements related to your work. If changes to a system are required in the future, should your work be altered somehow for compatibility? If your work is dependent on something else functioning correctly, make that clear.

Ownership Is All About Communication

You may have picked up on the theme by now. Nearly everything I described around ownership for software developers is about communicating with others. Each action or question creates another communication touchpoint, where challenges and risks can be surfaced and tackled head-on.

There are some positive side effects to ownership I should mention. Consistently taking action on most of what I shared above will produce a sense of control, which is always a great feeling. Even when things don’t go as planned or your team needs to pivot strategies, you can get there in a more controlled and informed manner; this reduces stress and strengthens your team.

The next time you hear ownership mentioned or receive feedback related to showing more ownership, think about how you communicate. And consider the strategies above as actions for filling any gaps.

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

Why Your Promotion and Raise are Taking Forever

Ricardo Luevanos — Wed, 03 Mar 2021 20:00:29 +0000

This article was part of The Rising Dev newsletter issue #3, published on Mar 1, 2021.

I was inspired to write this after following this Twitter discussion initiated by @duretti.

// Detect dark theme var iframe = document.getElementById('tweet-1362515101043941379-7'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1362515101043941379&theme=dark" }

@duretti asked a very fair question about a widespread occurrence in tech regarding promotions and raises. She was also kind enough to follow it up with an informative blog post, Unintended predatory delay is still delay, where she dives into the topic a bit further—it’s a good read; you should check it out.

The Twitter discussion and blog post got me thinking about and reflecting on my own experience with promotions and raises. I’ve been on both sides of the table regarding promotions and raises, and I’ve had to play the waiting game. And as a manager, I’ve asked others to wait.

The Variables Delaying Your Promotion or Raise

What follows is a brain dump of the variables that affect the timing of your promotion or raise, as I experienced myself or through others. Not all of them will be relevant to your company or situation, but I’m willing to bet some combination of these will affect your rise if they haven’t already.

You’re Not Ready

This will be valid multiple times in your career. Ideally, someone is having the tough conversations with you about this—usually your manager. You should be having at least a couple of conversations a month around goal setting and prepping for your next move.

The four stages of competency apply here. You want to aim for eventual mastery by identifying and addressing current skill gaps. With the proper support from good managers and teams, you can build out and execute against a plan.

It’s ok not to be ready yet, but you need to validate progress from outside of yourself. If you’re not getting the feedback and input you need to make improvements, find out why.

A Case Needs to Be Built

In some form or another, the case for your promotion or raise always needs to be built and presented.

If you’re in an established company with a fair process and good managers, the justification or case for your promotion or raise has been in progress already, as part of your regular goal-setting efforts and as part of ongoing conversations about your progress and impact.

Unfortunately, it’s often the case that the due diligence and proof gathering for your promotion or raise doesn’t start until you speak up. Start early!

There Are Budget Constraints

This will always be true to some extent, either due to budget cycles or budget limitations. Organizations aren’t always trying to get in your way, but optimizing, doing more with less, is a staple of efficiency, something we as engineers have top of mind. It’s possible to over-optimize, to leave folks under-rewarded for their impact, for far too long a time.

In some cases, engineering managers are given a pool of money to support promotions and raises, meaning only a few will pass. In other cases, the company grew so quickly that the annual budget allotted is already being surpassed, triggering a cutback and reduction in certain areas, including promotions and raises.

In other cases, managers failed to plan for growth properly. It was a blind spot for some reason, and they now find themselves in a position of asking others to wait until budgets are re-negotiated.

There Are Policy Conflicts

Believe it or not, some companies have policies around how long a person should have worked at the company before being considered for a promotion or raise.

One company I was at had a 12-month rule regarding new hires. No promotions or raises were allowed unless you had worked for the company for at least 12 months. If you’re stellar at your job and a quick riser, this one is incredibly frustrating.

I’m not sure what the justification for it is, but a good manager will advocate for you anyways. Sometimes the squeaky wheel is heard.

Your Company Shifted Into Wartime Mode

If your company is struggling to survive, it’s in wartime mode. In wartime mode, a lot of things get reprioritized, especially anything that relates to money.

With Covid-19 dominating much of 2020, you can bet that folks who were on track for receiving promotions or raises were asked to wait, assuming the company was doing well enough to avoid laying them off.

Many factors can shift a company into wartime mode, from mismanagement to stiff competition. It’s an unfortunate variable and something to keep top of mind. In my experience, most folks don’t know whether or not their company has shifted into wartime mode—do what you can to find out.

A Foundation for Success Is Not Yet in Place

In a healthy organization, there is a balanced ratio between role levels to ensure adequate support for growth. Ideally, you have someone to learn from (higher than you) and someone to mentor and coach (lower than you), more experienced peers to help you through your growth, and an excellent manager to help you manage your career.

Good companies are always working towards maintaining a balance that provides an opportunity for folks ready to move up, but it won’t always be the case that this balance exists.

I’ve been in situations where promotions to Sr level were delayed until we hired experienced Sr staff to help them in that role. I’ve also seen delays while waiting to hire junior or mid-level staff to ensure proper succession planning, knowledge transfers, and backfilling to replace those who move up.

If your promotion can upset the balance, and negatively impact other people or the company, expect delays.

Your Company Has an Unhealthy Culture

Perhaps the most frustrating of all, this one ranges from the mildly biased up to the ugliest. It’s unfortunate, but some humans will make every attempt to stop your rise because of the way you look or sound, or because your preferences don’t align with theirs—it’s just plain hateful and shouldn’t be something we need to look out for, but it’s real.

If you’re in the wrong place, folks will hold you back. Worse, you will get positive feedback and the impression that you are on your way, only to find yourself waiting a little bit longer.

Other companies have the best intentions and genuinely want you to succeed, but they haven’t implemented or sustained a culture that focuses on people and their career goals. Nor have they trained or conditioned their managers to properly coach and mentor others.

Under these circumstances, you’re swimming upstream when it comes to making change happen, especially the kind of change that rewards you for your impact.

Do your best to assess the situation you’re in, and move on if you need to and are able.

Your Company Lacks Process

I’ve seen this at both newer companies and older ones. Where the process for promotions just isn’t structured well, or at all. In some cases, it was a complicated process to understand for both managers and individual contributors.

For managers, this has the unfortunate effect of making promotions feel like one-off efforts. The current promotion proposal won’t follow steps similar to the last one, making the whole thing a very unpredictable endeavor.

In cases like this, a delay is due to the lack of transparency around how things truly work, making it difficult for managers to understand where the leverage is.

Your Company Is Re-leveling Titles and Salaries

This is often an occurrence with earlier-stage companies that are growing. These companies have changed salary ranges and role levels to remain competitive, so some folks have been hired at a lower salary or title than others along the way.

It’s often the case that your promotion or raise, though well deserved, is a lower priority for the company while they work to re-level others and get them caught up.

Your Company Is Going Through Leadership Changes

It sometimes happens that there are ongoing changes at the executive level within your company, and newly incoming execs want time to review and approve any proposed promotions or raises put on the table before their arrival, not unfair.

It’s prudent for execs to want to get their heads wrapped around recent decisions, or proposed decisions, before letting them be completely finalized. This can put potential promotions and raises on pause for a bit.

I’ve had the unfortunate experience where the promotions I was advocating for within my teams were delayed up to 9 months purely because of leadership changes. Two interim c-level leaders delayed the process by six months before a final leader was brought in, who finalized decisions three months after that. It was very frustrating for me but incredibly frustrating for those waiting on their promotions.

Start the Promotion or Raise Discussion Now

Here’s the hard truth, even if you’re at a great company working with a great manager, who both have your best interest at heart, your promotion will take time. Start the conversations well before you are ready for that promotion or raise.

Remember that the next level, the next title, is not a target you hit all of a sudden; it’s something you trend towards. You want to have all the momentum you can before the opportunity presents itself.

Consider this list, are these true or false?

You’re aware of the skills and experience required for you to succeed in the higher role, and you understand how the promotion process works within your company.
You’re performing at the next level consistently, as confirmed by your manager and others.
Your manager is aware of your promotion goals and is a sponsor in helping to make them happen.
You’ve spent the last 6-12 months working with your manager to fill any remaining gaps in your current role.
You’ve spent the last 6-12 months working with your manager on identifying your strengths/weaknesses for your next role and goal planning to level-up.
You’re already performing the next role informally at least part of the time.
You’re coaching/mentoring another who is performing your current role informally at least part of the time.

If all of the above bullet points are true, your promotion is likely around the corner; at least, I would bet money that is the case. If most of the above are false, your promotion is likely 6+ months off; I would guess at least a year off.

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

How Building Domain Knowledge Raises Your Value

Ricardo Luevanos — Fri, 19 Feb 2021 14:30:22 +0000

This article was part of The Rising Dev newsletter issue #2, published on Feb 15, 2021.

As a software developer, I’ve had the opportunity of working in various industries throughout my career, these include automotive, property management, e-commerce, gaming, and streaming media.

In all cases, I was able to build some level of expertise—domain knowledge. Domain knowledge is the industry-specific understanding, insight, and experiences you gain while focusing on a specific area for a while.

For example, in the few years that I focused on e-commerce, I built domain knowledge around PCI compliance; how credit card data is securely transmitted, processed, and stored. While working in streaming media, I built domain knowledge around digital asset management and distribution, how video assets are captured, encoded, and streamed to various TV, computer, and mobile devices.

As a software engineer, this domain knowledge made me more valuable. It differentiated me from other developers and helped me advance my career.

Why Domain Knowledge Matters to Companies

Domain knowledge is like a power-up; it makes you run faster and jump higher; in a software developer kind of way. When you have it, companies pay attention, and usually more money.

As a hiring manager, and someone who seeks to help developers get hired and promoted, I have some opinions on why domain knowledge matters to a company.

When you have domain knowledge related to the industry you are in or the role you are working towards, you will be on-boarded much faster—allowing you to make valuable contributions to the organization and team much earlier in your transition. An additional positive side effect is that these early wins will help you build confidence and trust.
Domain knowledge is often built on the back of failures. Having domain knowledge likely means that you’ve seen what works and what doesn’t, and you will be in a unique position to identify and mitigate risks while proposing more thoughtful solutions.
Knowledge sharing, mentorship, and coaching are vital parts of building great teams. If you have domain knowledge, you have the experience to catalyze learning and growth in others.

A more direct way of putting it is, hiring and promoting great software developers with domain knowledge saves time, money, and energy.

Why Domain Knowledge Should Matter to You

You don’t "need" domain knowledge as a software developer. Your technical skills can be enough to get you contributing to teams and getting features and products across the finish line. However, having domain knowledge can be a differentiator, something that separates you from the rest.

If your goal is to level up, to work on more challenging projects while rising in your career, building domain knowledge can help you do that; here’s how:

Generally, domain knowledge changes less than technical knowledge. You can invest time and energy and be confident that the domain knowledge you acquire will likely keep a longer shelf-life. There’s efficiency in intentionally pivoting some of your time to building domain knowledge.
Domain knowledge within specific industries can help you make data-driven decisions early. There are constraints or guard-rails already set at the industry level that can benefit you and your team. For example, in the case of video-on-demand (VoD, think Netflix or Hulu), there is a wide range of public data and metrics around quality of service (QoS). When you have the domain knowledge to know that a 3-second delay in a video starting might mean losing 13% of your users or that an 8-second delay could cause you to lose 50%, you may want to focus on optimizing for performance over aesthetics.
Having domain knowledge can help you make decisions around priorities and tradeoffs. In the case of an e-commerce domain, companies like Shopify and BigCommerce have already set consumer expectations and established the table stakes for features. You become quicker in analyzing their product offering and those of your competitors, and you can more quickly devise a strategy for what to build vs buy.

When you focus on technical skills alone, you can easily miss some of the advantages I just described. A lack of domain knowledge may not stop you from rising, but you would be missing out on some acceleration.

Domain Knowledge: Depth and Competency

Having domain knowledge isn’t necessarily about specializing. You still need to be a good software developer with a well-rounded set of hard and soft skills. Think of domain knowledge as a multiplier; it can make you and your team more effective while reducing risk to an organization.

Something to consider is the variability regarding how deep you might aim to build domain knowledge. You can go deep and become an expert or simply learn enough to be competent. I mention this because if you’re like me, you may prefer to build domain knowledge in multiple areas at once, and going shallow may be the best strategy for managing time and energy.

Let yourself explore multiple areas. The notion of T-Shaped skills applies here. A T-Shaped developer will have a breadth of knowledge across several areas and more in-depth knowledge in a more narrow area. An example of this could be a developer with a range of expertise and experience across UI development, testing, browser compatibility, and troubleshooting. Additionally, and in contrast, they have more in-depth knowledge in areas like accessibility or performance optimization as it relates to video streaming, or e-commerce, or gaming.

The point is you don’t need to get bored building domain knowledge. Breadth of expertise in other areas helps you maintain flexibility so you can alter your career course as your goals change.

Domain Knowledge Is a Strategy

Building domain knowledge needs to be intentional. You should focus on it and study it as you would any new coding language or framework. There are a couple of reasons for this:

Domain knowledge can overlap and stack atop other domain knowledge. Some domain knowledge in payment systems, coupled with user management systems, would help you stand out within any company focused on building and maintaining a subscription service. You can be strategic about how you combine this knowledge to achieve your career goals.
Having domain knowledge equips you to mentor and coach others, to share your knowledge. It allows you to build strength in others—this is how personal succession planning for getting promoted starts. You build others up so they can fill in for you as you rise in your career.

One last thing, experience has taught me that domain knowledge in most fields is relatively scarce, and it comes and goes as people move between industries. Consider the last time you watched a video or took a 30 minute course on a specific field or industry (not just code languages and frameworks); not many developers do this.

The journey between being a competent developer and being a competent developer with domain knowledge can be quick. A single hour of study per week can quickly put you in the top 5-10% of developers within a given industry—this is an opinion, of course, but it’s an opinion informed by 20+ years of observation and experience. We are leaving way too much of our value on the table as developers.

If you believe the data, there are about 24 million developers worldwide right now and growing. Differentiating yourself within software development has never been more critical to your career success.

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

A Conversation About Imposter Syndrome

Ricardo Luevanos — Mon, 08 Feb 2021 23:20:54 +0000

The topic of Imposter Syndrome, especially as it relates to software engineering careers, is a prominent and repeated one. And for good reason, it's something many of us struggle with, some of us more than others.

Some Questions For You

How often do you deal with Imposter Syndrome?
What tactics have you tried when dealing with it?
What have you learned about how IS affect you?

Share your answers in the comments section if u like 🙂

A Recommendation

I recently had a great conversation with @_MarkSnyder_ on his podcast Building Better Software Teams. The topic was about Dealing with Imposter Syndrome.

Give it a listen, let me know what you think.

I'll be tackling similar topics on my newsletter, The Rising Dev - Subscribe Here.

Follow me on Twitter

What a 20 Year Career in Tech Has Taught Me About Getting Promoted

Ricardo Luevanos — Fri, 05 Feb 2021 23:45:38 +0000

This article was part of The Rising Dev newsletter issue #1, published on Feb 1, 2021.

I started my career in the late 90s as a software developer. At the time, my goals included being good at what I was doing, adding value to the people I worked with, and being rewarded for my efforts through promotion to more challenging roles. A few things have changed since I started my career. Like the various titles between a beginning developer and a more senior role now being better defined—somewhat. But the challenge of finding the path from one level to the next is still varying between companies.

I’ve learned a ton about rising as a developer. Many of these learnings have seemed counterintuitive at times. Yet, they all yielded observations, and fundamental principles that I think will help you execute on your rise as a developer.

The Challenges

The topic of promotions, especially in tech, can be very confusing. Employee count, stage of company growth, company culture, and a company's leadership experience may all have a role in how or when you might be eligible for a promotion. And the methodologies and philosophies around promotions can differ from company to company—your strategy for rising in one company might not translate to the next.

Consider this, based on an article by Indeed.com - with data from US Business Dynamics Statistics, larger firms (1000+ employees) employed nearly half of all US workers. In contrast, small to mid-sized firms (less than 1000 employees) employed most of the rest. However, the narrative regarding promotion paths comes mainly from the larger companies where the different job levels are better defined. As a result, roughly half of us in the US alone, especially those newer to their careers, may be lacking a well-defined path to career growth and promotion.

There is another variable that will impact your rise. You might be “re-leveled” due to a merger, an acquisition, or after a company reorganization. You can even promote yourself by leaving one company to join another. And you can get leveled back to where you were previously by joining yet another company. I’m a Director level employee at the time of this writing. If I wanted to join Facebook as a Director, I would need to be a VP level candidate when applying, and I would be re-leveled from VP to Director if hired.

None of this is necessarily good or bad. However, it emphasizes the need for awareness when devising your strategy for rising as a developer.

Where to Focus

When I started my career in software development, the situation around titles was quite a mess. As a contract developer, folks described me as a webmaster, web developer, and UI/UX Designer. Eventually, those titles evolved to become more technology-focused; I was a Multimedia Developer for a while when Flash was popular, then a Sr PHP Developer when PHP was the language du jour.

As I worked on larger and more complex systems for scale, titles like Software Engineer came into play, then Sr Software Engineer. These changes were not necessarily always promotions. A lot of them derived from the fact that companies didn’t have these paths figured out. Many still don’t.

At the time of this writing, I’m a Director of Engineering leading managers that lead teams—I’m still learning. And despite the challenges that came with finding and executing on a path to a more challenging role, a 20+ year career in software development has taught me that there are ways to manifest what you desire and deserve.

Here are a few strategies that I think make you promotion worthy.

Aim for Impact Over Output

Early in my career, I paid far too much attention to work output. I even volunteered to take on more work than I needed and relished working late nights and weekends to get projects across the finish line. I’ve seen this same pattern in others; we all wanted to be that so-called 10x developer.

This kind of effort might be helpful in a small startup for some time, but it’s not how you make an impact, and it’s not how you rise as a developer. The hard truth is companies can purchase output by employing freelancers, contractors, or staff augmentation agencies. Therefore, the output is not necessarily a promotion metric.

The impact is what matters, and I’ve learned this can mean different things in different companies. Here are a few areas to consider when seeking to focus on impact over output:

Understand as much detail as possible about the problem or challenge you are trying to solve, finding the “why” in what you are doing can often help you propose a smarter or faster alternative.
Share your work early and often, especially for projects that take longer than usual to complete. Regardless of how confident you may feel in your approach and solution, getting extra eyes on something can reveal a possible improvement or expose a risk early.
Look for ways to automate tasks you are repeatedly doing. Imagine others coming along in the future to expand and improve on your work. Look for efficiencies you can put in place, so their job is quicker and less complex.
Remove yourself as a single point of failure by transferring knowledge. Share and document what you know, think of the edge-cases and nuances surrounding your work and capture the context needed for others to pick up where you left off.

Work on the Right Things, the Right Way

I once worked for a video game startup where I tackled many challenging problems, and I led others in doing the same. Eventually, I had a playbook of approaches for the various challenges that came up. I felt like a hero—I knew I was good at this.

Later in my career, I worked for a much larger and established video game company, where I unleashed my playbook on folks to save them from their inevitable path to failure, so I thought. My so-called playbook was all wrong. It was like trying to execute football plays on a baseball field of tennis players. My playbook eventually became something more flexible, more rubric than a playbook.

I learned that the right thing to work on and the right way to do it are moving targets. However, you can set some constraints to ensure you are thinking in a way that allows for flexibility while remaining as close to “right” as possible.

Here are some questions to ask yourself to help filter for the “right things”:

Is what I’m working on prioritized against other things I could be doing? Were these projects part of a planning meeting with group input on prioritization?
Is this work captured and tracked somewhere for transparency, with a thorough understanding of the requirements and success criteria?
Does my team know this is what I’m doing? If I pivoted while responding to a production issue, did I broadcast this pivot?

Here are some questions to help filter for the “right way”:

Will other teams use what I’m building, and should I consider their specific needs?
What are the requirements for scale? Is what I’m building going to be used long term, or is it part of a first phase iteration? Will it be used by hundreds, thousands, or millions of people?
Do we have the internal expertise, bandwidth, and interest in building, operating, and maintaining this, or should we consider buying a solution instead of making our own?

The answers to the questions above won’t always be obvious, even after working through them with your team. Often you will only have answers to a few and the need to make progress right away.

The most important part here is the conversation. Asking these questions to yourself and your team increases the odds of working on the right things the right way and is another driver towards impact over output.

Ruthlessly Prioritize Personal Growth

It should be no surprise that continuous learning will always be a significant component of your success. I knew this early in my career and embraced it, but I missed something that slowed my growth for a bit; I wasn’t asking for enough feedback.

I now realize that feedback is a multiplier to personal growth. If you are looking for a way to accelerate learning and development, this is it. I didn’t learn this until I received enough critical feedback that stung, forcing me to throw my arms up and set my ego aside, and focus on gathering and integrating as much input from others as I possibly could.

Share everything and share it early, not just the work you are doing. Share your point of view, your gut feelings, your decisions, and your decision-making process. Share how you approached a conversation or how you are thinking of conducting a conversation—share it all with folks who are more experienced and listen to what they say.

In addition to being intentional about always learning, I made it a point to seek feedback around what I should be doing less and what I should be doing more. I didn’t judge that feedback; instead, I analyzed it, threw away some, and fully integrated the rest. Then I asked for more feedback.

Every company and team you join is a school. Look for schools that will help you explore your capabilities and help you fill any gaps. If you’re not feeling challenged, or getting enough feedback, find a better school.

Focus on Team Over Self

There’s this urge to compare ourselves to others, and look at the more technically experienced developer next to us and wonder about the things we should be doing to be like them. As I worked within different companies and different teams, I found myself doing this very thing. It was a waste of time and emotional energy.

I once worked with a very talented database engineer. I would partner with him on building out specific features, and everything we did together came out great. I envied his abilities, and I worked hard to learn as much as I could about everything he did on the database side so that I could be like him.

He did not do the same. He learned enough from me to get by, to pick up where I left off if needed but not much more. When I asked him why he simply stated, “That’s not my role; it’s yours.”

He saw us as a team. We augmented each other’s abilities, and together we were greater than the sum of our parts—I should have focused more on bettering my role like he was.

Once this clicked, I realized there were differences between myself and others in similar roles, we didn’t all know precisely the same things, but we augmented each other. We could support one another around the differentiators when needed.

Know your role and what the expectations are. Learn about what others do and focus on getting better in the areas where you are accountable. Having a team with varying capabilities and skill levels creates a Venn diagram of possibilities. You will all overlap in many places, but your differences are where insight, innovation, and creativity happen.

Finding your difference and strengthening that can elevate your team as a whole.

Build Organizational Awareness

As you progress in your career as a developer, you will start to detect a pattern. You will find that some people don’t care about what is happening beyond their immediate team, while others do.

Once I got into management, I saw this pattern from a different angle. I would receive complaints from folks about having been asked to sit in on a meeting or discussion with very little to do with their responsibilities. Others complained about being excluded from such discussions. They wanted to be a fly on the wall, listening in and learning a bit more about what’s happening elsewhere.

Finding that balance between avoiding distraction and building awareness can be challenging, but I would be lying if I said there wasn’t some kind of correlation between promotions and what side of the line you choose to sit on.

What I learned here is to avoid both extremes and find a middle ground. Lean on your leaders and team to help protect your time, to allow you to focus on doing great work without distraction.

Also, lean on them for additional insight and express interest in learning more about what goes on beyond just your team. By allowing a bit of both, you strengthen your filter and learn to focus on the right information, and information is power.

In Conclusion

There is a ton more to unpack here, and everyone’s situation is different. I didn’t learn or do everything I shared above in one single shot. I did a little as I knew a little—it all stacked into a strategy over time.

A little bit of what I shared above got me promoted. Larger chunks of it eventually got me into management. Better still, embracing and learning even more of it helped me get others promoted.

I learned that sometimes you need to claw to get to that next rung in the ladder, and other times you’re lifted. As you execute on your rise as a developer, remember to lift others on your way up!

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter

Copy Code to Accelerate Learning

Ricardo Luevanos — Fri, 25 Sep 2020 18:55:32 +0000

Way back in the before times, if you wanted a copy of a book or manuscript, you needed to make that copy yourself with pen and ink by copying the text line by line. A term used to describe this is Copywork.

Copywork was also used by great authors of the past to learn more deeply about the great authors that came before them. It allowed them to feel like a master writer for a short while, make observations and connections, and ask questions about why great writers used specific words and structures.

Copying the code, line for line, of other engineers can accelerate your learning. It has been one of my goto tactics any time I endeavored to learn a new programming language.

How Copywork Helps Coders

In my opinion, one of the most significant benefits of using copywork when learning a coding language is that it gives you a break from repetition and the rote memorization process, which frees your mind to zoom out and analyze more deeply as a whole.

Copying the code of several different and more experienced engineers will expose you to other approaches to a similar problem. Some engineers have an individual style, and you can see it in their code. The more copies you make of work by different coders, the greater the scaffolding that gets created in your mind; it helps create a mental lattice for new things to stick.

This process can also reveal the varying strategies and tactics used by others. Some patterns will be evident to you, and others won’t—make a note of what you see for further investigation later. Some of what you are learning with copywork will make its way into your work someday; a combination of different styles will converge to become part of your style.

One significant side benefit of this kind of practice is that it helps relieve some of the overwhelm that accompanies learning to code in a new language. Immersing yourself in multiple compositions of code creates familiarity.

How Copywork Helps Coders

1. Find Some Authors

Start with some Google and GitHub searches for well-known and more experienced coders for your language of choice.

Examples of code authors for TypeScript:

Anders Hejlsberg: https://github.com/ahejlsberg. This repo is a bit dated, but it’s by a lead architect and core developer of TypeScript, so tons of value here.
James Hickey: https://github.com/jamesmh. Author of Refactoring TypeScript: Keeping Your Code Healthy.
Boris Cherny: https://github.com/bcherny. Author of Programming TypeScript: Making Your JavaScript Applications Scale.

2. Pick a Composition of Code

When picking a composition or page of code, don’t worry too much about where it fits within the rest of an application.

The code you copy could be part of an abstraction and challenging to understand its role within the broader scheme. And that’s ok; again, our goal is to copy and zoom out, to analyze a piece from a higher vantage point.

As an example, I might choose one of the following:

3. Copy and Observe

Now that you have a composition of code to copy, sit back, and start copying the piece at a steady pace and consider the following as you progress:

In what areas of the composition did you slow down or speed up while copying? Take note of locations where you slowed down a bit, as this may indicate topics for further research. You slowed down for a reason; maybe your brain wanted a bit more time to comprehend what you were copying.
Does what you are copying feel easily readable, or does it feel crowded or cluttered? Pay attention to how blocks of code are structured, think about the kinds of formatting decisions the coder might have made.
Based on what you have learned so far in your coding journey, what might you have done differently from this particular composition? You might see something done differently than the way you learned to do it yourself, and that’s ok. It might be worth researching later—maybe the differences matter.
When done, compare the copywork to others you have done in the past; what patterns seemed common and which seemed different? These differences might be coding style or preference. As you do more copywork, note the parts that resonate with you as these may contribute to your style and coding principles for that language as you improve.

Conclusion

Copying others’ work with the intent of observing a composition in its entirety is a tool I think all aspiring coders should be using. This practice has been a learning accelerator for me.

You might be thinking, “I’m already copying code all day long from books and tutorials!”. While this may be true, you may likely be doing it focusing on one particular area, as part of learning variables, scope, functions, etc. Remember that for copywork, the goal is to zoom out of the granular learning and focus on the code in its entirety.

Give it a try!

Follow me on Twitter - It's the best way to learn about any new content I publish.

Hacking Imposter Syndrome: A Cheat Sheet

Ricardo Luevanos — Tue, 08 Sep 2020 02:30:02 +0000

Direct Image URL

Follow me on Twitter - It's the best way to learn about any new content I publish.

How are you all handling burnout?

Ricardo Luevanos — Tue, 01 Sep 2020 19:03:45 +0000

Have you burned out and recovered?

Are you in the process of burning out?

Anyone experiencing micro-burnout, like the usual kind of burnout and recovery cycle but condensed to weeks or days?

How are you all coping with this?

What’s the Opposite of Gatekeeping?

Ricardo Luevanos — Mon, 31 Aug 2020 06:55:50 +0000

The topic of gatekeeping, especially in tech, seems to be getting increased attention recently. I'm not sure of the exact reason, but I think most of us can agree that the unproductive form of gatekeeping has gotten quite frustrating.

I'm calling out the unproductive form because a little bit of research indicates that a productive form of this actually exists. Whether it be to protect the worthiness of news, media, data, or to protect privacy, there seem to exist legitimate forms of gatekeeping—you can Google for more info around this on your own.

The point of writing this is to explore the unproductive form of gatekeeping, and what the opposite of that practice might be.

Unproductive Gatekeeping

Whether it's your level of experience, your job title, or the various skills you have learned and practice, there is no shortage of folks that will tell you why you are not really at the level you think you are at, or why you might never really reach such a level.

Some common threads around unproductive gatekeeping include:

"You're not a software engineer because [Insert infinite reasons here]."
"[Insert programming language they dislike] programming isn't real programming."
"You don't have a degree, so you're not actually a [Insert infinite variations of professions]."

Unproductive gatekeeping exists at all skill levels; it's a big fish, small fish cycle sometimes. I've been told before that I'm not a real web developer because I use tables versus CSS—this was after CSS had just come out, and I had not made the transition yet (dating myself here).

I was also once told that I'm not a real iOS developer because I was programming on a windows based machine versus an Intel-based Mac. Believe it or not, when the original iOS SDK was introduced, there was a PC toolchain that allowed us to make iOS apps, at least before Apple walled it off (dating myself again).

It's easy to identify and focus on unproductive gatekeeping because it's prevalent and so damn frustrating, but what of concentrating on the opposite of unproductive gatekeeping—by pondering this, I'm not referring to "productive" gatekeeping. My question is, what is anti-gatekeeping?

I think the answer is stewardship.

Stewardship

There are a lot of definitions for stewardship on the interwebs—do the Google search. I've done my investigation and have distilled a definition to the following:

Stewardship is having a level of experience and taking responsibility for elevating others to the same level of expertise.
Stewardship is being entrusted with what's in your care, like your craft, and guiding others through a path that empowers them to be entrusted with the same.
Stewardship is creating an environment where people can grow and improve within a space while enhancing their sense of well-being.
Stewardship is acting in service to others despite your personal interest.

I like these definitions; they feel right!

What Stewardship Might Look Like

Let's take the definitions above and imagine what stewardship (anti-gatekeeping) might look like out in the real world:

When someone expresses a challenge or loss, instead of explaining why these are dues all people pay, or how they're doing things wrong—choose to be compassionate. Respect their journey and normalize their struggle. You were there once yourself.
When someone expresses a win or achievement, instead of reducing that experience or shadowing that achievement behind your own—choose to give praise. Share that these achievements and victories will stack themselves into even greater ones. Help them keep the rocket fuel burning.
When someone expresses interest in what you do by asking you a question, instead of finding reasons for the irrelevance of their question—choose to share more details about your own experience. Answer the question, share what worked for you and what didn't, and guide them towards the next questions they should be asking.
Finally, be in service to your field and industry by empowering, elevating, and stepping out of the way.

Follow me on Twitter - It's the best way to learn about any new content I publish.