Posted by: lrrp | July 22, 2021

Delegating Effectively as a Tech Lead

Lessons and missteps in engineering leadership

Being a tech lead is difficult.

As a tech lead, you’re often expected to continue to be a high performer as an individual contributor while also taking on additional responsibilities to help the team. These additional responsibilities may include breaking down work into clearly defined tasks, grooming the backlog, prioritizing work, mentoring junior engineers, and resolving blockers for the team.

The hardest part of being a tech lead is learning to balance your individual work with the needs of the team.

How do you get your own work done while helping the team remain productive? You can’t do it all, and you certainly don’t want to burn yourself out by working longer hours.

One solution to managing this added workload lies in learning to delegate effectively. So the question is, when should you delegate and when should you do something yourself?

The Delegation Matrix

Tasks can often be characterized along two spectrums — complexity and frequency. A task may be simple or complex, and a task may need to be performed frequently or infrequently. We can use these attributes to determine when work should or should not be delegated.

Engineers love to automate tedious work. Ideally, anything that you have to do frequently should be automated as much as possible. For example, if you need to gather metrics for your team’s work each sprint, see if there’s a way to automate that process.

In the event that the task cannot be automated, simple and frequent tasks should be delegated. These could be things like running standup meetings or performing simple code reviews. Simple and frequent tasks are things that anyone on the team should be able to do with little or no additional training, so don’t make the mistake of thinking you have to do everything yourself. You’re here to help your team, but your team is also here to help you.

Simple and Infrequent Tasks

If a task is easy and rarely needs to be done, just do it yourself. If it would take longer for you to explain to someone how to do the task than it would for you to just do it, then go ahead and tackle it on your own.

Please don’t misunderstand. There is a lot of value in training team members and helping others grow. However, these kinds of simple and infrequent tasks generally are not the core responsibilities of someone’s job and are not essential to anyone’s career progression.

An example of a simple and infrequent task might be running a script once per quarter to generate a report. Or it could be purchasing tickets for an upcoming team activity — nothing too exciting, and nothing too time-consuming.

Complex and Frequent Tasks

Again, automate everything you can. If you can take a complex and frequent task and automate the process to complete it, you should!

Assuming you can’t automate the task, complex and frequent tasks should be delegated to your team members to help them grow. As a tech lead, you are someone who is good at breaking down work, planning projects, resolving blockers, and handling incidents. Train your team members to develop these skills too!

Ask a team member to lead the planning session for the next project your team is assigned. Delegate to a colleague the exercise of breaking down complex work into smaller tasks. The next incident that occurs, invite a teammate to debug the problem with you.

When you can train your team to handle these complex and frequent tasks, they will progress in their careers. It also frees you up to focus your time and energy elsewhere, as you are no longer the only person capable of doing this kind of work.

Complex and Infrequent Tasks

Complex and infrequent tasks are oftentimes the most difficult to delegate. These tasks don’t happen regularly, so they don’t consume too much of your time. They may be valuable for other team members to learn, but due to the infrequency of the task, the return on investment of training and delegating the work isn’t as high.

Complex and infrequent tasks should be delegated to rising leaders on your team as stretch assignments. You might ask a senior engineer to help provide a performance review for the intern that they mentored last summer. Or you might ask a senior engineer to do some research and then give a high-level estimate for a new feature that product management is considering but hasn’t committed to yet.

These types of tasks don’t come up often, but they can be good learning experiences for all involved.


Let’s return to the delegation matrix. Here it is, all filled out

As you can see, much of your work can be delegated! Your role as a tech lead is to help keep the team productive, and oftentimes the best way to do that is to invest some time upfront to train your team members so that soon they can handle even the most complex tasks on their own.

Invest in TTFC to expand your potential developer base

API publishers among Postman’s community of more than 15 million are working toward more seamless and integrated developer experiences for their APIs. Distilled from hundreds of one-on-one discussions, I recently shared a study on increasing the adoption of an API with a public workspace in Postman. One of the biggest reasons to use a public workspace is to enhance developer onboarding with a faster time to first call (TTFC), the most important metric you’ll need for a public API. If you are not investing in TTFC as your most important API metric, you are limiting the size of your potential developer base throughout your remaining adoption funnel.

Close up of a stopwatch on a laptop

To understand a developer’s journey, let’s first take a look at factors influencing how much time and energy they are willing to invest in learning your technology and making it work.

  • Urgency: Is the developer actively searching for a solution to an existing problem? Or did they hear about your technology in passing and have a mild curiosity?
  • Constraints: Is the developer trying to meet a deadline? Or do they have unlimited time and budget to explore the possibilities?
  • Alternatives: Is the developer required by their organization to use this solution? Or are they choosing from many providers and considering other ways to solve their problem?

Developer journey to an API

With that context in mind, the following stages describe the developer journey of encountering a new API:

Step 1: Browse

A developer browses your website and documentation to figure out what your API offers. Some people gloss over this step, preferring to learn what your tech offers interactively in the next steps. But judgments are formed at this very early stage, likely while comparing your product among alternatives. For example, if your documentation and onboarding process appears comparatively unorganized and riddled with errors, perhaps it is a reflection of your technology.

Step 2: Signup

Signing up for an account is a developer’s first commitment. It signals their intent to do something with your API. Frequently going hand-in-hand with the next step, signing up is required to generate an API key.

Step 3: First API call

Making the first API call is the first payoff a developer receives and is oftentimes when developers begin more deeply understanding how the API fits into their world. Stripe and Algolia embed interactive guides within their developer documentation to enable first API calls. Stripe and Twitter also use Postman public workspaces for interactive onboarding. Since many developers already use Postman, experiencing an API in familiar territory gets them one step closer to implementation.

What do you need to know about production as a developer?

In most organizations, developers are not allowed to access the production environment for stability, security, or regulatory reasons. This is a quite good practice (enforced by many frameworks like COBIT or ITIL) to restrict access to production but a major drawback is a mental distance created between developers and the real world. Likewise, the monitoring is usually only managed by operators and very little feedback is provided to developers except when they have to fix application bugs (ASAP, of course). As a matter of fact, most developers have very little idea of what a real production environment looks like and, more important, of the non-functional requirements allowing to write production-proof code.

Involving developers into resolving production issues is a good thing for two main reasons:

  • It is highly motivating to get tangible evidence of a real running system on a large infrastructure (data centers, clusters, SAN…) and get insights about performances or business facts about their applications (number of transactions per seconds, number of concurrent users, and so on). It is also very common for developers to feel overwhelmed as they are rarely called directly when an outage occurs.
  • It may improve substantially the quality of the code delivered by helping to design properly operation aspects like logs, monitoring, performances, and integration.

So, What Do the Developers Misunderstand the Most Often About the Production?

1. Concurrency Is Omnipresent

Production is highly concurrent while development is mostly single-threaded. Concurrency can happen among threads of the process (of an application server for instance) but also among different processes running locally or on others machines (e.g., among n instances of an application server running across different nodes). This concurrency can generate various issues like starvation (slow-downs when waiting concurrently for a shared resource), dead-locks or scope issues (data overriding).

What can I do?

  • Perform minimal stress tests on DEV environment or even on your own machine using injectors like JMeter or Gatling… When using frameworks like Spring, make sure to understand and correctly apply scoping best practices (for instance don’t use a Singleton with a state).
  • Simulate concurrency using break-points or sleeps in your code and check the context of each staled thread.

2. Volume Is Huge: You Must Add Limits

In production, everything is XXXL (number of logs line written, number of RPC calls, number of database queries…). This has major implications on performances but also on operability. For instance, writing a Entering function x/Leaving function x type of log could help in development but can flood Ops team with GiB of logs in production. Likewise, when dealing with monitoring, make sure to make alerts useable. If your application generates tens of alerts every day, nobody will notice them anymore in a few days’ time.

Keep in mind this metaphor: If your DEV environment is a sandbox, production is the Sahara

In production, real users or external systems will massively stress your application. If (for instance) you don’t set attachment files maximum size, you will get soon network and storage issues (as well as CPU and memory as collateral damage). Many limits can be set at the infrastructure level (like circuit breakers in API Gateways) but most of them have to be coded into the application itself.

What can I do?

  • Make sure nothing is ‘open bar’: always paginate results from databases (using OFFSET and LIMIT for instance), restrict input data sizes, set timeouts on any remote call, …
  • Think carefully about logs. Perform operability acceptance tests with real operators and Site Reliability Engineers (SRE).

3. Production Is Distributed and Redundant

While in DEV, most components (like an application server and a database) run inside the same node, they are usually distributed (i.e., some network link exists between them) in production. The network is very slow in comparison with local memory (at scale, if a local CPU instruction takes one second, a LAN network call takes a full year).

In DEV, the instantiation factor is 1: every component is instantiated only once. In any production environment having to deal with serious high availability, performance or fail-over requirements, every component is redundant. There are not only servers but clusters.

What can I do?

  • Don’t hardcore URL or make assumptions about the colocalization of components (I already saw code where localhost hostname was hardcoded)
  • If possible, reduce dev/prod parity by using from your own workstation a locally distributed system like a local Kubernetes cluster (see K3S for instance).
  • Even if this kind of issue should be detected in integration testing environment, try to keep in mind that your code will eventually run concurrently on several threads and even nodes. This has implications on datasources number of connections tuning among others considerations.
  • Always favor stateless architectures.

4. Anything Can Happen in Production

One of the most common sentences I heard from developers dealing with a production issue is “This is impossible, this can’t happen”. But it does actually. Due to the very nature of the production (high concurrency, unexpected behaviors of users, attacks, hardware failures…), very strange things can and will happen.

