If you're a senior or staff engineer, or aspiring to be one, you're probably looking to maximize the impact you have. Beyond solving hard technical problems, a very effective way to do that is through mentoring. I've found that a lot of engineers either avoid it or just don't leverage their full potential, so here’s a short guide to help you get there.

The best software teams rely on their senior and staff engineers not only to steer technical direction but also to help their peers become stronger engineers. This second goal can be challenging, we are trained to reason about predictable systems at scale, but working systematically with people is a different skill set. Some might assume that growth and development are solely the responsibility of engineering managers. However, the most impactful mentors are often individual contributors who shape how their colleagues think (mindset) and how they work (behavior).

Growth impact has many facets, but this article focuses on two:

• Depth: How long the effect of your guidance lasts. This ranges from providing immediate, short-term help to creating deep, long-lasting change in an engineer's skills and mindset.

• Reach: The breadth of your impact. This moves from one-on-one interactions to affecting an entire team or even department.

Senior and staff ICs already review code, pair-debug, and answer domain questions. Those actions raise quality now but often evaporate by the next quarter. Impact Levels turns each mentoring touch-point into durable leverage, guiding design rigor, ownership habits, and culture well beyond the immediate task.

The Depth Axis: Creating Lasting Impact

Moving from L0 to L3 trades shallow, short-lived help for deep, long-lasting change.

While deepening impact, broadcast the lesson. Write a short guide, demo in team sync, or embed the pattern in a shared template.

Depth delivers value; extending that impact to more engineers multiplies it.

The Influence Axis: Scaling Your Impact

Progress here means moving from 1-to-1 guidance to 1-to-many amplification.

The two axes together form the grid below.

The Ripple Grid

Read the grid like a map: Move up ↑ for deeper impact; Move right → for wider impact

• Shallow + Narrow: A quick fix for one person; the impact fades fast.

• Shallow + Broad: A useful tip shared in a team channel; it's helpful but easily forgotten.

• Deep + Narrow: Transformative coaching/mentoring for a single engineer; the impact is significant but limited in reach.

• Deep + Broad: Mindset shifts that spread across teams; this is the ideal outcome and where you can have the most significant impact.

When planning for impact, ask:

1. How deep and long this impact will last?

2. How broadly can the result spread?

Even one step deeper or wider compounds the value of time already invested, turning today’s actions into next year’s culture

I took some time to try and break down some potential areas of disruption in management due to AI and highlight the caveats.

Know your people

In a previous article, "No Shortcuts: Know Your People," I discussed the fundamental aspect of management, which involves a deep understanding of the people you work with. As AI evolves, team members will do more, this means also a lot more information that their manager needs to process and analyze to ensure good growth and performance.

LLMs can help managers to analyze their team members’ activity, spot repeating patterns, and even monitor progression. This seems like a stretch but a mini-version of this already exists. Products like Multitudes allow you to connect multiple sources such as GitHub, Jira, Slack, and more, than surface insights and static patterns per person (PRs, Cycle-time).

With LLMs, we can extend these capabilities and move beyond static metrics. Go into the textual content itself and not the metadata, look into the meaning.

Imagine receiving a comprehensive report on your team member's coding style, the number and quality of design patterns they used last week or an evaluation of the quality of inter-team communication, in terms of tone and directness. With this report, managers can see a better picture of potential improvements areas and follow-up quickly.

Caveats

1. People are complex creatures. While you might get a fantastic view of their visible work there is always a lot below the surface. Managers might start to overlook deep understanding and resort to basing their feedback system on the LLM reports.

2. Delivering the feedback is still the most delicate part. You can have all the right information but fail miserably to make a real behavior change. Even if this info will be available to the employee themself (and it should), most of us are not able to easily make the leap from knowing what are the issues to making the improvements.

The right person, on the right task, at the right time

A big part of the engineering manager's job is the art of assigning work. Done right, this can be a great tool for driving and reinforcing growth. There’s a limit to how much conversation can impact behavioral changes, there are things that need to be learned by doing. If it’s learning a new technical skill, leading a project, or improving communication.

Now, imagine you could fine-tune an LLM model to assign work based on weekly reports and a description of a growth plan.

Inputs fed into the model:

1. Shy’s and Maya’s weekly report

2. Focus on improving Shy’s distribute systems skills, project leadership and direct communication.

3. Focus on improving Maya’s team work and DB indexing, give her a complex project which will let her unleash her technical skills.

4. GitHub’, Jira’s or Linear’s issues, bugs and tasks

Outputs:

1. Shy should work on project A.

2. Assign Shy to work together with Maya.

That’s pretty awesome, isn’t it? Managers can ensure every team member gets the growth path tailor-made for their needs and reinforce it with real production work.

Caveats

1. What about personal details? Life can’t be summarized into a few lines of the prompt. Our professional life is just a small portion of who we are and an LLM model might make wrong assumptions about who can work with whom or even prioritize some people over others.

2. Managers will need to verify the plans and the assignment. People are not machines and might resist even projects which on paper are perfect for their growth.

Performance reviews

I almost forgot performance reviews. These might become completely automated.

In the good scenario that might be a summary of all your weekly (or bi-weekly) 1:1s. Where you share feedback and follow up on personal progress. In the bad scenario, it will be an automated summary of the raw activity events as PRs, Commits, Messages, and Zoom transcripts. It will become easier to spot trends and behavior changes as improvements in code and communication quality.

Performance reviews might become just a ceremony instead of a true analysis (which many managers aren’t doing at all).

Caveats

1. The quality of the review can be as good as the events coming in. If the manager won’t follow continuous feedback and record every interaction they have, the end results might be inaccurate.

2. As with everything, once things become automated people will start finding ways to trick the system. It is possible for managers to create the wrong incentives if they blindly trust the curated performance conclusions. This is similar to how people can game the system in other areas, for example, Google ranking algorithms.

Looking forward

A more individualistic approach will emerge since people will be able to get good support from tools like copilot or GPT. This means that the manager's role may shift into filling the lack of community and a human touch.

The ability to engage and fulfill your employees is already an important part of a manager's responsibilities, but the individualistic approach will give these factors even greater significance. Managers must work hard to maintain healthy relationships and strong connections between team members.

Data quality and supervision of the inputs will become critical. AI models are well-known for biased results and the company that created the model may change it in the future. Managers will need to ensure that the data used to train the models is representative of the real-world.

A Reminder

Knowing your people means that you know your people, not the LLM model.

For some things, there are no shortcuts.

As a manager in the tech industry, you may feel pressured to implement frameworks and follow best practices to improve team performance. While these tools can be helpful, there is one key factor that can make a substantial impact on your team's success: knowing your people well. In this article, we'll explore why taking the time to understand your team members is more significant than any other task a manager can do.

The Framework Manager

The rapid growth of the tech industry in recent years has led many companies to hire massive amounts of employees, resulting in a high demand for managers. Most companies require that managers be technical and experienced engineers. This naturally means these new managers must originate from engineers without managerial experience or education.

I believe that this was a significant advantage. People were not bound to old-style management methods, tried new things, and experimented a lot. That wasn't always pretty, but it helped the industry take another direction.

Now, a few years later, our industry is a little bit more mature, and more patterns are emerging. Engineers love patterns, so we began to create (or mostly copy) frameworks that we can implement and yield the outcomes we need.

• Want to grow your team's personal growth? Use a "Career Ladders" framework.

• Want to improve performance? Use a quarterly OKR framework.

Using frameworks is great and very advisable! The challenge starts when managers skip "the fundamentals."

The Fundamentals

