Edge of Enginering Leadership

Black Box Estimations

Fri, 06 Mar 2026 00:00:00 +0000

Software estimation has always been hard - a running joke in the industry for so long the joke stopped being funny. And yet, with enough discipline, decomposition, and calibration, we got into a vicinity of truth. Close enough to plan a quarter, set a customer expectation, or make a reasonable staffing decision. The underlying assumption in all our tools - story points, t-shirt sizes, velocity baselines - is that engineers are roughly predictable actors. Given similar context, a similar task takes a similar amount of time.

That assumption is now under serious pressure.

Enter the Black Box

AI coding tools have become a real part of how engineers work. Cursor, Copilot, Claude, Codex. The productivity gains are real and visible. Engineers regularly report that certain tasks which used to take hours are now done in minutes. Some classes of problems that required senior knowledge to approach are now accessible with a well-crafted prompt.

But here’s the catch: essentially, these tools are non-deterministic black boxes.

What that means in practice: the same engineer, with the same AI tool, working on two superficially similar tasks, can have wildly different experiences. One task - writing a straightforward CRUD endpoint with familiar patterns - might be done in a quarter of the usual time. Another - integrating with a poorly documented third-party API or working in a legacy codebase the model has never seen anything like - might end up taking longer than doing it manually, because you’re now debugging AI-generated code that looks plausible but introduces subtle bugs you have to hunt down.

The multiplier is unknowable upfront. It could be 10x. It could be 2x. It could be 1x. It could, in some cases, be 0.8x.

The Volatility Problem

This is where estimation gets into genuinely new territory. Before AI tools, the variance in execution time for a well-understood task was fairly bounded. A mid-level engineer estimating a task in their domain of expertise wouldn’t be wildly off - maybe 1.5x, maybe 2x in bad cases. That’s manageable.

With AI tools in the mix, the variance explodes. Virtually the same task, the same engineer, on a different day, could now take 20 minutes or 3 days. And crucially, you often don’t know which until you’re already in it.

Now imagine building a sprint plan, a roadmap, or a customer commitment on top of estimates with this kind of range baked in. What does a “two-day task” even mean anymore if the honest confidence interval is “somewhere between two hours and two weeks”?

An estimate with that kind of spread is not an estimate. It’s a shrug with a number attached.

Does This Make Estimation Useless?

Not entirely - but it might retire some of the tools we’ve relied on. Story points as a proxy for effort assume that effort is at least somewhat stable as a concept. Velocity as a planning baseline assumes your team’s throughput from last quarter tells you something about next quarter. Both assumptions become significantly shakier when a core ingredient in the work - AI assistance - is this unpredictable.

What might still hold: relative estimation. If Task A and Task B are both AI-assisted in similar ways (similar codebase familiarity, similar documentation quality, similar problem domain), comparing them to each other still carries some signal. The absolute number might be nonsense; the ratio might still be meaningful.

What I suspect will emerge as more valuable: leading indicators other than time. Things like: is the AI generating confident, clean output for this task, or is it hedging and hallucinating? Has this type of work been done in this codebase before, so the tool has patterns to latch onto? Is this a greenfield problem or a legacy archaeology expedition? These don’t give you a number - but they give you a risk profile.

My wild guess: estimations will be done only after the first AI-only pass on the problem.

What This Means for Leaders

If you’re managing teams or communicating commitments upward, I think this deserves an honest conversation - perhaps before the next planning cycle rather than after the first one blows up.

A few things worth putting on the table:

Acknowledge the new source of variance. It’s not that engineers are estimating poorly. The tool they’re using has genuine uncertainty baked in at a level we haven’t dealt with before. Treating blown estimates as a calibration failure misdiagnoses the problem.

Consider time-boxing over estimating. For high-AI-leverage work, “we’ll spend three days on this and see how far we get” might be a more honest contract than “this will take three days.” The former is a commitment you can keep. The latter might just be fiction.

And have the conversation with stakeholders now. The teams that will handle this best are the ones that proactively reframe how they communicate uncertainty - not the ones that keep using the old vocabulary and hope nobody notices when the numbers stop adding up.

Closing Thought

We spent decades learning to be better at estimation despite the inherent difficulty of the craft. We got better because we understood the variables. The arrival of AI tools has introduced a variable we don’t yet understand well enough to model - and that’s the honest state of things.

