I have been a hands-on developer for my entire career and love working with code. I have always resented the team lead who has little or no expertise regarding a particular technology and yet insists on a certain implementation.

Now I find myself on the other side of the looking glass. I am the lead developer of a fat client to be implemented in C#, however my expertise is in building Java web applications. While I know that I can leverage design patterns and OO paradigms in any language, I am lost when it comes to coding standards, project life cycle tools and release/distribution procedures. I have no doubt that I can pick up the basics within a month or two, but there are certain experiences one can only gather with time.

What should I do, and how do I avoid becoming the project lead that I hated when I was developing?


9 Answers 9


Honestly, it doesn't matter how much experience you have with a technology, my advice is the same: Do not enforce technology decisions on those who will have to live with them while you are busy managing.

Be honest with yourself. I'll bet the reason you hated those prior managers was not because they didn't have the knowledge-base from which to make decisions, it was because they enforced decisions and never dealt with the consequences.

That applies whether you've never touched .NET before or you're the most expert developer on the team. Your job is now to manage, not to make technical decisions.

Managing might, depending on the skill level of your developers, mean advising them when they ask for it. "Have you looked into Spring.NET?" (note the lack of instruction there) is a perfectly good thing to say. Also, "Google around, see what the rest of the world is doing, we're not the first to face this problem."

In some respects, as an experienced Java developer, you may be in a better position than most for this. Most Java frameworks and technologies have an analogous equivalent in .NET. So you don't have to say "Here's the best thing to use," you can say "I've used this in Java, do you know of a .NET equivalent?"

Also encourage a lot of conversation within the team. Arrange weekly technical discussion meetings. All you ever need is information, in the end; you need to know what decisions they made and why. You don't need to make those decisions for the team.

  • 2
    Right. The main thing is to be willing to let your technical "stars" make decisions that are different from what you would have made. If you can do that then everyone (except, of course, upper management) will be happy and productive. Commented Feb 22, 2012 at 12:40
  • 'So you don't have to say "Here's the best thing to use," you can say "I've used this in Java, do you know of a .NET equivalent?' In most cases if an equivalent tool exists it'll be prefixed with an 'N'; so you can generally find these yourself. Commented Feb 22, 2012 at 14:31
  • Keep in mind, he is tagging himself as "Lead Developer" and not "Project Manager". In my experience, these are two very different things. Commented Feb 22, 2012 at 19:06
  • @WonkotheSane: It's true that the OP refers to Project Lead, Team Lead and Lead Developer as if they are all the same thing, and that's confusing. But I took my cue from the context in which they're used.
    – pdr
    Commented Feb 22, 2012 at 20:09
  • @pdr - agreed, almost. The part about "I can leverage design patterns and OO paradigms" makes me wonder a little bit. Commented Feb 22, 2012 at 20:49

I've had some very good managers/team leaders who knew very little about the technology, and some of my worst managers have been those who thought they knew everything.

To be a leader, if you have reasonably competent people, the main thing is to be able to judge their competence and judgement, and give each as much latitude as he can handle, while keeping the "wild ducks" on task and the "barely competents" busy with "safe" but productive activities. Make sure everyone's marching to the same drummer.

Your bigger challenge is likely keeping upper management at bay. They will want reports and schedules and checkmarks, and you need to figure out what it is they want and how to fake them reasonably well. (Well, not exactly "fake", but produce documentation that satisfies them without eating up your time or the time of your team.)


You weren't chosen for your C# coding skills, and unless you're going to be writing code from the outset, it doesn't matter whether you know C# or not. You need to start thinking at a higher level:

  • What skills does each person on your team bring to the table?
  • Which components are critical to the success of the project?
  • What do you have to produce in addition to the actual code? (Tests? Documentation?)
  • How will you gather requirements, if you haven't already?
  • How will you and your team approach the design process?
  • You know that having a coding standard is important, but you can rely on your team to figure out exactly what standard they want to follow.
  • How can you detect problems early?

Some of these things may cross over into project management territory, but as the lead developer you'll be working closely with the project manager on these and other issues.

By all means, learn to be effective working in C# as quickly as you can. Just remember that your role is to see past the syntax and the framework details and look at the bigger picture.


Take a hands on approach. Start by grabbing yourself a simple C# primer and write some code. Try a few basic things that you would know how to do blindfolded in another language.

Read up on programming style and convention. You should find this in part in your primer anyway, but you can also use products like StyleCop and Resharper to enforce style rules that you are unfamiliar. This will effectively train you very quickly to do things in a commonly accepted way in order to avoid problems compiling your software.

Just be yourself, and apply the design knowledge you already have. The basics are essentially the same regardless of the language. Where there will be differences will be in how the languages differ in terms of structure will be fairly minimal, and much of it will become apparent very quickly as you throw together a test app or two.