Frameworks are just a tool to reach an outcome; they help us ensure reasonable consistency between teams, departments, and direct reports. Many managers begin to see the framework itself as the goal.

"I do 1:1 every week"

That’s great, but are these 1:1s helps your reports to grow? Do you feel you are learning new things every session? 1:1s are just a tool to ensure that managers are meeting their reports. They are not the goal.

Know your people before anything else.

When I change responsibility with a manager, I do several handoff sessions: the first for ongoing projects and maintenance, the second for domain expertise, and the third for their people. I expect that the manager is well acquainted with each of their reports, what they like and dislike, their strengths and weaknesses, with whom they work best and with whom they have issues, and on which points I should be easy and on which ones strict.

You'll be surprised how often I found out that managers had no clue about their team members. They knew some details, but most were superficial. They had never dug deep.

Management is Personal

So why do so many managers keep things superficial? There are multiple reasons for that, but I suspect that most managers in the tech industry are a bit afraid to make things personal. They prefer to keep things simple and stay behind a safety net to avoid awkward moments and difficult situations.

Remember, this doesn’t mean you need to like your reports. If you set the right expectations, the manager-report relationship can remain professional.

My most successful managers knew their team members so well on a personal level that they could motivate them to reach their full potential while maintaining a healthy work-life balance. The teams operated smoothly because each member was tasked with tasks based on their strengths (or weaknesses).

The manager's ability to ask difficult questions and follow up every week (or two) made this performance possible.

No Shortcuts

Some things were not meant to be easy. People are complicated, and therefore managing people is complex. Don't take shortcuts, and learn your people. It may be the most essential foundation for any framework you build on top of it.

Any organization but mostly for:

1. Engineering-focused organization.

2. Total of 1-20 engineers.

3. Async.

This could still be relevant if your organization has more than 20+ engineers but will require a proper structure and low level of dependencies.

The Era of Mighty Tools

The average seed to Series A startup uses more tools than the number of team members. Every tool has a unique offering and can do some things better. I’m not a huge fan of all-in-one solutions, but a team must find the balance that will help them regain control of their operations.

The ever-going search for the perfect tool will never end. Focus on the tools that make you feel good and help the team be lighter.

Harder, Better, Faster, Stronger

With every new feature you introduce to your operational stack, you create a more complex interface for your team. The simpler and cleaner interface to more clarity and efficiency for your team members will get. We often think that a full-featured product will increase productivity, but our organization usually needs less than more.

Ask yourself the following questions:

How many buttons do your engineers need to click before they can start writing a system design, writing code, or getting an answer to a blocking question?

Here is a common scenario for a small startup:

Pretty crazy, and here we are talking about a small company of no more than 10 people. Each platform has rich features and abstractions; labels, types, templates, automatons, fields, inline comments, and more.

This happens because each team member wants to use a system that’s comfortable for them. Docs should be written in a system that allows rich content and easy to use editor. Projects should be handled with a system that allows a complex dependency system and a beautiful interface to visualize the work. Code review should be managed in a system that allows one to see the changes and make proposals.

All these are unnecessary features that make you feel good but slow down the actual value the team can bring. Your team is so busy with the work of work.

Minimalism bliss

Your goal is to bring business outcomes while keeping your team happy. Operational clutter is a big issue for both. Let’s look at an alternative operational solution.

1. Team’s Plans — GitHub issues.

2. Projects definition — GitHub issues.

3. Project’s Plan — In the Project’s GitHub issue.

4. Tech design — In the Project’s GitHub issue.

5. Code — GitHub PRs.

6. RFCs — GitHub issues.

7. Decisions — GitHub issues.

*You can replace GitHub with any other tool (GitLab, Bitbucket, etc.)

You probably think this can’t scale, or maybe you think that using “just” simple markdown and lacking inline comments will slow you down. I believe that’s not true. The enforced minimalism will keep the team more focused on the actual work instead on the meta-work of managing comments and millions of channels.

The truth is that having a simple text-based list of things you need to get done today (or this week) makes it visible to know how things are going. If you need more than that, you probably lack clarity on your goals or what needs to get done.

If you have more time, spend it reducing content and not flooding your team with many processes and documents to fill up. Don’t overload abstraction; keep the team very close to their code.

Scaling with Minimalism: Addressing Concerns

I found that the greater the need for complex tools and interfaces, the stronger the signal for either.

1. Your organizational structure is not effective, which causes too much friction between teams. I suggest looking at Team Topologies.

2. Your software has too many dependencies, so you need to decouple your modules (or services).

Introducing “stronger” operational tools will act as a bandage and increase operational clutter so things move incredibly slowly.

Looking forward

1. Streamlining the toolset: Focus on using a single platform, such as GitHub or GitLab, to manage different aspects of software development, like project planning, tech design, code review, and decision-making.

2. Simplifying processes: Reduce the reliance on inline comments, custom attributes, and complex workflows. Encourage clear and concise communication.

3. Minimizing operational overhead: Limit the number of clicks and tool implementations required to complete tasks, making it easier for team members to get things done.

4. Scaling effectively: Upgrade or merge tools only when they simplify workflows and reduce complexity.

Last week I reread John Cutler's excellent article, "What Are Vanity Metrics and How to Stop Using Them", where he reflects on product vanity metrics and how to replace them with better KPIs. After reading it, I couldn’t help but think about the recent blooming of engineering measures. 

"Vanity metrics are metrics that make us feel good, but don’t help us do better work or make better decisions. No one is immune to using vanity metrics! The key is ensuring you provide context, state the intent of the metrics you use, and clarify the actions and decisions that the metric (or metrics) will drive. — John Cutler, What Are Vanity Metrics and How to Stop Using Them

It is quite simple to set up a team dashboard with KPIs today. There are a lot of intuitive tools and solutions for gathering and processing your team's signals (i.e., DX, Athenian, Waydev). Consequently, engineering metrics gained popularity, and more teams and leaders are involved in the discussion. People started arguing whether DORA metrics are useful or useless and whether outputs or outcomes were the best way to measure your team.

I am glad to hear about the friction in our industry and how it forces our industry to measure and continue improving. However, I think some people miss a fundamental point. Metrics for your team shouldn't be viewed as goals; rather, they should be viewed as health measures that help identify issues.

System of people, not machines

Almost all engineering leaders come from engineering backgrounds where they have built and maintained systems of machines (i.e., servers, modules, functions). These systems are constantly measured and validated for performance, stability, security, and many other metrics. It's a winning system that allows teams to improve customer satisfaction while reducing operational costs. 

Assume that customers start to complain about your product performance. You decide to improve them, and to achieve this, you set a requirement for all page loads to be performed within 300ms. Once you find out which queries are problematic, you can start figuring out why they are problematic. There is a solution out there, and it is only a matter of time.

It would be ideal if our dashboard looked as elegant as the one on our car. You can easily check your oil level and refill it if it's low, and if the tank fills up and gets empty, there is a rational explanation behind the problem that we can diagnose and solve.

So the thing is that.. humans are not processing units that you can debug. We are not pure input-output machines and are full of side effects. That's why we are capable of making beautiful and unexpected things that are also impossible to reason about. Therefore the way we reason and, more importantly, the way we act must be different.

Ultimately, engineering metrics can't tell your team the whole picture. They just provide a glimpse of what is actually going on. The good news is that they are still incredibly useful. By becoming more "data-informed" rather than "data-driven," you can use them to create experiments and define hypotheses instead. Focus on behaviors rather than shallow numbers.

Incentives shape behavior