The worst response is to keep estimating as if nothing has changed, and then explain the misses later. Altough everybody will accept the work that took 5x shorter time than estimation, next time your own integrity and knowledge will be at risk. The more useful response is to start figuring out, now, what estimation even means in this new environment - and to be transparent with everyone around us while we work that out.

Photo by Photo by Ann H

Junior Engineers in the Age of AI

Wed, 15 Oct 2025 00:00:00 +0000

Engineering talent market has shifted in recent years, and then shifted again due to the booming popularity of AI-powered tools. Where does a Junior Engineer fit into this new picture?

New Competition Landscape

Not long ago, a junior engineer was competing mainly against their fellow juniors and mid-level engineers. To make yourself hireable as a junior, you could gain an edge by studying the technology deeply, doing pet projects, and bringing energy and a fresh wave of positivity into the team. A situation where a junior engineer competed with a senior one was extremely rare.

Now, at the moment of writing this, a well-versed junior — with the right help from AI-powered coding agents or IDEs — can be considered a “supercharged junior.” Output expectations are higher, the learning curve speed is faster, ramp-up time - shorter. The entry point has risen to heights this industry has never seen before.

AI as Junior

Many senior+ engineers I talk with daily describe AI tools like Codex, Claude, or Cursor as being on the level of a junior engineer. “It’s like working with a junior — if you prompt it precisely enough, it will do a decent job, but for anything more complex I need to jump in myself.”

This sentiment is so widespread that it’s often accepted as fact, with many pitfalls overlooked. AI can’t talk to users or customers directly, won’t gain knowledge over time, won’t truly learn — and there are many other “won’ts.” Still, this perception has become another ingredient in our current reality.

Tough Market

With tougher competition and the “AI as a Junior” mindset spreading, companies are hiring significantly fewer junior engineers than ever — if any at all. The fortunate ones who do get hired face much more pressure. Others face a dilemma: should they change their career path altogether? This could trigger a loop where software engineering becomes an undesirable career choice for many.

For people with experience, this might sound like good news - less new blood entering the market means less competition down the road. But I believe this is a short stick to hold. We’re essentially shooting ourselves in the foot — just slowly.

Effect on the Industry

For any industry to stay healthy, it needs fresh minds bringing that youthful ignorance of how things “used to be done.” We, the old dogs, often don’t realize how easily we fall into doing the same things repeatedly out of familiarity. We need people who challenge, reshape, and sometimes reinvent.

You don’t need me to explain what that means for an industry that moves as fast as IT. Yes, juniors make the same mistakes we all did early in our careers (“let’s rewrite this legacy platform from scratch,” anyone?). And yes, they don’t yet understand all the reasons behind how things are built. But I’d rather go through that together for the sake of a fresh perspective and renewed energy.

New (Brave) World

We’ll need to learn how to nurture a new generation of software engineers, with AI tools under both our belts and theirs. This certainly changes how we can deliver projects together — but it doesn’t mean we should replace young professionals outright.

In my view, the time when junior engineers become hireable again should be near. Hiring the most senior people hasn’t exactly become easier, and competition at that level remains tough. AI isn’t complete enough yet to fill the gap, and with that realization, many companies may start opening their doors to new entrants. Those doors won’t be as wide open as they once were, though, since teams themselves are now smaller.

In any case, if you’re a junior engineer right now — I wish you patience!

If you’re a hiring manager — could a junior find their way back into your hiring plans? Your future self might appreciate the thought.

P.S. As with many AI-related topics, this one is bound to go stale quickly! Check the date of the post before leaving a comment. Thanks! ;-)

Photo by Mikhail Nilov

Difficult Conversations (Part 2)

Mon, 20 Jan 2025 00:00:00 +0000

Last time we covered the first 4 out of 6 principles I recommend considering when dealing with any kind of difficult conversations. Check them out before reading this follow-up.

#5. Have an Action Plan

Whenever you have a chance to sense a difficult conversation coming up, make up your mind with at least a crude action plan moving forward. What should be the exact steps you would recommend taking to achieve your goal? Think about it in advance, even if those steps seem obvious and trivial. In many cases, they won’t be so obvious.

Having that action plan gives you several advantages:

You are significantly less likely to accept an unfavorable resolution to a problem, since you’ll have an alternative to suggest at hand.
You can take advantage of anchor bias — with greater control of the conversation, putting your solution on the table first increases the likelihood that other alternatives will just be relatively small deviations.
And last, the most important — it transitions the whole conversation from the “problem pointing” phase to the “problem solving” phase.

