In the world of tech, #Leadership isn't just about managing projects - it's about inspiring teams & fostering collaboration.

Dive into this #InfoQ article that delves into how understanding the brain's different states - rational, emotional, and survival - can revolutionize decision-making and innovation.

📰 Read now: https://bit.ly/3HebzBS

#Teamwork #ContinuousImprovement #PsychologicalSafety #TeamCollaboration #DistributedTeam #Trust

Dive into the latest trends in #SoftwareEngineering with Chris Cooney!

In this #InfoQ #podcast, he explores:
✅ The backlash against "Agile" practices
✅ The growing importance of observability and people-focused metrics
✅ Strategies for aligning teams around common goals while preserving their autonomy.

🎧 Check it out here: https://bit.ly/4eKnra8

#Agile #Observability #Leadership #DistributedTeam #Performance

Improve your communication skills!

🎙️Listen to the #InfoQ #podcast with Thomas Betts & Jacqui Read for insights on Communication Patterns!

Discover how to improve communication by knowing your audience and what you need to explain to them: https://bit.ly/4dFfSRX

#SoftwareArchitecture #ArchitectureDocumentation #ArchitectureDecisionRecords #DistributedTeam

I could swear my colleague attending a video meeting actually said "I can share my scream"

#IT #videoconferencing #videocalls #DistributedTeam

🌟 Explore the latest trends in Culture & Methods!

The #InfoQ #TrendsReport offers invaluable insights to help you navigate the ever-evolving landscape: https://bit.ly/4aMXJQG

Read now! 💪 Knowledge is power! #StayAhead #StayInformed

#Agile #Leadership #Teamwork #RemoteDeveloper #DistributedTeam

What's on the horizon for the tech world in 2024?

The Culture & Methods editorial team & special guest Jutta Eckstein discuss the current state and trends shaping the technology industry in 2024.

Don't miss out! 🎧 Listen to the #InfoQ #podcast now: https://bit.ly/43GSfEO

#TrendsReport #PsychologicalSafety #TeamCollaboration #Teamwork #Agile #BusinessAgility #DistributedTeam #RemoteDeveloper

When we send the all-hands weekly meeting agenda and logistics email, it starts with the meeting time in all of the main #TimeZone cities nearby which live the #W3C team members:

05:00 Vancouver; 06:00 Phoenix; 07:00 Chicago; 08:00 Boston; 13:00 London; 14:00 Paris; 17:00 La Réunion; 21:00 Beijing; 22:00 Tokyo

#work #DistributedTeam

Jira, Bugzilla, and Tales of Issue Trackers Past

It seems as though Mozilla is never not in a period of transition. The distributed nature of the organization and community means that teams and offices and any informal or formal group is its own tiny experimental plot tended by gardeners with radically different tastes.

And if there’s one thing that unites gardeners and tech workers is that both have Feelings about their tools.

Tools are personal things: they’re the only thing that allows us to express ourselves in our craft. I can’t code without an editor. I can’t prune without shears. They’re the part of our work that we actually touch. The code lives Out There, the garden is Outside… but the tools are in our hands.

But tools can also be group things. A shed is a tool for everyone’s tools. A workshop is a tool that others share. An Issue Tracker is a tool that helps us all coordinate work.

And group things require cooperation, agreement, and compromise.

While I was on the Browser team at BlackBerry I used a variety of different Issue Trackers. We started with an outdated version of FogBugz, then we had a Bugzilla fork for the WebKit porting work and MKS Integrity for everything else across the entire company, and then we all standardized on Jira.

With minimal customization, Jira and MKS Integrity both seemed to be perfectly adequate Issue Tracking Software. They had id numbers, relationships, state, attachments, comments… all the things you need in an Issue Tracker. But they couldn’t just be “perfectly adequate”, they had to be better enough than what they were replacing to warrant the switch.

In other words, to make the switch the new thing needs to do something that the previous one couldn’t, wouldn’t, or just didn’t do (or you’ve forgotten that it did). And every time Jira or MKS is customized it seems to stop being Issue Tracking Software and start being Workflow Management Software.

Perhaps because the people in charge of the customization are interested more in workflows than in Issue Tracking?

Regardless of why, once they become Workflow Management Software they become incomparable with Issue Trackers. Apples and Oranges. You end up optimizing for similar but distinct use cases as it might become more important to report about issues than it is to file and fix and close them.

And that’s the state Mozilla might be finding itself in right now as a few teams here and there try to find the best tools for their garden and settle upon Jira. Maybe they tried building workflows in Bugzilla and didn’t make it work. Maybe they were using Github Issues for a while and found it lacking. We already had multiple places to file issues, but now some of the places are Workflow Management Software.

And the rumbling has begun. And it’s no wonder, as even tools that are group things are still personal. They’re still what we touch when we craft.

The GNU-minded part of me thinks that workflow management should be built above and separate from issue tracking by the skillful use of open and performant interfaces. Bugzilla lets you query whatever you want, however you want, so why not build reporting Over There and leave me my issue tracking Here where I Like It.

The practical-minded part of me thinks that it doesn’t matter what we choose, so long as we do it deliberately and consistently.

The schedule-minded part of me notices that I should probably be filing and fixing issues rather than writing on them. And I think now’s the time to let that part win.

:chutten