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.
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 #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.
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.
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$.
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.
It didn’t work. Rejecting all meetings (or most of them) and exchanging them with asynchronous comms usually creates another batch of problems.
It’s not like there are only bad things about asynchronous communication. Goodies:
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.
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.”
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.
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.
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.