The LeadTech Diet - Issue #5
Engineering Management II | Prioritisation | Serverless
Engineering Management (Part II)
What does an Engineering Manager do?
In this issue we’ll continue our series on the different aspects and responsibilities of engineering managers and talk about Technical Excellence.
If you have no idea what I’m talking about, have a look at the Engineering Management pillars below for reference to previous and future (once written) issues on the topic:
Technical Excellence (this issue)
Let’s get started.
Technical Excellence
As an Engineering Manager, your performance is no longer measured by your ability to solve complex technical problems, write high performance code or your understanding of distributed systems. Instead, you’ll be measured on your team’s ability to deliver a quality product.
However, you must absolutely be technical enough so that you can both build trust and guide your team when necessary.
It’s very difficult to manage engineers if you don’t understand their world. So while you may not be the most technically gifted engineer in your team, you should still have a strong foundation and opinions on the following areas:
Programming Languages
Architectural Styles
Automated Testing
Engineering Metrics
Programming Languages
More important than knowing one programming language really well, you should be competent in a few different languages that expose you to different paradigms and language design approaches.
Specifically, understanding the differences and trade-offs between dynamically typed vs. statically typed languages as well as object-oriented programming vs. functional programming will certainly pay dividends over time.
Architectural Styles
When should you advocate for microservices vs monoliths? Should you transfer data in batch or stream it in realtime? Should inter-service communication be synchronous or asynchronous?
As you probably guessed, the answer is it depends. The more you understand about the trade-offs, the better equipped you’ll be to ask the right questions and steer the discussion.
Automated Testing
Engineering teams are accountable for the quality of the products or services they build, from code and architecture to end-user experience.
Automated testing is a big part of ensuring the quality bar remains high and regressions introduced by code changes stay low.
A lot of teams will under-invest here because they think it’ll slow them down.
In fact, having a reliable test harness will have the opposite effect, which reminds me of a quote I heard sometime last year that stuck with me:
What is the goal of the brakes in your car?
They allow you to go faster.
Engineering Metrics
With all that’s going on in your team you’ll want some metrics to keep an eye on how everything is progressing. This topic has as many questions as it has answers however I find that the following high level metrics can tell you a lot about the health of an engineering team:
The DORA metrics;
Test Code Coverage (both at the unit and integration levels);
# of defects reported by customers (which means they escaped your test harness);
A measure of Cyclomatic complexity, modularity, and coupling;
Each of these will be more or less useful to you depending on the type of product you’re building and the maturity of the team you have.
Conclusion
The list above is by no means exhaustive - and you can probably tell the job of an Engineering Manager is anything but easy.
They need support. It’s incredibly important to engage with the rest of the team and technical leads to ensure everyone is contributing towards technical excellence.
LeadBytes
Prioritisation
There is always too much to do. Both professionally and in our personal lives. Choosing how we spend our time is, well, our top priority. It’s a scarce resource and once wasted, you can’t get it back.
But how do you choose what to do first?
One tool I find useful is the Eisenhower Important/Urgent Matrix:
It’s a simple concept but very powerful as a tool to both help you prioritise as well as effectively communicate and negotiate your priorities in your organisation.
What other tools have you used to help you say yes to the right things?
TechBytes
As Serverless as It Gets
I’ve been doing this [software thing] for a while. When I started my career, I wrote Windows desktop applications which connected to a database server inside the “server room” in our IT department.
I also crimped dozens of network cables, replaced network cards on servers and restored backups from tapes. Then web development became a thing and all our lives changed for the better.
But I still needed to rent a server - however virtual - with a specific amount of memory and processing power, set it up with an operating system, install all packages required for running my application, upload the source code, fiddle with the Apache configuration and then finally - some 5 hours later - I’d have a “Hello World” application running.
We have certainly come a long way...
…and now, we have Dark Lang:
I came across Dark recently. Its creators describe it like so:
Dark is a new way of building serverless backends. Just code your backend, with no infra, framework or deployment nightmares.
I went through their tutorial and I had a hello world RESTful endpoint running in seconds.
Obviously there are many open questions:
How do you do version control?
What is the approach to automated testing?
How do you handle multiple environments?
Who do you call when it invariably goes down?
…
However, it could be a game changer for quickly prototyping backends, validating hypotheses or building internal tools. I will certainly be closely watching where this goes…
Check out this live demo to get a feel for it.
If you have a question for me or a suggestion for the newsletter , please submit it here - I’ll address as many as possible in coming issues.