Over a number of projects I found myself in a poorly defined role towards the top left of the org chart with no-one reporting to me directly but with broad responsibility for technical aspects of the project. In cases where I have a team to manage I haven't done very well, both in not giving sufficiently clear low level direction, not delegating effectively, and not holding people to their commitments. I am more comfortable doing hands-on technical work, but find this does not scale sufficiently. Now I find myself guiding designs, reviewing reviews, and providing lots of advice and support for team leads and often for more junior developers. This has gone on for about 4 years now, overall I have nearly 15 years experience, I am wrapping up one project and in the early stages of a second, and I want to define more clearly what I'm supposed to be doing.

Is there a name for this sort of role (technical architect?) and resources for developing further in it? Alternatively is this simply a sign I should be either focussing on developing better people leadership skills or in a more specialist role where I could have a greater impact as an individual contributor?

  • Why is this attracting downvotes? We have so many answers saying "ask management" and "someone in management should know how to manage XYZ" that I find it hard to believe that it is off topic for management to ask what roles should handle XYZ in the general sense. – newcoder Sep 21 '16 at 3:28

Indeed the term in software development would be "technical lead" or "architect", maybe "technical architect" if the project has more variety and has differently flavored architects. As titles are not regulated, it might be anything close to those.

I found it's not as much a soft skills role as management. In management you need soft skills to sell your people stuff they don't really want to do. As a technical architect it's way easier because you need to sell things they should want to do. Your suggestions should make their work easier if you are doing your job right and that's not hard to sell.

So yes, it sure helps to read some books about people and project management, just to know what you miss out on. Just to know what the others act upon.

Personally, I like Peopleware a lot, although it's quite old already.

What is more important is your technical knowledge. Your programmers will respect you on the base of your technical knowledge. So you need to keep that up to date. Even on technologies you don't use, because you should know why you don't use that technology instead.

I guess I don't need to tell you what to do in that regard. Books, Conferences, User groups, hobby projects.

One important aspect is that the more you get into a supporting role of teaching and planning, the more you lose contact with the people doing the real work. Once in a while, drop all your books and plans and cancel your meetings and get your boots dirty. Grab a ticket and implement it. That's important because you will experience the problems first hand and make better decisions for your programmers that way. I have seen too many ivory tower architects, that insist on doing it one way while the compiler insist that it's wrong. Keep your contact to the roots and know what you are talking about in detail. If your people see that you can do what they have to do, it's a lot easier to convince them to do it also. If your solution has 100% code coverage and works great, it's easy to sell. If your solution is 5 years old and unmaintainable crap, people will have a hard time respecting your guidance. Practice what you preach.

So in short:

  • if you feel challenged to sell your ideas to the developers, get technical help. Courses, Books, Conferences.
  • if you feel challenged to sell your ideas to management, get help with your soft skills. Courses, Books, Coaching.

There is no official path into that job or advancing in it. You will need to find your balance between those two.

| improve this answer | |
  • While definitions vary across companies, I think it is a stretch to call the OP a "technical lead" or "architect". A "technical lead" would in general be the responsible person for all the technical aspects of the project. An architect is responsible for the overall architecture. Both roles would involve ensuring that the aspects under the person's domain are performed according to the technical/architecture designs. IOW, they own those roles and what goes with them. The OP's description doesn't sound like they have any of those responsibilities. – Dunk Sep 20 '16 at 22:14

Many companies have a technical track and a management track, and their titles are locally defined. Architect, technical lead and lead developer are used for leadership along the technical track.

Normally in the technical role you have an increasing span of control over a technical area, and any employee day-to-day activities in support of that technology. You wouldn't have "HR responsibilities" or direct reports. Your team reports to your boss or peers.

You may be expected to mentor your team. You are expected to coach them, since coaching is toward a specific work goal, and mentoring is more career-oriented. There are obviously many gray areas, but the common theme is that your interactions are predicated on having a technology focus. (Many people may use coaching and mentoring terms differently, but it helps to make the distinction here. :-))

Whether you choose to move to a management track or further along the technical, your next step would be to acquire people management skills. So why not do that and decide as you go?

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .