“The future is still so much bigger than the past.”

- Tim Berners-Lee, Inventor of the World Wide Web

For platform engineers, the future is bright. Commonly thought of as the next stage beyond devops, platform engineers are one of the most in-demand and well-regarded positions in tech.While there is a huge upside to being on the cutting edge of an industry, there is one major, potential drawback: A lack of tried and true wisdom you can apply to the role.

With the platform-engineering playbook still being written every day, I wanted to chip in with the best insights on being a successful leader and platform engineer I’ve heard from the best minds in our industry.

The Wisdom: Success is when engineers don’t notice your work

The expert: Kathryn Koehler, Director, Developer Productivity Engineering @ Netflix

There’s no better measure of success for platform engineers than to have the developers they support free from being blocked, stuck or disrupted. This is especially true when you’re building a fast-moving engineering juggernaut at Netflix, like Kathryn Koehler.

According to Kathryn, when your work goes unnoticed, it signifies a seamless, smooth development experience. This allows developers to concentrate on building applications and features, accelerating the development cycle and delivering high-quality software.

Ultimately, the goal of platform engineers is to create a stable and reliable platform that operates silently, enabling developers to excel in their work without unnecessary disruptions.

The Wisdom: Eliminate the most common sources of toil, like testing

The expert: Kaspar von Grünberg, Humanitec’s founder and CEO

Eliminating the most common sources of toil, such as testing, is crucial for platform engineers.

This wisdom comes from one of the top leaders in platform engineering, Humanitec’s founder and CEO Kaspar von Grünberg. Kasper rightly points out that by automating and streamlining testing processes, engineers free up valuable time and resources to focus on more impactful tasks.

Removing manual, repetitive testing work not only increases productivity but also reduces the risk of human error while making developers happier they don’t have to wase their time. In the end, it allows engineers to allocate their expertise and creativity towards innovation, problem-solving, and improving the overall efficiency of the platform.

The Wisdom: Focus on making your team complete with diverse skill sets

The expert: Charity Majors, CTO of Honeycomb.io

Charity Majors’ charisma is just one reason she’s a great leader. The other? She knows how to build complete, diverse and complementary teams.

Firstly, diverse skill sets bring a variety of perspectives, experiences, and expertise to the table, enhancing problem-solving and innovation capabilities.

Different backgrounds and skill sets enable the team to approach challenges from multiple angles, leading to more comprehensive solutions.

Additionally, diverse teams foster a culture of learning, collaboration, and mutual growth, as team members can learn from each other’s unique skills and knowledge.

A diverse team also ensures resilience, as it can adapt to changing requirements and tackle a wide range of tasks efficiently.

The Wisdom: Keep the whole engineering org regularly updated on what the platform team is thinking about

The expert: Ambassador Labs’ Katie Wilde

Keeping the entire engineering organization regularly updated on the platform team’s thoughts is essential — it fosters transparency, alignment, and collaboration across teams, ensuring that everyone is on the same page regarding platform developments and strategies.

It can be as simple as what Katie Wilde suggests: Making a blog or short video about what she’s thinking about. She sends it off to her team and those small updates let the entire org know what a crucial member of their department is thinking about.

These regular updates promote a shared understanding of the platform’s direction, goals, and challenges, encouraging input and feedback from different perspectives.

It enables other engineering teams to anticipate changes, plan their work accordingly, and leverage the platform effectively.

The Wisdom: Automate pull requests & code reviews

The experts: Dan Lines and Ori Keren, Co-founders of LinearB

There’s probably no easier win for platform engineers than helping fix the №1 undiagnosed problem in software development: Massive bottlenecks in pull requests and code reviews.

In helping engineering orgs get visibility into developer workflows with LinearB, Dan Lines and Ori Keren discovered that the majority of cycle time was being spent in pull request and code review. They found that:

• The average cycle time for a piece of work was 7 days
• Half of all PRs were idle for 50% of their lifespan
• Cycle time doubled when pull requests went from 100 lines of code to 200 lines of code

