Fahim ul Haq is the co-founder and CEO of Educative, the world's leading upskilling platform for and by developers. He is a former software engineer at Microsoft and Facebook with a deep passion for creating better, more efficient ways for developers to master in-demand skills.
Hey, I’m Fahim. Previously a software engineer at Microsoft and Facebook and now founder of a startup educative.io.
Do you remember your first job as a developer? I remember the first time I stepped through the doors of Microsoft's Redmond campus and the feeling of exhilaration for what lay ahead. That was a long time ago. Since then, I've had many more exciting career firsts, from finding a compiler bug (more on this in a future newsletter), joining Facebook (now Meta) during a peak growth phase, and perhaps my favorite first, becoming a founder of Educative. And while the logos and titles may have changed, the challenges of being a developer have not.
Engineering Enablement is a driving topic I’ve wrestled with since my earlier career days as a software engineer. It may not have been called by this name back then, but it’s a nuanced and complex topic that knowledgeable people and influential organizations worldwide are working to better understand. Articles such as “What is Engineering Enablement” helped shape my thoughts around this topic, and it’s encouraging to see more traction on a topic that needs more engagement.
I started the Engineering Enablement Newsletter to share learnings and conversations with others in the tech industry to build a community of individuals passionate about enabling developers to be more productive and successful. At its core, I believe Engineering Enablement covers three core tenets —
Ensuring developers are:
Aligned to the company objectives
Engineering Enablement priorities can look different from various perspectives across the organization. Developers are concerned about their work and careers, engineering and technical leaders are concerned with retention and team growth, and business stakeholders need to meet their goals. But no matter which of these groups you’re speaking to, they all align on those three core tenets.
For now, let’s start with the core tenet that I think about every day — technically equipping developers. Taking my background as a software engineer and now leading a product-driven tech startup, I’ve picked up on some critical areas of focus to help developers reach their full potential.
Here are ten pillars for technically equipping developers:
IDEs (writing code)
Task and bug tracking (project management)
Deployment and CI/CD infrastructure
Testing and verification
Performance reviews, feedback, and growth
Over several weeks, I would like to use this space to reflect on the industry and start to answer two important questions for each pillar:
Does this practice of engineering enablement have a significant impact on developer productivity and well-being? And if so, how and why?
What tools, practices, and management styles are available today that address this focus area of engineering enablement? And how are they successful?
For now, let’s have a quick overview on ensuring developers are technically equipped.
1) Developer onboarding (lifecycle)
An onboarding experience is the first impression developers encounter when joining a new team and company. Smooth and customizable onboarding ensures a fantastic developer experience and impacts their time-to-productivity. Overall, the onboarding process affects developers on a personal level and leaves a larger impact on a company’s goals.
Tied to a developer’s lifecycle, developer onboarding is more than just the first couple of months at a job; but has three distinct phases or stages of ramping up:
Minimal workable knowledge
Long-term mindset for the team
Throughout a developer’s lifecycle at an organization, their onboarding stage helps define potential impact and defines the necessary components to navigate to their next career stage.
There are two different kinds of collaboration:
Ephemeral collaboration usually happens in messaging apps like Slack or Teams. Conversations typically include asking if people are in the office or not or checking in on a teammate.
Long-term collaboration consists of one-pagers and documents that are important for the learning process of anyone who might join a project. Documenting collaboration around earlier discussions is necessary for quick decision-making.
With globalized companies and distributed teams, asynchronous collaboration tools should prioritize defining remote work as a norm than an exception. Ideally, people on the tool seamlessly collaborate on each other’s work and make sure people aren’t blocked. We’ll cover this and other important collaboration priorities in more detail with upcoming newsletters.
3) Developer environments including IDEs (writing code)
Your organization’s development environment, including IDEs, enables developers to write and debug code faster. This includes desktop applications such as Visual Studio, IntelliJ, or Eclipse. There are also cloud-based IDEs such as Cloud9, Replit, and sandboxes.
Ultimately, developer environments should provide developers with a performant coding environment that can run on their machine. Docker technology helps create an agnostic solution for companies with a wider range of hardware for remote teams.
I’ll later cover why internal teams should invest in writing custom plug-ins that enhance the experience for your organization, while also covering the importance of internal documentation, internal libraries, networks, and VPNs.
4) Code repos
Essential to any software engineer’s work are the products used for code management. Every developer needs a performant repository to collaborate, ship, share feedback, check-in with each other, and check out code. Great tooling leads to better products, whether the work involves rollback to different versions or looking for a bug.
GitHub and Gitlab are the main repositories used by developers, but there’s also a greater conversation around mono or multiple repos. Let’s discuss this in future articles.
5) Code reviews
The code review process is vital for developers to create quality code and collaborate on the new code created. Whenever developers submit a pull request and make a change, other developers need to look at the code and give feedback.
Great tools facilitate code reviews and enables teams to ship better products. But code reviews is as much about culture as it is about great tooling.
If you’re not deliberate about creating a good code review culture, they can become toxic. I’m fairly passionate about this topic, so I look forward to discussing how to create a good culture around code reviews that is productive and helps everyone learn to grow.
6) Task and bug tracking (project management)
Project management tools such as Jira and Asana ultimately serve two core purposes: bring clarity for your engineering team’s deliverables and track tickets to provide stakeholders an overview for estimations. Developers can be assigned and given predictability to what they expect to do and its urgency. It also provides clarity to leadership in a sprint and for the next release cycle giving more insight into the feature roadmap.
7) Performance reviews, feedback, and growth
Without a regular cadence of reviews, developers would not receive the critical feedback needed to grow in their careers. Great feedback at a steady rhythm allows them to do that. Developers should be able to track their performance and personal goals they’ve set for themselves for the next review cycle and keep themselves accountable.
Alongside personal accountability comes transparency between the developers and their managers. Growth is important to both engineers and their managers. Great engineering leaders intentionally create a culture of feedback, and timely feedback provides opportunities for consistent growth within engineers and their teams.
8) Deployment and CI/CD infrastructure
Without an excellent CI/CD infrastructure, software engineers are burdened by the chance their code will break while building something else. While waiting for their code to be tested, developers are either wasting a lot of time or feel demotivated from writing more code.
With faster feedback loops, developers can work on other items, and receive early indications of how their code will perform in production.
9) Testing and verification
Testing is part of continuous integration and an essential aspect of every software engineer’s work. They are burdened by whether the changes they are trying to merge will work before moving on to the testing environment.
I’m eager to share how testing frameworks should tie into the CI/CD infrastructure. I’ll later cover the importance of creating a culture of writing testable code and why developers should write code they can test to find bugs and regressions.
10) Developer upskilling
Learning is pivotal for every developer’s career growth and ultimately affects a company’s technical debt. New languages and frameworks are created every month, and software engineers need Just-in-Time learning to build better products and build their knowledge base. Meanwhile, early migrations through well-timed upskilling can result in less technical debt in the future.
Ultimately, every software engineer should have easy access to quickly upskill themselves. For future newsletters, we’ll discuss how developer learning funnels into conversation topics such as developer retention, shipping code faster, APIs, developer satisfaction, and frameworks.
There are roughly 26 million developers worldwide, and this number is only expected to grow. As a software engineer at heart, I hope conversations continue to grow on how current and future developers are enabled to be more productive and successful. Engineering enablement has never been more important and will continue to develop as an indispensable part of any tech organization.
It’s a big space, and I’m curious to hear others’ approaches and perspectives as my following newsletters dive deeper into each focus area.
Until then, feel free to subscribe, and let’s talk soon.