Being the Boss – an incomplete opinion on managing teams from the intern in the group.

This is a post about management. It is a post about my observations of being a member of software engineering teams over the last two years. I’m compelled to comment on managing teams, not because I’ve been in that position, and I don’t presume to tell my superiors how to do it “right”, but it has been an educational process to be part of teams as an intern.

A Project for an Intern

For my sophomore year I worked for the research lab of a big internet company. We were a team of about 6 people, with 3 other teams reporting to the same director of the lab. My team lead was responsible for assigning projects to us. After the initial stage of getting accompanied with the different moving parts the team was using and doing some bugfixes on the codebase for about 2 weeks, my lead met with me to get me started on a project. He had 3 different projects that he offered me, talked me through each, and left me to pick one. The next day I chose my project, pitched my approach to it, and started work on my own project with more than enough excitement to get me started. When I interviewed, they gave me a fairly open-ended idea of the work I can do with them, and although these projects were more specific, the range the 3 projects covered reflected the original interview.

Keeping Track of the Intern

Since I chose the project, my interest and curiosity was my main motivating factor to work on the project. My team lead would check in on my anywhere between daily to twice weekly. This would normally start with him asking me whether I was getting stuck anywhere or whether I was making good progress. This opened the floor for asking questions and discussing blocks rather than me giving him a purely “status report” reply. He would pick a time when he could sit down and work through issues with me if I had any. These check-ins took on three different types. Sometimes it would be a quick “nothing to report” hello. Sometimes I would have an almost-complete feature or a major bugfix to show. Often I’d have a question. These meetings were especially good to get rid of those minor questions that’s not really worth asking someone only that one question, but that’s still handy to get answered.

Making The Intern part of the Team

The lab was applying the SCRUM concepts to manage the group. The biggest effect this had on me as an intern was the weekly “stand-ups” we did as a group. Every Friday, we had a team lunch with everyone present. We would then stand in a circle, giving each person the opportunity to say what they did during the week, what they hope to do next week, and what things were blocking them. This did fulfill all the ideas that SCRUM wanted it to do – create conversation, let the team know what each member is doing, help to get rid of blocks, etc. etc. Something far more important was happening here though – we were all standing on the same level, with everyone from the director to the interns talking about their challenges and successes. This integrated me into the team and made for several interesting conversations after hearing of something cool a person is working on.

Talking to your manager

It was almost ridiculously easy to go up to my team lead and ask questions, make suggestions, or even (on the off chance) complain about something. We were interacting on a level of two engineers working on a common problem, with me respecting his skills and experience and he acknowledging my passion and accomplishments. This managed to make troubles easy to address, since I had no qualms about asking for help when I came upon stumbling blocks.

This is a hard lesson to learn at my current internship, where the above three points are not as emphasized – having my own project, frequent check-ings on a problem solving level, and being on an equal footing with the team. An internship of bugfixing is mentally hard and forces you to jump all over the codebase. You learn a lot, but you never get to “own” some of the code. Now, there’s lots to be said about how good or bad the idea of code ownership is (I’ll leave it to Paul Graham, Guy Kawasaki and the rest of the smart folks in the blogosphere to talk about that, their opinion us much better developed than mine on this subject). I believe it’s good to have a specific project, whether you’re the sole owner of that piece of code or not. Its definitely much most satisfying than semi-random bugfixes.

Thus my observations on managing teams are as follows:
- Give team members specific projects, and let them choose it.
- Check in with members, and do it in a “Can I help you with anything?” manner
- Bring everyone together and make the doings of the team transparent

and to team members
- Interact, interact, interact!
- Let the people above you know about your experience

I hope this helps in the future!

One Comment

  1. ayman says:

    a nice post indeed. not to speak with an insiders voice :) – but your sophomore internship was at a research lab. its not too common for a research team to be run via SCRUM (i think more should be run with it), so i like how you said it made things iterate and, more importantly, gave a sense of connection.

    is your current internship a research group? do you think the same features you outline could be easily applied?