Organisations often proclaim that they want to “behave like a tech company”. I suspect they mean product companies, but that’s an essay for another time. They then struggle to actually change employee behaviours, and their “agile transformation” stalls.

‍

However, the 80/20 rule can be applied - there are some simple changes which can be made to drive large-scale change. The purpose of this essay is to describe specific, actionable items that a company can immediately execute to unlock agility, not simply extol that one should “improve culture” and “be more agile”.

‍

The Communication Platform

‍

Years ago I was on a large project, and one of the first things that the lead did was to create a chat application. It was channel-based, with communication aimed at open discussion amongst groups rather than direct messages. At the time, many people made fun of it - asking why chat was a priority, when surely banking functionality was the objective. In retrospect, I now understand the wisdom of that decision and I am now a strong evangelist for the approach.

‍

Communication is key to progress. The less friction, the better. Email is a horrible medium for discussions:

• It is a drop-in replacement for the traditional memo, and people write using that style (you have probably spent months of cumulative time writing “Dear X, As per my last email. Kind regards, Ned”).
• It is simultaneously too broad (you added more people than necessary) and too narrow (you forgot some people).
• Because some email is a synchronous conversation, you are forced to treat all email that way in case you miss something.
• The ‘online disinhibition effect’ is where people say things online that they wouldn’t say in person - the so-called “Keyboard Warrior”. Email is not as bad as an anonymous forum, but much worse than real-time chat.
• The ‘timeliness’ of email is ill-defined. Sometimes a quick decision can be made, but it is lost in someone’s inbox.

‍

The very first thing a leader can do to improve their organisation is implement a channel-based communication platform, and encourage people to move across. Broad channels are important (and they should be obvious to new joiners), as it moves conversation out of the darkness of point-to-point messaging and into the light.

‍

Wherever applicable, the channels should be cross-functional. Nothing brings together product, technology or design more than being in a shared space discussing the issues of the day.

‍

It is important for leaders to be present and visible on these channels. As well as building camaraderie, it sets the tone for the whole organisation when leaders answer questions directly, in front of others.

‍

As a culture building tool, have channels for teams to share interesting articles they have read, or stories from their past. The technology landscape is constantly shifting, and being inquisitive and up to date is to be celebrated! Be proud of your field!

• Use broad channels not point-to-point messaging
• Create cross functional channels with different departments of the company represented
• Leaders should be present and set the tone
• Share interesting articles and stories

‍

A final point: important decisions should not be memorialised within the chat app! They should be separately recorded in a wiki or other documentation tool. This will prove invaluable for future reference, and to help staff in other timezones to not have to read every message every morning in order to catch up.

‍

Training & Certification

‍

When trying to adopt a new technology or methodology at scale, countless hours of meetings will be lost in debate between people who don’t have any expertise in the topic. Questions about capability, security concerns, cost concerns - all being discussed by well-meaning, but inexperienced, staff. The one person who actually has production experience is probably dejectedly sitting in the corner keeping their mouth shut.

‍

To change this, the majority of people discussing a decision ought to have at least some understanding, to ensure everyone is talking about the same thing, and that nothing is being lost in translation. In the context of cloud, Forrest Brazeal calls this “Cloud Fluency”.

‍

Getting staff trained & certified is a relatively cheap short cut to more effective communication. The team will have shared vocabularly, and be able to cut through a lot of the confusion and noise. Note that it is particularly important to train security, risk and compliance staff members, as they are critical to decision making around the technology’s adoption.

‍

As an aside, I believe that large technology vendors should offer free training and certification for those that want it. People who understand and can explain your product to other people in their organisation are your best evangelists.

‍

A Culture of Writing

‍

As the joke goes, “This meeting could have been an email”. Why do we hate meetings so much?

• Time spent in meetings is often spent repeating information already known to many of the attendees.
• A discussion in a meeting is a relatively sequential process, with little opportunity for parallelism. This is inefficient.
• The loudest voice in the room dominates. Or the HIPPO (the Highest Paid Person’s Opinion).
• Due to the unstructured nature of conversation, it is hard to build a clear narrative around a particular idea, then give people time to absorb it. “Fast” responses get discussed, over-emphasizing verbal intelligence.
• Meetings punctuate the day, making it hard to get into a state of flow. See Paul Graham’s famous essay Maker's Schedule, Manager's Schedule.
• Meetings are synchronous - everyone needs to be available at the same time. Scheduling this can be hard, leading to the discussion being delayed. When it comes around, key people often can’t make it anyway, plus is never quite the right time for anyone.

