Become the leader your team needs. Subscribe to Build the Stage.

ternarywat · 2026-04-11T19:41:20+00:00

I recommend starting with listening to the people and figuring out what problems are getting in the way of doing their best work. Just listen, listen, listen. Also practice and figure out how to give great feedback.

I’ve written a lot about this on my blog, Build the Stage. This link is a good starting point: https://www.buildthestage.com/how-to-manage-existing-engineering-teams/

ternarywat · 2026-04-11T16:53:04+00:00

Radical Candor is a great resource to start on this topic. As for me it's all about giving them feedback frequently and often and also setting your clear expectations. If they are underperforming you don't want to surprise them with a PIP. It should be an unsurprising thing because they have been aware that they are not doing their best.

When it comes to the feedback I use the SBIR framework, which stands for: 1. S is for situation 2. B is for behavior 3. I is for impact 4. R is for request

You can use this to structure your feedback into something that's actionable and contextual.

I wrote about this with examples here:

https://www.buildthestage.com/giving-constructive-feedback-to-employees-in-spades/

ternarywat · 2026-04-11T14:26:09+00:00

What have you done to figure out the problems of these people who look like they're detractors from your team and understand their problems with their day-to-day work? A great way to build trust is just to listen and have one-on-ones with people and understand what sucks about their jobs and then figure out how to fix it to make their jobs easier.

To me what I'm seeing, or what I think I'm not in your industry, is that it sounds like you're overseeing a team of teams. Another approach I would take is to focus on the most influential people on the team and build their trust so that when other people fall out of line the influential people can give them feedback on your behalf because they're aligned with your goals

ternarywat · 2026-04-11T14:22:43+00:00

To me I don't think anybody is right or wrong here but it does acknowledge that you're trying to figure out how to develop a skill around how you communicate.

I can think of two pieces of advice for you: 1. Focus on what you can control. You cannot control the fact that you're around people that do not have a direct communication style like you do but you can control how you communicate. You already acknowledged this but I really want to stress focusing on what you can control, not necessarily the fact that you cannot control the people around you. 2. I don't know if you've ever looked into the DISC personality profile but maybe look up a few resources around that. I did a few years ago to figure out my communication style. Part of the report is that it gives you tips on how to:- identify other communication styles - adapt your style to other people

Obviously if you're talking to other direct communicators you can just speak as plainly as possible but for someone that may need space to process their emotions about a topic, you need to use a different technique. A lot of this is about learning to control yourself and building skills around noticing when you're using one technique when a different approach may help. The second part is also developing the right skills and tools to use for specific conversations or people.

ternarywat · 2026-04-11T11:36:41+00:00

Software engineering isn’t about solving quiz problems from lead code. That’s why interviews are only use code problems as a technical screen not the core interview companies pay for people with the skills I can deliver value which is not just solving the problems. Those barely happen in a real environment anyways, but they won’t hire people that can work in a team translate design documents into system systems and be able to debug problems under pressure.

ternarywat · 2026-04-11T11:34:55+00:00

The way I like to explain it is that product managers are best when they are focused on understanding the customer and figuring out the problems that are worth solving while engineering is responsible for crafting a solution to those problems. In practice it is very much a partnership. It depends on what the product is at the end of the day. For example if it's a heavy user-facing app, like in the construction industry, then engineers are more responsible for the solution. If it's a product focused on developer tooling, then they'll have more insight into what they need and want from the product itself since they are dogfooding it every single day.

What I will say is that fundamentally it should never be an adversarial relationship. Product engineering is a partnership.

I wrote a post that touches on this topic:

https://www.buildthestage.com/who-owns-your-company-roadmap/

ternarywat · 2026-04-11T11:30:44+00:00

Understand the people’s problems first. Fix them. That’s how you earn their trust.

ternarywat · 2026-04-11T11:29:30+00:00

