Speed is a key feature of successful development teams and organizations. As software developers, it is our job to turn abstract visions and ideas into something that users can touch, feel and use, the faster the better.
1:1s can be the most dreaded meeting of the week, both for managers and employees. But they are also one of the most important tools in a manager’s toolbox. Properly and consistently executed, 1:1s hold the keys for going from decent to great relationships with your reports. And having a good working relationship with your team members truly makes your life so much easier as a manager. It allows you to catch potential issues before they become real concerns. To build a healthy feedback culture where you both give and receive honest feedback. Address performance issues in a constructive way. Understand what motivates and drives your employees so that you can assign tasks accordingly. It’s an opportunity to explain and give context, resolve conflicts and have crucial career conversations. Basically, all the things that will allow your team to run as smoothly as a well-oiled machine.
During recent years, I’ve come across (and worked with) three basic variations of the Tech Lead role. While the essence of the role remains relatively constant, each flavor adds some interesting characteristics and comes with its own pros and cons.
So, what is a Tech Lead and why do we need one? As with most roles within our field, there is a fairly wide spectrum of definitions. However, most people tend to agree that the role’s primary focus is to take responsibility for the technical quality of deliveries within a defined area and that it includes a mix of programming, architecture, project management and leadership. It is usually not a full-time management role, meaning that the Tech Lead is still expected to code at least some part of their time. As such, it is often seen as a good next step for someone with a few years of experience as an individual contributor, who now wants to take on more responsibility and dip their toes into leadership, though approaching it from a very technical angle.
Over the years, I’ve seen way too many engineers get off to a bad start during their onboarding process. And even though the evidence is very much anecdotal, I think it is fair to say that the onboarding phase is one of the riskiest parts of an employee’s lifecycle at a company. Get it wrong, and you risk losing your hard earned recruitment or have them create a mess in your team that you’ll spend months cleaning up afterwards. Get it right, and you’ll soon have a highly productive, motivated and loyal employee that boosts both the efficiency and morale of your team.
“This code base is a mess, we need to spend more time on refactoring”. Chances are, you’ve heard this complaint from developers in your team on more than one occasion. Probably even said it yourself a few times. And while most of us can sympathize with a statement like this, the analysis usually doesn’t go much deeper than that. Way too often, the next step is simply to put your noise cancelling headphones on, roll up your sleeves and dig into it, randomly refactoring pieces of code that happen to cross your path. I think we can do better than that.
When joining a company as a technical manager, one of the major challenges in front of you is to learn the details of the technical platform(s) that you are responsible for. You are most likely not coding any more, or at least not making any major contributions to the code base, and with your days filled with meetings and other management duties, it can be a real challenge to find the time to actually dig into the more technical parts in order to get the understanding needed to do a good job.
In my opinion, one of the best, and perhaps also one of the most underappreciated, developments in our industry the last couple of years is the State of DevOps report and its companion book, Accelerate, that presents the findings and the research behind it in more detail.
Recently, I decided to dig a little deeper into consumer driven contracts and more specifically the Pact framework. In essence, consumer driven contracts are about having consumers of a service define their expectations (i.e. contract) on that service in terms of tests that can be executed on both the consumer and the service provider side. Such tests can then be run as part of the CI build of the service provider as well as the consumer. If done right, the provider service can evolve independently as long as it doesn’t break any of those tests and you therefore limit the need for extensive end-to-end testing as a means to catch breaking changes. Which is good since such tests can be both time-consuming and fragile. In this age of APIs and (micro)service oriented architectures, I think this is a very interesting approach to QA and test automation. And arguably also a fairly underutilized one.
subscribe via RSS