It is also common for managers to set goals based on metrics' values, such as, "In Q4, we aim to reduce our lead time by 30%". Don't get me wrong, the reasoning behind it is solid. A smaller idea-to-production loop will enable the team to learn faster. However, do you believe reducing lead time by 30% will result in more learning? You're just trying to set a proxy metric because there is no feasible way to measure your learning rate. Reaching four hours lead time means you reached four hours lead time. You are likely to reach this goal if the team is motivated by this, but probably by doing things unrelated to learning. While the team might be shipping faster, they might not look back and learn.

“When a measure becomes a target, it ceases to be a good measure.” — Goodhart’s Law.

Imagine we want our city to be safer, so we set a target for our police department's case closure rate. This might result in the opposite. The department might choose to focus on easy-to-solve cases and avoid difficult ones that would significantly impact our community.

Lead time is a measure that can be used to assess the health of the team. Establish patterns for your team and start tracking anomalies. Has the lead time increased from 4 to 30 hours? Investigate, write your assumptions, and build hypotheses. Then validate them with qualitative research and keep measuring the impact of your changes.

Accept that your data is incomplete.

Although GitHub, Linear, or Jira can provide quite a lot of information about your team, these metrics are only a shadow of what actually happens. The rule of big numbers can help in large teams (100 or more engineers), but it is also more vulnerable to inconsistencies between departments and teams. Accepting this truth will help you to ensure you are leveraging the full potential of your tools and analytics. 

• Has the number of bugs increased? The problem could be caused by a buggy feature or by a new manager with a higher quality standard.

• Has the lead time decreased? There could be several reasons for this: either your team is shipping smaller chunks, or maybe they started designing their plans on a new tool that isn't being tracked.

Measurement systems should allow you to reduce your search parameters and focus on a smaller interface. Health metrics can indicate where you should start looking and will help you validate the effects of your decisions.

But elite performers’ teams reach XYZ

True but lacking context. Logic states that A⇒B doesn't imply B⇒A. In other words, many outstanding teams indeed share similar metrics and patterns, but that doesn't mean that if your team reaches these results, it will make them outstanding.

Even if an article suggests presenting a team that merges 10 PRs a week is the new rule, take a moment before setting a new standard. Study the ins and outs of that difference and why your team is doing things differently. It might turn out that having 10 PRs a week comes with a weak code review process and a lot of follow-up work. Are you willing to make this tradeoff?

Instead of focusing on metrics, identify your team's strengths and weaknesses by talking to members and stakeholders (product, design, and customers). Develop theories by being curious and inspired. Don't adopt any system before testing if it fits your specific context.

Summary

The availability of data gives us managers a lot of new opportunities. If we know how to avoid our desire to rely on qualitative data and mix some qualitative approaches, we can unlock impressive growth for our team. Make sure you don't skimp on assumptions and hypotheses. Research and experiment properly.

Recommended follow-up readings:

• Are You Data-driven, Data-informed or Data-inspired?

• What Are Vanity Metrics and How to Stop Using Them

• Episode 8: "Big Manager is Watching"

Did you ever wonder why tech companies love giving you t-shirts with their logo on them? Why are people willing to work insane hours while getting paid globally?

In addition to personal and professional reasons, one is based on the survival instinct of our ancestors. In his book Sapiens, Yuval Noah Harari claims that humans managed to reach the top of the food chain by embracing collaboration with strangers. Sounds familiar?

A company is essentially a group of strangers cooperating to gain market share. The most successful companies were the ones that had built a strong collaborative culture and were very successful at defining their own unique culture. However, there are so many companies out there. How can someone stay when there are so many options?

"Ants and bees can also work together in huge numbers, but they do so in a very rigid manner and only with close relatives. Wolves and chimpanzees cooperate far more flexibly than ants, but they can do so only with small numbers of other individuals that they know intimately. Sapiens can cooperate in extremely flexible ways with countless numbers of strangers. That's why Sapiens rule the world, whereas ants eat our leftovers and chimps are locked up in zoos and research laboratories." – Yuval Noah Harari, Sapiens.

Tribalism is a concept in anthropology that refers to a cultural phenomenon through which individuals create groups or organizations of a social nature. These groups or organizations enable individuals to identify and reaffirm themselves as part of something larger.

Leaders must acknowledge this tendency and its immense impact on the humans who work in their company. Tribalism exerts a two-way influence. People seek to leave a trace of their passage through the organization, and, in turn, the organization itself exerts influence on the person.

Loyalty: If this feelin' flows both ways?

In the current downturn, while tech companies keep cutting their staff, loyalty starts getting a negative connotation. There is a shame in this because loyalty can be rewarding if both sides are treated with respect.

In light of our tribal nature, I believe most of us are searching for a loyal relationship that will provide us safety (in different shapes and colors). I also believe companies can be an excellent place for that. How can you tell if this feelin' flows both ways? In the recent downturn, many found themselves asking this question after they received an email thanking them for their time and wishing them good luck with what's next (they got fired).

Managers must realize that when they ask for high loyalty, they must provide something in return. In some cases, it can be simple loyalty in return, but savvy managers know this is impossible when working in a fast-paced environment. The company needs to ensure its survival which means loyalty can't be achieved at all costs. Nevertheless, you can give something else in return. It could be personal growth, respect, or excellent compensation. The main point is that loyalty doesn't come for free, and as a manager, don't rely on the ability to give it back.

Once loyalty is established, you have a moral obligation to avoid exploiting it. In many cases, people are reluctant to dissolve even toxic relationships that could be potentially destructive due to their fear of breaking social bonds. Managers often use that to keep an employee while they know it is bad for them or push them for 200% before a deadline while they know it's bullshit. Remember that loyalty takes time to build but once removed, it is nearly impossible to regain.

