A brave new culture

In your organization, if you find your teams aka people in scenarios like:

… disperse across the globe
… constantly misaligned
… segmented in different roles and hierarchies
… jammed into heavy customizations to encompass business needs
… delaying planned releases frequently
… struggling to put a feature into production
… complaining that when they tested it worked
… blaming other teams intervention
… afraid to break the working version in production
… manually intervening in every new release
… unaware of which data to capture to measure release impact
… uncomfortable to improve features from previous releases
… overwhelming to support infrastructure challenges
… seized to dated approaches
… unaware of best practices, standards or quality levels
… willing to execute new tasks
… thinking that it’s one more day job

There’s a strong possibility that your organization bureaucracy is preventing you from going fast. Mostly, because your organization culture is not evolving to meet digital.

Heavy bureaucratic rules can establish commitment between your siloed teams so they support each other. But in the day-to-day, each one of them will have different roadmaps. Roadmaps with goals subject to be compromised because prioritisation can change for the team responsible to unblock a dependency previously agreed in calendar. The same calendar you strive to keep updated to have the sensation of overall control.

Despite roadblocks and the delays, eventually, you reach success and came up in new releases to production. But, from that to a service failure situation it’s only a matter of time. And then, you will find yourself tied up in a critical scenario seeking for quick alignment between “close shell” siloed teams, wasting each other’s time.

With the experience of previous real case scenarios in mind, and after having digested the points of view about  “Spotify Engineer Culture” – Part 1 and Part 2, from Henrik Kniberg, I’m also joining the discussion with my point of view structured in 5 statements.

Statement 1: Break siloed teams into cross-functional teams

Build autonomous cross-functional teams with 8 or less elements. Look at them as small startups ruling their own business towards the vision of the holding company. At the beginning, keep existent siloed teams to provide shared services and then progressively transfer autonomy.

A cross-functional team should be built to have autonomy to quickly solve problems, deliver business ideas and propose new ones. Inside each team, every member should be aware of the long term goals of his team in order to be fully aligned with the mission. And at the same time, the teams should keep up with the macro strategy defined to address vision. So the team’s autonomy its bound to strategy changes.

What skills should compose a cross-functional team you might ask. Well, it will depend from the challenge’s nature and the long term goals you set.  The aim can demand for people with different domains – analysis, UX/UI, architecture or development. But people are T-shaped. People aren’t intellectually formatted to do the same task from day 1 and keep the same motivation. Cross-functional teams as a combination of multiple T-shaped people can collectively create something new that could not have been created by the individual users. 

Teams should be built to answer the problem they committed to. Regardless, it’s every team member commitment, contribute to change and change to evolve alongside the rest of the organization.

Statement 2: Decentralize control 

More autonomy implies great responsibility and it will be cross-functional team’s responsibility the conception of the overall solution – analysis, brainstorming, planning, design, development, deployment, quality assurance and maintenance. 

Solution conception will be a result of the skill set that the team puts together. Based on top of their knowledge and previous experiences, but, especially in the trust you lent to them. Blindly trust that teams will follow organization guidelines – recommend approaches and continuous improvement of their solutions, don’t guarantee long term governance. To keep decentralised control aligned, create groups of domain keepers across teams (analysis, UX/UI, architecture or development) for the implementation of each domain best practices, standards and quality levels to be a responsibility of all teams. Eventually, adopt new ones in replacement of oldest or then when there’s a lack of a proper option.

It’s every team’s commitment to invest in reinforcing the trust relationship by adopting the attitude and mechanisms that give cross-cutting visibility and awareness to the organization.

Nevertheless, cross-functional teams are highly subject to failure. In turn, what is expected in return is that teams in addition to the ability to quickly react, have the brains to look in retrospect and learn from their mistakes. More than that, the audacity to share their mistakes with remaining teams.

Statement 3: Communicate, Cooperate, Collaborate, Coordinate 

In order to create the alignment between teams it is important to keep everyone’s involvement and feeling of belonging through frequently information sharing. Consider to use communication channels that promote proactive participation of people – forums, presentations, talks, demos or knowledge bases instead of using regular ones – email, meetings or intranet.

Provide the means for exchange of ideas and information on top of dedicated communication channel, keep track of the  long running discussions and register relevant information that could be lost in time. Use communication channels as way for:

  • Cooperation –  share knowledge, understand someone’s perspective and collect new knowledge
  • Collaboration –  find someone that would like to be part of and collectively create something
  • Coordination –  define a vision, align strategies and set goals.

