Through years of experience working in the software industry in Europe and the United States, I have developed a certain philosophy when its comes to lead teams, whether it is in the formal role of the manager or as a senior advisor in the leadership team.
I see three tenants to this philosophy:
- Diversity: in hiring, forming and executing with, the team.
- Nurture: grow and let grow individual talents for long term returns.
- Higher expectations for one-self: as you demand much of others, it is key that you hold the bar high to yourself as well.
Sticking to it
What I enjoy is to deliver concrete results, software, ship services and features. What I don't is taking short term shortcuts and half-baked solutions that turn out to drag the team in the long term, taxing it more and more through the accumulating engineering debt. I like to stick to it until it's done to a state easily sustainable, complete in the customer's eyes, well documented and easily serviceable. This is not the easy path - when you compete with peers at individual, team and project levels, who do not abide by the same standard. And you cannot rely on middle management for the intellectual sturdiness to dig deep in evaluations comes the time to pass judgement.
Based on these tenants there are a few recurring initiatives I took during my career.
- Engineering manuals: The initial ramp-up period in a team is a critical time for any new member. Are they going to learn the trade quickly so they can be productive? Many have to struggle to pull essential information from their new colleagues to get their job done. Many teams are stuck in a strong oral tradition where knowledge transfert is an initiation ritual, a hazing. I've picked up two pagers riddled with obsolete information and transformed them into full fledge guides to daily activities of our engineers, living documents which each new team member benefits from and in turn contributes to. This is even more so relevant today as the industry is pushing ahead with a dev-ops approach where the same individual needs to engage with customers, design features, implement, test, document, deploy, operate. As we engineers are stretched even thinner, we need to fight our instinct to by-pass any written material, combat the fallacy of code-is-documentation and invest our time in thoughtful writing to help ourselves and others perform.
- Foster a community: Through MDSN forums, blogging, yammering (with Azure Advisors), advocate for open and complete documentation, and where possible Open Source. (more on that later)
- Mentoring: It is a pity that the internal career mentoring program that used to match mentors and mentee at Microsoft is no longer. I am now volunteering semi-monthly mentoring hours at EverWise. I've been impressed by the quality matching done by this company. It is very rewarding to see a protégé apply the skills learned and practice ideas discussed in mentoring sessions.
- Explored diverse staffing approaches: I've been an interviewer for most of my time at Microsoft, a hiring manager, used staff augmentation, managed services vendors and articulated delivery-based supplier contracts.
- As an interview I see too many limiting themselves to a l33t coding question and feeling good about themselves that they raised the bar and made it very hard to get in the team. It's a very trendy approach in the whole industry at the time of this writing. Not only that behavior is counter-productive, even the candidates that do make it through the gauntlet are unlikely to be what the team needs: you end up hiring think-alike clones of one-self, created a dangerous mono-culture, racing ahead like a chariot of wild horses with blinders. I find myself often arguing for the soft skills a candidate bring to the table -communication clarity, empathy, teamwork, social intelligence, work ethic, ... -, and original approaches they come up with to solve problems -which does require asking to solve problems with potential for alternative approaches-.
- As a hiring manager I strive to better leverage the tools at my disposal, while challenging the process boundaries. It starts with a quality job description - there you need to give a precise idea of the team that's hiring, the project that's available, the skills and qualifications required. And on that last, it is important not to be stuck in a rigid mentality - yes they are prestigious school out there which students are prime candidates; there are also degree-less self-though candidates who would be a miss not to consider. I engage directly with the sourcing team so they funnel a rich set of quality candidates for the team. Besides the traditional sourcing team for industry hire, I took advantage of the quality graduates coming from MSSA academy for veterans, hiring events for new graduates, the internship program and the many internal job aliases / resource groups for minorities at Microsoft. As I get to review resumes, conduct phone screens and on-site interviews, I keep a feedback channel open to the sourcing team and recruiter so together we iteratively improve on the search for the right individual. For on-site interviews, it takes work to prepare a thoughtful loop. I make sure there is a balanced set of interviewers, each with an area to focus on with the candidate to build a well-rounded picture at the end of the day.
- Staff augmentation and contract-to-hire (more on that later)
- Use of vendors (more on that later)
- Adopt the best tools: From internal static code analysis tools to public ones, from kernel mode drivers to managed code, from test secrets in Key Vault, code coverage and fakes to ReSharper or busTrace, you've got to use the best tools and convince teams to adopt them.
- Re-use, re-use, re-use: Code, ideas, implementation. Pioneer the adoption of KMDF with CDROM.SYS and eliminate the redundant third of the code base. Don't start a space allocation system for a distributed file system from scratch - go talk to the knowledgeable NTFS engineers. Don't create a custom compute platform for MDM - migrate off internal distributed compute and leverage Microsoft HPC. Don't create your own engine for SOAP to REST translation - go create a shared GitHub repo and NuGet package for the existing engine in Azure API Management. Sharing, collaborating, re-using is hard. People will frown upon not-invented-here; people will be scared by the inherent regression risk for sharing a common component; interfaces become contracts and breaking change must be avoided or carefully handled. It is not easy, it is the right thing to do. And you've got to have that higher expectation of yourself not to take the short cut. Dare to share!
Complementary to the things I find myself repeatedly doing, there is also what I repeatedly refused to do. I do things because they are the right thing to do - I do not do things because they are the convenient, easy, or self-serving ones. I don't do something for the sake of a promotion. I don't lead an initiative because one has to have one to brag about comes review time. I don't go present that thing for the sake of visibility. There is for sure a cost to that, I am well aware. There would be for me a greater personal cost to ignore my principles. So in the end, I might not be a principal engineer, yet I do consider myself a principled engineer.