DEV Community: Shy Alter

Potential Impacts of Large Language Models on Engineering Management

Shy Alter — Wed, 31 May 2023 13:24:49 +0000

How will LLMs can impact the day-to-day work of Engineering Managers and long-term changes.

Credit: Author

Everyone is talking about AI and Large Language Models (i.e GPT), and how they are reshaping the roles of software engineers, designers, customer support, and more. The narrative seems to overlook the impact of AI on management roles.

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 improvement areas and follow-up quickly.

Caveats

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.
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:

Shy’s and Maya’s weekly report

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

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

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

Outputs:

Shy should work on project A.

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

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.
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 about 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

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.
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.

Originally published at https://www.engstuff.dev.

No Shortcuts: Know Your People

Shy Alter — Fri, 12 May 2023 14:12:51 +0000

Before applying any management framework, talk and listen to your people, know who they are and what they do.

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.

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.

Originally published at https://www.engstuff.dev.

Operational Minimalism

Shy Alter — Tue, 04 Apr 2023 13:30:32 +0000

Say no to advanced features, and embrace simplicity on your way to operational bliss.

Credit: Author

Who’s it for?

Any organization but mostly for:

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:

Many jobs, many interfaces

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.

Team’s Plans — GitHub issues.
Projects definition — GitHub issues.
Project’s Plan — In the Project’s GitHub issue.
Tech design — In the Project’s GitHub issue.
Code — GitHub PRs.
RFCs — GitHub issues.
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 I had more time, I would have written a shorter letter.”— Marcus Tullius Cicero.

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.

Your organizational structure is not effective, which causes too much friction between teams. I suggest looking at Team Topologies.
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.

Recommendations

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.
Simplifying processes: Reduce the reliance on inline comments, custom attributes, and complex workflows. Encourage clear and concise communication.
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.
Scaling effectively: Upgrade or merge tools only when they simplify workflows and reduce complexity.

Originally published at https://www.engstuff.dev on April 4, 2023.

Team’s Metrics: A Human-Centric Approach

Shy Alter — Tue, 06 Sep 2022 15:37:44 +0000

Take a human-centered approach to evaluating your team’s metrics and determining how to use them to drive growth

image by author

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, how we reason and, more importantly, how we act must be different.

Ultimately, engineering metrics can’t tell your team the whole picture. They just provide a glimpse of what is 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 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 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 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.

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 ten 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 ten 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:

Originally published at https://www.engstuff.dev

Tribalism and Leadership

Shy Alter — Tue, 26 Jul 2022 16:57:16 +0000

What is Tribalism, and why does it hold such a critical place in the leadership world?

“People are tribal. The more settled things are, the bigger the tribes can be. The churn comes, and the tribes get small again.” — Amos Burton, The Expanse. Image credits: Author

Did 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?

Are you getting what you are putting in?

In the current downtime, 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)

Ride on your team’s self-confidence

“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 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

Your team; your safety net

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 firefighters 1, which are similar to 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.

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

Originally published at https://newsletter.engstuff.xyz on July 26, 2022.

The Five-Point Framework for Saying No

Shy Alter — Wed, 22 Jun 2022 17:52:53 +0000

Learn how to identify the signals that it’s time to say no

The fun part of working as engineers is that we get to solve challenges. We are expected to deliver high-quality solutions on time, which puts us under pressure. As a result, many engineers (primarily juniors) become silent when they need to say no.

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

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.
You can also say stop in the middle of a task

Originally published at https://newsletter.engstuff.xyz on June 22, 2022.

Top-Down, Bottom-Up, and Everything In-Between

Shy Alter — Tue, 07 Jun 2022 05:35:53 +0000

Balancing strategic work with day-to-day work for a B2B product-led company

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 is, 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?

The business impact is evident and significant. (10% more subscriptions, close three large clients, reduce support pressure by 30%)
The engineering impact is evident and significant. (Increase productivity by 10%, reduce bugs by 25%)
Red flag for engineering or product standards. (Developers can’t deploy quickly, Users don’t understand how to use the product)
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.

Direction

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

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.

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.

Originally published at https://newsletter.engstuff.xyz on June 7, 2022.

Anti-pattern: The Engineering Managers’ Group

Shy Alter — Wed, 11 May 2022 11:37:34 +0000

Invest in a true team of engineering managers to reap the benefits

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?

A team or a group?

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

Only the team can understand this joke :)

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

Goals should involve multiple teams

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:

We aim to reduce 4-weeks customer churn: team growth and team app will work together and figure out initiatives that lead this change.
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

Find a partner

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.

**Want to Connect?**

This story was originally published at [https://newsletter.engstuff.xyz](https://newsletter.engstuff.xyz)

Engineering Levels: A Case Study From Three Perspectives

Shy Alter — Sun, 24 Apr 2022 20:48:23 +0000

The power of a good level framework as seen through three different perspectives

Recently, there has been a lot of debate about engineering levels, whether they are good, bad, or just useless. In the story, I hope to show the positive outcome of a good effort. However, before we get started, let’s take a look at what are the critical elements to make a good framework

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 ICs, used by managers

You must focus on the principle that levels are meant for ICs and not managers. In assessing where they stand and where they lag, ICs can determine where they stand and what their future might hold. There are many places where levels are simply ways for leaders to control IC 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.

As a tool for growth, the leveling framework should use performance to measure growth.

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

It’s all about gaps

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

Different skills

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

Building the force

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?

Originally published at https://newsletter.engstuff.xyz

The Cone Model for Teams' Support Network

Shy Alter — Tue, 29 Mar 2022 14:36:08 +0000

Lay a strong support level for your teams, even when you are away

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

"1 to 1" relationship between manager and reports

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.

Your attention must be distributed wisely.

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

Create a many-to-many support network

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 :)

An internal network of support

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

5 Heuristics to Decide When It’s Time to Stop Designing and Start Coding

Shy Alter — Wed, 26 Jan 2022 14:42:52 +0000

Techniques for balancing design and development planning

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).

Iterative Design Process

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?

Albert Einstein

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

Donald Rumsfeld

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.

We want to balance the business value and the design maturity.

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: F_alling_ 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 :)

The Magic of Setting Expectations

Shy Alter — Wed, 29 Dec 2021 14:42:53 +0000

How to use expectations as a tool for growth and excellent

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

I mean, it’s obvious, isn’t it?

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.

With or without

I’m expecting you to be more independent
I’m expecting you to lead this project
I’m expecting you to own the communication outside of the team
I’m expecting you to coach our juniors
…

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.

What happens when no one remembers…

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.

The ideal flow for setting expectations

A need emerge
You think of an expected outcome
Formulate the thought into text
Communicate async or sync
Get feedback and improve
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,