It’s totally fine not to have a strong opinion on the best path forward. The point is to show you’re here to solve problems, whatever their source, and bring everyone together to this side of thinking. If you’re unsure about your plan, share those thoughts with other participants, and use it as a chance to engage them in finding the best path forward.

And yes, you got it right — the famous phrase “a bad plan is better than no plan” is also true in management.

#6. No Lies, No Manipulations

This sounds just too obvious, but stick with me for a moment. It can and will be difficult to resist softening some part of your discussion when it’s getting heated, just to get it off your back. This is especially true when someone close to you is involved, e.g., a friend, partner, or a colleague with years of working together.

So gather all the strength not to:

Skip any problems or facts, however difficult they are.
Downplay the importance (“Oh, but you know it’s not that big of a problem”).
Transfer blame.
End with a crap sandwich (“You have a problem X, but you’re doing a great job” — so does it mean it’s insignificant?).

The danger is that any of these tactics can send a completely opposite message than intended, especially in a multicultural environment where a language barrier may also be present.

Sticking to and stating only the blunt truth does not justify being disrespectful in any way. Even if someone has committed a very serious infraction, stay professional and respectful at all times.

On-The-Fly

Okay, I already hear you saying, “But most of these tips are about preparation, what if I’m caught by surprise?” Here are a few techniques I can suggest in such a case:

First, see if you can actually delay the conversation. If you get caught in a difficult conversation accidentally while walking down to get coffee, can you continue it once everybody’s back? Maybe it’s touching on a topic where more people should reasonably be involved? Is it really that urgent to address right here, right now? See if it’s possible to navigate it to a more controlled environment and timing, gaining those precious moments or hours for preparation.
There’s no shame in asking for time to prepare, especially if the topic requires looking into some data or artifacts. It’s absolutely no shame to be aware of our own recency bias and take an additional look at the data even when you’re sure you have a strong understanding of the problem. Does our team really ship more bugs than everyone else? Maybe it feels that way, but can we verify it?

However, the situation doesn’t always unfold or get controlled exactly as you want. So if you’re pressed to continue while still unprepared:

Make sure you shut up and listen. Treat it as a feedback-giving session, where you put on your detective hat and try to understand where this person is coming from. Even if it doesn’t seem true from your point of view, why do they think so? What exactly are the circumstances?
Follow up on the topics discussed later, once you’ve had a chance to process and think about them deeply. Even if you don’t change your initial response or opinion, rephrasing in your own words ensures you’re on the same page. More often, it will give a chance to make corrections to any agreements made in the heat of the moment.

Difficult Conversations (Part 1)

Fri, 22 Nov 2024 00:00:00 +0000

Many great books have been written about difficult conversations, but I’d like to revisit this topic with you, my readers. With a twist of my own experience, I hope you’ll leave with actionable advice to handle these conversations better — without needing to read a stack of books.

What’s Difficult About It?

First, let’s clarify what I mean by a “difficult conversation.” It’s any discussion where the stakes are high. Often, you’ll anticipate it, feeling your blood pressure rise beforehand. But sometimes, it sneaks up on you when a casual chat escalates, leaving you with a sweaty forehead and a racing mind.

6 Principles

Through my work with my engineering leadership team, I’ve developed six principles to prepare for and navigate difficult conversations. Some can even be applied on the fly if you’re caught off guard. More on that later.

#1. Preparation, Preparation, Preparation

If there’s only one takeaway from this post, let it be this: you can never be too prepared for a difficult conversation. Plan ahead:

What is your main message?
When and where will the conversation happen? Consider time, place, setting, and attendees.
How will you structure and present your key points?

Think through all the details in your control beforehand. This isn’t overthinking — it’s freeing mental space for the unexpected. By preparing thoroughly, you won’t need to stress over what’s already accounted for.

Difficult conversations aren’t public speaking, but similar advice applies: practice. Start alone — use a mirror or record yourself. For instance, while I’m confident in writing, the same sentences may sound awkward when spoken aloud. Identifying and adjusting these will boost your confidence immediately.

Next, practice with someone you trust — a mentor, manager, peer, friend, or spouse. The feedback is valuable, but even more so is the experience of voicing your thoughts to another person. It helps you anticipate both your emotions and possible reactions during the real conversation.