The solution for this came in the form of gitStream, a tool that solved a host of issues keeping pull requests from being effectively picked up, including auto-assigning the best reviewer, adding estimated time to review, limiting PR size, segmenting PRs based on risk and more.

The Wisdom: Have regular meetings with devs on what their problems are

The expert: Kelly Vaughn, Director of Engineering @ Spot AI

Kelly Vaughn’s unique background makes her wisdom even more relevant. As a trained-therapist-turned-engineer, Kelly has a simple-but-impactful way to become the platform engineer your company needs: Find out the problems you should be solving based on unearthing the problems devs are actually having.

These conversations provide an opportunity for platform engineers to understand the specific pain points faced by developers and gain insights into their needs and challenges. By actively listening to developers, platform engineers can identify areas where the platform can be improved, optimized, or customized to better support development workflows.

This direct feedback loop fosters a collaborative environment where solutions can be brainstormed, prioritized, and implemented efficiently. By addressing developers’ problems proactively, platform engineers can enhance developer productivity, streamline processes, and create a platform that truly meets the needs of the entire engineering team

Proven strategies for being a great platform engineer

When an industry changes as fast as ours, advice can be obsolete by the time it gets written down. That’s why it’s important to tap into the real-time wisdom of people whose opinions you respect and careers you admire.

If you enjoyed these takeaways and would like to hear more interviews with platform engineers, founders and tech leaders, consider subscribing to the Dev Interrupted podcast. New episodes drop each week wherever you listen to podcasts.

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

gitStream is the free dev tool from LinearB that eliminates the №1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

Originally published at https://devinterrupted.com on July 30, 2023.

6 Proven Strategies For Being A Great Platform Engineer was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

On this week’s episode of Dev Interrupted, co-host Conor Bronsdon and Ben Lloyd Pearson, LinearB’s Director of Developer Relations, detail the evolution of Continuous Merge and the tool behind it, gitStream. Joining the conversation is Nik LeBlanc, VP of Engineering at DevCycle.

Nik shares the ways his team is using gitStream to streamline code reviews and offers practical advice for anyone looking to implement the tool on their own team. He also explores the somewhat controversial practice of splitting up and reshuffling engineering teams, a strategy that DevCycle has used to great effect. Nik finds that this practice helps balance teams, manage diverse knowledge bases, and de-risk the organization.

Conor and Ben wrap up the conversation by casting an eye on the future, focusing on the potential and direction of gitStream.

Episode Highlights:

• (2:50) Splitting and reorganizing dev teams
• (9:20) How DevCycle is leveraging tooling to enable positive change
• (14:50) Why teams are paying “a lot more attention” to PRs
• (17:00) Nik’s thoughts on DORA and shipping
• (21:20) Threads & socials to follow
• (23:35) Ben & Conor breakdown their convo with Nik
• (27:30) Applying estimated time to review to PRs
• (31:30) gitStream integrations
• (32:30) The future of gitStream

Read the full episode transcript here

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

gitStream is the free dev tool from LinearB that eliminates the №1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

Originally published at https://devinterrupted.com.

Labs: The Evolution of Continuous Merge was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

On this week’s episode of Dev Interrupted, co-host Conor Bronsdon welcomes Francisco Trindade, Director of Engineering at Braze, to discuss strategies to improve collaboration and effectiveness within engineering teams.

Francisco notes a shift in the tech industry over the past decade from focusing on rapid hiring and individual growth to a need for more effective team dynamics. Criticizing the tech industry’s aversion to micromanagement, he argues that it has inadvertently resulted in a lack of focus on team effectiveness and proposes a renewed emphasis on fostering productive environments for engineers to fully realize their potential.

Episode Highlights:

• (2:20) Managers can’t be micromanagers
• (4:40) Francisco’s three key aspects to improving team effectiveness
• (11:15) Creating the right incentives for your team
• (14:00) How to work with teams around the world
• (21:15) Increasing engineering team efficiency
• (27:30) What is Braze?

Read the full episode transcript here

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

gitStream is the free dev tool from LinearB that eliminates the №1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

