Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
December 15, 2021 06:10 pm GMT

Collective Community: How we empower developers

This article was written exclusively for devinterrupted.com by Ben Matthews
.
.
.
Putting employees and your community first should be a crucial priority for every organization, and it shouldnt 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 its 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 - heres how we built it.

Indicators of team health

Common metrics that organizations tend to follow are often a symptom of a teams 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, thats real success. If this kind of people-driven success is occurring, youll 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 thats 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, weve 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 whats 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 youve been around software development long enough, Im sure youve 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 cant 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 theyre worried about whats going on in their personal life. Ive 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 doesnt 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, thats zero sum thinking. Its 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 organizations 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 - thats 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 arent sick is probably more of a time sink than how much it will happen.

By choosing to be invested in your peoples 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, were quite a flat company. And I dont mean this by measuring the number of levels between an engineer and the CEO (its 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, weve 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. Weve seen over 20,000 users join Collectives on Stack Overflow and start collaborating since the launch in June. That said, we know we dont 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 Slack to build better communities because after all thats really what we do: we are in the business of building communities.

Collectives do just that.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is based on an episode of Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

https://devinterrupted.com/podcasts/


Original Link: https://dev.to/linearb/collective-community-how-we-empower-developers-1noc

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To