Even after serious postmortem studies, the root cause of a significant proportion of the production issues will never be diagnosed or solved (I would say from my own experience in about 10% of the cases). Some abeyant defects can occur only on a combination of exceptional events. Some bugs can happen once in 10 years or even by chance (or misfortune?) never occur during the entire application lifetime. Small story: I was faced very recently with a bug in a node.js job that occurred about once every 10K (when a randomly generated password contained an unescaped double dollar characters sequence).

Check out any production log and you will probably see erratic errors here or there (this is rather scary, trust me).

Preventing expected issues is a good thing but truly good code should control and handle correctly the unexpected

Hardware or network failures are very common. For instance, network micro-cuts can occur (see the 8 Fallacies of Distributed Computing): servers can crash and the filesystem can be filled.

Don’t trust data coming from others modules, even yours. As an example, an integration error can make a module call a deprecated version of your API. You may also get corrupted files with wrong encoding or wrong dates. Don’t even trust your own database (add as many constraints as possible like NOT NULLCHECK, …): corrupted data can appear due to bugs in previous module versions, migrations, administration script issues, staled transactions, integration error on encoding or timezones… Let run any application over several years and perform some data sanity checks against your own database: you may be surprised.

Users and external batch systems should be treated as monkeys (with all due respect).

Don’t rely on human processes but assume they can do anything. For instance, two common PEBCAK problems occurring on front parts I observed recently:

  • Double submit (some users double click instead of single-clicking). Some REST RPC calls are hence done twice and concurrency oddities occur in the backend;
  • Private navigation: for some reason, users switch to this mode and strange things happen (like local data lost or browser extensions disabled).

Most of the time, users will never admit or figure out these kinds of errors. They can also use the wrong browser, use a personal machine instead of a pro, open the web app twice in several tabs, and many others things you would never imagine.

What can I do?

  • Make your code as robust as possible, write anti-corruption layers and normalize strings. When parsing data, control time formats, encoding, formats  (if using hexagonal architecture, perform these controls as soon as possible in the ‘in’ adapters).
  • Add as many constraints checks in your database as possible. Don’t just rely on the domain layer code.
  • When possible, instead of writing your own controls, rely on a shared contract (like a JSON or XSD Schema).
  • Think about retries, robust error handling, double submission, replays from save points in batch jobs, …
  • When writing your tests, think about as many borderline or apparently impossible cases as possible.
  • Use chaos-engineering tools (like Simian Army) that generate errors randomly to test your code resiliency.
  • Think about what to do with rejected data.
  • To deal with human errors, identify problematic users, book a meeting and observe them using your application before asking any direct question to avoid directing them.
  • Build a realistic testing dataset and maintain it. Add new data as soon as you’re aware of a special case you didn’t consider before. Manage these datasets like your code (versioning, cleanup, refactoring, documentation…).
  • Don’t ignore weak signals. When something strange happens in development, it will probably happen in production as well and will be far worse then.
  • When fixing an issue, make sure to identify all the places where it can occur and don’t only fix it in the place you localized it.
  • Add clever logs inyour code. A clever log comes with:
    • A canonic identifier in the message (an errors code like ERR123 or an event ID like NEW_CLIENT). This greatly eases monitoring by enabling regexp matching;
    • All required debugging context (like a person UUID, the instant of the log…);
    • The right verbosity level;
    • Stack traces when dealing with errors so developers can easily localize the problem in their code.

5. Issues Never Walk Alone

In production, things never ever get better on their own: hope is not a strategy. Due to Murphy’s law, anything with the ability to fail will fail.