Finally, decide and write down your objective. Keep it in front of you. Is your goal to give feedback? Share news? Address behavior? Let someone go? Defining this will guide you when the conversation gets tough.

#2. Don’t Beat Around The Bush

Be clear and direct with your main message. This is harder than it seems, as it’s easy to dilute your point.

In The Culture Map, Erin Meyer highlights cultural differences in presenting decisions. While I advocate for following this advice in formal settings, for private, difficult conversations, lead with the “what.” People are sharp — they’ll sense where you’re headed and may stop listening while trying to guess your point. Breaking the news early avoids this.

Also, avoid softening your message to match the other person’s mood. Doing so risks muddling your point and causing confusion, especially in multicultural teams where English may be a second language.

Be concise and lay your cards on the table. You can elaborate or provide details if needed, but you’ll likely find that it’s less often required than expected.

#3. Stick to Facts

Rely on 100% accurate, indisputable facts. Prepare these thoroughly, ensuring clarity for everyone involved. Keep them at hand during the conversation.

Both parties need to agree on the facts, though they don’t have to agree on their interpretation. For example, if you’re addressing low performance, the fact might be that an engineer completed two tickets last month. This is provable. Whether that’s acceptable or not is open to discussion. Your decision may involve interpretation, but the supporting evidence must remain factual.

Avoid rumors, unclear data, or second-hand information — they’ll only complicate matters. When referencing feedback from others, tread carefully, as it often carries inherent bias. Only use such input if absolutely necessary, and ensure you’ve gathered as much context as possible.

#4. Prepare for Emotions

You can’t fully prepare for an emotional response unless you’re a machine — but you can brace yourself. Expect emotions to surface and allow space for them. Don’t rush; continue only when both parties are calm. If needed, take a break to let emotions settle.

You’re not immune, either. Even with preparation, the real moment can hit hard. And that’s okay. Pause if necessary. Sometimes, simple actions like grabbing coffee, opening a window, or stepping away briefly can help you regain composure.

If emotions overwhelm the discussion, it’s better to reschedule than push through without clarity.

Continue to the 2nd part.

Photo by Matt Hardy

Decaying Software

Fri, 07 Jun 2024 00:00:00 +0000

Software is not a physical object, so the concept of decomposition is quite unnatural to consider in such a context. However, this doesn’t mean there’s no decay over time.

How It Happens

Every engineer faces software decay once they try to work on a project that has been abandoned for longer than a year. In some cases, it’s just about getting the proper updates in, but more seriously, forgotten systems are sometimes easier just to bury and write anew.

Generally, the amount of “rot” gets more prominent because of two main reasons:

Getting outdated technically, or
Getting behind business-wise

Both happen naturally over time unless the organization is committed to paying at least some essential upkeep cost. However, both are equally dangerous in backfiring in the most unusual ways.

Organizational Debt

Getting behind business-wise is not only about missing this new department org that launched 2 years ago or missing convenience features and UX optimizations. It’s an increasing risk of failing to comply with various laws and regulations, potentially opening the doors for serious investigations nobody ever needs. GDPR and OFAC sanctions - to name a few, ignored for long enough, will give any business a lot of headaches. Especially if abandoned software is available publicly.

The biggest mistake here is the dangerous assumption that a snapshot of a valid state five years ago is as good as today.

Iceberg Technical Debt

Interestingly, the technical debt on such abandonware is usually considered more straightforward to fix if you need to revive the project. Sometimes, this is the case, but the highest risk appears with the iceberg effect and exposure to potential security attacks while all holes have been patched up.

The iceberg effect happens when the dependencies you need to upgrade are no longer backward-compatible, their API has completely changed, or they may not even be maintained anymore. The community might have just moved on to some better solution, so instead of a version bump, you get to rewrite parts with a completely new library.

Exposure to severe security holes is relatively self-explanatory. To add, nobody monitors abandonware as well, so you might not even be aware of the “stuff has been going on,” a technical issue is becoming a pretty severe legal accountability problem, especially if personal data was involved.

Avoidance

There’s only one way to avoid such headache-inducing abandonware: be absolutely brutal with your software. It has to be either adequately maintained or mercilessly taken down—it’s as simple as that.