Originally published at https://devinterrupted.com.

Have Engineering Leaders Become Too Hands-off? was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amid the escalating buzz surrounding AI tools, many development teams grapple with deciding which ones suit their needs best, when to adopt them, and the potential risks of not doing so. As AI continues to pose more questions than answers, the fear of falling behind the competition lurks for many.

This week’s episode of Dev Interrupted aims to dispel these uncertainties by welcoming CodiumAI’s founder & CEO, Itamar Friedman. In one of our most illuminating discussions this year, Itamar pierces through the AI hype, explaining what AI tools bring to the table, how to discern the ones that would truly augment your dev teams, and the strategies to efficiently identify and experiment with new tools.

Beyond the allure of AI, Itamar doesn’t shy away from addressing its pitfalls and adversarial risks. He also probes into the future of the developer’s role in an increasingly AI-driven landscape, answering the question: “Will there be developers in 10 years?”

Episode Highlights:

• (2:40) Founding CodiumAI
• (8:25) Will there be developers in 10 years?
• (11:20) What kinds of AI tools are popping up?
• (15:00) Core capabilities of AI
• (19:30) Finding AI tools to solve pains you don’t know you have
• (23:00) Enabling your team to use AI
• (26:45) Falling behind the competition
• (33:00) Pitfalls of AI
• (38:30) Adversarial risks of AI
• (43:45) Experimenting with new tools
• (47:40) Measuring the success of AI tools
• (50:15) Will AI replace or empower us?

Read the full episode transcript here.

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

gitStream is the free dev tool from LinearB that eliminates the №1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

Originally published at https://devinterrupted.com.

AI Tooling For Your Dev Team: To Adopt or Not to Adopt? was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

Does the emergence of feature flags affect the interpretation and utility of DORA metrics?

On this week’s episode of Dev Interrupted, host Dan Lines and Ariel Perez, VP of Engineering at Split.io, discuss the state of DORA metrics and whether they need reimaging in a world of feature flags. Listen as Ariel explains why he believes feature flags are more than a tool, and have begun to reshape our understanding of software development and the metrics we use to measure it.

Dan and Ariel also touch on how feature flags can drastically reduce lead time and mean time to recover, and conclude their chat with an intriguing look at the granular nature of control in the modern software engineering landscape, where the unit of control has shifted from the application as a whole to individual features.

Episode Highlights:

• (2:05) Introduction
• (7:15) Pursuing productivity at the expense of effectiveness
• (15:50) Project allocation discussion
• (24:55) Reimagining DORA metrics
• (31:30) Radical ideas for DORA
• (41:25) How teams should invest in shipping faster

Read the full episode transcript here.

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com.

Reimagining DORA Metrics & Leveraging Feature Flags with Split was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this week’s episode of Dev Interrupted, we’re focusing on the increasingly valuable role of DevRels. Francesco Ciulla, Developer Advocate at the open-source daily.dev community — which has more than 100,000 daily active users — joins us for a DevRel deep dive.

Listen as Francesco explains how a career change in his thirties set him on a path towards becoming a developer, being hired by the European Space Agency and, eventually, landing a role as a developer advocate, crediting much of his success on his ability to leverage social media to advance his career.

Outside of his personal story, Francesco shares his thoughts on connecting with devs, why YouTube is such a powerful platform and settles the debate on the kind of content developers are most interested in.

Episode Highlights:

• (0:00) Accelerate State of DevOps survey
• (3:05) Francesco’s career change to programming
• (10:15) How to leverage social media
• (16:10) Best ways to connect with devs as a DevRel
• (22:28) Challenges of being a DevRel
• (25:42) What platforms should DevRels be using?
• (30:07) Community building on YouTube
• (33:12) Technical vs non-technical content

Read the full episode transcript here

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com.

The Art of Landing a DevRel Role with daily.dev was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

Chaos Engineering might sound like a buzzword — but take it from someone who used to joke his job title was Chief Chaos Engineer (more on that later) it is much more than buzz or a passing fad — it’s a practice.