Worse: issues often occur simultaneously. An initial incident can induce another one, even if they look unrelated at a first glance (for instance, an Out Of Memory can create pressure on the JVM Garbage Collector which in turn increases CPU usage, which induces queued work latency and finally generates timeouts from clients.

Sometimes, this is even worse: truly unrelated issues may occur simultaneity by misfortune making the diagnostic much more difficult by leading down on a wrong way when performing the post-mortem.

What can I do?

  • Don’t leave issues in logs in production or in DEV unresolved. Most issues may be detected in development or acceptance environments. Often, we observe problems and we ignore them, thinking this is transient, due to some integration issue or intermittent network issue. This kind of issue should instead be taken as a chance to reveal a real issue and should not be ignored.
  • When you observe something strange, stop immediately and take a few minutes to analyze the issue or to add new test cases. Think you may have found an abeyant defect that would take days to diagnose and resolve later in production.

6. In Production, Everything Is Complicated, and Time-Consuming

For some good but also not so good reasons, every change should be controlled and traced in a regulated IS. Perform a single SQL statement must be tested in several testing or pre-production environment and finally applied by a DBA.

Any simple Unix command has to be documented in a procedure and executed by the Ops team who is the sole one to access the servers. Most of these operations must be planned, documented in-depth, motivated, traced into one or several ticket systems. Changing a simple file or a single row in a database can hardly take less than half a man-day when counting all involved persons.

The costs increase exponentially when we are getting closer to production. See [Capers Jones, 1996] or [Marco M. Morana, 2006]: a bug can cost a low as $25 to fix in DEV and as high as $16K in running production.

Even if modern software engineering promotes CD (Continuous Deployment)  and the use of IaC (Infrastructure As Code) tools like Kubernetes, Terraform, or Ansible, deploying in production is still a significant event in most organizations and most DevOps concepts are still theoretical. Deploying a release can’t be done every day but about once a week or even a month. Any release usually has to be validated by the product owner’s acceptance tests (a lot of manual and repetitive operations). Any blocking issue would require a hotfix coming with a lot of administrative and building work.

What can I do?

  • Perform as much unit, integration, and system testing as possible before the production environment.
  • Add hot-reloading configuration capacities to your modules (like changing log verbosity using a simple REST call against an administrative endpoint).
  • Make sure that all processes with operations (ticket system, people to contact, way to alert…) are documented and quickly accessible. If not, document them to gain a lot of time the next time.

7. Production Is Very Stressful

When an incident occurs in production, your stress level may depend on the kind of industry you’re working for but even if you work for a medium-sized e-commerce company and not a nuclear facility or a hospital, I can guarantee that any problem generates a lot of pressure coming from customers, management, others teams depending on you. Ops teams are used to it and most are impressively calm when dealing with this kind of event. It’s part of their job after all. When the problem comes from your code, you may have to work with them and take on yourself a part of the pressure.

What can I do?

  • Make sure to be prepared before the incident by writing or learning procedures (read for instance the great SRE Book by Google chapter 14).
  • Be confident in your logs and monitoring metrics to help you to find the root cause (for instance, prepare in advance insightful dashboards and centralized logs queries).
  • For any complex issue, begin the investigation by creating a post-mortem document centralizing any note, stack trace, log, or graph illustrating your hypothesis.

8. In Production, You Usually Don’t Start from Scratch

In development, when your database structure (DDL) evolves, you simply drop and recreate it. In production, in most cases, data is already there and you have to perform migrations or adaptations (using ETL or others tools). Likewise, if some clients already use your API, you can’t simply change the signature without asking questions but you have to think about backward compatibility. If you have to, you can depreciate some code but then, you have to plan the end of service.

What can I do?

  • In development, don’t just drop DDL but ‘code’ changes using incremental changes tools like Liquibase. The same tools should be used in production.
  • Check that your libraries or API are still backward compatible using integration tests.
  • Use Semantic Versioning conventions to alert for breaking changes.

9. Security Is More Pregnant in Production

In any seriously protected production environment, many security systems are set up. They are often absent from the others environments due to their added complexity and costs. For instance, you can find additional level 3 and 4 firewalls, WAF (Web Application Firewalls operating at level 7 against HTTP(S) calls), API Gateways, IAM systems (SAML, OIDC…), HTTP(S) proxies or reverse proxies. Internet calls are usually forbidden from servers that can only use replicated and cached data (like local packages repositories). Hence, many security infrastructure differences can mask issues that will be only discovered in pre-production or even production.

What can I do?

  • Don’t use the same values for different credential parameters. This can hide some integration issues in production where parameters have more chances to be different and where different passwords are used for any resource.
  • Make sure to understand the security infrastructure limitations before coding related user stories.
  • Test security infrastructure using containers.


It’s a good thing for developers to be curious and get information about the production by themselves by reading blogs, books or simply asking colleagues. As a developer, do you know how many cores a medium-range server owns (by socket)? How much RAM by blade? Did you ask yourself where the data centers running your code are located? How much power consumption your modules use in KWH every day? How data is stored in SAN? Are you familiar with fail-over systems like load balancers, RAID, standby-databases, virtual infrastructure management, SAN replications…? You don’t have to be an expert but it’s important and gratifying to know the basics.

I hope I provided developers a first glimpse of the production constraints. Production is a world where everything is multiplied: the gravity of issues, costs, time to fix systems. Always keep in mind that your code will eventually run in production and a working code is far from being enough: your code must be production-proof to make the organization IS run smoothly. Then, everything will be fine and everybody will be at home early instead of pulling out hair until late the night…

21 Years Of Programming Experience Distilled

I’ve developed software for over 21 years now, which is way over half of my lifetime, both professionally and as a hobby.

Here are some of the most valuable lessons I learned along the way.

You will never know everything

Especially at the beginning, I thought I could learn everything, and I thought this for a good portion of my developer career. But each time I learned something new, a whole new world of other concepts and techniques opened up.

It may seem tempting to try and learn it all, but it’s a never-ending endeavor. There will always be another library or framework and another cool thing you could also learn.

The only thing that happens is that you slowly start to burn out because you seem never to reach your goal. Better settle on what you know well and learn on-demand when you really need to learn something new. This keeps you sane and your motivation up.

You can also transfer this to any other domain. It’s possible to be effective without knowing everything. Use this to your advantage, learn along the way when necessary.

A good team doesn’t scale your capabilities linearly but exponentially

Working on your own is fine, but it also leaves you in your own capacity.

A good team, however, that you can always talk to and discuss with, can leverage your thought process a lot. Issues become easier to solve, problems better to tackle. The effect is usually exponentially and not only linearly in my experience.

There is a threshold, though, at which a team becomes too large. In my experience, this threshold depends on the people involved.

Try to surround yourself with amazing people you can get along with pretty well, also on a personal level. You’ll see that you can get things done way faster than before, and you’ll perhaps even enjoy it more.

Code should be written for humans

There was a time I felt so clever to write highly optimized code that ran as fast as possible. Whenever I revisited this code after a long while, I had no clue what I did back then anymore. It always took me a good portion of my time to get back into the code before doing the work I actually came for. Even worse: 99% of the time, those optimizations were unnecessary.

Code should first and foremost be written for humans to read and understand. If you believe that a certain code path might be a performance bottleneck, then test it. Add metrics to measure the execution time for the paths in question and analyze them later.

You will usually find out that the code in question is actually not the problem. More often than not, you find that the problem is actually something completely different.

If some code is really the issue, please add as many comments as necessary to explain why this code is optimized. If you need to explain what your optimization does, do it.

You’ll often catch comments from people stating that you should never state “what” code does. Here is my take: If you can’t make it more understandable and know other developers will need help understanding it, add those comments.

You can either listen to people evangelizing against this approach and spend more time and money on a future issue, or ignore them and ensure that everyone has a chance to get into and work on it. Teams are individual. Act accordingly.

Patience is your best friend

There was a time I wasn’t patient, and I still suffer from this sometimes.

It regularly takes time to solve a bug or complete a feature. And often, learning something new takes longer than anticipated.

If you really feel the need to hurry, you should ask yourself what the reason for this feeling is.

Is it yourself? Please stop it. You can still finish tomorrow or the day after tomorrow. Then, the next time you have to solve a similar issue, you’ll be faster.

If it’s your employer, you should definitely think about whether this is the right company for you.

There are many managers out there who think the faster software is delivered, the better. They set unrealistic deadlines and expect too much from their developers. Those managers have understood nothing about how software development works.

Sometimes you are confronted with something completely new. It takes time to come up with an idea. The more experience you get, the better you become at dealing with such situations.

Try to stay patient and don’t put yourself under pressure. You work better when you can stay calm and order your thoughts to develop an idea. And it will definitely benefit your mental health.

It can be the most difficult thing on earth to not pressure yourself, and you won’t always keep yourself from doing it. That’s okay. You should still do your best to prevent yourself from doing it, though. It can harm you for a long time.

Consistency is key

Doing something consistently over and over again is what helps you to become proficient in it. It’s not about putting 20 hours in once. It’s about 15 minutes or an hour each day you put in.

The repetition you do over and over again is what makes you better at what you do. You first look up things frequently, and slowly but steadily, you have to look up less and less. This is your brain slowly learning patterns and saving them.

There is always someone better you can learn from

Technology is such a large field that you’ll never learn everything.

Other developers have learned different things than you. This puts them at a knowledge advantage in certain things. Use this to your own advantage!

Your colleagues might be better at backend, CSS, or low-level stuff than you while you have your own strengths. You can learn from them, and they can learn from you.

This is never something you should be jealous about or take to your heart. It’s actually awesome that you can make connections to people that can enrich your knowledge. You get years of experience you can profit from to increase your knowledge. And you also get years of failure to learn from, so you don’t have to make the same mistakes.

Networking is important

Get out and find people to connect with. This is so important today.

I thought that having a great CV would open all the doors for me, but boy was I wrong.

If people don’t know you, they will judge you based on a piece of paper. But if people know you, they are probably aware of your strengths and weaknesses. This makes it so much easier to get your next job or contract. And it always opens up opportunities for learning, work, and interaction.

Frequent breaks make you more effective

As long as you don’t hit “the tunnel”, that state where you can simply go on coding or working without even noticing time passing, your brain will need frequent breaks.

A break helps your brain to recharge and process the information it previously consumed. You basically enable it to catch up. Do something completely different. Go, get a coffee, take a short walk, but at least somehow leave your work desk.

You’ll probably notice how your performance degrades more and more before you take that break. When you return after your break, you’ll notice that you’re back at it. You can perform again until your next break.

There were times I didn’t take care of breaks because I wanted to get my stuff done. It turns out I would have finished way faster if I would’ve let my brain rest for a little every once in a while.

A good rule of thumb is at least a 5-minute break each hour and a longer one of up to 30 minutes after 4 hours. Even better: Listen to your body and adjust your breaks accordingly.

If you begin to feel tired, see your performance degrade, or have problems concentrating, take a break.

If you want to advance further in your career, you need to be a people person

At the beginning of my professional career, I believed that I’d get rewarded if I put enough work in. As it turned out, at least for me, this was not the case. No one came to me to offer me a promotion or more money. I felt I simply went on unnoticed.

The moment I became vocal about my work and started to interact more with my peers and managers, my career took off. If there was a problem that somehow suited me, I could be sure to get the task assigned. I became known for certain things and was frequently asked for support, and I got promoted. I didn’t have to make a lengthy list of my accomplishments for my early performance review anymore. My manager already knew everything.

Why? Because I talked about work with my colleagues and managers frequently. I never bragged. I made statements and openly helped my colleagues. And I also talked a lot with people on a private level. We got to know each other better and formed a connection.

At least for me, it worked out perfectly. Your experience might differ because it highly depends on the company and culture, but it might be worth a try.

Most companies are not what you expect them to be

When I finally got to work professionally, I had unrealistically high expectations of how it would be. I imagined working with top-tier engineers, technologies, and on awesome problems. As it turned out, I was wrong.

Don’t get me wrong, the engineers were still awesome, but simply not how I had imagined them to be. The technologies we worked with were nearly boring. The problems were not so awesome.

I learned that all engineers make mistakes and don’t know everything. They are human, after all. And the technologies were usually exactly the right ones to tackle the problems we worked on.

The more boring a technology is, the better it helps to solve certain problems.

Software is made to solve all problems. Some of those are more boring than others. Not every developer can constantly work on software that is going to change the world. Often, that small frontend that makes someone’s life a little easier or the API that moves files from A to B is what makes your employer money.

The important thing to realize is that not all companies can work at a scale that FAANG companies do. And even there, problems are tackled that sometimes seem boring.

Another important takeaway: There are many developers like you out there. You will make your impact, and not all your colleagues will be as top-tier as you imagine them to be. They are normal developers who do an insanely good job and know as much as you do.

This image has an empty alt attribute; its file name is 1_om7uik6cinjxwllaxgjstg.jpeg

Discern their subtle maneuvers and tackle them by not overreacting to their insidious insults. (Everyday examples)

Some months ago, I was looking for the WC in a “high-class” bar, dressed in a not-so-formal style. At that moment a waiter passes by, looks at me, and says in a weird yet insidious manner; “The WC is only for the customers.”

So, me thinking with my non-suspicious mind that he might be confused, I reply with an innocent smile; “Yeah, I’m sitting right there”, waiting for his apologies. However, what I received was something I didn’t expect at all.

He, with the same insidious and purposeful manner, said “It’s only for customers.”, and as soon as he threw those malicious words he leaves, giving me no time-space to answer.

For about 30 seconds, I hadn’t understood what all this was about. Then, I realized. That person had just insulted my appearance. Despite that, he got away. “Poor me” I was completely unaware that I could receive that treatment.

Life isn’t so peaceful as we believe. War still exists but in less apparent layers. When we talk about “war” in our everyday lives, we think about insulting moments, usually the subtle ones. Offensiveness colored by subtlety is the only form of aggression that can survive through our politically correct society.

The people who act like that are called passive-aggressive. You deal with them every day. Most of the time, they are toxic people that you should avoid and get distant from, but for whatever reasons — being your colleagues, boss — you just can’t. So, let’s navigate together through some classic examples of their behaviors and see how we can deal with them.

Two Classic Examples of Subtle Passive-Aggressive Behaviors

All the passive-aggressive people, share the same mixed characteristic: cowardliness with offensiveness. It’s usually displayed as:

  • Irony: Passive-aggressive people bombard their targets with subtle insults and teases, usually presented as a bad sense of humor. In those cases, they dress up their immense cowardness as fun, because they are fearful of exposing their real intentions to the person they speak to. However, if you become vigilant for a moment, you can tell for sure, that something goes wrong with their statements.
  • Passive Disrespect: This behavior defines their true face. They use their indifference to passively offend you. A classic example is that they don’t look you in the eyes while talking to you. By demonstrating that subtle resentment towards you, they offend you even more, as they aren’t showing simple rules of respect.

How to Deal With Them; 1) Don’t Fall Into Their Trap

Passive-aggressive people are excellent at justifying themselves. In fact, they can brilliantly manipulate you and make you believe that you’re hyperbolic. They can convince you that their teases are just for fun, and their disrespectful behavior is due to their bad mood.

And indeed, you might believe them for an instant, thinking how stupid you are to making that presumption. However, the next exact moment, they’ll push you more to your edges, and because you “had enough” you’ll give up on your feelings, getting outraged.

When you become so overreactive, despite it might seem that you stand up for yourself, in fact, you’ve fallen into their trap. Why? Because you got into their game. They led you where they wanted right from the start — to erupt and suffocate. Thus, all of a sudden, people from your close environment start to name you as hyperbolic and emotionally unstable, because how could they know? They tell only what they can see.

So, how do you break their game?

