DEV Community: Arsen

Range of autonomy practices: Six examples

Arsen — Tue, 20 Dec 2022 22:10:30 +0000

Autonomy is one of the core intrinsic motivation factors. When we talk about performance and motivation, the freedom to choose what and how you do is indispensable.

I used to think about autonomy as "leave product decisions to the Product Owner and technical decisions to developers". But from recent reading I discovered a whole range of autonomy people have in various companies. I ordered the list by the level of trust and transparency between the employees and their leaders. Let's start from the top.

1. Microenterprises: Haier

Haier is a Chinese home appliances manufacturer that revolutionized the organizational structure with its RenDanHeYi model. Haier consists of 4000 "microenterprises" - completely independent groups of 10-15 people. Each microenterprise functions as a small company in a network of companies. It can contract with other microenterprises, seeking services and sharing a part of its income. Anyone is free to organize their own microenterprise if they see the need. You can even contract with an external service provider if an internal service is not good enough. There are microenterprises for HR, legal, compliance, and anything else you need to deliver service.

Haier says that the best employees are those who have the entrepreneurial spirit, and the RenDanHeYi model allows everyone to unleash their inner entrepreneur.

More about Haier by Corporate Rebels

2. Teams define their product backlog: Shopify

James Stanier, Director of Engineering at Shopify, wrote a post for LeadDev describing their approach to autonomy. In that case, the product items don't come from executives to the bottom. Instead, engineering teams propose things they want to add to their product. There are processes to align them with the organizational goals, to review by the executives, and to define good metrics. Then, the engineering team is responsible for the delivery and the outcomes.

Encouraging autonomy within engineering teams

3. Teams choose items from backlog: LeSS

The LeSS framework suggests a more strict approach. The roadmap and prioritizing are still done by the Product Owner. Then she brings the next upcoming items to the Engineering teams (there can be up to 8 teams per one Product Owner), and the team representatives negotiate who takes what. A team might choose an item because they have the proper expertise, so they'll do it quicker. Or they may want another one because they lack the knowledge and want to learn it better.

It's a lower level of autonomy, but it still allows the engineers to grow and contribute in the best way. It is important that the engineers decide what is best for them.

Large-Scale Scrum: More with LeSS

4. Dynamic reteaming: Valve, Pipedrive

Dynamic reteaming is when people can change teams and projects to increase their impact and learnings.

In my game development past, 10 years ago every other game developer dreamed about working at Valve. I clearly remember that their New Employee Handbook said every office desk had wheels. This is because anyone could change their project at any time. If you are bored with your project and you have found another one - more interesting, more rewarding, and where your skills are needed - you can join it, just roll your desk.

Valve: Handbook for new employees

Another example is Pipedrive and the Launchpad system, as presented in a case study of the unFIX model. All the engineers start in a Launchpad group that deals with maintenance and overall improvements. From there, people can form Mission Teams that leave the Launchpad to deliver certain items. The Mission Team is gathered for the specific needs of the challenge they resolve. After the item is delivered and accepted by the Launchpad, the Mission Team returns.

The case study presented by Jurgen Appelo

5. Individuals work on their ideas: Google

Another famous example of a smaller scale of autonomy is Google and their "20% rule" - 1 day per week each employee can spend on something they see to be valuable for the company. In case of success, these small experiments grew into services like Gmail.

There are rumors that Google dropped the 20% rule, or at least it is restricted by conditions. Allegedly, nowadays an employee needs her manager's approval, as the 20% on a side project would impact the team's performance.

Other companies also use different forms of this rule, ranging from 10% to 20%.

6. Hackathon

The least risky option is an internal hackathon. 3 days every 4 months would take just 3% of working time, and it still gives people the freedom to experiment, learn, reteam, build horizontal connections, and do something meaningful.

Autonomy is a cultural matter

Not every option suits every organization. The autonomy level is strongly tied to the organizational culture - not only values but also practices, processes, and beliefs that support those values. Changing a culture is possible, but it requires both executive support at the top and engaged people managers at the bottom.

Intrinsic motivation models

Arsen — Wed, 14 Dec 2022 20:20:41 +0000

