patkua@work

How do I still write code as a Tech Lead?

I have previously suggested that effective Tech Leads spend an ideal minimum of 30% of their time writing code. A common question I hear in the Tech Lead training course I run is:

Where do I find the time to code when I have all these other responsibilities to take care of?

I know that many Tech Leads struggle to find the right amount of code, and also struggle to know what sort of tasks to take on. Here are some useful bits of advice that have helped me and others:

Avoid working on critical path items

Although Gantt charts have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path. A Tech Lead will usually find themselves interrupted and finding a solid block of coding time will be unusual. As a guideline, I advise Tech Leads not to focus on critical path tasks because they will often block progress on those tasks.

If a critical path item requires knowledge or experience, that only the Tech Lead has, it is useful to work with another developer on the task, so that progress continues when the Tech Lead works on responsibilities.

Learn to delegate

Delegating is a skill that Tech Leads must develop, and a skill that developers rarely have an opportunity to build. The Situational Leadership Model clearly explains when to delegate. Effective delegation depends on the skill and motivation of an individual. The model explains four modes: Telling, Selling, Participating, Delegating with the end goal of aiming to delegate as much as possible.

Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task.

A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.

Loosely pair program

I’m not a big believer in full time pair-programming. But finding the right balance between full-time and nothing is hard to achieve. A good arrangement is to work with someone on the approach or design for a particular problem, and then to do regular reviews (or short pair-programming sessions) to see what new information or challenges emerge as code is written.

This style of “co-working” on the design and code works well for a Tech Lead, who will find themselves constantly interrupted.

Avoid unnecessary or poorly run meetings

There is nothing worse for a programmer to sit in a meeting which has no purpose or no outcome. These are frustrating because the time spent in the meeting is waste. Learn how to run effective meetings, to avoid the frustrations of ineffective meetings.

Use the “5 P’s of Effective Meetings” model:

Learn to say no

The art of leadership is saying no, not saying yes. It is very easy to say yes. — Tony Blair

As a Tech Lead, you will be pressured to always take on more than you can possibly take on. The more activities you say yes to, the less time a Tech Lead has to code. If coding is really important to you (and it should be), then you need to develop an awareness of what things are really important and those that can be done by others or by non-technical people.

Block out coding time

I know some Tech Leads who block out calendar time in their diary on a regular basis to ensure that they have uninterrupted time to code. Developers know how interruptions break the train of thought and Tech Leads will find themselves even more interrupted in comparison to developers.

Conclusion

It is important a Tech Lead spends time writing code but the other responsibilities demand time away. Keeping the balance right is tricky, but the techniques described above can help you cutting code. Please leave a comment if you have other suggestions.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Exit mobile version