Emotionlessly Reveal Their Malicious Intentions

The moment, you’ll remain stable in their passive-aggressive behaviors and very calmly expose them, you’ll win. Of course, to achieve that you need very strong emotional control: As they start messing with you, stay calm. Then, having a very logical yet assertive look state they’re annoying behavior.

For instance, as they make an offensive type of humorous statement, don’t enter their frame. Reply to them, with a calming yet strict voice, “What do you mean?”. The important thing here is to remain unreactive and passionless.

They’ll probably try to analyze their “joke intentions” but as they’re doing that they lose their power. Because you’ve just revealed their cowardness, and therefore all their weakness. Now, they feel tight and stifled.

This is the body language of a cowardly sly character, tight and insidious. In fact, most thieves in metro and bus stations, when they are revealed in the act, look like that. Because theft, in general, is a very sly act anyways.

Final Thoughts

Life will throw a bunch of different people you’ll need to deal with. However, passive-aggressive people are a weird category as they possess an insidious strategy, and so they can offend you and easily get away with that.

Being aware of what it takes to tackle their artful maneuvres and don’t enter their toxic game is a skill that you need to learn. So, start to be more strategic about how you deal with them and remember:

  • How to identify their invisible behaviors.
  • Don’t get into their trap and play their game.
  • Remain emotionless and directly reveal their cowardliness.

The more we’ve learned, the more we’ve realized there’s so much more to learn

As developers, the longer we’re on the job, the more experience we gain. Eventually, we may even become the go-to person on our team or in our organization, seen as the technical guru of our field.

At this level, we get a self-esteem boost, which is positive. But at times we may fall into the trap of getting an unnecessary ego. The wrong mindset creeps in, which can lead to the beginning of our downfall.

I’ve been through that journey. So I now consciously remind myself not to fall into one of those mindsets again. We’ll talk about three of them.

I’m a Self-Taught Programmer, and I Need No One

I once saw a tweet from a person who claimed his father (a programmer) offered to teach him how to code, and he rejected it. The author of the tweet is now a developer, describing himself as a self-taught programmer.

Programming isn’t a skill one can master completely by simply taking a course or getting a degree. A lot of sweat and time spent digging and learning is needed to build one’s competency.

It’s not a field that can be effectively explored and fully discovered alone. We might not have a personal mentor and we may not have taken any formal courses, but that doesn’t change the fact that we still learn by reading from somewhere — whether that be a book, tutorial, blog, manual, or even Stack Overflow. All these things were written by someone.

In fact, the best way to learn programming is by working with a group of developers — through code reviews, pairings, constant discussion, and the exchange of ideas and the information learned. Attending conferences, guilds, dojos, etc. helps too.

Therefore, much of what we’ve learned and where we are today isn’t a result of our self-meditation on a mountain. Instead, it’s an accumulated assimilation of the knowledge and experience others have shared with us, either directly or indirectly.

We should always be grateful.

I’m Better Than Younger Programmers

Someone responded to one of my past blogs saying, “The young ones can’t concentrate. And their productivity is vastly lower than that of us oldsters. Their code quality is way lower.” I felt disgusted by this blanket statement targeting young programmers, even if I’m not the young one.

We learn, we grow, we age. With the advantage of time, we sometimes gain an upper hand in terms of both knowledge and experience in some area.

However, software development is an ever-changing field. One needs to continue learning to keep abreast of a skill. Over time, some of the past knowledge we acquired and spent time on is no longer relevant. When you consider what’s still relevant, the knowledge gap between older and younger programmers becomes smaller.

At times, some area of knowledge younger programmers have might surpass us, the older folks (I consider myself an older folk, having worked for more than two decades). In software development, there’s been so much new knowledge to harvest in the last 10 years, and it’s not possible for us to extract it all.

Never look down on the young ones. Respect each other, and always shamelessly ask and listen to their opinion. Be open. Avoid impostor syndrome. We might be surprised to learn a lot from those younger than us.

The young ones are the future. They’ll shape the world one day. Teach them as much as you can, and also learn from them as much as you can. We’re not always right.

New Tech Is Just Recycled Old Tech

“What more is there to learn within programming? Everything new is just an old thing with a different look — or it’s just if-else or for loops covered by fancier names and structures externally.” I thought this back then after I’ve mastered C++ and object-oriented programming.

I despised Java as an inferior language to C++ and looked down on all scripts — VBScript, JavaScript, and let’s not forget HTML, which isn’t even a language to me. Python, what is it? No {} and, it’s optional to use ;? Using indentation is a must??

The word evolve meant nothing to me, and after a decade, Python became the most used language.

I still have the utmost respect for those with competency in C programming, having the ability to work with pointers, having proper memory management, and writing code that compiles into the smallest and most efficient executable.

However, that’s no longer what mainstream software development looks like. Web programming took the world by storm in the ‘90s and early 2000s. Since the launch of the iPhone, mobile development has become a significant player in software development. And now artificial intelligence could be the next wave, which the Python language plays a significant role in enabling.

Fast forward to today: Now I’m getting my feet wet in mobile development, a rapidly changing field. I just realized how wrong I was back then in despising the newer yet seemingly inferior product (i.e., Java) over what I’d mastered (i.e., C++). Java has influenced many of the programming languages we have today, and its JVM is the backbone of many new languages (e.g., Scala and Kotlin).

Never despise newer tech at a glance. It’s true most of them spawn from an existing tech and may look similar (or at times even inferior), but all of these small little changes could contribute to the next leap of change.

Posted by: lrrp | May 20, 2021

Why Some Senior Developers Ain’t Ready to Lead

Leading development is no longer just developing software

After being promoted to a senior software developer, it is natural that our next aspiration is to be a lead developer. A lead developer is a position where one still technically very involved, but no longer does all the coding by oneself, instead, works with other developers to get the project through.

It may sound simple, just get another project done. However, there’re nuances one needs to be aware of to able to lead the project through successfully. Failing to tackle them, could incur unnecessary loads or impede the success of the project. Below are a few points to look into.

“Please give me all the requirements” attitude.

Product Manager: “We need to build a saved user notes feature.”
Senior Developer: “Hmm… where do you want to save it? On the device or on the server? What format do you want us to save? What about this… that… We’ll need all these before we can work out anything.”

As a developer, we love to be given specific requirements. The best is the requirements given are to the dot without any ambiguity. Without them, it is impossible for one to proceed with the project. That’s typically the mentality of some developer.

For the example given of “save note” above, from the technical point of view, the requirement above is really vague. There are many options and considerations one should consider.

The developer asked valid questions. However, from the product point of view, it is relatively clear (assuming the design is given). The product manager will not be able to advise all the technical aspects.

As a lead, we will have to take such a “vague” requirement and work out the details, make it clearer from the development standpoint, that developers can work on them.

We will not be given “all the requirements”. Instead, we are responsible to detail out these “requirements” to fill the gap between what the Product Manager is asking for and what developers can take in and start the work.

“That’s simple, anything can be easily done without thinking broadly” mentality.

Product Manager: “We need to build a saved user notes feature.”
Senior Developer: “That’s a piece of cake, easy peasy. It is just a user input, and save to a file.”

The reason one is promoted to a senior developer is that one has a set of strong technical competencies, with a “can-do” attitude. This is a great asset of a senior developer.

The “can-do” attitude if not handled well, and not given any boundary, might lead to “over-confident” with the risk of oversimplifying a given project, making one fails to take pre-cautious of to notice what’s really required, what’s in place, and some unforeseen complication behind.

As a developer, whenever we are given a task from our lead developer, it is more likely the task is already scoped properly, well thought and covered. Hence we can take in the task as it is, as its feasibility has been verified beforehand.

However, as a lead, we are given a relatively raw requirement. The technical aspect of it has yet to be ironed out. Even if a task might sound simple, there are likely many edge cases consideration to cover, options one needs to evaluate, and how it needs leverage and links to the existing systems. It requires either one’s experience or conscious mental thought process to prepare ahead before committing

The example given of saving notes can be a simple piece of features for a solo developer if he owns the entire small piece of software. But, within a larger organization, any features introduced are more likely to be linked with other systems that one should take into account before developing, e.g. how the backend service should handle it, how do we manage synchronization, etc. Therefore, it might not be as “easy peasy piece of work” as it looks.

Having said this, it doesn’t mean no project can be a simple project. It just means the meaning of “simple” needs to be qualified with the experience one had with the industrial requirements and organization context of what’s feasible.

Nonetheless, it is okay to ask questions for clarities from a product perspective or technical vs business tradeoff. Having said so, as a leader, one should be ready to make recommendations and provide options when it comes to technical requirements, instead of waiting to be fed with the details.

“I only know what it needs after I work on it, there is no way to split my task” process.

Project Manager: “Can I have someone to help you with the work?”
Senior Developer: “I’m better off working myself, as there’s no way to figure out what’s needed until I work on it. I don’t think anyone can help me.”

Some developers did very well when given a card. They can experiment and then craft the thing out nicely, optimize it, and have good tests. Initially, they are given a simple task, and hence it takes 1–2 days. When given a bigger task, it will continue to be a single card, but take a longer duration of 3 to 4 days.

It is not because they don’t like to break down tasks into smaller pieces. It is just to do so, requires experience and time spent on it to plan it out. Without the experience of doing so, and willingness to spend that overhead time, one will not be able to split the tasks out properly or at all. Even if it is split out, the small tasks often overlap with each other without a clear partition of how they linked with each other. The definition of done for each task is fuzzy.

The tendency of developers is when given a requirement, one would like to jump on coding, and see how it progresses. Naturally, as a developer, we feel planning is like a waste of time. Without doing coding, it feels like nothing is done. We feel nervous. All these while, our deliveries are code and product, and hence we like to start coding soon and minimize any overhead.