Let's look at modern motivation theories, particularly intrinsic motivation.

Extrinsic motivation: reward and punishment

Motivation systems distinguish extrinsic and intrinsic motivating factors. At the workplace, the most common extrinsic motivators are reward and punishment ("carrots and sticks"). Until recently they were the default approach to people management. As Peter from "Office Space" brilliantly describes it:

Now, if I work my ass off and Initech ships a few extra units, I don't see another dime. So where's the motivation? … And here's another thing, when I make a mistake, I have eight different people coming by to tell me about it. That's my real motivation - is not to be hassled. That and the fear of losing my job, but y'know, Bob, it will only make someone work hard enough not to get fired.

Notice how Peter is depicted as motivated only by money or being hassled / fired.

Intrinsic motivation: RAMP model

But researchers also noticed that people voluntarily partake in activities that don't provide any reward: playing games, solving puzzles, tackling challenges. Something inside us makes us do that - these are the intrinsic motivation factors.

Two models are mentioned the most frequently (in my social network bubble). The first one is the Theory of Self-Determination (SDT) by Deci and Ryan. It lists three core motivators:

Autonomy - the feeling of having choice and control over your actions and decisions.
Relatedness - the need to feel connected to others, to belong to a group.
Competence - being an expert, being effective at what you do.

Another popular theory is the Drive model by Daniel Pink. Its core components are Autonomy (same as in SDT), Mastery (corresponds to Competence in SDT), and Purpose - knowing why you do what you do.

Since there is a noticeable overlap, there is a third model created from the previous two called RAMP - an abbreviation for Relationships, Autonomy, Mastery, and Purpose. (If I understand correctly, the model was created by A Human Workplace.) For example, mission command approach contains all four RAMP components.

Extrinsic motivators suppress the intrinsic ones

In the book "Drive", Daniel Pink describes an experiment where one group of children were promised a reward for drawing pictures, and others just drew because they enjoyed it. After the experiment, the children in the first group showed less interest in drawing later. It turns out an extrinsic motivator can deplete the intrinsic ones.

In life, once you attempt to motivate with a reward or a threat - there is a spike of motivation that rapidly depletes. To maintain it, you must provide bigger rewards (or increasingly scarier threats). Otherwise, you end up with highly demotivated people.

Here is a talk by Andrzej Marczewski from the Gamification Europe conference: the second case he describes is how an extrinsic reward ruined a system with built-in intrinsic motivation. A notable quote:

What you must not do - and you really must not do - is to offer a reward.

Using motivation models

One way to apply a motivation model is to define the driving motivating factor for every team member. It sounds a bit troublesome, so I use it as a checklist for detecting gaps:

Do people feel like a team that moves towards a common goal?
Is the objective clear enough?
Does everyone have a chance to express their opinion?
Can people decide how to do their work? Can they choose how to contribute?

And to summarize with another popular saying that I like:

You don't need to motivate people — instead, remove what demotivates them.

(Cover photo - by Todd Diemer on Unsplash)

Let's talk about feelings

Arsen — Fri, 09 Dec 2022 21:41:19 +0000

Did you know that the whole "boys don't cry" / "men don't have feelings" adage is just 200 years old? It appeared only in the early 1800s. For thousands of years before that, things like manly tears were a social norm.

Let's talk about feelings.

I often ask about feelings: "How do you feel about this?", "Any feelings to share?", "How does it feel when we do this?" I intentionally use the language of feelings, because this way I can learn more than through thoughts and opinions.

Our brains do a good job of storing memories but are not so good at retrieving them. Consciousness gives access to recent memories and some bright events from the past. I'm sure you were in a situation when you knew something, but you just couldn't remember it in the moment.

Emotions come from the whole body of our experience, whether you are asking for it or not. Also, they emerge very quickly, faster than we realize.

E.g. someone mentions a risky deployment before Christmas vacation - and you immediately feel anxious. You go through a particularly unreadable piece of code - and you can feel almost physical discomfort. You haven't even formulated yet what is wrong, but you can name the feeling.

It's like a superpower - your brain throws an immediate answer to any question, but the tricky part is deciphering it. If it's anxiety - what makes you anxious? If it's a feeling of satisfaction - what contributes to that?