But the challenge is that in today’s organizations of growth and revenue, nobody is getting a medal (or bonuses) for shutting down unnecessary systems. So, it must be codified into the product management lifecycle right from the beginning, and the accountable owner must be appointed from the inception of any piece of software the company runs. Leaving it to a “later stage to think about” is the highway to all the abovementioned problems.

If your organization is already facing these issues, make sure your communication about them is right to the ear of business owners, as it’s not a technical problem but an organizational one with very real consequences for the company.

Physical World Analogy

Running your own software is similar to owning a car. If you just park it for years, gasoline will break up, brakes will rust, the battery will die, and all kinds of other pleasantries will make the car unusable without more or less serious upkeep investment before it can be driven again.

However with the software, more accurate it would be to compare with a car that you keep using, but pay absolutely no attention to any maintenance needs whatsoever. So no oil changes, no tire changes, no brakes maintenance. For some time it’s going to be okay, but it’s just a matter of time until some accident happens.

Photo by gina christoforou

AI Developer?

Fri, 22 Mar 2024 00:00:00 +0000

There’s a lot of hype around these days about the new inevitable - the arrival of entirely independent AI developer. With a risk of this getting terribly outdated terribly fast – so please check the date of this post before reading – let me share a few thoughts on why I’m not holding my breath just yet.

The Promise

Industry has been looking for ways to replace expensive and “slow” software engineers with tools that never break, never get tired, don’t need time off, and never get sick—probably for the last decade already. With the rise of LLMs, this promise of such an independent system looks to be closer than ever.

The dream user journey for an AI developer should look like this:

You specify what you want to get built, e.g., “I want a mobile app, with registration and login, 5 screens: <..>.”
An AI developer, like an actual human, clarifies uncertainties with you, e.g., “Do you want to use a username or email to log in?”
You take a coffee break, and once you’re back - here’s your new $1B app ready to roll. It might need a few more iterations to adjust things where an AI developer, like an actual human, took the wrong direction, but in principle, it’s a rinse-and-repeat of the steps above.

The Doubt

Artificial intelligence models, or Machine Learning, or Neural Networks, have been around for a very long time already. Specialized models have become so good that they outperform humans in some tasks many times over. Some of those models are already participating, even if invisibly, in our daily lives in facial/fingerprint recognition, traffic control, threat assessment, etc.

However great those models get, some areas do not get AI-fied despite colossal amounts of effort. For example, self-driving cars. With incredible amounts of training data and the fact that humans are pretty bad drivers on average, it seems like a no-brainer with today’s technology. We have some limited applications, yes, but it’s nowhere close to a mass-spread adoption as everyone was expecting and dreaming about 10 years ago.

The Real World

I guess that the problem is… the real world. Our natural world, with complex humans around it and their interactions, is far less predictable than it might look. As with self-driving cars, is that object a cat or just a cat-like shadow on the ground? That pause a mortal human was making - is it a doubt about the requirements (clarification should be issued), or did they just get distracted because of a message on the phone? How do we explain aesthetics? Don’t even get me started with cultural differences so prominent in different parts of the world.

Existing Tools

We already have so many tools that should remove “developer” from some aspects of application development. Website builders got so incredibly powerful that, in theory, one should never bother building a new ones from scratch; should that be a news website, e-commerce, or just a representational site. Enterprise systems like BPMs have also been around for decades, where you should be able to re-adjust business processes on the fly without the touch of a single engineer. However, we still do so many things manually.

In Humans We Believe

AI developer should have been trained on such vast amounts of data, it should know pretty much everything software engineering has to offer. This sounds (and will be!) impressive, but it’s a limitation at the same time. It can repeat what has already been done more efficiently than a human many times over. But what if you’re trying to do something new? Trying to innovate, merge areas never merged before, and experiment with approaches that were considered anti-patterns a few years ago. How specific will you need to be to achieve that? Or is everyone going to be very happy with the similarly-looking apps and websites? Just because research data showed that a specific layout maximizes engagement, therefore it is likely only one layout, one type of design, one type of interactivity model is here to remain. (It seems like something of this kind is happening already without AI overlords anyway)

Humans understand loosely connected systems intrinsically. Cultular and real-life systems, too, can manipulate their experience of real life to know what they’re building, why, and how it will be used. Aspects of physical and psychological safety, interactions, heritage, and when it’s actually appropriate to cross some of those lines (well, not always) all with the ability to put this knowledge into use when we’re discussing requirements and solutions to it.