The habit of “code immediately” doesn’t scale when it comes to a larger task. It limits to having one person work on it. It is actually also not an ideal “coding practice”. Ideally, even for smaller tasks, having some thought process of how it can be broken down and structured properly is would almost well pay off later.

The ability to break down projects into appropriate feasible smaller tasks requires skills, experiments with careful thoughts and considerations. It is not something one can switch on and do immediately when one became a lead.

Therefore, one should start by learning how to break down a medium-sized task into few smaller tasks, and gradually gained experience when working on bigger and bigger tasks. Over time, this will become more natural, and one can easily visualize it without even need too much mental process.

“I need to figure out all details before I can clearly plan out the project” urge.

Project Manager: “Can we break this piece of work down to get an estimate?”
Senior Developer: “Give me some time to code out all the details. It will take what it takes.”

Okay, we need to plan the project by breaking it into small tasks. It is important to ensure these tasks are well-linked together and clear partitions between them. To do so, some developers will plan out all the tiny details e.g. what class, function, member variables, etc.

Each task was so well polished and contain precise clear steps of what one should do to achieve the card. It at times even has pseudocodes of how one can get it done. The task card itself is almost like a done code, except it is written in English instead of code.

While this sounds really great, it is impractical. To get such detailed task cards in place, too much time is spent on them. The time used could equate to the time needed for the real work sometimes. The bottleneck now is in the planning stage, as it is handled by one person who performs such detailed planning.

As a lead developer, we should learn to only plan out the high-level detail, but leave out the low-level detail. This is crucial both in terms of efficiency as well as flexibility. In each card, we just need enough information on “what-to-do” instead of “how-to-do”. We will save time, and also allow “how-to-do” to evolve with more time to plan for it.

The lead developer perhaps can code the initial high-level framework and stubs as preparation for the subsequent cards to add in the details of it later. Such a high-level framework once put in place, allows the subsequent development to be done in parallel by developers.

Therefore, the lead developer doesn’t need to get into the detail of everything before the development can begin. Everyone gets to work on it sooner.

“It should only be done this one and only way” compulsion

Developer: “Can I explore that new way of doing things?”
Senior Developer: “I have done this for years! Why don’t you just trust me and follow what I just told you.”

As senior developers, we are experienced and have a fixed set of ideas on how things should be done. Sometimes we do have some philosophical view of certain aspects of development, which has no right or wrong. That’s perfectly fine.

However, at times if we are not careful, we can fall into a fixated mindset of one and only one way of doing things is right, and that is the way we think is always right. This is not definitely always a bad thing if we are technically the most competent person in our group, and continue to be one despite we have lesser time to code and learn.

Most often than not, we as humans ain’t perfect, and we work better as a team with a collective set of knowledge and experiences. Thus, it is very important for us to differentiate between what we think is best vs what the team think is best.

“Documentation is just an essay of my thought process, no diagram, no tables, just words” slackness.

Developer: “It is possible to put a diagram to illustrate the flow better?”
Senior Developer: “Everything is written in the document. Just read it… and read it a few times if you cannot get it.”

Many developers dislike writing documentation. Coding is more fun than writing documents. But everyone understood and agreed, to work on a big project, we need to document out and communicate what’s needed. Hence it is like a necessary evil.

To write, some will just simply write steps one, two, three, etc. No context given. No further elaboration in digram on how the complex flow works, but just a long paragraph of the essay-style writing stating how that is done.

Drawing diagrams and tables is cumbersome, as most tools require one to use the mouse. Developers just like typing and not having their fingers leave the keyboard. Hence writing and typing essay-style of words while is not fun, is still bearable. The work is to just get the document done, and “at least I have done it”.

However, as a lead developer, documentation is one of our products. It will be used to communicate the essence of the project to developers. Good documentation will usually couple with diagrams and tables, especially those work that requires work across systems and flows. It is universally recognized people visualize better with diagrams and tables for technical knowledge.

Again, this is an area that needs practice and the desire to communicate clearly what is the project about and how it will be partitioned and worked on. If this is done properly, 50% of what the lead developer needs to do is done. Down the road, as the developers work on the tasks, this will be a source of reference. Hence, effort on it will pay off very well.

Beyond communication, well-thought documentation is a good mental exercise to discovered missed areas, corner cases, and options one has on a project. My experience is when I’m drawing up diagrams and tables, I often noticed parts that were missing in my thoughts, and raise further questions for me to answer.

At times, as the writer of the documents, I forget the content, and the document helps remind me too. The diagram makes me recap quickly and explains to others without the need to scan and read through a paragraph of words. The benefit is enormous.

Try to put some diagrams and tables etc, and whatever makes it easier to consume for everyone. A very just-essay-style of technical documentation is not as digestible.


As a developer and senior developer, our main role is to work on a project, code, and deliver the software product. Coding is the core of what we’re doing.

To grow to the next level e.g. lead developer, where while we should still be technically relevant, our main role is no longer producing product by coding. The role of a lead developer is to technically prepare how a project can be successfully kicked off and progress effectively.

Therefore, before a senior developer can transition into a lead developer position, it is important for one to start looking into the aspects mentioned above and try to change some typical “career-limiting” developer attributes.

It is true that a lead developer will not be able to code as much, instead write more documents, and with more meetings. The satisfaction no longer comes from code and see it compiled well, but more from seeing how the project smoothly worked on by the developers.

Ultimately you still see the product shipped knowing it is not your sole effort, but it is really a team effort. It’s no longer a small project, but a larger project that one cannot just do alone.

My boss once told me, “If you successfully ship the product by coding it all by yourselves, you still fail.” Working through and with the team is the key.

Sometimes what the team prefers is not what makes sense for us initially, but as a lead developer, one should have the capacity to rationalize and being flexible in accomodating the team’s decision, unless we have a crystal clear view that’s totally wrong.

Secondly, as a lead, we defined the high-level tasks. When it comes to low-level tasks assigned to the developer, it is very important to allow the space for the developer to work more flexibly on how the tasks should be solved instead of us mandating everything.

We just need to figure out what to figure out, so that developers have the opportunity to figure out the lower level item. At most, we can provide guidance and advice that suffice for one to not diverge from the team norm, but still allow ample room for the developer to explore and innovate.

There are many benefits to doing so. One, it is more scalable (i.e. the lead developer doesn’t need to decide all the details). Two, the team’s overall knowledge and skill expand as well. Three, the developer feels more empowered and contributes better.

The ability to work as a team is crucial for a lead developer. It is important to remember, although we are in a leading role, we are not in a dictating role.

Posted by: lrrp | May 13, 2021

The Real Reason You’re Not Getting Promoted

Why is it that our education system neglects to teach us the skills needed to excel in our career? Yes, we are always taught to do a good job, but is that enough? The answer, as we all know, is no.

Doing good work and trying your best is simply the baseline expectation for being considered for a promotion, but it’s not what gets you promoted.

Most people admit to doing just enough work to avoid getting fired. How is that a way to go about your career?

75% of the workforce believes that advancing in their careers and finding meaning in their 9-to-5 is some sort of a myth. I’m here to tell you that it is not.

Before jumping into specifics, you must first believe that finding purpose in your work is not out of reach. You must believe that your work matters. You must believe that you matter. And lastly, you must believe that the ceiling is not where you think it is.

Let me first start by saying, you will never get ahead in your career, or even get promoted if all you’re banking on is doing your job well.

That’s right. Contrary to belief, if all you bring to the table is being good at your job, then at best, you might get recognized for your service. Every so often you will receive the occasional “bump” in your salary too.

I’ve been in the career coaching/staffing business for quite some time now, and here is what I see most often on resumes:

  • 20 years of project management experience.
  • 15 years of experience as a Senior Accountant.
  • 10+ years of experience of financial analysis.

I think you get what I’m saying. Each time I read that, I always ask my clients, why have you been a Project Manager for 20 years? Why haven’t you moved into a Director, VP, or Program Manager role in that timeframe?

To the Accountant: why haven’t you moved into a controller-level role? Do you not want to be a Director of Finance?

If you love what you’re currently doing and a promotion is not a goal of yours, then that’s totally fine. There are many people who go the specialist route and there is nothing wrong with that. In fact, there might even be more money in that route in the long term. But that’s a completely different story for a different post.

If you are, however, getting passed up for promotions and not moving into leadership roles, then keep reading.

Being in the industry that I am, provides me direct access to Fortune 100 — Fortune 500 executives and leaders. I also have extremely successful friends. From people who’ve built multi-million dollar companies, to corporate big whigs, and thought leaders.

I know the exact qualities, and traits they look for — not only when they are hiring someone, but more importantly, when they want to promote them.

And what’s the last thing they look for? You guessed it, the last thing that they look for is someone who has merely done their job well. Let me reiterate, that’s just the minimum standard to even be considered for advancement.

From working with my clients, and talking to my super-friends, I’ve compiled a list of the most important traits that people who get promoted possess:

They don’t rely on good work alone. Their behavior, and the way that they treat people is what others remember most about them rather than just their professional output.

They are extremely self-aware. They welcome constructive criticism about their weaknesses (both personal and professional weaknesses), and then work diligently to improve upon them.

This can be done in many ways — reading self improvement books, working with a coach, attending conferences, finding a mentor, etc.

The point is, they hate to be stagnant. They believe that growing is living, so they work extremely hard to improve who they are every single day.

They have a strategic vision that is bigger than themselves. If you only care about yourself, your work, being solely recognized, and your own salary, than you’re digging yourself into a bigger hole than you might realize.