Tapping into feelings requires some ground work.

You need to create an environment where having feelings is safe.

You need to understand your own emotions and be able to expose them in a safe manner.

You need to show your vulnerability.

You need to have the emotional intelligence to accept others' feelings.

The reward is immense. People can be their true selves and get more fulfillment from work. You also build trust and accelerate communication by dropping formalities. You get access to a deeper level of others' expertise.

There are no useless feelings: fear, uncertainty, anger, annoyance are as crucial as joy, peacefulness, confidence, support. Each emotion is your brain helping you to survive. If you want to get 100% from your team - listen to their feelings.

Values are words, culture is behaviors

Arsen — Sun, 16 Jan 2022 21:57:33 +0000

Values and culture

Values are beliefs, attitudes and opinions that the group members consider essential for their life.

Values are expressed by words or sentences that you put on a wall or a website. Sometimes values are not reached yet, but they guide the group in its journey. Some examples: passion, trust, respect, kindness, equality, transparency, accountability.

Culture comprises behaviors that are expected and considered normal by people within a group. Culture is expressed in the actions you do every day.

Culture is supposed to be aligned with values, but it might not be there yet. E.g. a company can say that it values equality, but it is far from true when you look closer. It might be that they are still on their journey, or it might be that they actually don’t care.

If you want your values to matter, you have to put some effort into them.

Supporting values

The convenience of using values is that you can express them with a single word or a sentence. They allow you to communicate and align quicker. But without referring to them in everyday life, there is a high chance they are dead weight. You need to establish a culture driven by values to bring them into life.

There is another side to the compactness - they might be ambiguous. For example, “passion” is often included in the values list, but what does it actually mean? There was a situation when I shared some ideas with an executive, and he yelled at me in response. Then he wrote me a private email: “I’m sorry, I was passionate”. No, such behavior cannot be justified by “passion”. So, be sure to have occasional discussions about values.

Establishing a culture

How do you establish a culture around a value - i.e. how do you make a behavioral change in a group? From what I learned, the only instrument is “little nudges”. Like the river gradually shapes its banks, you can apply only three little actions:

demonstrate the desired behavior yourself;
encourage others when they show the same behavior;
disapprove of behaviors that contradict the desirable one.

The first one is easy: if you genuinely believe in the value of the behavior, you are already expressing it every day.

The second point is a bit harder to do; you need to make an effort here. Software development is still a competitive male-dominated area, and we are not used to encouraging each other. You have to notice small things and let people know that you notice them. Use a small conversation at the coffee machine, drop a message in the chat, have a minute of acknowledgement at the 1:1 or the retrospective meeting.

The third one is the toughest. It requires a high level of psychological safety for everyone to be comfortable with expressing criticism. It is a bit easier when you have a leading/managing title - you can organize 1:1s to talk to people in private; younger and less experienced team members look up to you. Even then, giving negative feedback can be challenging. The “Radical Candor” book helped me get better at this, but there is still a journey ahead.

The challenge of values

The values are not just about aligning. It is acknowledging that we are not perfect, and we want to grow in a specific direction. Life is tough, 50-100-1000 people in a company cannot follow the values impeccably. But you also cannot move towards your values without supporting and challenging each other.

This post is partially inspired by the ”Principles of Technology Leadership” talk by Brian Cantrill. Watch how he goes crazy - it is funny and makes you think.
I can also recommend an episode on culture from my favorite "Soft Skills Engineering" podcast.
Plus this "Designing cultural transformations" talk by Ryn Daniels from a LeadDev event has a great example.

Cover photo by Matthias Schröder on Unsplash

Managers, don’t work overtime

Arsen — Sun, 19 Dec 2021 21:46:07 +0000

I already wrote a post on dangers of working overtime, but this time I'm looking from the manager's perspective. It's a story about overtime, but more generally, I would call it "Don't show behaviour that you disapprove of".

Management changes habits

One of my strongest opinions is that no one should work more than your contract specifies. The reasons behind it are:

