Operations | Monitoring | ITSM | DevOps | Cloud

From its outset, the agile methodology defined how teams operated for decades. Yet, the success realized within product and development organizations triggered an explosion of adoption. From rapid development, faster time to resolution, to improved communication and better product quality, there’s no debate: the benefits of agile are real and they are impactful. Get stories like this in your inbox.

Pop quiz! What do email threads, restricted documents, and water-cooler conversations have in common? They are the raw materials with which information silos are built. We think of silos as rock-solid structures that can (and sometimes do) survive a category five tornado. But in truth, the information silos we encounter at work aren’t as indestructible as they seem. With a few techniques for more open, effective communication and a little bit of moxie, you and your team can beat the system.

In any organization, large or small, a defined strategy and tireless accountability are essential to making sure all teams are aligned and focused as they go about their day-to-day work. For a company operating in a scaled agile environment, where teams are empowered to make decisions, strategic context must be crystal clear to create a trusting environment where teams can do their best work and drive business results.

By 2022, the skills employees will need to thrive will include creativity, trustworthiness, emotional intelligence, and leadership, according to the World Economic Forum’s Future of Jobs Report 2018. Intelligence matters. But recently, business leaders have begun to place more emphasis on “soft skills” – you know, those intangible qualities that make the difference between being a dear or dreary coworker.

It’s been a few years since the “Spotify Model” became the latest trend for structuring an engineering team. But, like its predecessors, the model based on tribes and squads has some pitfalls. How to structure an engineering team is a question that’s been covered at length, from the strengths and weaknesses of common team structures to a matrix of organization based on risk and scale to why you should choose your own model.

If you’ve ever created products that can be deployed in different types of environments, you know that it can be challenging to migrate between one and the other since the core architecture often needs to be very different. We learned this the hard way back in 2018 on Confluence, when a large number of customers trying to migrate from server to cloud were having problems. It was a challenging, prone-to-failure process that required a lot of attention and preparation from site admins.

Maybe your company just merged with another organization. Or perhaps you were a member of a group that was just bought out. Chances are you’ve been there: more than 75 percent of industries have become more concentrated since the late 1990s and the mergers and acquisitions boom is only expected to grow.

Team-focused research supported or executed by the military has yielded major insights into the nature of team performance Team allegiance features heavily in the oaths soldiers take when they swear their service to their country.

When I was a little girl, I played “business” at my grandmother’s house. She gave a box of blank payroll checks from a defunct business and heels and fancy clip-on earrings that she wore to work. I stuffed a bunch of blank checks into a purse and strutted down the hall to the back bedroom (y’know, the official boss’s office), where I’d wave my hands around telling everyone to get to work.

Atlassian is built on the belief that there are better ways to get work done. If we find a way of working to be ineffective, we will change it. This belief is fundamental to how we build and sell our products, and now we’re applying it to how we acquire companies (aka mergers and acquisitions, or “M&A”).