Solution design, as a process of creation, requires wisdom. However, wisdom minds sometimes need to cooperate in order to achieve a common goal, to keep up with the strategy established to address the vision. With that in mind, arrange dedicated communication channels between domains keepers (analysis, UX/UI, architecture or development) is a way to put these people talking about their problems, expressing points of view, discussing solutions and eventually collaborate together.

Solution design can lead to re-usable work that’s an enabler for velocity. A team that achieve a solution previously can influence others to adopt the same – cross-pollination, by proposing its experimentation. If it proves to be a success, other teams can progressively converge to use the same solution and when commonly accepted became a definition for a best practice, standard or a quality level. Otherwise, flag it for further improvement or replacement. 

Additionally, take advantage of new communication channels – collaborative platforms, to improve the way you assign tasks or even the way you build and record documentation. Teams are mutable and the knowledge must be persistent in time, as well as updated. Documentation as a way of communication to a future consumer – incumbent, client and/or researcher, enhances the existing work and gives change awareness.

Besides work related topics, use communication channels to bring some fun to your organization. To organize team buildings, to create communities of interest or to create challenges. Look at it as a way to push people out of their comfort zone.

Understand what works best for your organization. If it works and produces good results keep it, otherwise if it’s only a waste of time, dump it.

Statement 4: Decouple the architecture

We’re facing an advent of “break something”. In what concerns to software, organizations are still tightly coupled to legacy vertical products and to custom made patched solutions that proved to be “stable” over the years. What you can do about transforming those monoliths depends on how much you are prepared to accept the costs to pursue potential gains. Good sense will say that step-by-step approaches will be safer, but sometimes only one-shot approaches suit ecosystem constraints. Questions that you should answer to find out what would be your options are:

  • Will key users will be involved?
  • How many business domains existing in the current monolith architecture are necessary to build a minimum viable product (MVP)? 
  • What data will be necessary to ensure retrocompatibility?
  • Which criteria will define transformation failure and success?
  • Will new requirements arise during the transformation?  

With that in mind, put into consideration the possible scenarios and the advantages and drawbacks of each one. Most of all, when planning existing software transforming, avoid breaking a monolith to build a new one. 

When it comes to conceive new architecture solutions the team should have in mind the following premises:

  1. Key users are involved
  2. The scope for the minimum viable product (MVP) should be kept at its minimum
  3. Continuous Integration and Continuous Delivery (CI/CD) demand for automation 
  4. Release impact must be captured through the appropriate criteria
  5. Regular feedback can imply architecture refactoring

In order to reduce dependencies and inter-team impact, the architecture of the solution to be adopted must segment the various modules so that they are loosely coupled and can evolve independently. For that reason, the solution must be designed in order to scale the number of multi-functional teams that may come to work on top of it.

A solution’s architecture it’s an alignment of multiple domain keepers concerns. Psychical architecture more than provision the required infrastructure should seek for an easy and flexible way of teams build their environments on demand. Security architecture more than highlight security threads should guarantee that known security flaws were properly addressed. Applicational and data architecture more than integrate data from diverse sources should build solutions capable to scale. Cross-cutting to all of them, it’s the concern to collect the information that will allow the monitoring and auditing of each of the domains.

Build a vision of an awesome architecture, and define what should be the next three feasible actions to achieve a realistic scenario towards the vision. By example:

  1. Gather the domain keepers to agree in best practices, standards or quality levels – architecture guidelines
  2. Put the outcomes constantly to proof across cross-functional teams 
  3. Keep everyone involved by sharing and discussing results through communications channels 

Statement 5: Explore the world outside organization walls

Along with the autonomy, every team needs space to conduct investigation. Investigation not only for continuous improvement of organization solutions but also as a means to keep themselves updated for self-development. This approach, more than the creation of a space for self-motivation it’s an enabler for cooperation and encouragement for collaboration.

Look at investigation as a means to leverage the strategy. A way to learn how to address further challenges:

  1. How can legacy be decommissioned?
  2. How can enterprise application integration be faster?
  3. How can low code platforms improve velocity?
  4. How can governance be more flexible? 

Investigate and try out! If it has potential, invest in it, if not, move forward.

And now what?

Considering to break silo teams, into cross-functional teams with the autonomy to solve problems and create business value it’s already a signal of investigation in the organization.  More than ever, businesses are ecosystems repeatedly changing to evolve. To keep yours perfectly balanced, you have to encompass the changing.

Your organization is likely to fail when trying to adopt something new? Definitely yes. But what will happen to your organization, in a medium-long term, if you don’t try it?

Get rid of things that slow you down and start building a brave new culture!