working overtime is not heroic; it's a management failure;
the person who works overtime pays for it with their mental health;
unpaid overtime breaks the contract between the employee and the company, then breaking the contract breaks the trust. If that paragraph can be violated, what else can the employee or the company violate? What is such a contract worth?

When I was an individual contributor, I would never open my mailbox or chat after working hours. But as a manager, I never have enough time to do everything I planned (at least, to my quality standards). Also, I feel responsible both for the project and for my team. Suddenly, I found myself checking my mailbox in the evening or on a day off. And one day, I felt tempted to answer a question in the chat because I knew the answer, which would help the team. But I had to stop myself.

Okay, maybe, it is acceptable to check your emails - if it helps you cope with the anxiety. But you certainly cannot let your team know that you do it. When you are a manager, people pay more attention to what you do. Your actions have more weight. If your teammates notice that you work on your day off, they might think this is expected from everyone. But when you do that - you normalize such behaviour, you add it to the work culture.

Sometimes you feel down, you are out of time, and it seems like an extra couple of hours of work can fix everything. It makes you feel good about yourself - selfless, dedicated, sacrificing your free time for the greater good. But no one benefits from it in the end; actually, both you and the company lose in the long term. (Unless you are a co-founder and a stakeholder and receive 30% of the company's income.) And when you are a manager, your team joins the group of losers. So - don't work overtime.

Matters of culture

It is a part of the manager's responsibility to form the work culture in the team. The same applies to questionable humour, gossiping, talking behind someone's back, handling critical situations, asking for help and giving feedback. Everything you do might be an example to someone else. Do you apologize when you lose your temper? If nine people interrupted you asking for help, how do you answer to the tenth person? When someone makes a discriminating joke, how do you react?

Photo by Abdelrahman Hassanein on Unsplash

How to turn a 10x developer into a 1x developer and vice versa

Arsen — Wed, 24 Nov 2021 14:04:37 +0000

A lukewarm take on the topic of 10x developers, based on real-life events.

How to turn a 10x developer into a 1x developer

hire the most talented developer you can find;
put the developer on a project where multiple teams share the code base;
the team has to have a product owner, a business analyst, and not less than two project managers, all of them can make product decisions;
final product decisions are actually made by an executive who is accessible once a week for 30 minutes;
but the same executive can also come by at 7 p.m. and scratch everything that was done during the day;
the code reviews are mandatory, no pair programming allowed;
there should be no limit on how long a code review can wait and how many iterations it can take;
the testing environment should be unstable and inconsistent;
let anyone ask them questions at any time because the 10x developer knows a lot, and sharing knowledge is essential.

How to turn a 1x developer into a 10x developer:

take any senior developer in your team;
separate them from the rest of the team, put them on a mini-team with 2-3 other people;
let them focus on a single well-scoped project for days/weeks;
the mini-team members should have all the skills to move forward without being blocked;
one person should make all the product decisions, and that person is available at any time;
track progress and update priorities weekly;
let them work on a separate branch - no code reviews, no merges, no conflicts;
take them off all the "obligatory" meetings, let them organize their own processes;
other team members are not allowed to bother them with questions/discussions.

On a slightly serious note

The most time-consuming factor is communication - how fast and how efficiently we can convey decisions. Naturally, by increasing speed, we lose quality and vice versa. Maintaining this dynamic balance is what makes it a tough but exciting job. Sometimes you might prefer a steady team over a high-speed 10x developer.

There are some questions to help with choosing though. How long do you plan to maintain this product? Eventually, people leave - what happens if they leave? What is at stake - the existence of your company? The well-being of your family? Your career? Your yearly bonus?

Photo by Zdeněk Macháček on Unsplash

Traits of a Senior Software Engineer

Arsen — Sun, 08 Aug 2021 21:41:01 +0000

For a long time, I wanted to compile my list of qualities of a senior developer. How do you become one? What do people expect from a senior developer? This post is my first attempt.

There are many angles to approach the topic. Here are some of the sources I found interesting:

John Allspaw's On being a senior engineer
Camille Fournier's Career ladder of RentTheRunway and An incomplete list of skills senior engineers need, beyond coding.
Soft Skills Engineering Podcast, where a listener once asked, "Can I call myself a senior developer after X months in the industry?", and the host answered: "I'm afraid, you didn't make enough mistakes yet".
A recent Twitter thread (in Russian), where the author says that to him seniority is not about hard skills (languages, frameworks, technical stacks), but more about professionalism, responsibility, decision-making, and ability to solve business problems.

In this post, I'm writing down my answer. I wish I wrote it a couple of years ago to compare how my views have changed. I'm sure I will give a different answer in a couple of years. Here I just list the points, and I plan to elaborate on some of them later.

Important Senior developer traits (2021):

Hunting for business knowledge - actively search how the product works, how users interact with it, why it works as it does;
Being able to discuss without raising the voice;
Express opinions and support them with arguments;
Gut feeling - listening to your intuition;
Remember stuff - writing down, documenting, keeping lists of things, organizing information inputs and outputs;
Knowing the processes of working with people in Software Development;
Knowing the next step and the one after that;
Pushing a task till the end or passing it to another person;
Changing processes when needed (supported with an opinion and arguments);
Looking at things from the team point of view;
Seeing people as collaborators and contributors (or at least parts of a solution), not obstacles;
Solving the unsolvable problems;
Experience in putting out fires;
Experience in breaking things (build, CD, production).

Cover image by Valeria Cerbu on Unsplash

Dangers of working extra hours

Arsen — Sat, 10 Jul 2021 22:49:01 +0000

Disclaimer: It is not your fault if you are in a situation where you have to work uncompensated extra hours. Sometimes it is hard to find a job; changes can be scary, so you stick to whatever you have at the moment. However, it is also not normal, and in most countries, it is a violation of labour laws. Please don't put up with it; there are better places to work.

It used to be common for an employer to convince employees that working uncompensated extra hours is good - that it makes you "a part of the family", it shows your loyalty. Sometimes your next promotion depends on how many extra hours you worked. Luckily, this abusive practice is becoming a thing of the past. So I'm going to talk about situations when developers choose to work extra hours.

It is especially in the COVID era that many people felt like they don't work enough, so they started spending 9-10 hours working from home. I made an effort to limit my workday to 8 hours, and from time to time, I remind my colleagues and friends to do so.

A tired brain can't evaluate how tired it is

The tricky part is that we have to use the brain to estimate how tired our brain is. A tired brain tends to make lousy conclusions. The same happens when evaluating how drunk or how underslept we are. Only by using external markers (counting glasses of beer, hours of sleep, or hours of work) can we gain a somewhat reliable understanding of our mental state. Even if you feel like you are as efficient as in the morning, your brain might be just lying to you.

We have an 8-hours workday only because in 19th-century striking workers negotiated to reduce it from 10 hours. I assume the work at that time was very different from what we do today. Are the same standards applicable to modern intellectual jobs?

The most important result of a developer's work is not the code but all the decisions you make while writing that code. Making decisions requires willpower which depletes during the day. The more tired you are, the more you are inclined to cheat, take shortcuts, avoid difficult conversations. In software development, that doesn't lead to good things.
(A great book on willpower is "The Willpower Instinct" by Kelly McGonigal")

Working extra hours is an alarming sign

If one of your team members consistently works more than 8 hours, it's a sign that something goes wrong.
The most probable reason is a project being delayed. The developer sees that a delay is inevitable and tries to make an extra effort. It could be because she feels personally responsible. It also could be that she tries to protect herself from being blamed when the delay becomes obvious.

It is great if you can catch this early, because:

First, now you know that the project is getting delayed, and you have time to reconsider the plans.
Second, it is a great chance to show the developer that you care about her mental health and psychological safety. It is more important to have consistent productivity every day than try to burn yourself fast. Overworking does lead to burnout, especially when you realize that your two extra hours per day can't "save" the project.
Finally, it is a chance to explain that changing plans is usual in software development. Either you have 1) a fixed project scope and a flexible deadline or 2) a flexible scope and a fixed deadline. Both fixed scope and a fixed deadline is unrealistic. (This is borrowed from "Shape Up" by Ryan Singer)