If you don’t align your work with your company’s vision and mission strategy, you’re not going to get ahead.

Extremely successful people will tell you that they believe in something that is much bigger than themselves. Their turning points (including my own) came when they set out to help others achieve what they wanted and put their wants on the back-burner.

They aligned their actions with their company’s values and vision. They thought about their role and how it could help the entire company further its cause. It wasn’t just about them.

They had an owner mindset. This is perhaps the most important trait of them all. Having this mindset says a lot about you as a person, and it shows how much you actually care about the company.

When you see yourself as an employee — someone who works for ‘just’ another company — your employer will view you that way as well. Your employer will notice that you’re only working for a paycheck, that you’re clocking in at 8, taking a full one hour lunch break at 12, and then clocking out at 5.

Don’t get me wrong. You will still get noticed from time-to-time if you do good work. You’ll possibly even get rewarded for it too, but you won’t make it to that next-level of success you’re hoping for.

When you think like a company owner, you become one with the company. You put the company’s best interest at heart. You act and talk differently. This is when your employer will notice you and put you in a better position to succeed.

Think of it as a relationship. The more you do for someone else, the more appreciation you will receive. It’s the same exact concept with a company. You get out what you put in.

They make everyone else’s life around them much easier. One of the key take-away’s from this point is this: if you can make your bosses life easier, and even their bosses life easier, you’ll automatically be viewed much more favorably then anyone else.

There are several ways you can accomplish this.

  • Do not give your boss any real reason to talk to you, at least about your performance. Unless you need coaching, or guidance on something, become invisible to them (again, as it relates to talking about performance). The secret is, leaders want to know that they can trust that you’re always doing what’s best for the company, and doing it well.
  • Become proactive. One suggestion that always works is to ask your boss to teach you to do one of their tedious administrative tasks, something they find redundant and time consuming. Once you’ve learned it, then take it off of their plate. By saving them time, you’re now viewed as an asset and someone who is willing to go above and beyond their responsibilities. It also gives you good visibility into a leadership task.
  • Become really good at what you do, and start teaching it to your counterparts and peers. Mentoring others, without expecting anything in return, is yet another sign that you care about other people’s best interests, including the company’s.

They speak up for their work, but they don’t brag. — This one might sound confusing at first, but it’s really simple.

Your work, and your work alone will never speak for you. It will ONLY get you so far. You need to be the one that speaks up for your work, and not only that, you need to speak up for how much value it brings to the company.

If you can articulate how your work aligns and even furthers the company’s mission, it’ll speak volumes for your career advancement. By doing this effectively, you’ll always stay relevant in management’s eyes.

The best way to do this is to schedule a weekly or bi-weekly 1:1 with your manager to go over your progress and your accomplishments. Take this time to talk about how your work is helping the company, the team, and the bottom line.

Again nobody likes a bragger, so make sure you speak to your accomplishments with a sense of humility.

They’ve had excellent relationships with their higher ups. 95% of the time, the one and only gatekeeper you have to helping you move ahead in your company is your boss. Everything will live and die by them.

If you’re one of those people who do not like their bosses, my only advice is to learn some conflict resolution tactics fast, then apply them to your relationship. You have to get this person on your side, and then keep them there at all times.

Each week when you do a weekly analysis of your work, ask yourself: “What can I do to better my relationship with my boss? Have I done all that I can to help make their lives easier?”

Successful people have mentors, or coaches who do not work for their company. A mentor or a coach that works outside of your company can give you objective feedback on your short-comings and areas of improvements.

The right mentor or coach will already have been down the road that you’re on right now.

Mentors and coaches are not meant to validate your self-perceptions. They are there to be completely honest with you, and relay what they’ve observed about you in a constructive and actionable manner.

They are also there to help you to navigate through your career. They will give you clarity on where you are, help you to figure out where you want to go, and work with you to strategize how to get there.

The best part is, they are your safe-zone. Sometimes, no matter how close you are to a colleague, there are just certain things you should not feel comfortable telling them about yourself, or about work. You don’t have to worry about that with your coach.

They view every challenge as an opportunity. This one is about attitude. If you pay attention, you’ll notice that leaders and uber-successful people have an extremely positive outlook on life. No, I’m not talking about delusional-optimism.

They view bad days as good days and great days as good days too. If something didn’t go the way they anticipated, or if they hit a roadblock, they will take as an opportunity to learn from it, and make sure it doesn’t happen again.

They don’t waste time complaining. If anything, they give themselves a very short amount of time (usually a few minutes) to vent and complain, and then they are right back to work figuring out a solution to their problem.

They don’t view things as happening to them, rather they view things as happening for them. They don’t fail, they learn.

They also do not waste time gossiping. They are busy worrying about how they can better themselves for the sake of the company. They always think about what more can be done. They celebrate other’s successes.

They are life-long learners. Most importantly, they are humble, and they don’t walk around with a sense of entitlement.

This trait is equally as important as the rest, if not one of the most important. Attitude is everything. You can read more about it here, The 5 Attitudes of Career Success.


So there you have it. You’re little cheat sheet into the mindset you should have if you want to move ahead in your career.

Since becoming a manager and leader, I’ve had the privilege of access to information and vantage points I didn’t have as an individual contributor. I’ve seen the inner workings of performance review cycles and how promotions are decided. It’s also given me a broader view of people, their skills and behaviours in the workplace, and how those influence their likelihood for promotion. The aim of this post is to empower and inform frustrated individual contributors who want to progress to senior and leadership levels and are struggling to do so, and might not know why they’re stuck.

I recognise this is a sensitive topic for many people. Reward and recognition are among our most primal needs. Undeniably, there are multiple complex systemic and organisational factors that can hold someone back from promotion — gender and race discrimination, bias, etc. amongst many. The maturity, stage and industry of an organisation can also significantly affect the types of roles needed and available, which influences likelihood for promotion. The aim of this post isn’t to negate or downplay those factors, nor to blame individuals for not progressing.

This list is about the things that you can control. And while it’s true there might be things outside of your control, you also have a role to play. You may inadvertently be doing things which are holding you back and feeding your frustrations.

It’s easy to blame your manager or leadership when you don’t progress and you think you should be. You could argue that your manager should be telling you if you are doing any of the things listed here. Unfortunately, not every manager can or will. So rather than rely on others, these tips may help you take control of the situation and what’s ultimately your future.

Roles need to be available in the organisation

The points in this post mostly apply to mid-sized and large organisations where a leadership role is available. They may also be helpful for people in startups and scale-ups, although these often don’t have established review and promotion cycles. Equally, roles in young organisations can quickly change in scope which can bring a new layer of complexity as goalposts move and expectation shift beneath your feet.

The post also assumes that the organisation you’re in can promote individuals into leadership positions — for example if you’re moving towards the top end of an individual contributor track, or sideways into a management track. Sometimes those roles don’t exist or there isn’t budget, which is a different situation altogether. Also worth noting that the eight factors below reinforce and multiply each other. They often go hand-in-hand and compound one another.

1. Your behavior doesn’t match expectations for leadership

This is arguably the top factor I see holding people back in their progression. People who don’t take personal responsibility for the part they play in creating a better environment to work in. They frequently complain, criticise people and processes, and don’t do anything to improve things. Everything is a problem and it’s up to someone else to sort them out. They broadcast their concerns and freely find faults in existing efforts.

This behaviour often couples with defaulting to assuming negative intent and not taking feedback well — becoming defensive. I’ve often seen this in fixed rather than growth mindsets. It can destroy relationships, team dynamics and trust. This matters because the more senior you are, the more you become a role model for others, especially those junior to you. Leadership is about cultivating environments where people feel safe. Openly criticising the very people you’re wanting to become peers with doesn’t contribute to that.

You might not realise, but this behaviour doesn’t only eat into your productivity, it eats into others’ too. You might think others want to listen to your problems, but often they don’t. Especially if they’re of your own making or you have unreasonable expectations. It’s okay to have a moan every so often to a trusted source — sharing frustrations and listening to others can build relationships. But if you look back and find most of your conversations are negative, maybe something’s wrong.

This doesn’t mean you shouldn’t raise issues to your manager and leadership or talk to your peers about your concerns. It’s important to flag problems, but there are ways to do so with positivity. It’s one thing to communicate thoughtfully and take personal responsibility for what you can impact. Or to show empathy for how things got to where they are and a willingness to navigate the change. It’s another to dwell in negativity, bottle up frustrations and openly vent and blame or become petulant when things don’t go your way or as you expect. One is constructive and helpful, the other is self-indulgent and destructive.

This might be you if…

  • Your last conversations with your peers were largely you complaining or criticising. Could you be coming across as cynical and jaded?
  • You think leadership is a title and something you have to be given before you can or should behave like a leader.
  • You’re frustrated about problems and think it’s down to your leadership to fix them, not you. You’re failing to lead.
  • You don’t contribute unless prompted. You see problems you could fix and dismiss them as “not my job”.

What you can do about it:

  • Take personal responsibility for the part you play in improving things around you. Find a problem you feel passionate about, figure out what you can do about it, then speak to your manager about making it happen.
  • Learn to manage your frustrations and communicate constructively. Focus on the positives, not the negatives.
  • Practice empathy towards your leadership and be patient as your company navigates change. Instead of passing judgement, try to understand what’s happened and offer support — they’ll probably appreciate it.
  • Behave like a leader and be consistent with it: provide vision, listen to concerns and resolve doubts. Be present.

2. Your expectations of progression are off-track

I’ve seen a number of people believe they’re entitled to a promotion simply for doing the job that’s been agreed at their level. Or maybe they stepped it up in the 2–3 months before the performance review cycle, knowing it was coming up and wanting to be considered. It doesn’t work that way, unfortunately. Although progression depends on performance, just because you’ve smashed it at your level, that doesn’t mean you’re necessarily ready for the next level in terms of the responsibilities and expectations.

