How to effectively on board high level technical leadership roles?

Orthanc

I'm not sure if this will be a relevant question for these boards, but I always find a bit of diversity in opinions is useful so I thought I'd ask anyway.

I'm looking for strategies to successfully bring in external people into technical leadership positions within a software company.

A bit of context; I'm responsible for overall technical strategy & direction for a group of about 12 development teams. Due to some historical stuff ups, we've got a good range of people at the lower levels, but lack people with serious software architecture chops and understanding of concerns beyond the code.

Personally I've come up through the development organisation so have a good understanding of how the software actually works. I'm a strong believer that in order to do software architecture effectively you need to spend some time in the code.

We've struggled in the past to bring people in to software architecture roles in the past because it seems to be too hard to both build the necessary understanding of the existing software while hitting the ground running and contributing as an architect.

But we need to find and bring in some external people at this kind of level, both for fresh ideas and because it's going to be too long before internal people are ready to step up.

So I'm looking for ideas on how to effectively on board these kinds of roles. The best idea I have currently is to set the expectation that it will take 6 months to really take over some of the architecture, and spend that time rotating between various teams & projects to get a feel for the software.

Inquisitor77

Question #1: Are you going to refactor the existing code?

This seems kind of secondary to what you're asking for, but I ask because I think it's important to understand the underlying situation. If you want someone to come in and completely overhaul what is already there while not breaking anything, then that's a completely different task than someone going in to take over an existing project and imposing better standards on existing work.

For one, if the former is really the case, then you need to make sure that you have the business resources lined up to actually get something like that done. In my experience, most for-profit entities who engage in this kind of work don't look to kindly on hearing, "Well, you aren't going to get anything new, and it's all going to work exactly the same, but all the stuff under the scenes is going to be a lot better I promise! Just wait 12 months and give me a million dollars and we'll get started right away! Oh, and by the way, for the first 6 months the guy I'm going to hire who is the most expensive out of everyone isn't going to actually write any code he's just gonna do research and dig around and stuff."

A more realistic expectation is probably going to be that you will hire someone to manage new work and train up your less experienced team members while helping to triage existing issues. They should literally be getting their hands dirty across all the teams in some way, not just watching from above and making grand plans. At some point you will either need to create a new iteration of existing functionality, which might lend itself to a 50/50 approach of refactoring while redesigning, or the problems will get so bad that the business will be willing (or you will have enough to make a good business case) to expend the necessary time and resources to fix the underlying issues. Which by then, hopefully, the new person you have hired is now up to speed from having actually managed real-world business problems and having had to untangle existing code.

One thing I've noticed is that really good architects rarely come in with a predefined set of ideas beyond the basics. If you have a guy/gal who is willing to waltz into an unknown situation and simply start imposing complex coding standards, then that would raise huge red flags with me. Beyond the blatantly obvious (like making sure people comment their code and not writing in such a way that literally nobody else can figure out what the hell you did), there's very little in the way of major coding standards or architectural decisions that can be made without fully understanding the business environment in which the application is expected to operate. We had a whole slew of guys with great credentials (including one guy who literally "wrote a book") who could talk up their shit, but when push came to shove, they basically produced whatever-gets-out-the-door code that ended up needing to be refactored later on. Or, my personal favorite, imposed arbitrary, esoteric standards on their fellow developers for no reason other than because they liked it that way, which in some cases caused their own problems later on.

TL;DR - Put them on bugs and shadow duty for a while, so they are still actually writing code (e.g. "doing work") and you can evaluate their own work product and working style first hand. Let them manage new work as actual architects so you can, again, get a feel for how they go about that job, and pay particular attention to how willing they are to go beyond well-worn best practices right from the start (i.e., whether they seem like good ideas or bad ideas, how they are implemented, whether they align with your expectations). Don't set the expectation that they should be refactoring the old stuff unless the resources and planning are already in place that will let them actually do that job. Otherwise it's a lot of wasted brainpower that they could be devoting elsewhere, like on actual new code that really does need new architecture.

Orthanc

Thanks. You've hit on exactly why I don't want to just have someone in such a role not visibility productive for 6 months. Not a good look.

This is a scenario of ongoing gradual evolution of an integrated product set, rather than a big reafactor or new isolated build. So essentially looking for people that can guide the ongoing development to deliver good stuff that works, within constraints of environment and existing product, while being able to gradually evolve the existing to alleviate those constraints.

I like the idea of essentially hiring someone with the right skills & experience, then getting them spending time as an engineer in the team(s) producing, with a gradual transition to architecture at wider scale as they get to understand both code and business.

This is essentially the approach I use for growing people from within, but by starting with right external experience, it should be a much faster process.

Thanks again.

mellestad

If you're looking for people to bring on as senior architects, as *them* that question in the interview process. Chances are, if they're the person you need they know more about how to accomplish what you want than you do. They should be able to give you an idea of the process they'll follow and examples of when they've done similar things for other companies. I'd be careful of trying to impose a methodology on them when you don't have a lot of experience in that area.

My 2c. Good luck finding the right person(s)!

Jasconius

What kind of software are you dealing with?

I find that different software cultures deal with this differently and with varying levels of ease. In Java, it's pretty easy to just install a new chief because those systems basically operate right out of the book, and it's the chief's job to make sure the book is right and people follow the book

Whereas in something like a Ruby service on the cloud, there's a lot more wiggle room and a lot of "subject to taste" technical decisions, and opinions, and interpersonal conflict between developers that make it hard to just install a new boss to overrule all that


I would say begin by giving him some responsibilities of a typical lead developer. Give him a feature and a team to implement it with. Repeat for as many systems as you are responsible for. Then "promote" him to the overlord status. Then give him some meta achievement like pinpointing 2 or 3 things he'd like to do/change/fix himself after having worked with these systems, just to make sure he's really paying attention.

lunchbox12682

I will tell you what has been killing me for the last several months.
Make sure they have all their accounts and tools.
Make sure they have access to the necessary people to pick up what they need to.
Make sure you and the new person have clear goals on what you want them to get done and what they want to get done. Don't tell them about the expected objectives and then continually delay starting some new project or the new person's planned main task.

Also, how good is your documentation? I have been piecing history and current state together for months because none of it was maintained and the control repositories are a mess. Make sure who ever is handling that is keeping things in a decent state.
Good luck. I've been on both sides of this and it can be such a pain for a number of reasons.

RiemannLives

At the place I work one of the best things they do in terms of management is to have two independent career paths for developers: engineers and leads. Someone in either role can continue to be promoted and grow throughout their career without being forced into the other. EG: a programmer can just be a more and more senior programmer. They don't have to become a manager or executive. edit: though of course people can transition between roles if it suits them

The two roles are vastly different skillsets. Someone who is a lead with more than ~5 people under them is going to get almost no actual coding done. In fact if they try they are going to hurt their team (they will have demands on their time that will often delay their work leaving the team hanging waiting for it).

So which do you want? A manager or an engineer?

schuss

I think first figure out what you want their role to be - Best Practice Creator, Innovation Leader, Example for team etc. Then tailor around that. For a senior technical professional, they should be driving their own bus on knowledge acquisition in the company, as if they're going to be a senior member they probably won't have a guide for future endeavors. One thing you may want to do is meet with them on your goals for them, give them contacts/general context of systems then tell them to write an onboarding guide for the team.
I recently did that with a senior business systems analyst and it worked great. They were able to build a rapport and understanding through interacting with their peers as well as show their skills around knowledge acquisition and gap analysis. We ended up with a good guide and recommendation for modules for new people to work through that we used a few months later to onboard a junior analyst.