If there are obvious things you don't know, be forthcoming. Your team will respect honesty more than simply barging on without a clue. Make well informed and reasoned decisions, and always take a couple of minutes aside to consider your response. You will need to be assertive without attempting to dominate, and you can't let your lack of knowledge in one area appear to be a reflection on your ability to lead the team. Leadership implies mentoring, yet mentoring does not mean you can't also show a willingness to learn something new.

  • 3
    I would say this is the exact opposite of what to do as a manager. It may be tempting to get in and throw down some code but that's not your job anymore...your job is to enable your team to do what you hired them to and trust their experience and judgement. Trying to come up to speed on a different platform is counter-productive. Commented Feb 22, 2012 at 14:16
  • @MikeBrown This only holds true if the position is a management one. All of the team leadership positions I have held have required a significant amount of time coding in addition to the project management, planning and other responsibilities you'd expect of this position. Had the OP said he was to be a Manager, then my answer would have been very different.
    – S.Robins
    Commented Feb 22, 2012 at 20:54
  • You're right. I was assuming manager from the fact that it was for a technology he had no experience in. Make an edit and I'll undo my downvote :) Commented Feb 22, 2012 at 21:02
  • @MikeBrown I'm not sure what you feel I need to edit. I've answered the OP's question based on his own statement that he was to become project lead... however, I will extend the answer a little. :)
    – S.Robins
    Commented Feb 22, 2012 at 23:26
  • Oh it wasn't that I felt you needed to edit...just that SO wouldn't let me change my vote without an edit :( Commented Feb 23, 2012 at 4:42

If you think like that and actually worry about it, you already avoided the risk to become this kind of project lead. It's a totally different kind of personality who would dare to make decisions without the proper knowledge. Just keep an open mind to what your coworkers tell you and create and encourage a culture of dialogue and exchange of information in your team.


It sounds like that are a few issues at play here.

The technology used in the project you are leading and the process that govern the development of that project.

Are you the team leader, or a lead developer? A lead developer also does quite a bit of the design and development work. So the only way around this is just to knuckle down and learn the new technology.

If you are actually leading the team, you will need to trust the team and let them steer the majority of the technical direction of the project. Of course, conceptually, you will be able to keep that steering in the right direction.

The processes that govern the development of the project should mostly be in place. It is just a matter of reading up on them, understand them and execute them.

If not, negotiate with your boss to get a mentor to help you to put some development process in place. This is pretty important. It will fail pretty quickly if the process is not in place, and is ad hoc.

Good luck!


Opportunity comes once in a while .. Do Grab it.. I would say, try to learn the basics of C#. Get some tutorial from online , try to work on it. initially it would be tough to learn the new concept , later when your first task done you will have some confidence in it.

Think positive, Try to take hard task, Debug your own code and am sure you will master in it..

Do not loose your opportunity.


I think if you have a good bunch of .Net developers there is a lot of knowledge in the team that perhaps you need to tap into to get started. There are a lot of similarity between Java and .Net that what you already know may actually apply more of less directly. The importance is knowing what is important to get right for this project and the risks involved. Communicate with your team as often as necessary. Software engineering practice evolves throughout a project so it may be difficult to have a "best practice" very early on in the project.

I kinda had the reverse of your experience where I am given a very green team of grads who are not from software related field. While I have all the reason to stipulate what needs to be done (I was employed to) I instead looked for practice to get us moving and plenty of coaching and discussion to evolve our software engineering practice. I learnt heaps from the team on the way and we are almost there in delivering our first in house project after more than a year on the job!


I am lost when it comes to coding standards, project life cycle tools and release/distribution procedures.

Find an open source product that uses the same technology you're going to use.

If possible, find one that is in some way similar to the problem domain. This isn't as important as finding a project with the same technology and active updates.

Download their working code. Read it.

Figure out what tools they use. Use them.

Figure out how to build and release the open source project. Build it and release it.

An open source project (with a number of contributors) will illustrate best practices.

I have no doubt that I can pick up the basics within a month or two, but there are certain experiences one can only gather with time.


Learn from the open source community.

  • 2
    Sometimes people working on the open source projects don't use the best available tools or even follow the standards (good practices). I know few open source projects (I don't want to name them) which are really really bad in terms of using the right tools or even following the industry conventions. Commented Feb 22, 2012 at 13:31
  • @ChristianP: While there are some less-than-stellar open source projects, it's easy to find large ones that are quite good. And finding any open source project as an example is better than no example at all.
    – S.Lott
    Commented Feb 22, 2012 at 13:41
  • I agree that any example is better than none. But when searching for best practices, tools etc. one can learn more from a good open source project even if the project doesn't solve the same problem. Commented Feb 22, 2012 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.