In summary, nobody benefits from one developer working uncompensated extra hours. The quality and speed go down, the developer suffers mentally, they will need time to recover later, and their sacrifice is essentially for nothing.

A particular case of newcomers/junior developers

Some developers think that newcomers/junior developers should invest extra time in learning the new codebase. Others say: "I wouldn't encourage it, but I would do it myself". In my opinion, it depends on factors like the person's ambitions and the complexity/importance of their work. The more important the work, the more I insist on a maximum of 8 hours per day. However, in the first 3-6 months, people usually have relatively safe tasks. If it is just reading and learning, I will only remind them that they don't have to work more than 8 hours.

Photo by Beth Jnr on Unsplash

Learning as a senior developer

Arsen — Fri, 09 Jul 2021 21:33:42 +0000

"Things I already know eventually bore me, and things I don't know stress me out. It feels like the line between the two gets thinner with each year." Dan Abramov

Learning is stressful

Everyone keeps saying that you should learn a new programming language every year.

But how exactly do you learn a language? When can you say that you have learned a language? I remember that when I learned my first languages, I was excited about everything. Usually, I just practiced the syntax, the keywords, the OOP features. And it would make me happy about myself.

Years later, I know that besides syntax, keywords, operators, and OOP / FP features, "knowing a language" includes:

