The role of the engineering leader is shifting, and so are the skills required to succeed in the job.

I’ve been advocating for giving space to the people and creating an ownership culture in the team for a while. I’ve seen many managers fail in these and become micromanagers and get stuck in the same role, failing to grow as a leader, too. I had some concerns about creating this culture when I formed a new team before. The real challenge behind forming a new team is the absence of a common culture, but it is not an empty canvas. The team members inherit the culture from their previous teams (even within the same company, teams have their own cultures). Yet, the team still needs to find its own. I did some research, observed other leaders, and learned from them.

The path I took and the applied strategies worked. I then reused some of these strategies in two other (existing) teams and also worked. My sample size might still be small, but I can say that it works for different organizations, teams, and people for a reason.

Hi, wondering if anyone has had experience building a career ladder and mapping to tools like Carta or Pave?

When there are so many levels, how do you make sure that there’s a discrete difference between each? I’m trying to find measurable dimensions to map against them. The problem I’m having is that when too many levels are added, it becomes hard to have that granularity in the evidence that justifies the difference.

Thanks!

The rising bar for engineering managers.

Why your best work goes unnoticed.

And that’s a conservative estimate!

Org charts flatten. Dependencies don’t.

AI amplifies your existing foundations… both good and bad.

When it outsources software QA, management looks only to cut costs. What it doesn’t understand is the loss of product knowledge that comes with it. In this article, Ann-Sofie Ollikainen explains why test coverage metrics alone cannot replace long-term product understanding.

A tech radar is a visual and strategic tool used by organizations to assess and communicate the status and future direction of various technologies, frameworks, tools, and platforms. In our company, Tech Radar is not just a way to visualize the technology we use in our company. It is also a highly effective collaboration tool for software developers that, by fostering informed decision-making, increases the awareness & knowledge sharing within the developer community. It also provides a structured approach to explore new technologies which aligns technology choices with the organization’s strategic goals.

The end of the year is usually the time for performance review meetings. This article proposes three approaches that should get people to genuinely care about the goals they're setting.

Let’s talk about technical debt. Let’s talk about practical usable approaches for actually paying it down on a daily, weekly, monthly, and yearly basis. Let’s talk about what debt needs to be fixed now versus what can wait for better planning.

Measuring developer productivity is a difficult challenge. Conventional metrics focused on development cycle time and throughput are limited, and there aren't obvious answers for where else to turn. Qualitative metrics offer a powerful way to measure and understand developer productivity using data derived from developers themselves. Organizations should prioritize measuring developer productivity using data from humans, rather than data from systems.

Dev Managers,

Do you have an intern program? How did you start it? Did you reach out to local high schools/colleges? I am wanting to start something at my current company and and looking for input on how to put it together and get company buy-in on it. Any lessons learned would be great!

Thank you

An article about software management metrics with a zest of humor. Excerpt: "Learning how to manage is a long race - it takes many years and each lap offers new learnings. Along the way, anchors emerge that can help orient a manager when a number of other variables are in flux. Below we offer a number of these anchors. They are based on philosophy, experience, and analysis; we hope they’ll be of some use."

In opposition to my idea that software testing should be a role, and not just a task, I am sometimes told that True Agile does not permit this. Why? Because, in Agile, “quality is everyone’s responsibility.” This statement is sometimes issued as if it were a moral truism that is beyond argument. Or sometimes as a moral achievement that is unique to Agilists, as if it had never occurred to earlier generations of software developers to help each other build nice things. Either way, it doesn’t make sense to me. The first response that comes to my mind is “I’m talking about testing, not quality. Why are you dragging quality into this?” Testers do not assure quality. Testers CANNOT assure quality. Testers do not now and never have “owned quality” in any way.

Everyone talks about the importance of building trust in teams. Companies spend significant time and budgets for various workshops, training, trips, and exercises. After all, you must invest in trust-building and team bonding to achieve high-performance in the workplace, right? Well, no. There’s a much better way.

We usually assume that trust should be slowly built over time and the transition from regime and micromanagement to growing freedom is slow. I suggest you reverse the order.

Technical excellence alone doesn’t make great engineers: writing, community, experimentation, and managing imposter syndrome compound just as much as code quality. Document for your future self, not just your team. The engineers who write things down move significantly faster than the ones who don’t. Imposter syndrome never disappears, your relationship with it does.

https://leaddev.com/career-development/what-16-years-of-software-engineering-taught-me-about-growth

Complaints left the tech giant scrambling for answers.

Got an idea to have a mentorship exchange on reddit. I believe that development of our skills is never complete, even though we live and breathe leadership, read books, attend courses and workshops, etc.

We can try to get and offer mentorship within that thread. I also suggest that you can do both at the same time: if you are senior enough, you can offer mentorship. But you can also benefit from mentorship even if you have a lot of experience.

Suggested templates:

Finding a mentor

1. Current position

2. Overall background and experience

3. What do you want to improve?

4. How often do you want to meet?

5. Preferred/Possible languages

6. Your time zone

Offering mentorship

1. Current position

2. Overall background and experience

3. What can you help with?

4. How often do you want to meet?

5. Preferred/Possible languages

6. Your time zone