Since January 2021 I've moved from being an Individual Contributor (IC) to an Engineering Manager (EM). As a Technical Lead I'd had a lot of exposure to EM concepts so it's been a fairly gradual transition but I feel like after 6 months in the role, it's time to do a bit of introspection about what the role means to me.
<h2>Priorities x3</h2>
When starting out, your manager may define your priorities like this (in order):
<ol>
<li>People</li>
<li>Team</li>
<li>Company</li>
</ol>
For transparency I've seen this list in different orders in other blog posts and it's probably different at other companies and levels of seniority but, for me, this is what works and helps me prioritise my day. I like how it goes from most to least atomic.
If I'm struggling to prioritise things in a busy period or after some time off, I can ground myself by reminding myself of the order I should approach things.
<h3>People</h3>
My primary job is the support and growth of people. I took this job because I'm a people enthusiast - I love working with people, especially supporting them and finding them opportunities to grow. The tools and heuristics I need to do this are (and not limited to):
<ul>
<li>Regular 1:1s, giving regular feedback</li>
<li>Performance reviews, setting short/long term goals</li>
<li>Mentoring/coaching/sponsoring opportunities</li>
<li>Training courses &amp; materials</li>
<li>Hiring activities</li>
<li>Onboarding materials</li>
</ul>
If I get any free time, you can bet I'm looking through my 1:1 notes and cross-referencing with the above; questioning to see if there's anything I'm not already doing for the people in my team.
<h3>Team</h3>
Once I'm confident the people are as happy as they can be and their careers are being developed with realistic goals to strive towards, I can turn my attention to the team.
Teams are all very different - different sizes and compositions with different purposes and tenures - so this is where it gets a bit subjective. The main question I ask here is are we on track to achieve our goals as a team? Or at least moving the needle in the right direction and having a positive effect. Personal goals are often much more abstract and different to team goals; a personal goal might be &quot;Contribute 1 module to our Terraform repo&quot; whereas a team goal might be &quot;Quantify all our team's infrastructure as code&quot;.
This is where things like creating automated reporting can be a great investment of your free time, so it's easy to see where we have cause to celebrate being on track, or might be off track and can course correct. Having a good grasp of SQL from your IC days can help with querying things in a database/warehouse.
Cultivating the relationship between yourself and the Product Manager/Owner (PM) is a key part of looking after the team. If the last 20 years of Dilbert cartoons is anything to go by, Software Engineers can classically view this person as someone adding unnecessary scope and complexity, not wanting to focus on things like Technical Debt or Security; communicating these as focus areas is your job, just like the PM is looking for any Product opportunities and doing their job - Lara Hogan's <a href="https://larahogan.me/blog/team-leader-venn-diagram">Team Leader Venn Diagram</a> is a tool I go back to time and time again to ensure we're not stepping on each other's toes. Constructive disagreements are fine, maybe even healthy, in this relationship but any unwanted friction here is probably a signal there's a breakdown in communication.
<h3>Company</h3>
As a more junior EM this is where I spend the least amount of time. There's plenty to work on in this area, like creating/updating progression frameworks, working on hiring initiatives etc.
My main focus will be continuing to build up the foundational skills above (People &amp; Team), and with experience I'll get more and more chances to tackle something at this level - hopefully pairing with more experienced EM(s).
Yup, pairing still happens at this level - yay!
<h2>People are very different</h2>
Kind of goes without saying really but in all my preparation for moving into this role (the carefully crafted 1:1 documents, setting up meetings, reading many books) nothing can really prepare you for the budding emotional investment you will need make in your reports.
Some reports will need very little of your time. Check-ins and 1:1s are usually a nice exchange of pleasantries, a check if there's anything on our shared agenda and if not how they are performing against their short and long term goals, and anything else I can help with.
Other reports will require more of your time, they will (rightly) question any and all decisions which they feel do not hold up to their high standards. They will ask you to co-create detailed plans about how to get to the next level. You may need to help them micromanage their own workloads through tough periods when things go off track. They will have other things happening in their lives which (it's easy to forget sometimes) is not work, and may need a hand navigating it.
As a manager it makes it very unlikely that 2 days will ever be the same, which is diverse and stimulating, but also means you need a few hats to wear and to make sure you've got the right one to hand.
<h2>Be organised</h2>
One thing I've found as I've taken on more direct reports and got involved in projects at the company level, or during busy periods such as performance review season, is it doesn't take a lot and suddenly you can feel overwhelmed with things to do, and this is surplus to the most important parts of your job - taking care of the people on your team.
It's therefore crucial to be hyper-organised and get into a regular rhythm of when you do things - check your email, check Slack/Teams/whatever, even going for lunch, as things can easily slip the net.
There's a great section about this in <a href="https://www.amazon.co.uk/Become-Effective-Software-Engineering-Manager/dp/1680507249">Become an Effective Software Engineering Manager</a> by James Stanier that does a great job of explaning the tools and approach needed, but it essentially boils down to:
<ul>
<li>A well structured calendar</li>
<li>An all encompassing to-do list</li>
<li>A lot of self-discipline</li>
</ul>
With these basic tools you can abstract away your self management, freeing you up to make the most of any free time.
<h2>Having free time is fine</h2>
Once I'd finished onboarding into my role and navigated my first performance review process, I found myself with huge gaps of free time in my calendar. As an IC, I would welcome this precious time to contribute to the delivery of a project, or start planning ahead. However as a manager this time made me quite anxious - what was I supposed to do in this time? Once I'd actioned all my actions, checked in with everyone and made sure there were no issues, being completely honest, I had no idea what to do.
Fortunately, my manager had some great news for me. This is completely normal and this free time is your fallow time. It's time to maybe go for a walk or pour a coffee and think about:
<ul>
<li>Are your reports truly ok? Is there some reading between the lines to be done?</li>
<li>What do your reports need next to grow? What's on the horizon?</li>
<li>What does the future of your team look like? Can you prepare for any of this now in a favourable way?</li>
<li>What does your own future look like? Are you happy? Where do you need support?</li>
<li>And many, many other reflections that may pop into your head!</li>
</ul>
Let these thoughts form and come back to work armed with enhanced purpose.
<h2>Free time is precious</h2>
This is true for both you and your reports. As an IC I would encourage people to respect the <a href="http://www.paulgraham.com/makersschedule.html">Maker's Schedule, Manager's Schedule</a>; I try to do the same as a manager. As a manager it's rare that I need focus time (it's mainly seasonal, for writing performance reviews or planning workshops etc.) so I try to bend my schedule (such as regular 1:1s) around the best time for my reports.
However once you've completed all your regular tasks, don't forget to carve out some fallow time for yourself, to keep stimulated and ready for the next iteration.