1-2 popular frameworks and libraries;
package managers;
adjacent technologies and tools;
building and deploying what you have written;
writing tests and knowing test frameworks.

Learning a new language is more frustrating when you already have programming experience. You realize just how much you don't know yet. In your primary language, you are fluent and quick, you are so used to comfy old shoes. With the new language, every other line of code requires searching or reading documentation. It is just the sheer amount of things to learn that is overwhelming. Every gained piece of information seems like a grain of sand in the desert of knowledge.

Mixing in some familiar things

How to make the learning process less stressful for a tired senior developer? The idea is to use current skills as much as possible. That way, I can intake the new knowledge in small portions while still getting some noticeable progress.

I want to learn Go, so I reuse:

Deploying with a docker container;
Designing a REST API in OpenAPI format. Firstly, it is nice to have a layer of abstraction between the frontend and the backend code. Secondly, the echo framework has a code generator oapi-codegen - I can read the generated code and learn from it.
Using PostgreSQL as the database - I am familiar SQL databases, PostgreSQL is a popular choice, and there is a also popular ORM library gorm;
Using something familiar for the frontend, like Vue.

Where I started

These decisions already simplified my life - I don't need to choose frameworks, I know that I'll use echo and gorm.

Instead of reading golang documentation, I started with echo's "Hello world" deployed in a docker container. It immediately gave me the feeling of something real that I do.

The next step was designing a simple REST API in the OpenAPI editor, with just one type of resource and basic CRUD operations. First, I generated and ran the classic PetStore example from OpenAPI and then replaced it with my own.

Finally, after making it work, I added the basic code for PostgreSQL connection with gorm and tried writing and reading from the database.

I wrote very little code yet, I even didn't write any loops or switches. I have a very vague understanding of Go so far. But I have a server with an API that can write and read the DB. I can also deploy it in the docker container. How much of the language did I learn? How well do I know the language now?

Photo by Tim De Pauw on Unsplash

Team's external factors

Arsen — Sun, 25 Apr 2021 12:14:42 +0000

I looked into my working experience in different teams, and I compared how I feel about them. I didn't have any criteria in mind, but in the end, I got a list of factors that we couldn't affect as a team. Therefore, I'm talking about the team's external factors.

In my career, I've been in six different teams. I ranged how satisfied I was with the work and what were the reasons. It all came down to three items:

how many projects a team handled;
how many teams worked on the same codebase;
how good the manager was.

(By manager I mean the person directly above the team - an engineering manager or a CTO.)

Here is my rating, from the best team to the worst:
#1 - one team working on one project, good management;
#2 - two teams working on one project, good management;
#3 - many teams working on many projects, good management;
#4 - one team working on many projects, okay management;
#5 - one sort-of-a-team* working on one project, okay management;
#6 - many teams working on one project, bad management.
*I was the only constant team member, while other developers occasionally joined me to help.

Observations

