Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Tech Leading: Initial Thoughts

04.23.2011
| 3737 views |
  • submit to reddit

As I mentioned in an earlier post I’ve been playing the role of tech lead on the project that we’ve been doing at ThoughtWorks University so I thought it’d be interesting to note down some of my observations so far.

Out of the tech leads that I’ve had I liked the style of Dave Cameron the best.

He viewed himself more as a technical facilitator rather than as a person who should make every single decision about how a system got built which meant that others also got a chance to take some responsibility.

Varying the style

I wanted to apply this style with everyone on the team such that I would facilitate a conversation with the pair about the story that they were working on but they would decide how they went about it.

This worked reasonably well for some of the people but I quickly noticed that others were ending up quite lost if we only had a brief conversation.

They needed a bit of a structure around what they were going to work on so in those cases we tiny tasked out the implementation together.

A fresh view

When I worked with Christian as my tech lead I noticed that when we were stuck on something he would often come round and ask a question which guided us to a solution which had been completely evading us.

I don’t yet do that as well as him but I have found that having a fresh and higher level view of a problem means that you can see things which the pair may now be missing because they’re so stuck in the implementation.

That’s happened several times and is always immensely frustrating for the pair involved!

Knowing what’s on the wall

I’ve got quite used to only having to know what story I was working on and not really needing to know that much about what the rest of the team are working on.

That approach doesn’t work quite as well in the tech lead role where you need to be the one who has an idea of what’s going on with everything that’s in play.

This is the thing I’ve struggled the most with and there have been occasions where stories have been in play way too long where I could have intervened and help the pair work out how to finish them.

Other people that I’ve spoken to have suggested that one way of ensuring you know what’s going on is to browse every checkin that’s made to the repository each day.

I did try this a couple of weeks ago but it’s really time consuming and I think you can get information about a story quicker by just talking to the people working on it.

 

From http://www.markhneedham.com/blog/2011/04/17/tech-leading-initial-thoughts/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Zqudlyba Navis replied on Sun, 2011/04/24 - 8:30am

I was a (non-hands-on) tech lead for 12 months on a large project. Most of my time involved :

  • High level technical design and documentation using wiki confluence.
  • Creating Jira tasks, assigning them to developers, and managing the Jira workflow.
  • Coordinating patches and releases to production.
  • Attending lots of requirements meetings. Lots of time on the phone too.


I get to go home 5pm every day, while the developers who did the actual implementation had to slug it out beyond 9pm on many occasions.

Sure, I knew the project from a requirements perspective, how the stories tied together, and knew the high level technical design, but I was not involved with the implementation, so you couldn't count on me to provide a fix when there's a major defect at 3am.

I didn't find satisfaction in being a tech lead, and not being involved with the actual implementation. I didn't feel the intellectual stimulation of being able to craft something with my bear hands to the keyboard. When you get something to work with your beautiful code, and fix something extremely hard, you get that buzz in your brain having taken happy drugs. I don't get the same buzz being able to complete a wiki page, close off a jira, or finish discussing stories with incompetent business analysts.

I felt I lost half my brain being a tech lead doing paperwork all day. I have since gone back doing hands on development, and felt the satisfaction having produced something tangible at the end of the day.

Many years before that, I had a stint as a project manager as well for 12 months, where my primary tools were gantt chars, word, excel, powerpoint and desk phone....a complete waste of my intellect....but that's another story.



Anilchandra Noo... replied on Sun, 2011/04/24 - 9:36am

I feel tech lead is challenging role in a project and one should be confident in playing it.

Mark Unknown replied on Mon, 2011/04/25 - 11:00am

To me, being a good/true tech lead and not being hands on is pretty much impossible. I am afraid to take a week off because I just miss too much. It takes constant hands on to know what to do and how to do it. http://www.codingthearchitecture.com/pages/book/software-development-is-not-a-relay-sport.html

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.