Self-confidence: I've just been fakin' it (fakin' it)

"Chess and me, it's hard to take them apart. It's like my alter ego". – Bobby Fischer

Working in tech can be very stressful. A very result-driven culture can leave people in a continuous state of Imposter syndrome. "Feelings of self-doubt and personal incompetence that persist despite your education, experience, and accomplishments." While managers can't control the outside environment, they can create a shared identity that can promote self-confidence.

Employees can leverage their colleagues' confidence and commitment with a second identity: "I'm proud to be part of this team; we make a difference together". Creating a small tribe and a "team identity" can make people feel part of something bigger than them. 

Refer to your team as "We"; we decided, we need, we will. Whenever possible, discuss things in the team's channel. For example, when you need to allocate a new task for a team member, message them in the team's channel. In addition, develop a team language, your way of speaking, and what you talk about.

"Change the language in the tribe, and you have changed the tribe itself." ― Dave Logan, Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization.

It is essential to balance that tribal mentality so as not to fall prey to the Us vs. Them mentality; as a result of Tribalism, you cannot altogether avoid this. Therefore, ensure that your team has strong and stable connections with the "outside world". Another critical warning is that the company identity should never come before the individual identity. This can end up in a homogeneous culture which does not accept diversity. Rather than replacing, augment.

Safe zone: If you fall, I will catch you, I'll be waiting

A team member once told me, "I feel like I'm supposed to be under pressure, but for some reason, I just don't ". Their sense of belonging made them feel like this was a team responsibility rather than a personal one. People without a tribe may experience intense pressure since they do not have anyone to support them. Studies even suggest that organizational belongingness could mediate stress and post-trauma among firefighters1, which have many similarities with burnout.

One way to measure the "quality" of a safe zone is by looking at how much the team shares its vulnerabilities. It's a good sign if people share their failures and mistakes openly. But it's a red flag if every meeting is cheerful and no one talks about negative topics.

Managers can help their team to develop that skill by providing relevant and authentic examples. Talking about uncomfortable topics and surfacing issues that are usually "backchanneled" will show the team that it's ok to share.

Takeaways: Dos and don'ts.

• Do: Recognize the importance of loyalty and compensate accordingly

• Don't: Try to give the illusion of loyalty if you can't really do it (outside your control).

• Do: Offer a second identity in the form of a team identity

• Don't: Lose sight of the individual's identity in the name of the team

• Do: Keep an eye on your team's "Us vs. Them" levels to make sure it isn't reaching toxic levels

• Don't: Rely on one-to-one relationships or put pressure on individuals

• Do: Apply the Cone model to distribute team pressure and support

Reference songs:

If this feelin' flows both ways? — Arctic Monkeys - Do I Wanna Know?

I've just been fakin' it (fakin' it) — Simon & Garfunkel - Fakin' It

If you fall, I will catch you, I'll be waiting — Cyndi Lauper - Time After Time

But how do you know when to say no? What signals that it’s time to stop?

Here is an oversimplified framework that is easy to remember and use for requests, feedback, bugs, and tasks. 

The five-point framework

Product — What are the pain points or opportunities we are addressing? Do I know who will benefit from these changes and how?

Impact — Will the efforts make a difference to the company? Will this be the most valuable thing we can do right now?

Coding — Is it more challenging than it seems? How many “workaround” will I have to make?

Quality — Will the final results compromise any existing functionality? Does the final result meet our standards?

Results — Given the requirements, will the project be completed on time?

The list can be expanded based on your needs, but I strongly urge keeping it short and straightforward.

How to use it

1. Ask yourself these questions, and if you cannot answer one of them or do not feel confident about your answer, then say no until it is resolved.

2. You can also say stop in the middle of a task.

When a company reaches 50+ people (or sooner), things start to get complex. Departments are starting to form, and each one has different KPIs, targets, and incentives. What was just product engineering became Sales, Marking, Community, and Support. You begin hearing executives talking about budget and the “corporate strategy”. At this point, many tech startups feel a bit uncomfortable. They are used to a bottom-up approach where things happen naturally, and direction can be decided quickly.

The good news are, you do not have to lose your bottom-up approach. Balance it with a few (very few) solid and clear top-down strategies.

When you have to shoot, shoot. Don't talk.

"Plan and prepare for every possibility, and you will never act. It is nobler to have courage as we stumble into half the things we fear than to analyze every possible obstacle and begin nothing. Great things are achieved by embracing great dangers."

— Xerexes (maybe)

There is a tendency for leaders to be obsessed with strategies, but the simple truth is that many things don’t need any strategy. The team will work for a few weeks just to develop the exact same actions they knew they needed to do. 

Save your strategy work for the really complex work that needs research and coordination with other departments.

But how can you decide what "first things" to do?

1. The business impact is evident and significant. (10% more subscriptions, close 3 large clients, reduce support pressure by 30%)

2. The engineering impact is evident and significant. (Increase productivity by 10%, Reduce bugs by 25%)

3. Red flag for engineering or product standards. (Developers can’t deploy quickly, Users don’t understand how to use the product)

4. Everyone in the company knows about it and wants to do it. (The way we do X sucks)

Make the Top-down worth it.

Now that you addressed your "first things” (I urge you to do them before any strategic work), it’s time to think of your engineering strategy. You are not alone, and you must acknowledge this. As engineering has a massive impact on the success of your startup, your decision will impact every other department. If you only focus on scalability, you might ignore that new feature sales desperately need to reach their targets.

One team, one goal

Prioritize your company's few strategies holistically. Seat down with your leadership team and ask them, “What are your goals, and how are you planning to get there?”. Pick one of the many fantastic techniques to achieve this (OKRs or Opportunity-Solution Trees) and be sure to know what your fellow department is aiming for.

Use a collaborative method rather than a validation mechanism - Rather than working in silos and submitting your strategy for approval at the end, have collaborative sessions to discuss things together and create short loop feedback even when you are not sure.

Before, after, or in the middle? 

Once streams are moving, aligning them is much more challenging, but by adjusting their initial azimuth you can avoid a lot of friction. As is true of everything in nature, every friction caused by a direction change will deplete your team's energy. Startups require efficiency at every turn.

Your meeting with the leadership will help you determine the azimuth that is most appropriate, to begin with. Of course, you will need to keep monitoring the location of your department and make adjustments.

Commit to Focus

Usually, at this stage, the department will have 5-6 strategies in place that attempt to address all the critical issues. Sounds reasonable, doesn't it? No, that's just too much top-down direction. Choosing 1-2 is the most effective way to make top-down worthwhile. Push the rest.

Win 1-2 strategies, and then move on. It is easy to preach focus, but only by focusing your team's attention on the right strategy will you truly make a difference. 

To achieve bottom-up, one must work

Top-down can only bring you to a certain point, but bottom-up separates the most successful organizations where individuals lead innovation and hold up the product standards.

This post isn't going to focus on how to empower the team (maybe in a separate post), but I will mention some things that are often considered a strategy but are actually bottom-up.

Direction and vision

People link vision/direction documents with strategies, and it’s not wrong. The vision is critical for starting the discussion, but ultimately they are incredibly impactful for individuals in their day-to-day work.

Your strategies are focused on bringing you a specific outcome, but meanwhile, the team must keep working on the day-to-day. A well-defined direction will help engineers raise those red flags and identify high-impact work that wasn’t part of the strategy. Someone might bring to the table a fantastic opportunity they found out about.

In order to assist your team in identifying an opportunity, including both good and bad signals in your vision, for example:

Direction:
System usability improvements — we will raise the bar for system usability and level of quality.

Signals:
- Bad: We must write articles on how to use the system.
- Good: Features are adopted quickly.
- Bad: We often get “false bugs” because of misunderstandings.

If there is no law, you can't break it.

Another piece that can drive your engineers is standards. Setting the expectation for quality, success, velocity, values, and basically, anything you care about, your team can spot gaps and surface opportunities or pain points. The key to creating this culture is actually to do something when things come up. If your answer is always “not a priority,” at some point, people will stop coming to you.

Here are a few things you can do if you liked the article:

1) Share — Spread the word about this article to someone who may find it helpful.

Share

2) Comment — Feel free to share your thoughts, questions, or simply your take on things!

Leave a comment

3) Subscribe — If you haven't done so yet!

Subscribe now

EM = Engineering manager
EMs = Engineering managers

Whenever they are given the opportunity, engineering managers emphasize the importance of growth and the importance of teamwork. Yet, they often forget about their development and turn their backs on the techniques they use on their teams.

The fact is that when EMs work as a team, they can get the benefits of a team. Sounds simple? Well, it isn’t straightforward.

Are we… a team?

As a team, we work as a unit, share a mission, have common goals, and be accountable for our accomplishments. Naturally, engineering managers identify their groups as teams. They have a shared mission and goals they are set to accomplish (hopefully).  

Here are some signs that will allow you to figure out if you are working as a group or a team.

Signals

Some simple signals that can help you understand if you are a group.

What's my name?
People usually refer to their fellow EMs as "The EMs group".

Can you cover for me?
Can a fellow manager fill in for one of the EMs if they are absent?

Do we have a shared memory?
Are different teams making the same mistakes and failing on the same issue?

Do I have 1:1s with other EMs?
Is the manager the only one who facilitates communication?

Forming a team

Inside jokes

I decided to start here since most EMs completely miss it, skipping straight to the advanced part. Before you move forward, first ensure your team has some inside jokes.

Teams need shared moments, a time to create unique behaviors that will make them feel proud. Make some time for fun and discussion. A positive signal will be hearing people say, “Remember the time we..."