Software management framework didn't matter at all. We followed Scrum more or less closely in teams #2 and #6, a home-brewed process in team #3, and we didn't have any specific organizational process in teams #1, #4 and #5. There is no correlation between how we organized our work and the position in the rating.
Working on many projects was a bit inconvenient. You have to focus on many things simultaneously, and it creates an additional cognitive load. It also comes with more frequent switching of the context, leading to a loss in velocity or quality. Also, it is harder to maintain the focus on what is important for each of the projects.
Many teams working on one project was a more serious issue. Not only it affects the quality, but it also decreases motivation.
If you can't claim ownership of a part of the code, it is hard to feel fully responsible for it. Then it becomes harder to dedicate yourself to quality. What is the point of making a good design, refactoring the code, covering it with tests if at any moment "an outsider" can come and break everything? You thought everything was fine, but in the meantime, somebody hacked a global object in the middle of your code and marked all the failing tests as ignored because fixing them was too complicated. It's like tending to a garden where anyone can make a barbecue on top of the flowers.
This is when people start asking themselves - is there any point in doing the job well? In the worst situation, I saw a developer said: "I don't even care about the final product anymore, I'm just a cog in the wheel, I do as I'm told".
To my own surprise, the most important factor seems to be the management. It is hard to describe the management quality in a couple of sentences, but I'll try my best:
- Good managers were capable of listening, were open to dialog, gave autonomy to the team. They were interested in everyone's success, and they helped everyone to grow.
- Okay managers were not too helpful, but they trusted us and didn't stand in our way. It was more of old-school carrot-and-stick management: "Do the job, and I won't get mad at you, and there might be a bonus".
- Bad managers were interested in their personal success more than ours or the company's success. Sometimes they obstructed our work - probably because they were afraid to be undermined. There was no trust, and typically there were many lies, empty promises and political intrigues. Even if you manage to learn something under such management, you grow at a much slower pace than you could have.

What to do

In my opinion, there is a perfect setup of one team per one project, and it is achievable. If you put enough effort, bring enough facts and arguments, and repeat them enough times to the right people - it might take months, but the company's processes can change.
Having an okay or a bad manager is harder to handle. There is always a passive approach - to ignore, work fair and honestly, become emotionally insensitive, and hope your manager will leave the company or get promoted. From a lousy manager you can learn how not to be one - that's something, I guess. And you can always try to become a good manager yourself!

Cover photo by Alex Wigan on Unsplash

Optimize for decision making

Arsen — Fri, 09 Apr 2021 19:46:35 +0000

When working in a team, my first concern is access to knowledge. Access to knowledge is necessary to make good and fast decisions, and decisions are the main output of a developer's work.

Software development is making decisions

The developer's job is not just writing code; it's making decisions. Sometimes it is writing code, but it might also be:

deleting code;
reading code to answer a question about some behavior;
reading logs to restore the sequence of events;
reading through code and tickets to find how a specific decision was made;
organizing and moderating meetings;
writing documentation or meeting notes;
explaining code and business logic to newcomers.

Broadly speaking, the essence of knowledge work is using knowledge sources to produce and multiply new knowledge bits. I call the process "making decisions". In software development, the newly created knowledge is manifested in code, documents, or sometimes just conversations and ideas in people's heads.

If it were only about writing code, the developer's job would have been a lot easier (and somewhat boring). Imagine that all the decisions are made by someone else, and you are just writing down what that person tells you. At this point, they could have written the code themselves. From junior to senior, every developer has to make hundreds of decisions - from naming a variable to balancing code quality and project delivery. The more experience and trust you gain, the more impactful decisions you make.

As my colleague phrased it: "Pushing the keys on the keyboard is not the tough part - you also must know in what order to push them".

Enable every team member to make decisions

The faster and the better decisions a developer makes, the more value she delivers. If you are responsible for a team and the team's performance, enable everyone to make decisions.

We can make only a certain amount of decisions per day. There is a limited mental resource to a person's ability to make decisions. If you are trusted to lead a team and want the team to be more performant, you have to distribute the decision-making. If you take most of the decisions on your own, you limit the whole team to your level. Instead, invest time into helping everyone on the team to make decisions.