The Right Problem

And perhaps this is not even the right problem to solve? If a professional software engineer is writing code for 30-40% of their working time, it’s nearly incredible. The rest goes to getting and understanding requirements, reviewing, debugging, testing, deploying, refining, discussing. All those activities are not a waste - they would have been eliminated long ago if so. They’re all there to ensure the software that is getting created solves the problem it is supposed to solve. And more than what has been written down.

So, as long as somebody is ready to be so incredibly precise, ubiquitous, and descriptive with their requirements, an AI developer will work just fine.

But aren’t we all just writing precise enough instructions to the computer what to execute already?

Photo by Tara Winstead

Layoffs

Fri, 26 Jan 2024 00:00:00 +0000

2023 is behind us, but the waters in the IT industry are still wavy. January had quite a handful of announcements about reducing the workforce left and right. Truth be told, layoffs are probably one of those few could-be traumatic events for managers. Managers who fully invested themselves in the teams they need to reduce now. Everyone’s situation is certainly unique, but I’d like to share a few common principles on how to prepare and, at the end of the day, suffer less.

Objectives

Before going into the deep end, here is a reminder of the objectives of why organizations are doing layoffs. In most cases, it is:

Cost reduction. Across the board or in certain areas. Especially in the software industry, salaries are a significant portion of operational costs.
Restructuring. Eliminating redundancy, improving efficiency.
Change of strategy. Changes in the market, business goals, and growth projections require a change of strategy when the organizational structure has to adapt accordingly swiftly.

There might be many others, but keeping objectives in mind helps to make the most difficult decisions - who will be let go - a little bit less hectic.

That’s not enough, however. It’s necessary to sit down and think about the following angles as well.

Team Side

Business continuity is, of course, a hard requirement for any kind of change. Making sure you understand what’s going to be needed for the business going forward is the first step. With this information, one could start drawing a mental map:

Who in the team holds critical knowledge and cannot be replaced? (bus factor=1)
Who’s team’s enabler, the glue (loss of significantly more capacity than just this 1 person)
What’s the minimum level of operational coverage? Who has a track record of excelling in this?

Only then it’s worth considering the first obvious factor of who could be included in The List: performance. Too often companies ignore the items mentioned above and cut off key people with lower hard performance metrics. But those metrics are lower for reasons of training, enabling, participating in incidents, or other important but difficult-to-track work.

A good question to ask yourself is the following: what X (a number) engineers in your team absolutely could NOT be lost for the team to keep performing?

Personal Side

Another angle to consider is about personalities. Here, one has to start by admitting that a fully objective call is impossible. However, if somebody has had problems fitting into the team for a while already, the upcoming wave of stress is not going to make it better, if you catch my drift.

With the upcoming changes to the team, consider what the new structure will look like. It’s almost the same as thinking about a new team: they have to get along well, have a good mix of positive thinking, people who are challenging others, enablers, etc.

If you went through a lot with this team before, you also know who has better resiliency and will be able to recover faster as well.

Again, a good question for a self-check: would I form such a team completely from scratch?

Preparations

Layoffs are such an emotionally charged event, so just do not expect cold faces and indifference. People might and will get emotional; therefore, prepare yourself and choose a time and space for venting very carefully. Deal with hot-tempered with extra attention. Nobody needs to get fired because they got frustrated a bit too much at the wrong time with the wrong people.

You need to have the following plan ready and agreed with your peers:

Communication plan, with exact timing and message. Who informs exactly when and what’s the information to be shared?
Communication plan for the AFTER it happens. Here, it can vary based on teams and needs. E.g., a 1-hour Q&A with the team 2 hours after layoffs happen.
Ready Q&A materials. Prepare answers to the questions you can come up with yourself. They will certainly be asked. It will make your life so much easier, and help to restore at least a little bit of trust when your folks see you a bit more confident.

It’s a great idea to share all of this with your own leadership and peers (for alignment), but also to make sure nothing you’re doing and communicating has some unforeseen negative legal implications.

Decompression

However resilient you feel you are, you need to take care of yourself afterward. Lean on your peers, and find a way to let at least some emotions out and vent out.

Executing layoffs can probably be the most difficult thing you must do in your career. At least it was for me. However, remember: it’s not the end of the world.

Photo by Paula Schmidt

The Problem of Obvious