‍

Not all meetings can be eliminated. But they easily can be reduced - by introducing a Culture of Writing. Everyone has heard of Amazon’s approach to writing and ‘narratives’, and that is an admirable goal - but we can start more simply than that.

‍

Encouraging people to write down and distribute plans, ideas and proposals:

• Forces structured thinking - it is impossible to hide behind being vague and high-level statements when writing structured documents.
• Can replace many meetings, and elicit feedback from those who don’t always speak up in open forums.
• Allows multiple people to comment and ask questions directly within the same document (any modern writing application allows this - stop sending around ‘versions’ of a Word doc!).
• Provides a searchable history for why decisions were made, and acts as great onboarding material for new hires.

‍

The Employee Office IT Experience

‍

Part of the technology team’s scope is providing a smooth experience to staff and partners. In more traditional companies, this responsibility is often overlooked. A quick win towards becoming a more agile organisation is to assign an explicit person, who is tasked - and authorised - with making things better.

‍

An employee experience advocate essentially acts as a product owner for office IT elements. As with any product owner, their first task is to establish feedback loops with their user base to receive product commentary, ideas, or issues, and then prioritise accordingly. The resulting backlog should be made available to employees, who can then continue to give feedback over time. Most of the issues are already known, and reluctantly accepted.

‍

The onboarding experience for new employees and consultants is often horrendous, taking days or even weeks. This is a huge waste of time, and quickly impacts the enthusiasm of the new joiner. I also believe it acts as a great proxy for how overwrought and labyrinthine the overall processes of the company are likely to be. This is a great place to start for improving the employee experience.

‍

Virtual Desktop Infrastructure (VDI) is a common approach companies take for managing remote workers or other laptops outside the network, but the experience is often far worse than “normal” employee desktops. This poor experience is hidden, as most employees don’t experience it themselves - and certainly the tech decision makers don’t. The employee experience advocate should choose to use this infrastructure to empathise and understand those that must.

‍

One of the worst parts of the “raise a ticket to do anything” culture is that the person who actions the ticket is probably not the decision maker. This adds a needless step, plus bottlenecks via the overworked support staff, grinding everything down to a halt. Relentless hunt down opportunities to self-service, such that the decision maker can easily perform an action themselves, or their approval kicks off an automated workflow.

‍

Product Demos

‍

Stakeholders should regularly get together and demonstrate the progress of a product. This could be at the end of a sprint, or some other cadence if your organization has not adopted sprints.

‍

These demos serve multiple purposes:

• An opportunity to celebrate success
• An opportunity for different parts of the company to interact and engage
• An opportunity for public speaking practice for the engineers or designers involved in a particular feature
• An opportunity for early feedback in case the wrong direction is being taken
• A forcing function for the team’s output; no-one likes to give a demo for which they are not proud
• The demo gods will humble you, and help highlight fragile parts of the system
• Demo from a prod/prod-like environment (not dev/test) - this helps ensure the deployment pipelines and configuration management is working
• It forces a certain degree of small, iterative change - which as laid out here is a productive methodology
• Demos can be recorded and distributed, spreading organisational awareness and buy-in. These are also useful for new joiners.

‍

The frequency and attendance of the product demos is a useful proxy for the overall organisational culture. For example, if the tech team doesn’t invite business representatives, they are probably a little intimidated by them. If they do invite them but they don’t turn up (in my experience, this is rare), then the business team is not sufficiently engaged with the product being built. A regular, well-attended demo with healthy debate is the sign of a strong, cohesive culture.

‍

Conclusion

‍

Embracing a "tech company" mindset isn't about using shiny new tools or bringing in expensive consultants. It's about engaged and certified staff using equipment and processes that aren’t fighting back, aligned around products they believe in, collaborating with open and fluid communication. So, let's stop just talking about "being agile". Let's start with these straightforward actions and begin to truly unlock our potential.