yeshi-kangrang-iuqxv7kFj64-unsplash

6 months of being an Engineering Manager

While perusing Twitter I stumbled across the following video by Lee Robinson:
<a href="https://www.youtube.com/watch?v=R59e1Vl5lO8">10 Next.js Tips You Might Not Know!</a>
If you use Next.js or are just generally interested in it then I highly recommend giving it a watch, there's some great tips which as someone who has been using Next.js for a few years I personally was not aware of.
One of the things Lee covers in his video is replacing <a href="https://reactjs.org">React</a> with <a href="https://preactjs.com">Preact</a> at build time.
<h2>Why would you do this?</h2>
Preact is a a much smaller alternative to React with virtually the same API. The main differences are that Preact does not come with a lot of the experimental features that are built into React, such as Suspense and Concurrent Mode. If you don't use any of these or the more advanced features of React, then you have a good case for swapping it out with Preact.
You could go all in with Preact in development too, but by swapping out React at build time means:
<ul>
<li>You still get to use the familiar React API and ecosystem in development</li>
<li>The change is incremental and easier to remove if you spot a problem</li>
<li>Bigger bundles are generally not a problem in development (React itself even has a development mode which is much larger than the production build) and you'll still get the smaller bundle size at the end</li>
</ul>
Sounds good doesn't it? I gave it a try and this website is now running on Preact 🚀
<h2>Get started</h2>
The good news is there are only really 2 steps to this process, the first of which is installing <code>preact</code> and <code>preact-compat</code> as dependencies:
<pre><code>npm install preact preact-compat
</code></pre>
Or if you're a <code>yarn</code> user like me:
<pre><code>yarn add preact preact-compat
</code></pre>
Once installed we then need to tell Next.js when it compiles that we'd like to swap out React for Preact by using Webpack's <a href="https://webpack.js.org/configuration/resolve/#resolvealias">aliasing</a> feature.
If you don't already have a <code>next.config.js</code> file, go ahead and create this and add the following:
<pre><code class="language-javascript">module.exports = {
 webpack: (config, { dev, isServer }) =&gt; {
 if (!dev &amp;&amp; !isServer) {
 Object.assign(config.resolve.alias, {
 react: 'preact/compat',
 'react-dom/test-utils': 'preact/test-utils',
 'react-dom': 'preact/compat',
 });
 }

 return config;
 },
};
</code></pre>
If you do have a Next.js config file, just make sure it contains the relevant <code>webpack</code> configuration from the above.
And that's it!
I highly recommend doing this as a reversible task on your codebase (like a Pull Request) and if you're using Vercel or Netlify to build Pull Request previews then you should be able to give your website a check to see if anything has broken.
If all is well then you should have shaved a considerable chunk from your main bundle (~20kb).

