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.
Top comments (0)