Resources

As you increase your seniority, part of your impact and performance often includes mentoring and developing others. Or perhaps you see a need to help develop your team, so you’ll find opportunities and needs to mentor other software developers.

Many of us have tried setting goals in the past. Perhaps it was a required exercise for school or work, or we wanted to see if it could help us accomplish something. Results were mixed, and we often left goals unfinished.

Across most industries this year, leaders in all functions are working through difficult prioritization and budget justification exercises. Spending that was previously approved with minimal scrutiny is now being put under the microscope by finance and procurement teams. Software engineering organizations aren’t exempt from these intense audits, but development teams still have products to ship and expectations to meet. Now they’re attempting to pull it off with more limited resources.

Software engineering org charts have never been more complex. Gone are the days of large, stable teams that report to a single leader and work in highly structured ways on long-term projects.

Open source developer portal project Backstage hasn’t been on the scene for long. But in that time it has gained popularity quickly. The rate at which it’s added stars on GitHub is telling.

Our business is growing. Fiscal Q1 is almost wrapped, and it’s been a doozy: after closing our Series A our revenue is growing quickly, and we’ve been able to bring on a ton of new awesome customers–like OpenTable, BigPanda, Fastly, Adobe, and more.

Kicking off a Kubernetes migration? Moving from cron jobs to a data orchestratror? Locking down your software supply chain? Or maybe all three? Whether paying down technical debt, upgrading a library version, or staying on top of security and compliance, engineering managers and directors have a lot to coordinate:

As a leader, onboarding with a new company is hard. The stakes are high–you and your new employer have invested a lot of time and energy into choosing each other–and the objective is complex–quickly go from an unknown outsider to a trusted leader. Oh, and make a positive impact on your team’s trajectory or output while you’re at it.

Downtime sucks (duh) - it means unhappy end users and engineers. Failures and error messages frustrate customers and interrupt engineers (or worse, wake them up).

Burnout can affect us all, and unless we watch for the causes and signs in our teams and organizations, we may not see it coming until it’s too late.

These days we all feel the pressure of shipping more frequently and keeping up with the demands of our customers.

We’re announcing a $15M Series A funding and OpsLevel’s vision for accelerating software teams with developer portals.

Software developers have been putting badges on their repositories for a long time. Since they’re easily recognizable and have high information density, badges make it simple for developers to signal (or understand) things like code quality, test status and coverage, version, framework, or adherence to various standards.

With services, proper reliability is critical to success. But many don’t fully understand what reliability entails. In this post, we’ll set you up for success with an essential guide to understanding and improving service reliability.

Microservices will change. This is inevitable. But how do you manage that change to ensure your consumers don’t feel unnecessary disruption? Alternatively, what best practices can you follow to make migrations easy?

All over the globe, teams are scrambling right now to triage the impact of the recently announced Log4j vulnerability on their services and applications. Rather than reinvent the wheel, here’s a snippet from an informative Cloudflare blog post that puts CVE-2021-44228 in context:

Applications, products, and systems have become more and more complex. Microservices, dependencies, and external services provide greater functionality and improved reliability.

A security vulnerability was published on December 12th, 2021 by the NIST for Log4J version 2.14.1 or earlier, dubbed CVE-2021-4422. OpsLevel does not use Java in its technology stack and is not affected by this security advisory.