Mon, 13 Nov 2023 00:00:00 +0000

Why are they doing this? The best way to deal with it is so obvious! - did you ever think something along those lines? The chance is, the more experienced you are, the more often a similar phrase crosses your mind over the course of any day.

The Problem

Once, in a conversation with my peers, I used the term “bus factor” multiple times and noticed my colleague didn’t quite get what it references. I assumed that the “bus factor” idiom is so common in the industry that everyone knows it. It took just 20 seconds to clarify, as my colleague certainly did know the concept itself, they just didn’t know it’s also named in this particular way.

Another time, I was doing one of my favorite coaching sessions about difficult conversations. A manager I was coaching was senior and certainly did know the majority (if not all) of the main points of the topic. He still opted to hear and discuss it, and the feedback was along the lines of “it’s great to have knowledge shared systemically, while I did know those things, but thinking in this particular way was far from obvious.”

All of this made me think: am I considering too many things to be just too obvious, so I skip it? Use some expressions in a potentially cryptic way? Alienate some colleagues by staying silent when they need help or just a confirmation?

Inner Self

I find a character trait of often repeating yourself a little bit annoying. So I avoid that myself as much as possible, not to annoy others the same way. But the challenge with this is that our minds are not really great at remembering everything that was told to everybody. After several repetitions, it all starts blending, and the certainty this is something I have to explain slowly fades away. The doubt that I might be repeating myself increases. Little by little, I stop explaining and assume context is known for the entire group I work with. Unless I missed somebody. Oops.

The issue here is that our inner selves are pretty bad at registering occurrences and detecting echoes. It all feels way too familiar, way too fast.

Radiator

It must be a conscious choice to allow yourself to be repetitive sometimes. And take on the role of the intent radiator (a term used in The Staff Engineer’s Path by Tanya Reilly) to share your knowledge and context accumulated over your career. And, if people around are comfortable interrupting early with a nod they’re aware already, it starts to be really easy to jump right into the essence. If the communication structure is somewhat rigid, a good idea is to make this right to interrupt explicit.

Helpers

The typical helpers to organize this are notes and communication plans - as always! The latter can help tremendously in planning the right audience, timing, and order of the message that needs explaining. TODO list, in this case, is your superpower.

Going Extreme

The opposite danger, of course, is becoming the top leader of repetition. If notes are not taken and checked carefully, signals from peers are ignored, and the annoying cycle of repetitiveness takes over. It’s a fast way to become the least likable person, guaranteed :) So listen to the feedback carefully, and make sure to read the room at all times. Step up one abstraction level or fast-forward and see how that works.

Assumptions

The final thought on the problem of the obvious is that we sometimes don’t have the luxury of time. We sometimes have different teams around different sets of projects, and the landscape is usually changing fast. The usual way to deal with this pressure is to assume the knowledge level is similar and go with it. However, there’s nothing wrong with spending just a few minutes to very quickly check if anybody needs a hand with going-to-be-used terminology or concepts and only then launch forward. Those few minutes can save a lot of headaches due to misunderstandings later.

Photo by Vansh Sharma

Succession

Thu, 17 Aug 2023 00:00:00 +0000

So you are sailing along in your role successfully, projects are passing by with flying colors, and the team has its ups and downs, but overall doing great. Then your manager, on a regular 1-1, asks what about your succession plan? What? Is this a risk to your position? And why even bother?

Risks

First, it is a way to handle risks related to… you. Even when life and a job is going on extremely well, something substantial can still happen. How many times did you have a happy team member switch jobs just because they wanted to try something different? Or worse, they got sick at the worst possible moment. And a chance, even if temporary, to replace you with someone who has shown interest and received at least some training on the role can be life-saving in many circumstances.

So, in the same way you are trying to avoid a bus factor of 1 in your team, your manager is also trying to reduce risks related to their direct reports.

People Development

It’s also a great chance to kick off continuous development for those folks in the team who are considering a management career path. I’m emphasizing “considering” deliberately here: engineers often have the wrong impression of management roles and get bored in the 2nd chapter of the first management book. The same one you spent an all-nighter to finish because it was so good. I do not consider such cases a failure. The opposite - it’s a success identifying what role is not an excellent fit for someone. A lot of time and stress were saved, and unhappiness was avoided.

Developing your folks motivates them and challenges you simultaneously to find the best way to transfer knowledge. Even if the chance for promotion doesn’t appear fast, they will still be better engineers due to a better understanding your role.