Each team has its style, and you can try different things until you hit the spot. Maybe it's a fun session or a collaborative effort to resolve a critical situation. Nothing is more powerful than a good battle story to define a team.

Designing cross-team goals

The lack of a truly common goal achieved together instead of separately is a significant issue. EMs may share common goals related to engineering standards or company objectives. Nevertheless, they are often interpreted in terms of team objectives, making EMs feel they are working separately towards these goals.

Goals are a tool. Usually, they push execution excellence or align the team, but they can be much more than that. Goals set the culture and can bring people together. They can transform a group into a team.

Design cross-team goals that purposely touch multiple teams and set the expectations for EMs to work together. 

Examples:

1. We aim to reduce 4-weeks customer churn: team growth and team app will work together and figure out initiatives that lead this change.

2. Under 5-min CI running time for mobile releases: The team platform and the team mobile will work together to develop a solution.

Let the EMs figure out together how to accomplish that goal and split the work between the teams. Make sure to match teams that need to improve their collaboration and keep iterating.

Matchmaking game

For EMs, there is a lot of work to build the system, and this is not day-to-day product work. Things like the hiring process or improvements to your development flow are critical for keeping the system well oiled and reducing friction.

A common practice is to split these areas between the EMs. This can be done based on individual strengths. The idea is that these are critical projects, and no mistakes can be made.

In my opinion, this is a big mistake. As with any team, people must be matched to grow each other's skills. 

Example
Carlo has never built a hiring process. Every company that he joined already had a very robust process in place. On the other hand, Natasha had experience building a few. Rather than giving Natasha ownership, it would be more appropriate to allow Carlo to conduct research and create a proposal. Then Natasha can review and mentor him to level up his skills. Win-win.

Generate a healthy friction

While it is necessary to keep everyone aligned, healthy friction is needed to produce high-quality results. EM teams must create friction and bring different perspectives to the table. If the team always agrees on every decision and minimal pushback, that’s a warning signal. In some cases, this has to be artificially created by encouraging a few EMs to be vocal about different points of view.

Example
The company is about to change the systems development life cycle. An EM that used to work in a Scrum-oriented organization has planned to adopt a similar approach. All the other EMs are perfectly fine with that, and with some minor changes, the organization is ready to change. While it appears to be a compelling example, I will argue that there is a lack of friction. There are many different models out there that might fit better for your specific culture and situation. I want to get a few more options and let 2-3 EMs debate each other until the first iteration is ready.

The team should choose the right battles depending on the level of risk. The above systems development life cycle is an excellent example of a high-risk change.

So what?

All of the above require a lot of work. There are no magic tricks when it comes to building a team. The team must put down the effort and spend the time thinking and designing the culture they would like to have.

Subscribe now

You have levels, why?

Although it may seem like an obvious question, the answers can vary a lot. They can range from deciding salary to career growth. Setting your desired outcomes and prioritizing them is essential before designing your framework.

Prioritizing the desired outcomes is a significant component of the framework. If you have a level framework, but don't know which outcomes you are looking for, consult your manager, director, or CTO.

Principals

1. Designed for team members, used by managers

You must focus on the principle that levels are meant for team members and not managers. In assessing where they stand and where they lag, team members can determine where they stand and what their future might hold. There are many places where levels are simply ways for leaders to control team members' compensation or make demands. These organizations fail to realize the substantial value that levels can bring.

2. Performance vs. growth

Some managers can mix performance and growth. These might sound the same but are fundamentally different.

A Performance plan focuses on achieving results, whereas A Growth plan focuses on gaining skills, knowledge, and methods to achieve and sustain desired results.

Your 1-on-1s should drive the growth, and on a frequent basis adapt and assess expectations (The Magic of Setting Expectations). The leveling framework should act as a snapshot to measure the delta.

3. Contentious improvements

Do not wait for a leveling exercise. Before each 1:1, review the evaluation and determine where there are gaps. Provide opportunities and feedback to address those issues.

Chapter 1: Dejen the software engineer

Beliefs: I know what I'm worth, do you?

Dejen loves his current team. After working together for nearly a year, things looked promising. In his opinion, his skills were improving, and he was ready to undertake complex tasks, but other team members kept getting all the challenging assignments.

Fortunately, Dejen's company just released a brand-new leveling system. As part of the rollout, he performed a leveling process with his manager. Surprisingly, Dejen realizes that his manager disagrees with his self-evaluation. It was a good turn of events. They found the gaps, and after two months, he was certified as a Senior Software Engineer.

Objective: It's not just my manager

Dejen has been through two managers in the past three years, and now he is about to pass through another one after a company reorganization. One obstacle that made this transition a bit stressful was that Dejen felt he would need to prove his worth time and time again.

Fortunately, Dejen's company just released a brand-new leveling system. He and his manager performed a leveling exercise, and his level was established as Senior Engineer. Dejen will still need to prove his impact when he moves to Jan's team (his new Engineering manager), but he won't have to start from scratch. He will be given challenging tasks that meet his experience level.

Chapter 2: Jan the Engineering Manager

Specialists: Strengthen The Cone Model

The company hired Jan a few weeks ago with a mission to implement a new strategy. He has assembled a team of five talented engineers. After a few more weeks, Jan noticed that the team's growth was directly related to his presence. Some engineers needed more attention to improving their product mindset, while others needed to focus on quality. Jan knows that he can't be everywhere and decides to use The Cone Model.

Leveraging the latest leveling exercise, he was able to identify team members who are strong in these areas and match them with people who needed a push.

Local Maxima: Did you try that?

It has been six months since Jan and Dejen began working together. Jan is pleased with Dejen's overall performance and decides to perform another leveling exercise. The results present a different picture. While Dejen did a terrific job, he reached his "Local Maxima". The exercise revealed a gap in his leadership abilities. While he maintained an excellent delivery record, he did not demonstrate any mentoring skills. In reviewing his 1:1 notes, Jan noticed that no team member mentioned Dejen as an influential figure.

Together, they decide to establish an official mentorship between Dejen and a junior member.

Chapter 3: Amara the VP of Engineering

Framework: a high-quality standard for managers

Engineering managers can have different levels of competence, just like everyone else. Some are fantastic leaders who can inspire their teams, while others are capable managers who can plan and execute complex plans.

As a manager of managers (of directors), Amara needs a tool to ensure all team collaborators receive the best-in-class support and grow healthy. She wants to ensure all Engineering managers have a high-quality feedback loop with their team members. Therefore, all relevant areas are covered, and there are clearly stated expectations for the future. The leveling framework provides some structure for managers who have not yet mastered the skill of evaluating and giving feedback.

Managers typically benefit from a framework that consists of two dimensions, levels, and areas.

Areas of expertise: establish the engineering culture.

By defining areas, Amara (VP of Engineering) can influence her organization's focus and make sure that the engineering culture is growing in line with the company's vision. For example, in the pre-product-market fit stage, the areas reflect more innovation, whereas those reflect quality and specialization after a product-market fit. Having identified clear expectations from each area, Amara can set the tone of what high quality or collaboration means for her organization.

Levels: organizational planning

Generally, a healthy balance of experience and skills between team members facilitates a positive working environment and enhances the value of skills for both juniors and seniors. Juniors help seniors to grow leadership and mentoring skills. This helps keep the team engaged and hungry. On the other hand, seniors can teach juniors from this experience and boost their technical skills.

Unless Amara pays attention, her organization will develop pockets of senior teams. If new teams need to be created, she'll need to decide carefully who'll be assigned where.

An effective level evaluation will let her map the distribution of levels within your team and model potential growth scenarios. Amara will be able to answer questions like, how many juniors do we need to hire? Can we open three new teams? 

