As someone that was employed to write code, I tend to think in code. Repeatable processes help me when situations become tense, or chaotic, as they often do as humans struggle to build with software. The day-in-day-out grind can cause you to trip up or take shortcuts that are detrimental to your team's health. There are some things that come up quite often due to the natural tension between a company and the engineers it employs, generally you could categorize most of this down to "trying to get more with less".
Software developers tend to be more expensive and slower to deliver than their counterparts in equally technical, or complex, positions. Anything at scale is hard, basically, software doubly so simply because its so darn good at scaling to the moon and back. Making sure you're prioritizing the right things while you're actively building software, rather than planning or thinking more strategically, is critical. If you don't, your project will at best be more difficult than it needs to be, at worst turns into whatever they're calling Twitter.
Building something for months or years turns a lot of management instincts upside down. If I tell you to stop focusing first on efficiency, speed, or keeping people's workload full you might think I was here to sabotage you. When you're building for a long time, momentum is one of the most important things you can keep healthy. This can be done with more than this list, but if you focus instead on collaboration, predictability, and the people doing the building, a team's momentum turns into a battery you can rely upon.
Collaboration before efficiency
if (collaborationEvents.length > 0
&& teamSize < TEAM_MAX)
{
doCollaboration()
} else {
focusOnEfficiency()
}It's important to ask questions about simple things. Why do we have teams of people working together? I think a single person working on a thing has the capability of being quite efficient. There's no communication overhead, no one to convince about how things should be done. As soon as you add one more person the potential for efficiency goes down, but what two people are capable of working together exceeds what they could each do alone. When working on a team you should lean into the strength of a team, collaboration toward a shared goal, before focusing on efficiency.
Oftentimes a task will come across a team that is obviously suited for an individual with a skillset that matches up perfectly with it. Potentially the most efficient decision would be to assign it to that person and let it get done quickly. And the next time, and the time after that. This works until that person is out sick, or has left the company. Perhaps this is a skill some or all of the others on the team want to learn, whether it's for personal / career development, or just for fun. Sometimes it's the opposite, no one wants to do it because of the drudgery or complexity. Having more people level up on work that interests them, or share the burden of something no one wants to do always yields vastly improved results.
In a teacher/student environment we have a win-win situation. Teaching someone is not only rewarding on its own, but the thing you're teaching is further solidified with a deeper understanding while you're teaching it. Someone learning something new and fulfilling will improve their morale while increasing the number of people that have that skill on your team. This nets you more people that are better at their job all around.
If before you had an individual quietly fixing something that constantly breaks, or needs manual intervention regularly, you can break this cycle by adding more people to the process. The person that held it all together gets help, sometimes this can prevent burnout or employee retention in a serious way. Bringing more people into a situation like this can also give you unexpected results: a process that wasn't automated gets automated away because fresh eyes see a similar problem from the past.
Fostering this environment will empower your team to continue this collaboration without being told to do so. People will automatically jump in to help those that need it, or offer their support to teach those that want to learn. This starts to become a fun place to go to work every day. It creates a cycle of more capable and happy individuals which leads to the feeling of rampant creation anyone that's been on one of these teams will recognize immediately.
There is an upper limit to how expensive collaboration is on a given team. Communication scales exponentially for every new person on a team, which in extreme cases can cause everything to grind to a halt. If you're going slow in spite of having plenty of people, there might actually be too many people working the problem. There are also best judgement calls you will make regularly about critical fires that come up that take precedence, as long as this is not the norm this is totally normal. Efficiency is important, but not if it kneecaps your team every day away from what will help them grow and work on what they feel will empower them or make them grow.
You'll know you're at the happy balance when the team is learning and having fun, while at the same time delivering at a steady pace that is predictable. If not, focus more on collaboration and growth on the team.
Predictability before speed
do {
performWellDocumentedTaskList();
} while (criticalInterruptTasks.length < 0)Allowing your team larger blocks of flow state is one of your highest priorities as a leader. Being able to have time to think through complicated problems is required of anyone juggling complexity, but for software developers it's seen as sacrosanct. There will always be some team meetings and planning sessions as constant background noise, so anything you can do you take away other distractions will be hugely beneficial. Allowing people paid to think deeply to do that deep thinking unlocks a lot of things that will benefit both in the short and long term. This has the added benefit of increasing predictability because we can focus on root causes of bugs, paying down tech debt as we go, and is anti-crunch-culture.
With the breathing room you've helped to create, you'll suddenly find you're not constantly chasing bugs down because you're giving the time necessary to find the actual cause of the problem and fix / upgrade whole systems if necessary. You can encourage them to make improvements as they build, for a constant tempo of refactoring away that dreaded tech debt. On a long enough timeline, both of these things unattended drag projects to a dead stop while incidents, downtime, and customer-facing bugs run rampant. Not only is it impossible to be predictably consistent when these are out of control, but you also can't move quickly.
Without this predictability, strategic thinking and long-term planning become fool's errands. All the plans and product requirements in the world won't stand up to a few months time on a team that's been crunched up. That team is too busy chasing bugs, or working in environments that make building new things nearly impossible, and are barely able to tread water with whatever is in front of customers now.
With the team thinking deeply, and given the space to build what they feel is right, I've found this is the fastest you can build with software. To some, this is counterintuitive because it looks slow. If you're building something truly complex with software, you're talking about projects that last years without end. Not prioritizing predictability will be a disaster. Only teams that are predictable are capable of building complex things. Giving these teams simple things, like a sudden bug, and allowing them to work in the same way you'll find they chew those up and spit them out faster than a team you're crunching, and they'll be able to reliably give you a completion date.
In my more than twenty years of experience, I've come to find out that building with code will take as long as it takes. There's very little you can do to make it go as fast as the people with money want it to go. So when we're in the middle of building, the goal should be predictability rather than moving quickly. More predictability unlocks easier roadmap planning, allows for larger blocks of flow for the team, and serves as a great foil for crunch-culture. Prioritizing speed above predictability creates a chaos factory that leads to uncertainty over what you're building and why, which causes confusion, and in the long-term you end up delivering fewer big changes because you're being slowly boiled alive by emergencies. You might be able to move more quickly for a few months, even a year, but soon that will catch up to you.
Humans before employees
switch (whatsHappening) {
case 'LIFE_HAPPENED':
takeCareOfLife();
break;
case 'ALL_GOOD':
keepChuggingAlong();
}My hot take with being a front line manager is you actually need to put the people that report to you before the priorities of the company. Perhaps other layers of management further up that becomes less important - or even impossible, but in my opinion this is my primary purpose where I am today. In the never ending tug-o-war between ruthless business practices and being human beings, I am the only protector of that group of people against the constant assault of manufactured urgency. Unless someone is literally dying on your table, it's always manufactured urgency.
Putting your people's needs as humans with lives first means allowing real life to happen without guilt tripping, or the fear or reprisals. It's simply OK for people to go to an appointment, or take care of a sick kid, or take a vacation, or any of the infinite situations people find themselves in. If you have eight or more direct reports, it will feel like something is always happening - when you have twelve or more something literally always is. Give people support when they need it, ask for vacation pictures, get them excited for parental leave, because all the things they're working on will be fine. Ideally you have built in some time for unexpected issues into your planning, but if you haven't you should be able to tell a reasonable story why an arbitrary deadline has to shift.
To be fully successful at this, you'll need to grow your skills at managing up. Constant communication with stakeholders and your chain of bosses is critical. Giving them regular updates, demos, and wins is all I've ever needed to give my teams the space they need to live their lives the way they want (in a non-toxic environment, to be clear).
By doing all of this, handling the day-to-day with the right mindset will unlock levels of trust with your team you might never have achieved before. Teams of people become solidified around the shared struggle because everyone is arm-in-arm and moving forward with that trust. Allow for space to collaborate and be human, while focusing on predictability for the best possible outcome. Teams that have this leadership will be more fun, and more effective even in the middle of the grind.