Most companies need you to show that you can consistently perform at the level above yours for a period of time before you’re considered for promotion — often a minimum of 6 months, sometimes up to a year. You can’t just hit the gas pedal for a few months to get promoted and go back to cruising speed. A step up in level isn’t just a bend in the road; it’s like changing gears altogether with everything that brings.

The more senior you become, the more you need to have done to show you’re capable. You can’t expect to get promoted at the same speed or frequency during your junior years as your senior and leadership years. The scope of the role is different. The scale of impact you need to create is bigger. That takes time.

It’s also generally not singularly down to your manager whether you’re promoted, especially the more senior you get and the larger the company. There can be an entire panel of people involved. Your manager needs to have enough evidence to support the decision. Understanding the process is important for you to help your manager make a case to represent you.

In these panels, existing leadership will be considering what the impact of you being promoted will have on the wider business. Putting someone in a role with a large sphere of influence can be a risky decision as there’s a bigger potential blast radius. Many managers play it safe because of this.

And, in some positions there may be legal, regulatory, or other requirements about the experience you must have demonstrated to hold a position — this is the case for certain roles in banking, for example.

If you don’t know what progression looks like, that’s a separate issue. That can happen if your organisation is young or low in maturity and career frameworks are still in the process of being defined. The best thing to do in that case is to help your manager and leadership figure it out — not only will it benefit you and others in the long-run by showing you’re taking proactive steps which will further support an application for promotion, but it’s better than the passive alternatives.

This might be you if…

  • You expect to be promoted every 6–12 months.
  • You expect to be promoted for showing one or two skills or behaviours from the level above yours on one or two occasions.
  • You think it’s only down to your manager whether you’re promoted.

What you can do about it:

  • Ask your manager about the typical timescales for progression at the different levels in your organisation.
  • Speak to peers in other companies and look for industry averages.
  • Consistently show the behaviors and competencies above your level, on multiple occasions.

3. You’re missing the bigger picture

You’ve lost sight of your role and purpose in the organisation — why you were hired in the first place. There’s a balance between wanting to do things that benefit you and your career, and sometimes the reality of what the organisation needs from you, or the opportunities that are available. No company will always be able to offer you exactly what you want all of the time.

And being in a leadership position means things aren’t about you any more. You become responsible for the health of the organisation — that means the revenue and the people. If there’s no revenue, there won’t be any people. If there are no people, revenue will most probably suffer. If you’re thinking of yourself first rather than the greater good, you risk damaging the future of the organisation.

Being a leader doesn’t mean you have to sacrifice yourself at all costs and ignore your needs — far from it. It does mean you have to be willing to put others before you if it makes sense for the company. And you must consider the consequences and implications of your behaviours and actions on those around you and at an organisational level at all times, rather than just yourself and your immediate team right now.

This might be you if…

  • You expect things to change around you and for you within the organisation, and get frustrated when they don’t.
  • You’re picky about what you work on and don’t care or want to do it unless it directly benefits you or is perfectly aligned with what you want to do.
  • You don’t see how your role or team impacts the company’s revenue, goals or mission.
  • You don’t particularly care what other teams are doing unless it directly affects you.

What you can do about it:

  • Understand the business model of your company and how your department or team contributes to the organisation’s revenue, goals or mission.
  • Be willing to work on projects that you don’t necessarily think are flashy. They’ll likely be the ones that will have the most impact and would catch the eye of a future employer, or you will learn a lot from.
  • Ask your manager what the most urgent or important initiatives are in the organisation. Identify whether you have the skills to help progress things and offer your help if so.

4. You haven’t had the conversation with your manager

This might come as a surprise, but your manager doesn’t spend half as much time thinking of you as you think about yourself. If your manager hasn’t initiated the conversation with you about a promotion, it might be because they don’t think you’re ready. Or they have a lot on their plate and they assume you’ll bring it up. You might be one of many people they manage, alongside other initiatives they’re juggling which you don’t have visibility of.

If you haven’t spoken to your manager about a promotion and they haven’t raised it either, it’s unlikely to come out of the blue. If you want it, don’t passively sit and wait for it to happen. That’s only going to frustrate you, especially if you expect it and think you deserve one. If you think you should be considered, go speak to them and with plenty of notice — at least 6 months, ideally longer. Let them know what timeframes you’re aiming towards. Make them want to agree with you.

Your manager should be on your side and invested in your growth. They’ll want the best for you, especially if they hired you. Don’t make them the enemy. Build up a case for them to make it easy for them to put you forward to their seniors and peers.

If you want to be a leader, you have to take the lead. That starts with taking personal responsibility for your career and growth, having uncomfortable conversations and putting in the work to make it happen. Your manager will want to see composed hunger and ambition. Not everyone can deal with more responsibility and they’ll need to see the signs that you can.

This might be you if…

  • You haven’t had a conversation with your manager about your performance, goals, career or progression in months.
  • You’re waiting for your manager to tell you that you’ve been promoted, because you think you deserve it. You’re frustrated that they’re not bringing it up.
  • You’re worried about seeming entitled, so are avoiding the topic with your manager.
  • You’ve tried to bring it up, but you’re not being clear in your communication (after all, communication is about what’s understood, not what’s said).

What you can do about it:

  • Start the a conversation with your manager about your career from the beginning of your relationship. The second next best time is now. Take ownership of your performance and progression by setting meaningful and useful goals that will allow you to grow in skills.
  • Keep track of your achievements, so you can look back at your own growth over time and make it easy for your manager to see it too.
  • If you believe you are due a promotion, book in time with your manager many months ahead of the evaluation cycle and bring a list of achievements that show you have been consistently performing at the level above yours for at least 6 months.
  • Be direct and explicit with how you speak with your manager. Adopt a radical candour approach.

5. You’re passive and wait to be told what to do

The more senior you become, the more you’re expected to take responsibility for your own development. If you’re going to eventually support other people as a leader, you need to be able to manage yourself first. You have to put your own oxygen mask on before helping others.

It’s like becoming a parent, you have to figure out your own way that works for you. You can ask others for advice, but no two individuals’ circumstances are exactly the same, and what works for one person doesn’t for another. The same applies to developing your career. There are no step-by-step instructions on becoming a CEO. No one is hand-held into a leadership position. Your manager isn’t being told what to do by theirs.

You have to figure out what your organisation needs and how you can add value. You have to ask the useful questions. You have to suggest paths forward and gain consensus or commitment to decisions in groups. Your manager can’t be in the room telling you what to say and do, or when. Your manager can help you understand your options, point you at resources, connect you to people or unblock a path for you, but ultimately it’s your life — you have to make your own choices and follow through with action.

It’s worth remembering that organisations aren’t fixed entities; they’re constantly changing and evolving depending on market forces and the people inside them. Opportunities are around every corner. It’s why it’s essential you deeply understand your role and skills in the wider ecosystem of the organisation, and how you can provide value. If you’re patient and focus on what you’re learning and what you can offer, you’re more likely to reach the outcome you want than by focusing on that alone.

This might be you if…

  • You want and expect your manager to give you a checklist to get you promoted. You think it’s largely their responsibility to make sure you grow and progress.
  • You don’t know what your own strengths and development areas are.
  • You don’t have a clear sense of what skills you want to develop.

What you can do about it:

  • Ask your peers and manager for honest feedback to understand your strengths and development areas. Treat the feedback as a gift and craft meaningful goals that align with the company needs.
  • Speak to people outside of your organisation with careers paths or competencies you admire, to understand the skills they built and the gap you need to bridge to get there.
  • Reflect on your path and where you want to get to (beyond the title), and what that means in terms of skills you might need to develop.

Illustration of two people next to each other.

6. You view relationship-building as “politics”

Hopefully this won’t be news, but people don’t want to work with people they don’t like or respect. If you consistently dislike everyone you work with, perhaps you should ask yourself why. It might be you’re not in the right environment or company. Or maybe you’re not looking at things with the right mindset.

Relationship-building doesn’t mean you should butter people up. It’s not about being manipulative or inauthentic. It’s about showing people the same respect you deserve yourself. It means listening and being helpful. It’s about not showing contempt towards people you disagree with or decisions you don’t approve of. It’s about not having to be right all the time, or having to show how much smarter you are than everyone else. There are ways to disagree respectfully. You can disagree and still commit.

It comes back to assuming positive intent and focusing on the greater good rather than your own personal gains. I’m not saying you need to be best friends with everyone you work with, but it helps a lot if you don’t create friction or drama unnecessarily. Your existing leadership are unlikely to want to give a larger platform to someone who spreads negativity and doubt.

This might be you if…

  • You dislike and/or think you’re smarter than everyone or most of the people you work with.
  • You openly make flippant comments and cynical remarks about people and the organisation.
  • You don’t see the point of building relationships with anyone at work.

What you can do about it:

  • Think about the wider implications of your behaviours on others, especially in meetings or at critical moments in a project.
  • Be a role model for leadership behaviours like reliability, consistency, collaboration, clear communication and kindness.
  • Build genuine, curious and positive relationships with your colleagues across levels of seniority. Put in regular time with them, even just for a coffee.

7. You’re not making your impact visible

This is less about your behaviours and more about your work. It might be that you’re doing all the right things, but your work isn’t visible. If that’s the case, find a way to make it visible to the right people and via the right channels — often that’s by talking about it outside your team or sharing content in company forums. This isn’t about bragging about your work; this is about explaining what you’re doing, why it matters and why others should care. It’s about showing your value and how you’re making a positive impact on the company goals, culture or mission.