Enablement

A solid succession plan is often an enablement plan for yourself. It allows you to use those once-in-a-lifetime, time-sensitive chances to get promoted, move to a project you’ve been dreaming about, or accept some interesting challenge outside of your team. In incredibly successful teams, the upper management is not too eager to pry successful managers off, as this step eventually can be considered counterproductive long term. Now it’s a very different game if you have good and prepared leadership talent to take your place. The trust everyone had in you will reflect on your successor because you trained them.

Protip: make sure you mention about those candidates and their development to people working with your team, “as a matter of fact.” This is called priming.

Seniority

Few things scream about seniority more than proactively developing a succession plan for yourself and keeping it up-to-date based on developments around you. It’s a win-win for everyone. So what you’re waiting for?

Photo by Picography

Time Management

Fri, 10 Mar 2023 00:00:00 +0000

In Lithuania, we have this proverb (rough translation): the deeper into the forest, the more trees. Well, it’s exactly this regarding the number of meetings once you start climbing the career ladder. It can get swamped and very overwhelming fast. So how to keep your head above the water?

Let me share with you today my way of operating through jam-packed days. Mind you, it works for me, but it doesn’t mean it’s the best fit to copy for your situation or personality. However, I hope you’ll find some things you’d want to try.

Calendar

You probably never used your calendar app to such extent before. Your life is pretty much calendar-driven now. Use this to your advantage! A common mistake is to schedule there only meetings with other people. In effect, another meeting request can appear at any point in your free time slot. So you either have to take it or spend time rescheduling to something more appropriate. Therefore I always add two more “types” of “meetings” to my calendar:

Breaks (I’ll expand on this below)
Focus time

In the manager’s schedule, focus time is a rarity, and it’s simply a low chance it will appear naturally. Therefore it’s now your own responsibility to block time for it. I use this technique for a known planned work (e.g., I need to work on some decision for 2 hours) and unknown (a bunch of yet-to-be collected TODOs) type.

So if you need more focus time, take control and schedule it back in your calendar.

Breaks

Many consecutive meetings situations are attention, energy, and brain killers. So it doesn’t matter if you do 5-10 minutes breaks between them because you’ll likely use them to process your notes and TODOs from previous conversations.

You must schedule reasonable breaks after several consecutive meetings to stay effective and attentive throughout the day. After how many - it depends on you and how difficult those conversations are (or might be). However, I wonder if you’re your best after staying focused for more than a few hours. Research also shows you need breaks.

The worst days for me are always the ones when for some reason, I cannot follow this rule. And even the next day, I always feel I have less energy. The toll is obvious. Skipping breaks is borrowing from tomorrow.

Follow the science - and schedule appropriate breaks.

Dealing With Interruptions

Now, I always receive many requests from my direct reports, teams, and partners during the day. Questions, check-ins, requests to review or confirm something, etc. I follow the following mental model to work with them:

Does it take less than 1-2 minutes to answer? (I know the answer from the top of my mind) –> Answer right away.
Otherwise, place this question to the TODO, and give back an estimate when you plan to look into it.

For the latter, I leverage Slack’s reminders for things I receive through it and my TODO notes for everything else. Using Slack inline has the advantage of keeping the exact pointer to the context and not switching tools to postpone the work.

When to work on them? I hope you still remember scheduling focus time advice at the beginning ;-)

Manage Your Time

I often hear: “I’d like to talk with you about topic X, but oh, I see you don’t have time for it.” It is a polite gesture from your peer. But it would be best if you always managed your time very actively and aggressively, using the classic quadrant of importance (a.k.a Eisenhower Matrix: important vs. urgent). Therefore, it doesn’t matter how busy your schedule is, you always have time for urgent and important things. Yes, items will have to get rescheduled, but this is the only way.

Additional note: I try not to touch regular 1-1’s as much as possible so people don’t feel they’re constantly less important. Therefore I try to schedule them on the parts of the day when the chance of something getting urgently important is relatively lower.

Take Back The Control

One can develop a feeling that the calendar purely drives your work (and maybe even personal) life. Waive that feeling away - you are the one controlling the calendar. Do it ruthlessly and systematically, prune things that don’t bring value out, and make space for breathing and doing tactical work.

And: make some time for thinking!

This is The Way.

Photo by Pixabay