The world can be a scary place and more and more companies are beginning to turn to Chaos Engineering to proactively poke and prod their systems and in doing so are improving their reliability and guarding against unexpected failures in production and unplanned downtime.

During my career I dealt with my fair share of outages, including one that caught me mid-song during a bout of karaoke and far too many that woke me up at 02:00. As the co-founder and CTO at Gremlin , I do my best to make sure no other engineers have to suffer sleepless nights worrying about their product.

But the question remains, what is Chaos Engineering and where did it come from?

A Short History

The spiritual predecessor to Chaos Engineering is often called by a much more widely recognized name — disaster recovery. The focus when this practice was introduced is much the same as today: proactively suss out production problems by injecting failure.

Netflix ‘s Chaos Monkey is probably the most well publicized Chaos Engineering tool as it arguably kickstarted the adoption of Chaos Engineering outside of large companies, but this has led to the erroneous belief that Netflix invented the practice. In fact, the practice was already widely in use amongst the titans of technology.

Over a decade ago during my time as a Lead Software Engineer at Amazon, we implemented several crude practices designed to inject failure into our systems. The most rudimentary of which was employed by a man called Jesse Robbins, who earned the nickname “Master of Disaster” by running through data centers pulling out cables.

Let’s just say the practice has evolved a lot since those early days and your data center cables are much safer these days.

What is Chaos Engineering?

“What Chaos Engineering really is, is the art, if you want to call it that, of introducing controlled chaos.” — 2:16 on the Dev Interrupted podcast

At its core, Chaos Engineering is a disciplined approach of identifying potential failures before they have an opportunity to become customer facing outages.

It is a practice that lets you safely test your assumption about how your systems will behave under duress by actually exercising resilient mechanisms in a controlled fashion. You literally “ break things on purpose “ to validate and build resiliency. T he end goal of Chaos Engineering is not to inject arbitrary failure into a system, but rather to strategically inject turbulence to enhance the stability and resiliency of your systems.

How Chaotic is Chaos Engineering?

I always tell people that Chaos Engineering is a bit of a misnomer because it’s actually as far from chaotic as you can get. When performed correctly everything is in control of the operator. That mentality is the reason our core product principles at Gremlin are: safety, simplicity and security. True chaos can be daunting and can cause harm. But controlled chaos fosters confidence in the resilience of systems and allows for operators to sleep a little easier knowing they’ve tested their assumptions. After all, the laws of entropy guarantee the world will consistently keep throwing randomness at you and your systems. You shouldn’t have to help with that.

How do I Start?

One of the most common questions I receive is: “I want to get started with Chaos Engineering, where do I begin?” There is no one size fits all answer unfortunately. You could start by validating your observability tooling, ensuring auto-scaling works, testing failover conditions, or one of a myriad of other use cases. The one thing that does apply across all of these use cases is start slow, but do not be slow to start.

What I mean by this is to start testing across just a few nodes versus impacting your entire fleet. We refer to the impacted area as the “blast radius” and we highly recommend starting with a small blast radius (the number of systems impacted) and increasing it over time.

By starting small you allow yourself to gain confidence in both the experiments you are running and your systems. Of course your risk tolerance is also a factor of how large a blast radius your organization will use.

For instance, a large banking institution with millions of customers has a much lower risk tolerance than a tech startup with a couple hundred customers. In that case, they would want to run experiments in a programmatic way and would need to be very explicit about communicating to the rest of the organization what tests are going to be run and when to avoid any unplanned 2am or 3am disasters.

Eventually you want to get to the point where all of this is automated, a process we refer to as “continuous chaos.” Starting small with automation could be something as simple as taking out a single node; then taking out five nodes; then ten; and so on. Eventually you automate the process at a level you are comfortable with.

“Ultimately you want to be able to handle any of this random chaos being thrown at you, because that’s what the world is, it’s entropy, it’s degradation” — 7:35 on the Dev Interrupted podcast

No Tolerance for Downtime

When I founded Gremlin, it was just myself and my co-founder developing the first iteration of the product. The business looked very different then and I jokingly referred to myself as the “Chief Chaos Engineer” responsible for implementing code that was mostly used by enterprise companies. Many of these companies came to us because they had reliance thrust upon them by the US government or they had top-down reliability standards and they wanted a tool to help them shore up their systems.

As the company began to evolve, so did the customer base. These days it’s not just Fortune 500 companies that care about reliability, it’s everybody. Planned downtime is a relic of days gone by. It is no longer acceptable to espouse planned maintenance windows as part of development lifecycles and customers don’t have the patience for products they rely upon to spend any time unavailable. Companies recognize this dynamic — and it’s not a hard one to miss.

Seemingly our appetite for technology has gone up exponentially while our ability to stomach downtime has drastically decreased. Customers expect that your product is always working, always running. If your product is down because of outages then there are ten other similar products waiting in the wings to take their money.

Making Lives Better

Visibility is high these days and companies don’t need the publicity that comes with making any unforced errors, let alone to be subject to errors not of their making. No one wants to be blown up on Twitter because their product isn’t working or because one of their downstream dependencies or their cloud provider had an unexpected outage.

By preparing for the worst, we can be at our best as an industry and can be prepared when disaster eventually comes knocking. That’s why when an unexpected outage occurs or there is a production failure customers will never even know it happened.

I often joke that we are the engineers’ engineers because many of us know that feeling of being jolted from a dream at 03:00 by our pagers, groggily wiping our eyes and whipping out the laptop to go dig through a sea of monitoring dashboards and logs. It’s not fun and it’s exactly why I founded Gremlin. Because there is a better way to approach operations than merely sitting back on our haunches and waiting for the next outage. Chaos Engineering not only helps to protect against the randomness of the world, but also teaches people how to build more reliable software. And if enough people build more reliable software, we build a more reliable internet.

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com on January 4, 2022.

Chaos Engineering — The Practice Behind Controlling Chaos was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fact: You can’t become better at anything unless you understand what getting better would actually look like. This is especially true in the case of engineering teams.

Following the analysis of 2,000 dev teams and over 4 million code branches, the 2023 Engineering Benchmarks report is out.

To walk us through the performance metrics of the top 10% of engineering teams, LinearB’s Head of Developer Relations Ben Lloyd Pearson makes his first Dev Interrupted appearance.

From how long elite teams take to complete code tasks to the size of their pull requests, this is a great episode to understand where your dev team stands and where they have concrete room to improve.

Episode Highlights:

• (0:00) Accelerate State of DevOps survey
• (2:15) Introductions
• (7:38) Research behind the engineering benchmarks
• (11:23) Delivery lifecycle metrics
• (14:51) PR automation tooling
• (18:32) Elite developer workflow metrics
• (25:40) State of business alignment metrics
• (34:19) Predictability and planning accuracy

Episode transcript here.

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com.

LB Labs: Inside the Top 10% of Engineering Orgs was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

Putting employees and your community first should be a crucial priority for every organization, and it shouldn’t exist only in principle — it must exist as an actionable goal. Fostering a community within your team creates a foundation for high-performance, but it only works if you lead people-first.

At Stack Overflow, the level of collaboration between engineers is a step above any other organization I have seen. It takes conscious effort on the part of leadership to foster a work environment that puts employees first. Managers should choose to put people first, because it’s the right thing to do, not just a vague claim to a cliche.

Thankfully, we live in a world where the data demonstrates that caring for people first is also the economic thing to do. No one has ever done a better job because they were scared, stressed, or worried about their future; especially in jobs centered around creativity and problem solving such as software development.

This commitment to people is the leadership philosophy behind Stack and helps guide our decision-making and our workplace culture. It also helped us to create Collectives™ on Stack Overflow. To get there, we needed a successful engineering team and culture — here’s how we built it.

Indicators of team health

Common metrics that organizations tend to follow are often a symptom of a team’s performance, but not necessarily the whole story. Velocity, predictability, bug rate, etc should be viewed as an indicator of team health, not as a goal to be achieved; sometimes the best indicators to follow are subjective, and relative to the people and teams.

After all, what does success look like? If people are getting what they need, agreed upon expectations are being met, and team morale is high, that’s real success. If this kind of people-driven success is occurring, you’ll start to notice that things like velocity time and predictability will naturally improve and not the other way around.

For the record, predictability should never be the goal. The end goal should always be to create value for your customers and/or your community. Any team — or manager for that matter — can make predictability look good if they are making sure that they never fail a given estimate on paper, but that’s not an indicator of good product creation.

If you’re actually producing value, and you have a well run team, predictability will follow. It’s a side effect, a symptom of good team health.

Servant Leadership

At Stack Overflow, we’ve had long talks about what metrics we feel provide valuable feedback and those we believe are valuable to track. Numbers are important and should not be ignored, but again, they should not be the standalone goal. Tracking the right metrics should facilitate introspection for your organization and leaders would do well to keep this in mind. If we have a bad sprint, it tends to trigger us to think, “what went wrong?” and “how can we improve this for next time?” instead of thinking this was a failure of certain individuals.

For instance, if you had a sprint where you achieved a really high velocity, you should celebrate that success. But at the same time, you should be asking yourself what led to that success. Was there a behavior that changed? Not everything is internal. Sometimes external factors, a pandemic as an apropos example, influence successful team metrics just as much as internal ones do. Remember to look behind the metrics to see what’s impacting team members .

As far as following specific methodologies is concerned, try not to get hung up on the little things; analysis paralysis occurs is often a huge drain on performance and focus of the team. Time spent sitting around and arguing about whether something is a three point or a four point story is not productive. Call it a four and keep moving. Good leaders should keep their developers developing, while removing any hindrances to their performance, ideally before it is even on their radar.

Building a team and your product

If you’ve been around software development long enough, I’m sure you’ve had the experience of joining an organization where everything is dictated in a top-down approach. This kind of “my way or the highway” thinking ultimately undermines your teams and makes your organization rigid in an industry that is far more creative than some like to admit.

A good manager will do their best to accommodate their teams, even if that means allowing a team to communicate or operate in a way that is not established within an organization. Recently, one of my most productive teams started to struggle after the project we were working on started to shift. A lot of the QA and code review work associated with the stories became large and unwieldy and the common practice was to have that wrapped in with the dev story. That makes sense after all, the former can’t ship without the later. Eventually we just tried separating out the more cumbersome tasks into their own stories. The immediate and biggest reaction was from folks overly invested in the metrics: we just doubled our stories and made it appear that story cycle time virtually doubled. The instinct was to say “this is a step backward. Undo it all,” but that would be ignoring what’s going on behind the metrics: more work was getting done, and the bug count dropped. As those were saying we need to go back because the metrics showed team health was bad, my response was to just change the metrics to accurately reflect our healthier team that chose their own workflow. Adopting this mindset as a manager provides huge returns for your organization. People are happier when they are not being forced into something that doesn’t fit. With team members that control how they work, on their own and especially with each other, comes higher value creation.

Work-life Balance

I have never met anyone that works better when they’re worried about what’s going on in their personal life. I’ve found this over and over in my career as a developer and eventually a manager inspired me to write about it . People who are under stress feel strained to come up with strong solutions and tend to generate less errors. Those people who say “this person just works well under pressure” are really just saying “This person’s performance doesn’t fold as much as others once emergencies happen.” That’s a good quality for them, sure, but nothing an team should brag about; that should be embarrassing that it happened enough that some people have reputations around crises.

Work-life balance is not something a company sacrifices, that’s zero sum thinking. It’s been shown time and again that the opposite is true. Providing people with things like leave, and an investment in their mental health has more for an organization’s productivity than filling out timesheets ever will. At Stack we have a policy of unlimited sick days, no questions asked. If you need a day, we trust you to be able to take care of yourself.

When you take care of people they will work better and faster — that’s also what they want to do. Regardless of the stereotypes people will often hear from naysayers who balk at the idea of unlimited sick time, the folks who just want to phone it in and game the system are the minority. So much so, that spending the effort considering how to manage the time a person takes a sick day when they aren’t sick is probably more of a time sink than how much it will happen.