The more senior you become, the fewer people there are in leadership positions above and lateral to you. You need to be able to very clearly articulate and show the value you bring and why you should be in a leadership position. That starts with putting yourself out there and making yourself visible.

Part of this ties into building strong relationships with your manager and other leaders in the organisation. Depending on your organisational structure, your manager or another leader can and should act as your sponsor. They can open doors to you and bring you into forums where your impact can be made more visible. That begins with you doing great work and role modelling leadership behaviours.

This might be you if…

  • You don’t have a relationship with anyone in a leadership position beyond your manager.
  • You have never presented in a company forum or shared your work widely.
  • No one in a senior leadership position has ever acknowledged your work.

What you can do about it:

  • Regularly present at the company meetings or town halls.
  • Share your work in an engaging and interesting manner in public channels. Ask your manager or another leader to amplify your reach.
  • Identify whether there are leadership forums where you could and should be presenting deeper dives into your work. Ask your manager or another leader to open those doors for you.

8. You don’t have the skills needed at that moment for that company

You might be lacking in a particular area and have a blindspot, or maybe you’re over-confident in your abilities — the Dunning-Kruger effect in action. This should be the first thing to check off the list. I’ve seen people who were convinced they deserved promotions held back by weaknesses in their craft because they underplayed its importance.

Your execution needs to be excellent as it sets the standards for others. Promotions can be held up as a blueprint for others. If you’re not yet a safe pair of hands in a certain area, that can lead others to pattern match. At the risk of repeating myself, leadership means things aren’t just about you anymore.

If you think this could be the case, be proactive and get feedback from your manager and peers to understand your performance at all the parts of your role against their expectations for the level above yours. Ask them to be honest and describe the impact of your shortcomings. Armed with the feedback, put together a plan to improve and show your manager what you’re going to do about it. If you don’t know what that looks like, this is where your manager can give you pointers. But it’s up to you to own that process, make a plan and follow-through.

If you don’t think you can improve the particular skill to the standard needed, it doesn’t help to get angry and upset. Ask about changing teams where the role or problem space might be different. A role in another team might not be available, but you can always try.

In large organisations, the same titled role can have a different shape in a new team. I’ve many times seen product designers and product managers struggle in one space and thrive in another, where the constraints and goals suited their skills better. Or perhaps the skills you’re great at might have a different title. I’ve previously seen user researchers wanting to spend their time coaching, when that aligns better with the role of an agile or delivery coach.

If you’ve tried working in a few different teams and you’re still not progressing, you might need to realise that the time and effort needed to get to the position you want in this particular company is going to be challenging. You might want to reconsider your ambitions and bide your time until there’s an organisational change that might benefit you, or consider going to another company where the shape of the person needed is different.

This might be you if…

  • You’ve been given feedback to improve in a core area of the role multiple times, but don’t think it’s as big a deal as your manager makes it out to be.
  • You think you should be getting promoted because all of the other things you’re doing are great, and a weakness in one core area shouldn’t hold you back (spoiler: it probably will, unless you find another role that matches those skills better).
  • You’ve worked in a handful of different teams and still aren’t making progress.

What you can do about it:

  • Ask your peers at different levels what the impact of your shortcomings are. Focus on the ones who give you useful constructive feedback, not the ones who placate you.
  • Ask to change teams where your skills might be a better fit.
  • Consider a change in role (title) where you can play to your strengths.

If you recognize some of these things, great.

It means you have room to grow. The first step in making progress is to identify your shortcomings and accept you have work to do. Contrary to popular belief, leaders are forged, not born. Some people might have baseline levels of skills or behaviours that mean they are more suited to leadership positions, but that doesn’t mean they can’t be learnt by everyone.

In summary: take personal responsibility for your development, build healthy relationships, adopt a growth mindset, think of the wider organisation and business, communicate constructively, and be patient. You’ll get there.

Posted by: lrrp | April 21, 2021

6 Reasons You Should Always Be Looking at New Jobs

Even if you’re 100% happy in your current position

Change is a constant.

Not just in your career, but in every area of life.

Hold loosely to where you are, and allow yourself to learn, grow, and seize opportunities, even if you don’t know exactly where they’ll lead.

At 33, I can wholeheartedly say that taking the time to look at new opportunities is something I’m so thankful for and would highly recommend.

Whether it’s making a new connection on LinkedIn or going on an interview, often our most worthwhile experiences come from tiny actions that might not even look like big opportunities at the time.

Regardless of where you currently are, here are 6 reasons you should always be looking at new jobs.

Things can always change in the blink of an eye

You’re probably familiar with the Heraclitus quote that says, “The only constant in life is change.”

This quote still reigns true today.

Even if you like your job, things are always changing and often at a rapid pace.

A new manager could come in, layoffs might be around the corner, or maybe your company has a merger or acquisition. I share this because I have experienced unexpected job changes multiple times. In each job that I left, 3 or 6 months before leaving, I never would have anticipated that I would leave. However, I left because the work situation had changed drastically.

The key is not to be panicked or always worrying about what could happen in the future.

Instead, appreciate what you have today while still keeping yourself aware of other opportunities around you.

Knowing you have options gives you the confidence to do your job well, without fear of the unknown

Whether you are a freelancer or an employee, you always want to have options available to you.

I know from personal experience that I often do my best work when I feel like I have plenty of available opportunities.

When I mentioned previously that I left previous positions rather quickly, the main reason that this was possible for me was because I had other sources of income and had already been exploring other options.

While I certainly didn’t have a 5-year plan in place, I at least knew the direction in which I wanted to go.

On the other hand, if you’re constantly anxious about getting laid off and wondering whether you’ll ever find another job, your daily life will be much more strenuous.

In Psychology Today, Susan Weinschenk Ph.D. writes on the power of having choices and shares,

“We like having choices because it makes us feel in control. We won’t always choose the fastest way to get something done. We want to feel that we are powerful and that we have choices.”

Practically speaking, having choices might look like:

  • Having one informational interview a week to learn about jobs/careers that you’re interested in.
  • Sharing your expertise on a blog or Medium once a week to make connections and become known as an industry expert.
  • Taking 30 minutes a week or month to look at new jobs on LinkedIn or Indeed.
  • Keeping a “work” journal like career expert Lauren McGoodwin recommends to track your career, what you like, don’t like, and what you’re learning.

You can gain a better understanding of changes in your industry, market, pay, etc.

Even if you’re happy or content, there are always opportunities to learn something new.

Browsing through potential job descriptions or even going on a few interviews can be a good source of personal and professional growth.

A few years ago, I was ready to quit my job. Fortunately, before I quit, I applied for a few jobs and went on a handful of interviews.

I quickly learned that very few roles would offer both the flexibility and autonomy that I was accustomed to as a freelancer.

Going on interviews allowed me to appreciate my work so much more. Instead of quitting, I found that I could make a few tweaks and adjustments to make my current work better fit what I was looking for.

As you interview or research other companies, you might ask questions like:

  • Are other companies in your industry allowing people to continue working remotely permanently?
  • Is the pay lower, similar, or higher than comparable positions in your industry?
  • Could I apply some of the benefits of other companies to my own role or position?

Finally, the more you learn about other companies, the more you may even be reminded of how happy you are where you currently are while still knowing that you have options.

You will meet people outside your current circle of friends and colleagues

If you know people that always seem to be getting offers to interview or even outright job offers with little effort, it’s often not luck; it’s preparation.

“Opportunity does not waste time with those who are unprepared.”

―Idowu Koyenikan

The more people you know, even acquaintances, the more opportunities you will have in life.

Connect with people on LinkedIn.

Find people in your field and see if they’ll do a 10-minute informational interview about their work or company.

A few tips:

  • When connecting with someone, be sincere and show that you’re genuinely interested in them. You might reference an article they’ve written, a previous job they held, etc.
  • Have a strategy. Instead of adding people haphazardly, look for companies, industries, or positions that you’re interested in, and connect with people specifically in those places or roles.
  • Create a tracking system. If you’re connecting with lots of people, use a Google Sheet and write down the person’s name, their role, etc., and the date. This way, you won’t lose track of all the wonderful people you’re connecting with.

You can find opportunities for side hustles or consult

Having a second or third stream of income can be incredibly liberating, even if it’s only an extra $100 a month.

A side hustle might be a way to explore similar work or even something completely different from what you’re doing now.

According to Fortune, 49% of Americans under the age of 35 now have a side hustle.

Having a side hustle will allow you to:

  • Generate a second (or third) income stream
  • Increase or diversify your skills
  • Boost your confidence
  • Explore areas that you might not want to do full-time

For example, for the past few years, freelance writing has been one of my side hustles. I’ve found that I enjoy writing on Medium and having 1–2 additional clients per month. But, I wouldn’t want to do this full-time.

As you try out new side hustles, you can test the waters with new opportunities. Even if you love your job, a side hustle is still a great way to try something new and diversify your income.

You’ll solidify what you currently love about your current work, and where there might be room for improvement

Over the years, I’ve applied for various jobs, mostly part-time roles that would accommodate my freelance work.

The thing is, although a lot of positions looked great on paper and in theory, once I applied and went through at least one interview, I often found that I was happier exactly where I was.

Whether it was a pay cut, a lack of flexibility, or just not an ideal fit with my current skills, I often left the interview more grateful for where I currently was.

On the other hand, exploring other jobs or opportunities has also been a great way to see ways that I could improve myself.

Looking at other opportunities can be a good source of both personal and professional growth.

Take the time to see what you don’t know that you don’t know. We all have room for improvement, and the more you’re willing to give yourself feedback and learn from each experience, the more prepared you’ll be regardless of what life throws at you.

Older Posts »