Monday, January 11, 2016

Being an architect and handling some of the managerial aspects

From mid last year, I have been playing a junior architect role, transitioning out of the technical lead role I was playing. It has been an interesting ride so far with many obstacles and many more to come I’m sure which makes it even more interesting. Taking the plunge to the new role required a change in the mindset. As a technical lead, I was predominantly focused on the technical aspects related to the product/project I was working on whereby the quality aspects of the code was the primary concern. With the switch to an architect, though most of those responsibilities still remain, there was an additional aspect which I had overlooked during the initial period.  In the capricious environment we usually work in, things do get overlooked which if left unattended will hinder the performance of your team and in turn affect the organization you work for.

Though I considered it to be a project management aspect, I came to figure out that this aspect was a responsibility of mine with this new role. So what is this overlooked aspect you ask? The management of the people aspect. Although you as an architect will not be involved with other project management aspects such as budgeting, schedule planning (though you need to assist on this one), goal setting, emitting CO2 with managerial meetings with no agenda (no pun intended of course), you do have the most important aspect of it all to manage, which is the people aspect. Though technical leadership and direction is your primary focus, you cannot overlook the fact that your team and the team morale is the determinant success factor of your team.

As an architect, you are now directly responsible of the career progression of your team. If you have a few under performers in your team, it does not mean you should corner them out and report them to management. On the contrary, you have to understand the individual’s issues, the reasons for under-performing and setting up a plan for that individual to focus on making the wrongs right. Most of the time, the under performers have a reason for their current predicament and understanding that will enable you to help that person out of the difficult situation. This is the time the team as a whole should drive the required productivity of the team until the under-performers do come up to the required standard. Constant feedback will help the people to understand their weakness and improve on it.

The catch here is that sometimes you figure out some people just do not take constructive feedback well. You cannot take this personally as this is the idiosyncratic behavior of some people. You can help someone as much as they want to be helped.

Learning to give feedback was another skill I had to obtain with this new role. Giving feedback is not the hardest part, but giving it in a way where the receiver does not go into a defensive mode is the harder part. Again, though I see this as a project manager’s responsibility, I believe as an architect, you are still responsible for the growth of your team and should give them feedback in order for them to grow. Feedback will include both the positive and the negative. “Good job with the XYZ module” is not a positive feedback. “Good job” works only if you are Hancock (you have to watch the movie to get that one). You have to be very specific regarding the accomplishment of the individual. “The new automation build script you setup for the team helped us to give regular internal releases whereby we were able to get feedback early on the features the team was working on”. Now that is a very specific positive feedback attributing what the person did and aligning that to the company’s goals of reducing operations costs and turnaround time.

Even though technical leadership still remains as the primary focus for you as an architect, you should not forget the most important people factor which will help you succeed as a team and move forward adding value to the organization you work for.
In the next post I will focus on the changes I had to make especially in the thought pattern transitioning from being a glorified geek.

Thank you for reading people, and as always your feedback is much appreciated and do please leave by a comment if you have anything to say, the good, the bad and the ugly.


  1. There is a difference of People Manager vs. Project Manager vs. Software Architect vs. many other roles. It doesn’t mean a Software Architects doesn’t have to do People Management or Project Management. From my experience as an Architect its best to give your input to People Managers & Project Managers to do their job and Focus on your responsibilities is the most sustainable way forward.

    As you progress in your career obviously you’ll get new responsibilities assigned, your new responsibilities will be at high priority (that’s the reason why you were appointed to the new position). Because of this I can’t 100% agree on [QUOTE] With the switch to an architect, though most of those responsibilities still remain, there was an additional aspect which I had overlooked during the initial period [END QUOTE]. The Sustainable model is to groom a layer of people to look after the previous work you did, and you oversee & audit their work time to time.

    Every team will have a few bad apples, I agree on the fact you need to give them a bit of time to improve and you may get involved for that directly but have your limits – never spoon feed, it’s not healthy for you it’s not healthy for them! As an Architect your time is precious, if there are underperformers first try to couple them with someone who is performing better and observe before you get involve directly. On giving feedback try the Sandwich theory to make it not personal and not offensive, but be very clear on the areas where you expect improvements.

    Being a Software Architecture is a serious matter, most of the Developers (or just coders – there is a big difference to a Software Engineer) don’t understand or simply don’t care about this. It’s a shame that even some seniors (people who claim to have x amount of year of experience) are not mature enough to become a Software Architect.

  2. Hi Chathura,

    That is some valuable insights you have brought forward. And i agree with you 100% on the fact that you need to groom someone to fill in your position during the transition period. The last point you had made is very appropriate and i too have met a few people of such caliber which baffled me as to what the experience in the end counted for. But then again, you have to deal with everyone.