Interview Number 2 – The Team Lead

Welcome again to this months blog entry. Let’s continue from last month with the next stage up in the food chain from the humble engineer, that is the team leader. This highly sensitive creature is supposed to be the approachable mentor, a facilitator for on-time, good quality deliverables. However it can be very hit and miss with the quality of a team leader. Sometimes they have many years of experience, deciding to sit in this position for fear of transmogrifying into a Dilbert type manager, and sometimes they are a newly experienced coding genius who has zero empathy and can’t lead a team to success for toffee. A team leader is just that, a leader (by example) of a team. The cycle begins with the defining of the project, then onto planning, executing and,finally delivering. They must be focused on what needs to be delivered, but they must also be dynamic, and be ready to react to any unforeseen problems that might arise. On top of the deliverable side, the team leader must also be a decent human being ! Often helping people out, including supporting them with any problems they have, out of the office.

This month we are talking to an old team leader of mine, with over ten years experience in this position.

ME: Let’s start with what your main responsibilities are.

TL: I guess I am really the conduit between the front line of development and the lower management of the company. My role is split between both layers. When all is said and done, I have to make sure my team develops good quality software and firmware, on time, whilst making sure my team is happy and therefore productive.

ME: What kind of team do you run ?

TL: I would call it a medium velocity software team, we produce an average amount of code, but our quality has to be a little higher than most. We deliver firmware, so once it goes on to the device, it’s not always easy or convenient to update it. If we get something wrong, consumers can be affected directly to the point where they notice it, and it becomes a difficult product for our sales team to shift. So a small malfunctioning piece of firmware delivered by us, could result directly in bad sales, and have a negative impact on our companies reputation for high quality products. We also don’t get much extra time for this expectation of good quality, so our deadlines can be very tight.

ME:  What are the more minor, non-obvious things you need to do ?

TL: Good question, well this also includes making sure my team works to processes that make sense.By processes I mean we follow a process to develop the code for example. So for a given task, we start with a review of the requirement, then groom the story to make sure we have all the information, and also record a test for completion so we know when it is complete. Then the developing begins,it could be a small design or prototype,right up to a Technical Design Document. This is reviewed by the team and other experts and peers, then the coding begins. We are mostly test driven, so the engineer writes unit and integration tests where possible, then in parallel with this they write the actual code. When they think it is finished, the code is sent out for a code review, the SE then corrects everything based on the review comments, after testing again, they push it to the repository where it runs through a whole regression test suite. This phase is called continuous integration, if that passes they then merge the code into our main repository. New SEs are often surprised to find out that their week is only about 25% new code, the rest of the time is spent fixing things, code or infrastructure, support – either customers or sometimes internal users, design, testing, documenting etc. A good SE is a good all-rounder, in my experience these brilliant coders that pop up in interviews often do not become very successful in a medium or slow velocity team, where quality is what we strive for not a high line count of code.

ME: So how do you spot a potential good candidate for a team like yours ?

TL: I tend to go for people who are motivated, have good skills in communicating ideas, problems and solutions. They must also want to work here, for this company, so I expect them to turn up and know what we do and how long we have been doing it. I also look for people who want to work in a team like this, so they want to learn about the area, they want to improve their knowledge and their skills in the technologies we use. If you have someone on your team who likes their job, enjoys it, then you have 75% of what you need already. The technical aspects will come from exposure to our problem space, as well as training, and mentoring.

ME:  Is leading a team an easy position to be in ?

TL: That really depends on the team ,and what you are working on. It can be very simple if the work you are doing is predictable and a repeat of what you’ve worked on before. In other words you are iterating new releases, simply providing support for new products that are very similar to what you already have, having said that I still wouldn’t get complacent ! Or if it’s a completely new area of work, let’s say a start-up with loosely defined deliverables and goals, or even if the team is very inexperienced, then it can be a lot of stress and pressure constantly explaining why everything will be late, or why key targets are not going to be met. It also can be affected by how much contingency you build into your plans. S.E.s have holidays, they get sick, their productivity levels fluctuate greatly. Software is also notoriously difficult to cost in terms of hours and time, so building in a generous amount of contingency can greatly affect your perceived performance.

ME: Do you think bosses in our industry are easy to fool ?

TL: (Laughs) No, I don’t, although I think I can guess you mean that if they are very untechnical then can they be easy to baffle when things are late. I guess so, but you have to remember they don’t necessarily care why things are late, they care why you didn’t tell them earlier, and they care when things are always late.

ME: How  do you measure success in what you are doing ?