As managers, we need to provide an excellent level of support to our team members, from technical to emotional.

This is hard work that requires a lot of patience and trust from both sides and, once established, will help your team to grow pretty quickly.

The Triangle

There are many techniques to build this excellent level of support. 1-on-1s are great, but as you might have noticed, there is a 1-on-1 relationship in "1-on-1s" that can be insufficient and dangerous. Most managers have more than one direct report, and their attention must be spread between everyone. Sometimes some members need more attention, leaving the others with low support.

Your team support network looks like a triangle, and everyone depends on you. Every person needs a different amount of attention at a particular time.

This is very natural as each person is unique and might have a different level of skills. On top of that, some might be involved in a complex project while others have a chill week. You probably tell yourself, "This is very natural to me," and you are right. But it also will affect the growth pace of your team and can quickly go out of control.

What can go wrong? (or why do I need it)

Let's look at a few widespread scenarios. These can be avoided using the Cone Model.

1. Neglecting talent

Linda (A Senior Engineer) is a very talented engineer in your team. She joined one year ago and had high-speed growth, and since then, you never had any challenges with Linda. She always pushed ahead and took care of her growth. Naturally, you started to shift away from your focus from Linda to Denny (Junior Engineer), who has struggled a bit lately. Linda stopped growing. She started feeling that her growth pace had dropped dramatically and couldn't understand why. A few months later, Linda announced that she had accepted an offer from a different company. She wants to pursue her growth.

Have you made a mistake by shifting your focus? No. Denny needed more attention, and you have a limited capacity. The error was that you didn't take care of Linda's needs.

2. Blind spots

In the past few months, the team has been performing very well. Work gets done on time and with high quality. When you have a spontaneous conversation with another colleague, they mention that Henry (Engineer) has issues at home that affect his focus. You are a bit surprised, you had several 1on1s with Henry, and the topic never came up.

Are you a bad manager for missing that? No. It might be that Henry is a very private person and therefore doesn't share his personal issues with most people. It might be something you will be able to catch by yourself.

3. Out of your league

It was your first time using the tech stack when you joined your team. You have a sound engineering background and understand technical principles and designs, but you are still behind in a deep discussion about the specific ecosystem. Denny (Junior Engineer) is taking his first steps in the development world. He's been coding for eight months now and needs a good level of support. You try your best to push him in the right direction but cannot give him very accurate feedback about his coding skills.

Are you responsible for developing Denny's coding skills? Yes. Can you provide him with all the necessary support? No

So what can you do to avoid these scenarios? How can a manager provide such comprehensive support without spreading so thin that it will impact their other responsibilities? (execution, strategy, hiring, etc.)

The Cone

You should minimize your dependencies and maximize the network between your team members. Instead of letting all your team depend on you for their growth, you should create a connection between people, leveraging the different strengths and weaknesses.

Identify the need

One way to create a connection is to identify a need for a direct report and surface it up during a 1on1. For example, Henry's need for mentorship in the team's tech stack. It's essential to explicitly indicate that you are not sufficient for the support in this area, but Linda can be a perfect match. You talk with Linda and let her know that you want her to spend more time with Henry and give her the main areas to focus on.

Set expectations

Sometimes you won't be aware of a specific need. Nevertheless, you must nourish the network. A great way to do so is to set expectations with your team. In your next 1on1, let them know you expect them to watch specific team members and even an area. "Paul (Senior Engineer), I'd like you to pay attention to Linda's system designs. Make sure to review them".

Read more here on The Magic of Setting Expectations.

How can a good network look?

• Linda supports Henry: Coding in our tech stack

• Paul supports Linda: On software architecture and system design

• Paul also supports Denny: Coding in our tech stack

• Denny supports Henry: Team collaboration and communication

• And you support everyone :)

Managers should build strong networks and create an environment where they are not critical components. They should be able to stay away for a few weeks without impacting the team.

PS.

The Cone Model can be very efficient for directors of managers.

Thank you, Damiano Condorelli

The Cone Model for Teams' Support Network was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

As engineers, we divide our work between designing solutions and building them. In this post, I'll focus on deciding how much time and effort should go into design work that happens before any execution (coding).

I'm a big believer in the "Iterative Design Process" which means instead of working in distinctive stages, one after another, you advance in tiny adjustments to the design as you identify challenges, get feedback, or come up with innovative new ideas.

But here comes the question, how would the team know it's time for prototyping?

So how do you determine the amount of time that will go into design? Will it be 10%, maybe 90% (like our dear Albert)?
When using agile methodology, this becomes a critical decision for software architects. Should you start iterating or wait for a complete solution?

The knowns and unknowns framework

In this framework, there are four levels of knowledge. These levels can help us measure how close we are to finishing our design and moving to implementation.

• Known knowns: Things you're aware of and understand
  Example: Developing SAML Single Sign-on

• Known unknowns: Things you're aware of but don't understand
  Example: Integrating the SAML Single Sign-on with the exiting authentication flow

• Unknown knowns: Things you're not aware of but understand
  Example: Additional requirement of Two-factor authentication (that you know how to develop)

• Unknown unknowns: Things you're neither cognizant of nor understand
  Example: There is a security bug in the Single Sign-on library you are familiar with and planning on using

We can work a lot on the first two levels in our upfront design. The last two will require implementation work, which can be the real deal or a PoC.

Heuristics

A heuristic, or heuristic technique, is any approach to problem solving or self-discovery that employs a practical method that is not guaranteed to be optimal, perfect, or rational, but is nevertheless sufficient for reaching an immediate, short-term goal or approximation. — https://en.wikipedia.org/wiki/Heuristic

We will start by defining our cost function:
How much time spent + level of risk.

Let's go over the desired expectation. We want a strategy that will allow us to decide when to stop designing and start implementation while optimizing the cost function.

Heuristic #1: There are enough "Known knowns."

Do you have minimal knowledge to bring value?

Your project might be massive; therefore, there are many requirements, and it might be that some of them can be delivered without the others. In the "Iterative Design Process," we want to get back feedback as fast as possible. That's why, if you have something you can ship with low risk, do it.

Pay attention to the level of risk. While you do want to iterate, you do not want to break the core components of your system.

Heuristic #2: There are no more "Known unknowns."

Did you solve all your "open points"?

It's very recommended to start any project with some risk assessment. During the evaluation, the team should surface up any open points. It could be a module you didn't touch for a long time or a new technology required for the project.

A good heuristic that it's time to move on is when you have got one or more solutions for each one of your open point points.

Heuristic #3: There are too many "Known unknowns."

You can't focus as you have too many "open points."

There are so many open points you don't know where to start. This might be a good indication that you need more info. A prototype can focus your efforts. You will probably need to return to the design table again, but this time with much more information (and fewer open points).

Heuristic #4: You stop learning new things

Do you keep discussing the same open point over and over?

So you did find solutions for all your "open points," but you can't decide on one particular point. There are multiple solutions, but the team keeps arguing which one is the best. You have a few discussions, but nothing sticks. It's time to code.

If the risk is reasonable, you might consider starting with one of the solutions and having a close follow-up. If the risk is higher, you can consider starting with multiple solutions and evaluating them iteratively.

Heuristic #5: Falling down the rabbit hole

Things start getting too complicated and abstract

Yes, we are here to solve complex problems, and yes, some solutions require some pretty deep thinking but try asking yourself, Does my project need that level of complexity?

Engineers love solving problems. That's why we often invent new ones (Imaginary Problems Are the Root of Bad Software). If you notice the design starts questioning areas that are hardly related to your goal, it's time for a PoC or prototype to keep your feet on the ground.

