One of the things that is challenging in Digital Services is keeping track of all of the projects and their statuses. I've found that misalignment among the leadership team happens really quickly, especially when things turn in to a "matrix management" situation.
One of the challenges that I've faced in my past is having a CEO who is a genius level developer, grew a small company to a size to where they needed help in running the development team because they wanted to focus on growing the business, but then proceeds to be involved at a technical level on all of the projects. What was interesting in this case is that early on in my tenure there, I was consisitently chastised for being "too close to the metal" and that I needed to be focused more on process, documentation, morale, supporting sales. Now, I agree to some degree with all of these. I inherited a very junior team, additional headcount for developers wasn't there, and now I needed to build up a solid foundation. However, the CEO can't help themselves except get involved in technical things, and in a lot of cases, openly countermanding certain things that I had said.
This can be described as a "managing upwards" issue. The CEO has a desire to be involved and a way that they want to see the development teams run. They've also got certain expectations from the developers since they've worked with the devs for some time in the past, and expected to see (too much) growth under my leadership. I think finding the right level of "in the trenches" and being above it all is really important. I'm still looking for that medium, and I don't think I have a lot of advice here other than it's kind of like the dating scene. People say they want a bunch of different things, but when it comes down to what they actually want, there is a big difference. Discovering those things requires time, patience, and grace under fire.
Honestly, leading the developers themselves in these cases is really a lot less of a challenge than working with the rest of the business as a leader. The biggest issues that I've had are:
One of the things that businesses have relied upon for quite some time, especially those in the silicon valley, is that the developers are going to be somewhere between passionate and motivated to insanely passionate and motivated. This is not going to be nearly as true as you would hope, both here in Japan, and at digital services agencies.
The digital services model has a problem with projects being very short term (1 - 3 months), and longer term engagements tend to have people coming on and off the project in order to minimize costs by the customer. The "Full-Stack" developer actually does fairly well as a hiring paradigm here because they tend to be able to provide more continuity to the project that others might be. Yes, a specialist front end or back end developer might be best, but you're not in the business of the best. You're in the business of meeting the requirements in a reasonable period of time for a reasonable price. What this does mean though is that developers don't really tend to feel a lot of ownership or responsibility for the project. Everything is just another person's thing. It's super important to have your clients be humanized here, so that means putting your devs in front of them. Early envisioning of the project should involve the devs that will be on the team, or at least getting them in to one meeting with the client.
If you use Project Managers, it's going to be really important that the PMs are keeping the team up to date on how the client is feeling, ensuring that the requirements and scope are being managed both to the team and from the team, and talk about the impact and excitement from the client with the progress. Mitigating the inevitable disappointment when you move from the early stage of a project where massive amounts of progress are seen every day, to the slower parts where bug fixing and polish are the name of the game is also key. If they're not excited and sympathetic with the team, just a mouthpiece for the client's discontent, you're not going to be able to manage the devs out of that hole.
Too much or too little communication is a real killer. Too much and you've got a really weak signal to noise ratio on the work that is being done, what has to happen, and what kind of issues or roadblocks you might encounter are. Too little and you'll find that a lot of devs will spin their tyres without letting you (or other teammates) know that they're stuck. If you've got a remote work setup, then you really need to monitor progress closely. A day late will snowball in to a week quickly if things aren't addressed immediately. The smaller the project, the more involved you have to be in monitoring the progress as well. A solo developer can be amazing, so can a pair, but it can also lead to a lack of communication to you outside of that bubble. PMs are also notorious for not surfacing issues.
Depending on your organizational structure, you might also run in to similar issues as I have. People will naturally drift towards speaking with the highest level of authority easily available to them. If the higher authority is responsive to their communications, then you're going to have issues on two fronts; The first is that you're being worked around and out of the loop from the bottom, the second is that the higher up will expect you to know things you don't.
Not pushing back on, clarifying, or otherwise assessing requirements put forward in specifications is a great way to find yourself in a position of underdelivering. Devs need to feel empowered to push back against insufficient details or requirements. Some requirements are implicit based on company standards of quality and functionality, but most things aren't. In digital services, it's especially true as most things that we believe are "no brainers" still take up a considerable amount of time to implement and test effectively, and that turns in to billable hours. Part of this is also assessing the scope of the changes that the requirements will have. For instance, if you're adding role based access to some resource, it's not enough to just test that the role can access it, you've got to test that other roles _don't_. Depending on where the resource is used and how you've architected your security model, you might have a multiplicative expansion in required testing that needs to be done to ensure that things are working correctly. Understanding those knock-on effects of seemingly small changes is critical for managing client expectations.
Clients are happy when they get what they were led to expect. They aren't when they don't. No amount of bonus/free work, extra features, better coding, etc. is going to salve the damage done by not meeting their expectations.
Our experience as developers is very important when you make the decision to lead a team of devs, or even a department of them. We've generally been seen as effective in the role, but also have the necessary soft skills (or at least the potential of developing them) to "herd the cats". It allows us to critically assess proposals from our developers, ask the right questions, help people get unstuck, and generally gives us an air of authority that developers (usually) respect. However, our experience often betrays us as we move along in time as managers. If you're not developing software day-in, day-out, you're going to be falling behind. Your team's knowledge will be more recent, more valuable, and closer to the world as it actually exists than you are (some exceptions may apply). This means that the longer you've been out of the game, the more you'll be more of a "sanity check" rather than an actual authority on the subject.
This was one of the hardest lessons for me to learn, but one of the easiest to overcome once it happened. I was a decent enough developer, and I was praised for my code quality, productivity, and clear communication as a dev. This was all key for moving me in to management, but as time wore on and I stopped coding every day, all day, I stopped being up to date in my domain. Technology moves faster than ever now, and when one of my talented and motivated developers went ahead and stood up a client stack using a whole new set of tech that was new to _me_, I pumped the brakes on it. On one hand, it make sense to do so. The stack wasn't agreed upon with the rest of the team, the pros and cons weren't talked about, and there was a lack of regard for our company's policy of selecting "boring technology". On the other hand, after looking in to to selections, it made sense and it was obvious that I was definitely choosing more boring tech than was necessary. After this, I established ground rules for what we chose and how we come to those decisions, and gave them free reign to pick what made sense within those boundaries.
When moving in to these roles, you do need to try your best to keep up to date with emergent technologies. Attending conferences, reading blogs or articles, following important people who do code every day that you trust, and talking to your team are important techniques to learn. It's also important to learn how to put a stop to overzealous adoption of unknown things, even if the choice makes sense in the end. Being too lenient on choices, not keeping things in line with the greater organizational goals, or otherwise allowing "resume driven development" is key. Being able to approach these occasions with a genuinely curious attitude is incredibly important. When I put a stop to the process in the above example, I asked questions which at the time felt curious, but on reflection didn't express that I was being cautious because they were new to me, and as the person who was ultimately accountable for our choices and ensuring that we're selecting the right tools, it was important to align on these things ahead of time.
To be continued where I discuss challenges that I still have
Authored by: Mal
Written: 2023-12-06