TL: Again it really depends on the project, but I always measure my success if I have delivered something of what I would call good quality, on time. I would measure my teams success slightly differently, by looking at not only the quality and time of what we produced, but also their dynamism. So did they react well when things went badly ? Did they bounce back when it looked like we were going to fail ? Are they wiser now ? Did they work well together ? Did they burn out ? In fact one of the things you must also counterbalance this with is the burn out. You’ve done a very bad job as a team leader if you haven’t defended your team from demands that were too high from upper management for example, and this has led to your team being exhausted and their nerves affected. So I suppose it’s not just what we did, but what state everyone is in afterwards that counts too. It can be hard though to do this, so most of the time you feel like you are failing. Unpredictable events are constantly popping up, with team members seconded off back to old projects to help out, or infrastructure going  down that we depend on. In fact you can guess how hard a project will be by the number of dependencies you have that you can not directly control. So for example, if we can’t get some software finished until we get a working library of code from another team, or we are waiting for a piece of hardware before we can start testing, then this can be good to blame when we are late, but also amazingly frustrating when we have really pushed ourselves to hit a deadline, and then we have to sit there waiting before we can really finish the next phase or even the entire project.

ME: What makes your job difficult ?

TL:  Most of the time bad planning, or bad estimating. Bad team members are very rare if you interviewed them yourself, or your company pays attention to recruitment. So most of the time, it’s listening to S.E.s incorrectly telling you that this is a simple task, only a few days, “We’ve done it before” etc. Then you push it to the low risk corner and forget about it. Two weeks later, when it’s still not finished and you realize the person who is on it doesn’t have the experience to get it nailed down, that is when you blame yourself, and that’s when the job is hard. How do you get your team out of that situation ?

ME: So how do you get your team out of those types of situations ?

TL: Sometimes you rethink the whole thing, it might be the case that the amount of work left to do is too much with the resource you have, it’s just not feasible. Or do we even need this feature in this release ? The best thing is always communication, so let the bosses know, maybe we can delay that feature, we might not need it for power-on or for Beta. If so, it goes away, get’s shelved and we breathe a sigh of relief. If we really do need it, then you do what always needs doing, break it down. I then get everyone on the team in a room, break the task down as small as makes sense, divide up the work, put your best person in charge of overseeing the big picture, then spend your time defending your team from anything external that might distract them, until it’s all done.

ME: What do you find rewarding in your position ?

TL: Well, at heart we are all engineers, and we all love solving problems, so I get satisfaction from solving the problem of producing and delivering software with all the problems that entails. Seeing the product hit the market, and even walking past it on the shelves in Wal-Mart is pretty good too.

ME: How could your job be made easier ?

TL: More resource, although that’s the cliche answer, and yes there are diminishing returns in software development, but most of the time just having more people with good skills would solve most of my problems.

ME: When a project fails, where does the responsibility most often lie ?

TL: I think it depends on the failure, most often it is with the planning. Failure in the context of  software projects is defined most of the time by a product that is late, and is full of bugs, so quality and time. If a product has only a few features, it is rarely called a failure, especially if it does those few features well. So trying to do too much, with too little resource, and not having enough contingency is nearly always to blame.

ME: Are you sticking in this position, or do you plan on moving up, or even back down to the front line ?

TL: Personally, the more I think about it,due to this interview,the more I want to go back to development again !

ME: Is it seen as a failure if an engineer doesn’t reach team leader within a given period of time ?

TL: No not really, although it can if  the SE hasn’t ever been a manager of some sort by the time they hit 35. Most good engineers have led a team at some point, and I would be suspicious if an engineer had been writing code for 20 years without ever taking charge of a delivery.

ME: What changes do you see coming up in the engineering fields in the coming few years?

TL: There are so many programmers coming up through the education system, unfortunately many of them have zero experience of the entire software development life-cycle. You might think that is an unfair statement, How can they have experience, they haven’t started working yet ! Well, I didn’t mention a commercial environment !

What I would like to change in the coming years, would be more graduates who have worked their way through an entire project, from feasibility, requirements capture, development including testing, to delivery and support, and even maintenance.  I would love to see more focus on this in their course projects at university. Covering the entire S.D.L. not just coding would be brilliant.

Other changes in engineering are probably just accelerations of what is here now, for example electronics being everywhere, so many jobs will become even more diverse. Also, AI and machine learning will be constantly mentioned as feasible solutions to complex problems, I personally think this will be a huge waste of time to be honest, but let’s see.