By choosing to be invested in your people’s health, an organization chooses to be a place that values its employees. When you avoid zero sum thinking, getting trapped in the idea that if employees are benefiting the company must be losing, you begin to realize that working with, instead of against, those you represent leads to happier people and a better bottom line.

We took all these leadership principles and applied them to Collectives

At Stack Overflow, we’re quite a flat company. And I don’t mean this by measuring the number of levels between an engineer and the CEO (it’s 4, for the record), but people of all levels have a voice in product decisions. Engineers are heavily involved in what we build and how it is built. Being a company built for engineers and driven by engineers is a huge part of why Stack Overflow is successful.

This success has allowed a beautiful community to thrive on our public platform, but we are always looking at how best we can give back to that community. How do we help our community grow? How do we make those experiences more meaningful? Those are the questions that guide us at Stack.

“Anything that fosters our users’ ability to help each other and to benefit from it. That’s always a homerun.”

- from the Dev Interrupted Podcast at 34:54

With that in mind, we’ve launched Collectives , a new way for the community to interact with the maintainers of the technology they use most.

As I discussed on the Dev Interrupted Podcast , Collectives are dedicated spaces on Stack Overflow where you can find the resources (including questions and technical articles) and trusted answers you need, faster, by centralizing that content and connecting you with the product experts and trusted users. For instance, if you have questions about Google Go, you can get answers directly from those who help maintain the language.

I am extremely proud of the work that went into this, and the work that we continue to do to make it something our users can enjoy. Like all new adventures, there is a constant feedback loop we work through to try and keep making Collectives, and Stack Overflow, a better and more welcoming place.

It is still the Stack Overflow you know and love

The Beta release of Collectives was a huge success. We’ve seen over 20,000 users join Collectives on Stack Overflow and start collaborating since the launch in June. That said, we know we don’t have a Collective for everyone (yet). For users that don’t want to take part, or haven’t found a Collective that they’re excited about yet, their Stack Overflow experience is not going to change.

For instance, we’re not changing accepted answers, whether it comes from Google (our new partner) or not. If people don’t vote for an answer, it doesn’t get accepted. Content moderation will be treated the same way. Moderators will interact with content from sponsored users just like they would anyone else.

“I think the most positive thing about it is that people aren’t losing the site that they love, and that we’re really proud of.” — from the Dev Interrupted Podcast at 33:22

With our community update, organizations will be able to improve the visibility and detail of content being created around their technologies, and users will be able to find more relevant and accurate answers they can put to use solving problems while being better recognized for their contributions. Ultimately providing both organizations and users with more actionable insights.

These efforts allow Stack to build better communities because after all that’s really what we do: we are in the business of building communities.

Collectives do just that.

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com on December 8, 2021.

Collective Community: How We Empower Developers was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.

The world is what we make it. Tech — and AI — follow the same principles.

On this week’s episode of Dev Interrupted, we sit down with Christina Enchevta, a Director of Engineering at GitHub, to unravel the link between the values we hold and the things we build. We delve into how AI applications mirror our values, intentionally or not, and how this can lead to surprising outcomes, no matter how benevolent our intentions.

Christina also shares practical advice for engineering leaders on how to take and provide constructive feedback, dismantle information silos, and infuse your values into the product development process.

“If you’re going to do AI, know the history, know how it works, and pursue it with a diverse group of people.”

Episode Highlights:

• (0:00) Accelerate State of DevOps survey
• (1:27) GitHub’s secret sauce
• (5:05) Being transparent with your dev team
• (11:30) Providing constructive feedback
• (17:45) Generative AI & art
• (22:40) Dismantling information silos
• (26:50) What devs should be excited about

Read the full episode transcript

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don’t miss this opportunity to take your team to the next level — save your seat today.

Originally published at https://devinterrupted.com.

You Are What You Build: Making Your Code More Human was originally published in Dev Interrupted on Medium, where people are continuing the conversation by highlighting and responding to this story.