Photo by <a href="https://unsplash.com/@cadop?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Mathew Schwartz</a> on <a href="https://unsplash.com/s/photos/speed?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>

mathew-schwartz-sb7RUrRMaC4-unsplash

Next.js + Preact

I tend to try to keep as much free-space on my computer as possible. I'm not quite sure why, but if development on a project I'm working on has stalled I'll make sure that source-control is up-to-date and delete the entire folder.
Fast forward a few weeks and, &quot;I wonder if I can use X library with this project?&quot;, or, &quot;I should probably tweak this bit of UI...&quot;. So I dive into the terminal, clone the project to my computer and begin working away.
Except I can't begin working right away. Like a good developer practicing <a href="http://12factor.net">12factor</a> I'm not storing my secrets in source control, so there's always a good 5-10 minute round trip of all the websites I need to retrieve my secrets from. Suddenly that quick thing I wanted to do just doesn't seem worth it, and inevitably it can stop productivity in it's tracks.
But there's a piece of software you're probably (hopefully) using right now which can make this a breeze. Your password manager!
A lot of password managers (<a href="https://www.lastpass.com">LastPass</a>, <a href="https://bitwarden.com">BitWarden</a>, <a href="https://1password.com">1Password</a> etc.) all have command line interfaces (CLI) which can be used to interact with your password vault. These are usually hosted on <a href="https://brew.sh">Homebrew</a> and are free to download. I use BitWarden, so the following command installs the CLI to my computer:
<pre><code class="language-bash">brew install bitwarden-cli
</code></pre>
Once installed, I can use the <code>bw</code> to interface with BitWarden. Great! Obviously most (if not all) commands require me to input my master password so it's super secure. Armed with the <code>bw</code> binary, I can then add the following to the <code>scripts</code> section of a Node project's <code>package.json</code>:
<pre><code class="language-json">{
 &quot;get-env&quot;: &quot;bw get item mikefrancis.github.io | jq -r '.notes' &gt; .env&quot; 
}
</code></pre>
This uses the popular <code>jq</code> CLI (also installed through Homebrew) to dump a BitWarden note with the name <code>mikefrancis.github.io</code> into a <code>.env</code> file, by running the following command:
<pre><code class="language-bash">yarn get-env
</code></pre>
So now rather than running around to different websites, grabbing API keys, I can just keep all these in a secure note in BitWarden. These API keys have no expiry so I only have to update these in one place.
This won't work for everyone but it's a pretty nice way of getting up and running quickly.

Technical Leader, Software Engineer & UI Designer based in London, UK.
Currently building and scaling a modern, renewable energy provider at Bulb.

Latest Posts

6 months of being an Engineering Manager

Next.js + Preact

Quick project environments

Technical Leader, Software Engineer & UI Designer based in London, UK.Currently building and scaling a modern, renewable energy provider at Bulb.

Latest Posts

6 months of being an Engineering Manager

Next.js + Preact

Quick project environments

Technical Leader, Software Engineer & UI Designer based in London, UK.
Currently building and scaling a modern, renewable energy provider at Bulb.