I also hope there is more of a gender balance in engineering, this is a strange industry where 90% of engineers are men, so I hope things balance out more. In terms of the internet, I suspect a revolution is about to hit us, with the computing power soon to be available through G.P.U.s and huge multi-core C.P.U.s, and also the cloud services, I think web sites are a thing of the past. There will soon be replaced by “portals” into domains, this might include V.R., A.R. (augmented realities), famous AI personalities or bots etc. The internet is about to become a very strange and exciting place.

Also with all this CPU/GPU power comes parallelism, so there will soon be new software tools available to take advantage of all this capability to distribute the processing of problems around. Of course with that power comes the ability to crack our current trusted encryption algorithms, so there will be plenty more leaks of data in the coming years. It’s quite an exciting industry when you think about it.

ME: Back to team leading, is there any good literature that you would recommend for those who would like to take up leading a team ?

TL: The obligatory title for anyone who wants to open their mind to delivering software, is the Mythical Man Month by Frederick P. Brooks Jr.

ME: What advice would you give to a new team member who has recently graduated, and is starting as an Engineer.

TL:  Never stop learning, both at work, and if you can at home. work on home projects, learn new areas, keep your mind fresh, as that is what you are trading when you come to work, and therefore that is the value of an hour of your time, so keep learning.

ME: What advice would you give to those seeking a position, in terms of their CV/resume ?

TL: Don’t lie on your CV, you could end up in a position of trust, and not be capable of delivering what is expected from you. But also, don’t play down any experience you have, even 6 months is enough to grasp 60% of a language. And in fact while I mention languages, don’t focus your CV on what languages/S.D.K.s/APIs you’ve worked on. Remember most TL’s are looking for all rounders, people who can write tests, spot flaws/ambiguities in requirements, know how to prioritize their work etc. So design your CV to reflect all round skills, as well as technical ones, and yes exaggerate it’s expected.

ME: What advice do you have for someone who is approaching an interview for an SE position ?

TL: Nowadays, I think interviews are much more intense and difficult. I would recommend practicing coding on paper, learning when to use different containers, complexity with O notation, a few design patterns etc. Show that you are technically minded, but also come to the interview knowing 5 facts about the company, i.e. earnings, when the company started, the CEO, the market and products etc Show you have read up about it. Think of an answer to why you want to work there. Just try and put yourself in the interviewers chair, think about what they want,  and focus on that. And if you do get a technical answer wrong, don’t panic, show you are receptive to learning the correct answer, ask for it !

ME: What is a successful engineer in your eyes ?

TL: For me, it has to be someone who can deliver on time, and to a good sustainable quality. I don’t want code written in 2 hours that will have 80% of my maintenance budget being spent fixing it two weeks before Power-on. In other words, we have engineers who knock out very quick code, it works in the few cases they have tested it with. Then when the rest of the system comes online, or when we switch our emulators/simulators over to the actual hardware, it quickly becomes apparent that we are going to have a lot of problems with that area. Maybe someone has over engineered the code, full of lovely software patterns, abstractions, and all perfectly decoupled. But really, we just wanted a few simply functions this release. Yes, maybe in the future we will be adding more to this area, but for now I don’t want  a huge generic state machine, with factories and singletons, I want an adapter with a few static functions. So from my perspective it is someone who just gets things right most of the time. A balance. Let’s not also forget if you expect perfection you’ll be living a very disappointed life ! So a successful engineer makes mistakes, the difference being is that they learn a lot from them.

I also highly rate engineers who try and teach other team members who are less experienced than themselves. In my eyes this is a highly valued team member, and so if I think that, they will be successful in my team.

ME: Finally, any advice you would like to pass on for those about to take the plunge ?

TL: Wow, it’s a great thought to start ones career all over again, I would say to those just about to start in this industry to remember to enjoy it. See it as a massive learning exercise. If you get a feeling of excitement when you have to solve an engineering problem, then this is a great career for you. The day however you see it as a series of unrealistic, stressful delivery dates, is the day you need to move to another job, because life is too short !

About the Author

Marcus O'Brien

Hi ! I’m Marcus O’Brien, I‘ve been a qualified Software Engineer for 20 years now. I chose engineering as a career because of my passion for learning anything to do with computing, be it programming languages, computer architectures or even operating systems. Now, after a journey through many diverse industries, I work for a video games company in Vancouver writing some of the best AAA and mobile game titles in the world! To keep my skills up-to-date, I work on several home projects involving many new areas of software, including genetic programming, swarm intelligence, artificial intelligence and recently robotics and automation. Technology to me is a fascinating, endless, almost infinite expanse of wonder. Every day, technology is moving us faster towards the future of mankind. Where will we end up? How will we develop and fit into this vast Universe? And more importantly, what is it going to look like when we get there?