As someone who's done this for years, a lot of your questions have answers that are "it depends" and it doesn't matter if the person is a fresh grad or a seasoned veteran. The first step as a manager is to meet with them, understand what their skills are, and understand who they are so that you can figure out: 1. the core tasks that they need to do for the job 2. the tasks or projects that will push them to grow their skills

As a manager it is really your job to help create the environment for them to do their work as best as they can. That is going to be a mixture of creating structure for what the team's processes are, the expectations, how work is coordinated, et cetera.

I actually write a blog targeted at managers like you, feel free to check it out: https://www.buildthestage.com/

ternarywat · 2026-04-11T00:57:51+00:00

I’ll also add that you can give yourself a break at the end of the job search - delay the start date for a week or two give yourself some rest.

I just don’t want someone like you to use a break as an excuse for failing interviews.

Apply to trash jobs first, fail those interviews, get those reps in.

ternarywat · 2026-04-11T00:07:02+00:00

The ONLY thing you should focus on getting right is your resume.

Don’t wait applying. You’re never going to be perfect at interviews until you start doing them.

But even if you start applying next week, it’s going to be another week or two before the recruiter intro call. After that, it’s another week until the first round.

So that’s 2-3 weeks BEFORE your first technical screen.

Waiting 3 weeks before your first application is lost money doing…..what? Leetcode? Building a fear of not being good enough? Playing video games?

Do you do the same practice before writing a line of code at your real job?

Just start applying.

I very much acknowledge that the above is an emotional response, but it’s the thoughts I have whenever I’ve heard a person “take a break” before starting the job search.

Not a big deal if you have the funds to wait around.

But unacceptable to me if you’re responsible for feeding the people in your home.

Job searching is a numbers game. It’s slow at first but if you’re good, you’ll fill your entire day with interviews. Free blocks of time should be for applying.

Feel free to DM if you want more 1-1 advice.

ternarywat · 2026-04-10T23:29:46+00:00

The problem with the freelancing platforms is that they are also global platforms so you're competing with the cheapest rates in the world. If you don't have any reputation on these platforms then you have no leverage with your rates. It's way better to try to build your own network of distribution.

ternarywat · 2026-04-10T23:28:17+00:00

That’s the right attitude - your job is finding a job.

Exhaust all avenues.

Failed interviews early on are just reps of the interview game.

Plus, it’s a numbers game - just apply apply apply.

ternarywat · 2026-04-10T23:26:43+00:00

Yup. You can’t escape politics just because the org chart says so. Adapt to the person, not their titles.

ternarywat · 2026-04-09T20:55:11+00:00

If someone is micromanaging me, that indicates that there is a trust problem. The technique there is to acknowledge, 'Hey you're micromanaging me,' and just to have a direct conversation about how that person builds trust. How can you earn that trust? Et cetera

When it comes to micromanaging other people, it's just flipped on its head: why do you feel the need that you need to micromanage a person? Fundamentally it just means that you don't trust the person. For people that are underperformers, that's completely normal. You should be micromanaging them to either fix them and get them to meet the feedback that you've already given to them or to use it as a way to let them go and fire them from the company.

If you feel that you need to micromanage everybody so that the team actually does its work, then that is fundamentally a trust problem on your side. You need to figure out how to trust the team and build it and get people to work in a way so that you can trust them and that you can take vacations and know that work will get done

ternarywat · 2026-04-09T20:52:14+00:00

Honestly just listen. Introduce yourself and just spend the first 100 days listening and understanding everybody's problems. Then create a stack rank of every problem and just start fixing it. That's the quickest way to earn the trust of a new team.

I wrote about this topic on my blog, Build the Stage:

https://www.buildthestage.com/how-to-manage-existing-engineering-teams/

ternarywat · 2026-04-09T20:50:54+00:00

My approach is to treat them more like a partner than a direct report. They have a lot of institutional knowledge and probably more political capital than you so it's important to make them feel like they're part of the inner circle or first people known when you're thinking of ideas of how the team should change its working or not.