Final words

Remember that these are heuristics; hence they do not provide 100% accurate decisions. Your role is to use them wisely as a kick-starter and evaluate your specific situation with your team.

You will never find the optimal ratio of design/build, but you can train yourself and your team to have a better feeling when it is time to switch.

Good luck with your next project :)

5 Heuristics to Decide When It’s Time to Stop Designing and Start Coding was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

How many times have you reached a performance evaluation, or a retrospective and noticed the following phrases?

• “Why didn’t you help John (a junior developer) with the onboarding?”

• “Based on your experience, I was expecting you will take responsibility on that part”

• “I didn’t see any growth in that area, thus you won’t get the promotion”

If you would like to avoid this situation, there is a powerful tool called expectations, the key is to set them up, loud and clear, upfront.

No, it’s not obvious

Something happen in your team, it might be a task that fell between the cracks or a team member who didn’t take ownership. You might find yourself saying “I thought it’s obvious that X will be done”. Many things that seem obvious to you, might not be obvious to your team.

People are coming from different backgrounds, life, and work experiences that shaped their expectations. It’s very likely that for someone who worked a few years in an empowered team, it will be obvious that the team can influence product decisions, but for another team member it might be the first time. As their manager, it’s your responsibility to ensure people know what is expected from them.

A tool for measurement

Without expectations it’s very difficult to benchmark yourself, that’s why many people aren’t able to grow at their desired pace. By setting expectations your team members will be able to see the direction and work in iterable mode.

On the left, you can see growth progress on a person without expectations, their manager assumes they know their value. On the right, the manager kept setting expectations and worked on adapting them with the growth.

1. I’m expecting you to be more independent

2. I’m expecting you to lead this project

3. I’m expecting you to own the communication outside of the team

4. I’m expecting you to coach our juniors

5. …

Write or forget

Having unclear expectations is much worse than having no expectations, thus it is very critical that expectations will be written. Many times I hear managers grumble that they did set expectations but the team wasn’t able to meet them.

When you try to analyze what went wrong, you realize that these expectations were not written anywhere, they were set in a meeting at best or a coffee chat at worst. I do understand that for some people is much easier to express their thought in verbal communication, but… if it’s not written it will be forgotten, or changed (which is even worse).

The process needs to be simple, you think about an expectation, you first write it down, then think about it a bit more, after you made sure it’s clear you either send it written or verbal communication. You should always get some minimal feedback from your member, it’s for making sure they understood and for adapting it to their reality.

1. A need emerge

2. You think of an expected outcome

3. Formulate the thought into text

4. Communicate async or sync

5. Get feedback and improve

6. Save and document

Some practical use cases

Performance excellence 🏁

Your team is working on a new initiative, it might be a new feature or a refactoring activity. As the leader of the team, you are sure your team will deliver the best results, I mean it’s obvious 😉

This might be less obvious to your team, by having a written page of the final expectation will help the team to figure out how to plan and validate their outputs. Besides that, the team would be able to get feedback on their work and improve for next time.

Personal growth 🐤

One of your senior team members seems to be working in isolation, you notice that junior members are not improving their skills and the team is not growing.

Your senior team member is likely aware that one of their responsibilities is to coach and mentor their fellow junior members. In your next one-on-one, let them know that you expect them to work together with others, even at the cost of tasks.

Team culture 🎮

Things seem to go in the right direction for your team. You managed to deliver challenging activities with great results, but you start noticing that many people are becoming toxic. Many sessions are ending with bad taste.

This is a substantial issue, it won't be solved by itself. One of the first actions you must do is to declare how do you expect team members to communicate with each other. Important to mention, this is only the starting point but it will provide the team a way to measure if things are going in the right way.

So let’s recap,

The Magic of Setting Expectations was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

How you can make good use of concurrency to reduce execution time.

So you are using Async/Await and enjoying all the great benefits of it:

1. Clean Code

2. Better error handling

3. Easy Branching (if/else)

4. Debugging

5. Much more…

Yet it’s a good idea not to let the nice and clean syntax take your mind away from concurrency and how you can benefit from running tasks concurrently.

Concurrent computing is a form of computing in which several computations are executed during overlapping time periods — concurrently — instead of sequentially (one completing before the next starts).

I will show the benefits by presenting two cases where concurrency shines.

Case 1: List of tasks

Let’s say you have a list of posts that need to be published on an external service. Before publishing you want to validate some post fields and if they’re OK to publish.

The sequential solution 😴

You can iterate over the list and check validation for each post, then if the post is valid proceed and publish it.

<a href="https://medium.com/media/b7132bdd98af811a2fee8d2591028fba/href">https://medium.com/media/b7132bdd98af811a2fee8d2591028fba/href</a>

This solution works, but you need to pay attention that each post has to wait until the end of the previous one to finish.

There is no reason why we should not execute all of them simultaneously.

The concurrent solution 😎

First we will create a publishing pipeline: validate → publish

Second, we will map all our posts to the pipeline and get back a list of tasks (Promises). Now we can call “Promise.all” to wait until all of the pipelines are done. Execution time has been reduced to almost one pipeline because each pipeline is running independently from one other.

If you are dealing with very long sequences of posts it’s a good idea to split the pipelines into chunks and execute them one by one.

<a href="https://medium.com/media/51970e13094ed603478f0e5a43feb245/href">https://medium.com/media/51970e13094ed603478f0e5a43feb245/href</a>

Posting time: 200ms

Number of posts: 20

Seq solution: 200ms * 20 = 4sec 

Concurrent solution: approximately 200ms

4sec vs 200ms - 20x faster

Case 2: Independent sources

Sometimes you relay on several independent data sources, same as having multiple arguments for a function. they are not blocking each other and can be fetched in concurrent.

Now let’s imagine you need to compare all users’ payments, invoices and receipts in your platform.

The sequential solution 😴

You can get each resource one by one and then use them.

But now each data source will be fetched only after the previous one is finished, causing a slower execution time.

<a href="https://medium.com/media/264b64cbf1835575faa8ed90fd5e7981/href">https://medium.com/media/264b64cbf1835575faa8ed90fd5e7981/href</a>

A concurrent solution 😎

Create 3 different tasks and wait until all of them are done.

Here all of the calls are made in concurrent, which means we now have a faster preparation time, especially when calls are expensive in terms of time.

<a href="https://medium.com/media/d39b7b5e9137114b65de86eeda7a575a/href">https://medium.com/media/d39b7b5e9137114b65de86eeda7a575a/href</a>

Get payments: 900ms

Get invoices: 800ms

Get receipts: 2000ms

Seq solution: 900ms + 800ms + 2000ms = 3700ms = 3.7s

Concurrent solution: Max(900ms, 800ms, 2000ms) = 2000ms = 2sec

3.7s vs 2sec - 1.85x faster

Conclusion

Async/Await can give us a lot of benefits in terms of readability and error handling, but we should not forget to use this feature wisely and always look for the tasks that could be handled concurrently.

• Always try to think which calls are non blocking and which ones have to run one by one.

• Every time you’re finding yourself writing a loop with await try to figure out if you can use Promise.all based on the dependency of the calls.

The queue is one of the most used data structures.

You probably use it every day when you shop for groceries (even online) or when you send a text message to your friends.

The concurrent task queue is a very powerful pattern that can really help you handle tasks over time or improve your performance.

Let’s start with the basics

What is a Queue? 🚶🚶🚶‍

A queue is a linear structure in which values are added at one end and removed from the other. This discipline gives rise to a first-in/first-out behavior (FIFO) that is the defining feature of queues. The two fundamental queue operations are enqueued (add to back) and dequeue (remove from the front) (source).

