Disruption Insights: Set Engineering Fundamentals and Follow Them Step by Step

Jun 28, 2023 • 9 min read

What skills and approaches are essential to co-create impactful solutions with Microsoft's largest clients? Laurent Ellerbach, a Principal Software Engineer Manager and Representative of the Board of Directors at Microsoft France, knows the answer to this question.

He’s been with the company for over 26 years and is currently engaged in projects that involve the work of about 100 developers.

In this episode of Disruption Insights, Laurent shares, among other things, his proven ways of leading satisfied engineering teams, his approach to testing, and how to ensure great tech solutions are adjusted to customer’s needs, at scale.

We all know that well-defined goals and KPIs are crucial for the efficient organization of technical work, but we believe there’s more to that. The Disruption Insights series aims to uncover how household names manage their tech teams and how it translates into business opportunities.

🎯 Engineering challenges

Surprisingly, the most demanding challenges while managing digital transformation projects involving work of about 100 developers are not tech-related – these are easier to solve. Finding the most agile and efficient way to assist clients in becoming a real engineering company is where things may get more complicated.

To ensure success, it’s crucial to follow previously established fundamentals and to do it step by step. At Microsoft, we gather these fundamentals in various libraries, including the ADO Programmer’s Guide. Throughout my experience, this rigorous approach proved to bring the best results in enabling customers to upskill to the latest Azure technologies.

💻 On the tech side

KPIs and missions essential to your role

My team usually engages in short-term projects (3-4 months) with focus on a very well-defined technical problem. To measure the progress, we create an overall definition of what “done” means for each milestone within the project and they become our KPIs.

An example of a well-defined KPI for a developer: implement the solution X with feature A, B, and C for the scenario S in production by the end of the milestone. We break them into smaller pieces: feature A, feature B, feature C and infrastructure for features A, B, C. It helps us define features, stories, and other crucial elements of the project.

A more granular approach is a distraction, not help. Tracking the progress of features development and their implementation is the most important performance indicator.

Success in the software development process

My recipe for a successful software development process is as follows:

Don’t release products that carry technical debt.

Iterate fast on the features and add some at each iteration.
Automate everything, including the documentation creation while you code.
Have tests for everything: unit tests, integration tests, end-to-end tests, and any other type of test when needed.
Follow agile methodology principles – methodology can change depending on a project, but it should always be agile-based.

Approach to testing, implementation, and eventual rollback

In the teams I lead, tests are mandatory, and coverage has to be decided in advance. Each task has to contain a test, no code can be checked in without proper tests or without all tests being green.

I also follow the “you break, you fix it” policy. Working in large projects with shared elements requires this level of accountability, so if a developer negatively influenced the work of their colleague, it’s their responsibility to fix the broken code.

🤝 Internal cooperation

Do’s and don'ts you’ve learned while scaling tech teams

To effectively form and scale tech teams, document all engineering processes, turn them into a set of engineering fundamentals and follow them step by step. It’s critical to be strict with the established rules, like: “What’s not in our playbook, doesn’t exist,” “What’s not in the pipeline will not be deployed,” or “No demos in the development environment.”

The other important aspect is finding the right balance between sync meetings and time to work. Scrum ceremonies or their equivalents should only involve team leaders and project managers – there’s no need for developers to participate in such meetings.

To track progress, organize a team-wide monthly demo, and arrange ad hoc meetings to cover dependencies between teams.

Building high-performing engineering teams

To ensure high performance, follow engineering fundamentals on the process side, and create a working environment based on trust and a sense of responsibility. Focus on openness must come from the top, so never do finger pointing, instead promote a problem-solving attitude and make people feel they are responsible for their work.

But remember not to punish developers for failures. Failure is a way to learn and improve. So, document it and drive conclusions for new projects to prevent mistakes in the future. Do the same with every learning – document it for future use.

Honest retrospectives are my way to build trust. Only team members should attend retros, there’s no need for a manager to participate or to record it. Obviously, each retro should end with a list of things to be improved and a plan to properly track progress. It’s also crucial to celebrate performance and achievements and demos are a good opportunity to do that regularly.

At Microsoft, when analyzing developers’ performance, we put an emphasis on their willingness to help others. We use it as a success factor and reward it. This creates a positive spin of supporting others if they are blocked and promotes knowledge-sharing.

🧩 Hiring and team management

What skills and traits you focus on

When hiring, the whole company follows the same approach – we focus on different competencies depending on seniority of developers. For junior candidates we use Codility tests, and when recruiting seniors, we’re interested not only in their technical skills, but also in how often they code, whether they are coachable, and capable of working in large, complex teams. We like to do real live coding and architecture design exercises as well.

Making engineers satisfied and preventing burnout

Managers should have weekly face-to-face meetings with everyone from their team to ensure engineers’ satisfaction and happiness. It gives them a chance to spot early signs of burnout and implement preventative measures.

The fact that helping others is a success factor in a developer’s performance review also plays a role in preventing employee burnout. In such conditions, it’s more likely that someone who suffers from burnout will be spotted by the rest of the team and will get support.

Leadership style you prefer

I lead by example and pick tasks up because there’s no such thing as a bad task, there’s only a job to be done. While working along my team I focus the most on pull request reviews – I’m the one commenting the most of them within my team and outside of it.

My aim is to bring clarity, focus on the long-term vision, build next steps within projects, and over-communicate them across units and departments. I also strive to connect people and promote the culture of learning, proactively helping each other and asking for help.

💡 Looking into the future

Software development trends

I’m sure edge cloud technology will grow in importance. I also think developers will use AI in their work even more often in the form of Copilot or equivalents.

This will require them to gain new skills and learn how to use and adjust accelerators, not just trust them. It also means improving competencies around pull request reviews, more focus on testing, and working with low-code/no-code technologies.

Bets on the future of development teams organization

Teams will be organized into small units that own the whole development process – from the infrastructure, through data, to UI – all this augmented with AI tools. I also think agile methodologies will be adjusted to be ev

en more flexible.