The two factors for a decision are gathering the input information and making conclusions. Making conclusions is a skill to learn, and it's a career-long journey. But providing the input information is something you can improve faster.

Input information is the raw material of decisions

They say that developers spend only 10% of their time writing code and 90% reading code. Some of the biggest time-sinks are:

finding out if some behavior is a bug or a feature;
finding out how a new feature is supposed to work;
implementing something in one way, without knowing that the specification was changed;
implementing a feature that was already dropped;
understanding how the code abstractions interact with each other;
understanding when the code abstraction is broken;
re-implementing something because of not knowing the design conventions;
not knowing the internal tools that could have sped up the work.

A lot of this time/effort waste is caused by communication gaps - between team members and between departments. We usually detect communication gaps with reflection, 1-to-1 meetings and team retrospectives.

Some rules of thumb:

Provide the necessary information in time.
Toyota used the Kanban system to deliver supplies for manufacturing cars. We manufacture decisions, and our supplies are information.
Write down the answers to repetitive questions or show other people how to answer them. Multiplying knowledge in the team speeds up the work tremendously.
To eliminate waste of efforts, schedule regular meetings with customers or stakeholders. This way, you won't implement features that are not needed. Also, you can inform on time if you are behind schedule, so no one gets unpleasantly surprised later.
Encourage asking questions and be ready to answer them. A direct question gets a faster and more precise answer. On the other hand, it might be interrupting and more time-consuming. Keep your cool and find a proper balance. In general, team members communicate closely, and sometimes the communication might take the form of pair programming or mob programming.

Why we work in teams

Arsen — Sun, 28 Mar 2021 16:20:38 +0000

Throughout my career, I worked in different team and environments; some were better; others were worse. Some teams were supportive, collaborating and productive; others felt alienated, too competitive and too slow at the same time.

In the last few years, I got interested in the topic of teamwork and collaboration. What makes the team a good team? How can we affect it? Every team and every person are individual, but are there founding principles of effective collaboration? These are questions I am researching.

But first, why do we even work in teams? Everyone is so used to work in teams that it feels like something by default. But to optimize, we need to formulate first why working in teams is preferable. Here are my observations:

Parallelization

A group of developers delivers a task faster than a single developer. Of course, there are many "ifs", there are limits to the size of the group, but there is a truth to it in general. There is a certain gain with growing the number of people - not linear, but at least logarithmic.

Cross-functionality

A group of people with varied skills can deliver a more complex product. There is a lot to know in software development, and it is impossible to know everything. So we choose specializations - servers, clients, databases, machine learning. Four people with deep knowledge in different areas can do more than one person who knows a little bit of everything.

Two heads are better than one

We all have our career paths; we go through unique experiences that make us better developers over time. We learn practices and techniques from colleagues and books, and then we meet in one team. The team's combined experience is more extensive than each personal view. Discussing the ideas, approaches, and practices allows us to choose the best way for a particular case.

Bus factor, sharing tacit knowledge

Developers come and go. Every developer who is leaving a company takes away her share of knowledge. There is a lot of tacit knowledge in software development - tricks, hacks, weird use cases, that appear here and there in the codebase. Tacit knowledge is something you forgot that you know. It is hard to share such things when you work alone. But when you work together every day, there is a much larger chance that tacit knowledge gets distributed. A team forms a shared "knowledge cloud" that exists in everyone's head. When one person leaves, the knowledge is mainly preserved.

"Management"

Ten to fifteen years ago, companies were obsessed with "individual performance", "lazy employees", "motivation", carrots and sticks. Since one person cannot hand out carrots and sticks to fifty people, five managers would be in charge of ten people each. These groups would be called "teams". Luckily, these times are going away. Nowadays, management work is shifting towards personal development and goal-setting.

So, these are the reasons that I keep in mind when thinking of team efficiency. We have a good team if we:

have the necessary knowledge and skills;
deliver what we are tasked to do;
do it in the best possible way.

But how to make it a great team? I will keep writing about my discoveries, but I invite you to share your thoughts.

"Bodie, Doyle, Tiger, the Jewelry Man!" (from "IT Crowd" TV show)

Cover photo by Richard Lee on Unsplash