{"id":2167,"date":"2014-11-11T10:34:13","date_gmt":"2014-11-11T10:34:13","guid":{"rendered":"https:\/\/thekua.com\/atwork\/?p=2167"},"modified":"2020-01-04T14:05:47","modified_gmt":"2020-01-04T13:05:47","slug":"how-do-i-still-write-code-as-a-tech-lead","status":"publish","type":"post","link":"https:\/\/thekua.com\/atwork\/2014\/11\/how-do-i-still-write-code-as-a-tech-lead\/","title":{"rendered":"How do I still write code as a Tech Lead?"},"content":{"rendered":"

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

Where do I find the time to code when I have all these other responsibilities to take care of?<\/p><\/blockquote>\n

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:<\/p>\n

Avoid working on critical path items<\/h2>\n

Although Gantt charts<\/a> have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path<\/a>. 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. <\/p>\n

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. <\/p>\n

Learn to delegate<\/h2>\n

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

Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task. <\/p>\n

A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.<\/em><\/p>\n

Loosely pair program<\/h2>\n

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. <\/p>\n

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

Avoid unnecessary or poorly run meetings<\/h2>\n

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<\/a>, to avoid the frustrations of ineffective meetings. <\/p>\n

Use the “5 P’s of Effective Meetings<\/em>” model:<\/p>\n