Time is money, as people like to say. Usually, when this popular statement lands in a conversation, someone tends to point out laziness, idleness, or lack of results.

Sometimes it’s a nudge to convince engineers that they could simply improve on productivity (why can't they just think faster, or type faster!?), maybe squeeze in some extra hours, and stop watching cat videos. It may work - for a short time… and up to a certain degree. Sometimes it will be a comment from a person outside of the engineering department, the stakeholder requiring a new feature with a deadline for yesterday. To sum up - it’s rarely a positive statement, and usually in this context - a voice of disappointment or concern about the ineffectiveness of our engineers.

The problem with this mindset is that it fails to recognize that we - people outside of the engineering team - often contribute to this ineffectiveness and that we have the leverage to change it. We should think more carefully and strategically about how we are impacting our engineering teams.

Effect of high-performing teams

In a famous book Accelerate it was proven after research performed on 2000 companies, that organisations with engineering teams considered as highly effective (being measured by the “4 key metrics”) are twice as likely to meet their commercial and non-commercial company goals. 

Hiring good engineers is not enough to become a high performer in the industry - it’s necessary to develop the right company culture which supports it. In the case of this book, the recommended approach is the Westrum organisational culture. Lately, a new term has become more and more popular - BizDevOps, sometimes referred to as DevOps 2.0. With each year, high performers are accelerating, even more, making the gap between them and less efficient teams larger. It’s a large topic to explore - I recommend reading the book to find out more. 

Action #1. By making your engineering teams more performant, you increase the chances of success of your business. If you don’t know if your team is performant or not, a good start is DORA DevOps quick check.

Action #2. See what you can do to move culture in your organisation to another level. Take a Westrums Cultural Typology Assessment and look for opportunities.

Theory of constraints

In 1984, Eliyahu M. Goldratt introduced a Theory of Constraints, which specifies that every system is limited in achieving more of its goals by a very small number of constraints. This theory applies not only to the production systems, where a specific machine or equipment can be a bottleneck but also to entire workflows (phase of a process as a constraint) and business (skills and people as a constraint). 

We believe in GAT that software engineers are such a limiting factor in a global market. Right now, 87% of surveyed companies report they have skill gaps in their staff, while forecasts for job openings in IT suggest expected growths of 22% between 2020 and 2025 alone. That’s way higher than 8% of growth for other professions. “Korn Ferry report” provides a great  summary:

“Worker gap grows as tech industry expands.”

Because of the shortage of available talent on the market and negative trends, companies need to think about software engineering as a strategic resource right now.  This covers the first step of the theory of constraints (identification of the constraint).

The second one encourages us to focus on exploiting the constraint. In most organizations, constraint is not well utilized - “often less than 50% on a 24x7 basis”. A typical mistake is to purchase more of a constraint, before learning how to utilize it efficiently. You can obviously invest more into hiring IT professionals, which will help to some degree (remember about the Brooks law), but applying the tips below may help you be more economical with what you already have… and that’s only 2 out of the 5 steps of ToC.

Surprising cost of a meeting

In 2017, results of over 2-year research on categorising different types of waste in software development were published.  Waste, in this understanding, comes from the lean methodologies approach and is defined as follows:

“Waste is any activity that produces no value for the customer or user.”

Overall, nine distinct groups of waste were identified. It may be a decent checklist for a team retrospective from time to time, but leadership teams can benefit from it as well, especially that many of these may be a side effect of a wrong culture, problems with alignment, or work organisation (like wrong product being built, cognitive overload, psychological distress, knowledge loss) but especially ineffective communication. 

You’ve probably seen a table representing the cost of meetings. While their goal is to raise awareness, they come at a price. Let’s assume for the sake of this exercise, that the hourly cost per person is 40$.

Woah, these numbers get high quickly. Let’s spice it up a little bit, let’s assume you have a team of 8 individuals and you’re having typical agile artefacts in place. Let’s calculate the cost per month.

It's interesting that we usually look first for budget optimisations in reducing the usage of external tools at a cost of (for example) 500$/month for the entire company, while a single team may generate more costs with standups lead in an ineffective way. Obviously, we could even enhance these costs with:

• Cost of the disturbed flow of knowledge workers (interruption)
• Missed opportunity cost (we could do something else)

Still, these meetings serve a purpose - communication needs to happen. We’ve discussed this topic multiple times within teams and we were looking to our lord and saviour - the async communication.

Async or not - choose wisely

It didn’t work. Rejecting all meetings (or most of them) and exchanging them with asynchronous comms usually creates another batch of problems.

• Slow feedback and decision-making. In async comms people usually tend to think longer about the response they're about to deliver. If it’s an unpleasant conversation, it may take hours. We’ve covered in another blog post, that instead of exchanging comments on GitLab during code reviews for 3 days, it’s way more efficient to jump on a quick call. Async comm is usually easier for us humans, but not always more efficient.
• Less communication in communication. With a lack of body language or tone of voice, we are just left with emojis and our past experiences with individuals. It was modelled already 40 years ago with a Four-sides model that there are plenty of ways how the message may get tangled between a sender and a receiver.  Written communication was never meant to be used as a means for instant exchange - we have adopted it as such. That’s one of the reasons why itn may be more difficult than the regular one to effectively consume.

It’s not like there are only bad things about asynchronous communication. Goodies:

• Written word makes it easier to spot misunderstandings. It’s a lovely exercise, to ask participants of the meeting to write down the agreements, decisions, or takeaways near the end of the session. Suddenly everyone sees, that they’ve spent 1 hour in this room together, and they view things differently. Usually, when we read, it’s more obvious that we have a question that needs an answer, than when we listen.
• If things are not urgent or are optional, we won’t disturb the flow. This information not useful for you? You don’t need to read it at all. You don’t have time now because you need to fix this important bug? That’s fine, you can read it tomorrow. Time saved.

Action #3. As Andy Groove once said - treat meetings seriously, because it is your work. Be present, use time wisely, and don’t make it longer than necessary. Explore topics of 3H’s and 3P’s and Lara Hogan’s guide to meetings, and become a master of quick and productive sessions. Categorise if you need to have a meeting (you require quick feedback or land a decision) or instead if you should just share information in an async fashion (slack, email, document, non-urgent). Categorise who is necessary and who is optional.

Create clarity and alignment

The concept that seems to be clear in our heads, is not always as easily transferable into words. The protégé effect is a known phenomenon, stating that we can learn through teaching others. By writing, we start a similar process, because putting thoughts into words forces us to rethink our message - through multiple edits, we finally look at a text and conclude that it messages us well enough about our statement.

That’s why writing is not only important to pass the message over, but also - hopefully - to increase the clarity of the message in our own heads. Maybe you’ve heard about the famous Amazon 6-pager’s or 2-pager’s. One of the tricks behind them is that they force us to be concise. As Benjamin Franklin once said:

“I would have written a shorter letter, but I did not have the time.”

It takes effort and deliberate training to communicate a written message well. However, once you possess this skill, it’s like doing the shortest, earliest and cheapest iterations that you can imagine in any agile process. We all know that every further step of development is more costly in terms of correcting mistakes. Start from yourself and correct as many as you can with your attention to precise communication. As it was written in Leading Quality:

“When a car’s wheels are out of alignment, steering becomes harder. (...) It becomes dangerous to move at high speeds and, in extreme cases, it can even lead to an accident. The same is true for misalignment in your company.”

Action #4. Write your documents carefully, study technical writing. Make it short and precise. Use writing more often in your company - every decision should create a written policy, and it’s not only about ADR’s. Make sure your product vision is written, accessible and discussed.

Spark the flow environment

It’s frequently said that meetings themselves are not as bad as the disturbance they introduce into the workflow of knowledge workers. Some studies say that we need 10-15 minutes to get back to coding after a single interruption and during a single day, most of the time we have only a single 2-hour block without any interruptions. At the same time, the famous book Deep Work states that the ability to work in such an uninterrupted fashion is one of the most valuable skills in our times, full of distractions (on average, we get distracted after just 3 minutes of work and it happens almost 87 times a day).

We shouldn’t contribute to this even more. There are plenty of ways to increase chances for a flow environment to exist, from being more mindful about our daily actions, like asking questions that we can find answers for, and more advanced, like creating a workplace full of trust and clarity of our goals.

Additionally, think about when people in your team have the most energy throughout the day and use it wisely. Don’t disturb their focus and don’t bother them with unimportant things when they are in their highest energy phase of the day, working on an important task. Usually, that means - try moving most or all meetings to afternoons.

Action #5. Make a self-reflection of your team workflow and see if your organisation is productive, or “just busy”. Explore differences between managers vs makers schedule. In GAT we participate in making long focus blocks for our engineers, through so-called “Focus days” where there are no regular meetings scheduled, so in an ideal situation, engineers can benefit from 2-hour focus blocks even 3 times a day. Even moving stand-up meetings from early hours to late afternoon can make miracles for people who are productive the most in the mornings.

Pains of growing

As your organisation grows, the Brooks law will manifest itself again and make everything that I’ve said about communication before even harder.

With each added person, another line of communication is added between that person and everyone else. With each added person, more chaos, misunderstandings, and misalignment situations may happen.  To make things worse, there is also a Ringelmann effect which proves the tendency that with each next member, each individual in a group becomes less and less productive. In many papers, a size of 6-8 people is considered as a maximum.

However, once again, having multiple, but smaller teams make synchronisation, communication, and alignment even harder, especially if there is no clean ownership defined between the teams. There are multiple resources on this topic, like Team Topologies, but the key concept is this: the way how you’ve split teams in your organisation will affect how productive they are, and you have control over it. Adding more people is always the simplest way to, but it’s not always the best. Being small gives you a strategic, competitive advantage over big companies because it’s easier for you to effectively communicate and align people.

Action #6. Inspect lines of communication in your teams and between the teams and investigate if you cannot make them better (minimise the number of lines, make them higher quality ones, reduce the number of frictions or misunderstandings between people or teams). Usually, that means - applying a communication framework and making implicit more explicit.

Conclusion

It’s common in the IT industry to waste software engineers' time through inefficient leadership and management. We shouldn’t allow this to happen, because these people are critical for an organisation's success as a business. There are plenty of things we can do, starting from working on our own communication skills, creating a flow environment and productivity culture, and minimising the number of frictions that may happen between the teams. 

Respect the time of your engineers.