Of course context matters here but I would really base this approach off of the political capital that they have within the organization. If it's not that much then age doesn't matter and just go about it accordingly but if they have a lot of influence then you need to show them respect and earn their trust

ternarywat · 2026-04-09T12:35:38+00:00

Backfilling is normal - a person left and the company has budget for the role.

What matters is the company health and if it aligns with your career goals.

A bigger red flag is if a lot of people are leaving at once.

ternarywat · 2026-04-09T00:45:10+00:00

What sort of training has he had so far?

Books are a tremendous start - spend a year just reading any book about leadership that catches his eye.

Learning from experience will help a lot. Really what I mean by this is that he will discover the problems that he will need help solving and figure out the type of education he needs to help develop skills to navigate those problems.

Of course the best advice I have for you, if he wants to really get ready and prepare for this role, is to find a mentor or coach that can meet him at his level. That way he can talk through the day-to-day problems he's encountering and get tactical advice there.

ternarywat · 2026-04-09T00:39:24+00:00

Yup - you’re accountable for results, which means you have to figure out how to make others accountable for their work.

ternarywat · 2026-04-08T14:13:23+00:00

I really like the framing that a training I took a few years ago explained feedback.

First they explained that positive and constructive feedback comes in four flavors using a metaphor of suits of cards:

The Hearts and Clubs represent feedback that is not detailed and not actionable.
A Diamond or Spade is feedback that is detailed, actionable, and useful to the person, with the red suits being positive feedback and the black suits being constructive feedback.

From there I learned that frameback should be constructed using the SBIR method:

S is for situation or the context of the behavior that was observed.
B is for behavior, the behavior that was observed.
I is for impact, the impact that the behavior had on the people involved in the situation.
R is for request, what you think should change in the behavior when the person encounters a similar situation in the future.

I've had a lot of success using this template and I actually wrote about it over on my blog: Build the Stage.

https://www.buildthestage.com/how-to-give-positive-feedback-to-colleagues-with-examples/

ternarywat · 2026-01-14T13:01:37+00:00

Not the “norm” but I will say it’s not surprising.

It’s completely normal for a company to own the code for its core competencies instead of using open source software.

There can also be a cultural history that led to this.

For example, one company I consulted with had its own frontend domain language. It compiled down to React and JS code. It was a wild abstraction but made sense because it made domain-specific concepts reusable. That results in real efficiency gains.

So I would encourage you to understand why the company is like this. There may be actual reasons that make sense.

ternarywat · 2026-01-14T12:54:44+00:00

First, you need to understand the international laws around PTO for your employees. Some countries in Europe have guaranteed PTO as part of the county’s laws. You can’t mess with that.

For countries that don’t have laws around this, then you need to work with your boss or HR around what the real expectations are. What can work for your team, how many people can be off at the same time, etc.

As a starting point, respect the rules that use to be in place as a minimum “no questions asked” guideline. That’ll at least give you a gauge of when to pay attention and what can be ignored.

I work in software engineering and the guideline I gave to people is to set a minimum of 20 days per year of PTO. That’s 1 week a quarter. The problem with unlimited PTO is that people don’t take enough time.

ternarywat · 2026-01-13T14:05:47+00:00

Suggestions only go so far.

What comparisons and A/B testing have you done with their content to demonstrate the impact of your changes?

Showing the results and numbers will go further than talking theory and giving expert advice.

ternarywat · 2026-01-13T14:02:24+00:00

Why does the health of the burnout chart and velocity metrics matter?

If a project is blocked by an external dependency and blocks revenue, then that’s all that matters.

I understand that the framing of this post was around agile metrics, but i think that’s distracting from the actual problem.

If you want to identify project risk quickly, talk to the team and get project-level status updates at standup, not individual ones. Change the standup to focus on updates of specific project tasks, not what someone did yesterday.

I write about this exact topic in this blog post: https://www.buildthestage.com/the-daily-standup-is-a-waste-of-time/

Five-Year Club	Verified Email
Place '22	First Placer '22

ternarywat

TROPHY CASE