Ok, when should we use it?

Use a queue when you need to maintain the order of events and process the value by that order.

Great, you convinced me! But why do I need the concurrency thing?

As I mentioned above, a queue is able to process one value at a time. But sometimes it’s not fast enough.

Consider the following case 🙌:

You are at your favorite grocery store and have just arrived at the cashier, but unfortunately, there are many people waiting. To speed up the process, the store opened several more registers and each additional cashier has its own queue. So you just have to choose one. If one of the cashiers is having a technical problem or they’re just slow, that queue will be delayed even if the other slots are free.

Concurrent task queue to the rescue! 💪

We will use only one queue for our purposes. In that way, every time a slot becomes free, we will dequeue a person from the queue and send him/her to the free slot.

Hooray! 🎉

Let’s examine a use case

Last week, I was working on a Google Chrome extension that sniffs and downloads HLS streams (HTTP Live stream).

HLS streams are combined from multiple chunks that are fetched one by one and streamed to your browser as a single video. You can have thousands of files per stream, and you need to download them all.

We will use our beloved queue to speed up the process and make sure that one slow fetch is not gonna hold up the others.

TL;DR: here’s the code

<a href="https://medium.com/media/e3e893d2c8e3dfbf70703ed75ed07963/href">https://medium.com/media/e3e893d2c8e3dfbf70703ed75ed07963/href</a>

Now let’s look at it piece-by-piece.

1. The handler

<a href="https://medium.com/media/10cd4512fe167910e06fdedc4559f221/href">https://medium.com/media/10cd4512fe167910e06fdedc4559f221/href</a>

This simple handler gets the URI from the payload and then:

• fetches the chunk

• transforms it to a blob

• emits a chunk-ready redux event

• gets the current count of ready chunks

• checks if it’s “all done”

2. Create the queue

<a href="https://medium.com/media/01b3b84e98100cbcaabc663269e353d7/href">https://medium.com/media/01b3b84e98100cbcaabc663269e353d7/href</a>

Using the handler, we create a new queue with 5 workers. We get back the watcher task and a queue channel. Then we are going to run (fork) the watcher task so it will start listening to tasks.

3. Push the tasks

<a href="https://medium.com/media/03897e90b6ebc2b002f08d2307c018e4/href">https://medium.com/media/03897e90b6ebc2b002f08d2307c018e4/href</a>

We map all the segments to a put task (into the queue channel that we got back), and then we fire all the tasks together.

4. Wait for all the chunks to be ready or for the action to be cancelled

<a href="https://medium.com/media/56b752d8889ce6e2e30bce01cf7cdb71/href">https://medium.com/media/56b752d8889ce6e2e30bce01cf7cdb71/href</a>

Now we are waiting for the first action to be called all-done or to be canceled. After that, we can cancel the watcher and act according to the action that has been received.

And that’s it!

If you want to see it live, visit https://github.com/puemos/hls-downloader, and download the Chrome extension.

I hope you learned something new! If you have any questions, please comment below so everybody can benefit.

Like many others, I fell in love with functional programming, the problem was that I was the only one in my team.

I believed that functional programming could have a great impact on our code base that’s why I’ve tried to convince my fellow developers to make the change.

These are my dos and don’ts from that experience.

Don’t sell it as the solution for everything

First, it’s not 😬.

Yeah sure, functional programming is awesome and solves many issues but it’s not a silver bullet and has many other pitfalls. Telling everybody that it will solve all their problems will just create very high expectations that will crash on the first obstacle.

Do present it as another approach to solving problems

Try to take a specific issue and show your team how it can be done in a functional way. In that way, the benefits will be clear and a lot easier to digest. Choose a complicated pipeline that, with the help of Either monad, will become clearer.

Don’t write your next feature in a completely functional way

Okay, so the feature is written flawlessly but you are the only one that can understand that code 🤓. It’s way more important to have a unified code base than having your feature written in an adequate way. You will create confusion and make your team feel overwhelmed by the names and unfamiliar patterns.

const simple = fn1 => fn2 => fn3 => fn4 => fn1(fn2(fn3, fn4)); WTF?!?

Do a workshop

A workshop is a wonderful way to teach new techs and paradigms. Start from the very basic and move to more advanced areas, take an existing feature, and refactor it together while indicating the best practices and the benefits.

Don’t fight

Many people just love wasting time and fighting over stupid things like tabs vs. spaces, vim vs. emacs … imperative vs. functional 😤. Try as much as possible to avoid any battle because they will make people automatically reject the functional ideas.

Do be flexible

It’s ok if someone mixed some imperative code inside your beautiful functional module. Go to this developer and open a discussion about why he/she chose that way and show him the other approach and be open to accepting his way.

Changes are a process, don’t give up and stop writing functional code in your job projects.

Do you have any tips from your experience? Please share them!

A two-part article about how you can benefit from working on a side project and how you can start your own.

First part: The Why

Side projects are a big part of my life, they helped me get my first student position and later on a job right after I relocated to Europe. I feel that one of the reasons why I love developing is the fact that we are creators, so why restrict ourselves?

I found 7 reasons why I really believe you should start your own creation today.

1. Improve your skills

We’ve all had the feeling that we’re a little behind. It could be with basic programming skills, like data structures or algorithms, a specific technology that you’re using at work (apache spark), or maybe a service that you don’t have a clue how it works like AWS. A side project is your opportunity to take a specific skill and build something that uses it.

Most of us are part of a team, and we can’t work all day on a specific skill because we need to deliver features and solve bugs; but in our field, you can’t lag behind and need to develop your set of skills.

2. Try new technologies

Last year I found out about functional programming and it was a pleasure. At work, we were using some other technologies and I really wanted to use my knowledge, so I ended up creating a small game in the wonderful #elm language. This simple game forced me to use the “elm architecture” and, by that, to improve my skills dealing with impossible states. Many times you find an amazing piece of technology that could solve all your problems, but perhaps your team is using a different stack.

In a side project, you’re choosing the technologies that you like to explore. And as a bonus, you may be able to convince everyone to adopt that tech.

3. Get feedback

We all need feedback because it’s the best tool to improve. Sometimes you may be working on internal projects or, in the worst-case scenario, on unused projects.

The benefit of building your own thing is the freedom to decide who can use it. You can build a smart home system and share it with your family and friends or even with the entire world.

4. Be a part of a community

A big part of building stuff is asking questions and struggling with unsolvable bugs. Luckily, there are many awesome communities that can help you with bugs and even with your motivation. You can find them on Slack, Reddit, IRC, and Stack Overflow, among others. You just need to look.

5. Build it from scratch

What’s the first project I worked on? A large-scale application that involved many pieces and technologies. I understood most of the parts, but I lacked the opportunity to really understand how things work. I believe that the only way to really understand complex systems is to try and build one yourself. Yes, you will struggle, but the struggle is actually the progress of learning and understanding all the small gotchas.

6. Unleash your creativity

You always tell your friends that you have this crazy idea, so why don’t you just try to build it? 🤓 Sure, maybe you will ditch it after a couple of weeks, but at least you will stop this itching. And prove to yourself that it’s doable. Or that it’s not.

7. Start something new

If you have an entrepreneurial soul, a side project is your opportunity to start something new. Many of today’s products started as side projects. So, give yourself a chance and build your dream product.

Some of the most famous examples are Instagram, Slack, Groupon, Twitter, Pinterest. So, give yourself a chance, don’t be lazy, and build your dream product.

You can find my side project here https://github.com/puemos

Happy coding!