# Leading Devs In Digital Services

This will be part 1 in a small series of relatively unfiltered/poorly structured writing on the topic

Despite my leftist inclination, I've often been moved in to postions of leadership within the firms that I've worked in. I've done it in my previous career, and I've somehow done it again in my software development career. I'm not an extremely competent developer, merely "good enough" when it comes to writing software that does what it's supposed to, and little else. It would seem that most places I work at appreciate that kind of level of ability, but want me to focus on things that are often considered to be less common in our industry, the "soft" skills.

# The Job

The job itself doesn't sound too terrible, and maybe I'm exposing some kind of incompetence on my part of things, but it's primarily around keeping the teams disciplined, preferably motivated, shield them from the pressures of managers above your level, and deliver whatever is expected by your customers to your customers. There are a lot of different nuances depending on company structure, size, the business model, and what industry your software firm is serving, but that's kind of the jist of things when you've been given the role of "manager" and the responsibility of managing that team's performance and output.

Reality, for people working in digital services, is really different.

# Learning As A Manager

One of the weird(er) things about software development management adivce around the industry is that it's almost completely focused around the structure and needs of product companies. I reckon that's a fair go since the majority of companies are product companies. Larger firms also tend to have pretty reasonable advice available to them because their kind of size really fits with the proferred experience and advice coming from people who have sufficient experience leading people. That's not my realm. I work at one of the many digital services companies out there that serve many different clients by developing software for them. When you've got an development department of less than 15 people, you're in a weird spot when it comes to managing it. You're large enought to require dedicated leadership, but you're small enough that the clients and projects that you attract don't really require a full team of people. Oftentimes, you've got one or two developers working on a project for 2 - 3 months, but then the projects available afterwards have them going different paths on different schedules. This flies in the face of what it (normally) takes to build a great pipeline of developers with time to build and thrive as a team and changes what you need to look for in your development team.

Talking to people who are currently working in your part of the industry also means you're working to improve the competition. We can wax on all we want about how competition is good and holy, but as a pack of commies, we know that it's simply not the case. Capitalism abhors competition, and while I'm leading teams at the firm, I need to make sure that I'm getting the best I can for my team while trying to maintain that competitive edge. As a company that is based in, and employs people primarily living in, a high cost of living country, we can't compete with the market on speed or cost. People who want fast and cheap will live with the absolute bitterness of low quality from development houses out of Vietnam. We need to do it on quality of implementation. When talking with other leaders who do the same thing, it's very easy to expose your stengths, weaknesses, and possibly client list. When you discuss quality issues with people who know your pain, but are also your competitors, it's a good time to strike at their clients. It doesn't rule out everyone, but it definitely allows for people who are directly working in your niche to outcompete you especially if you're not currently killing it.

So what's a guy to do? I suppose it's up to you to determine whether or not someone in your sector is someone you don't directly compete with so you can roll over and not get bit. I'm not sure. I don't think I have the right answer to this yet. I talk with my peers, but I do find that some of the advice just doesn't apply to what we're doing, but I do my best to adapt their successful ways of thinking to what I'm doing and drop those things that I think aren't working out.

The same goes for books that are out there. Team Topologies by Matthew Skelton and Manuel Pais seesm to be a great book for people who are leading companies where teams can be relatively stable and projects are going to be at least 6+ months long with fairly consistent across the board. At the very least, companies that have a single product with a clear vision that everyone is working towards even if they are not able to be working on the same set of features the whole time. A single, unified vision.

# The Projects

Depending on your firm and the success of your sales team, backed up by your developers, you can be getting projects from a couple of weeks from a single developer all the way up to a multi-year deal where you build out a full application, iteratively improve on it, and then operate/maintain that software for years. Chances are though that you're going to be skewed pretty heavily over to the 3 - 6 month range of things if you're good and charge a price commensurate with the kind of developer salaries that the North American/European paradigms have provided. It's long enough to get a little invested in the project itself, but too short to really get that dedication from people who are motivated by wanting to build out a project that feels a lot more "theirs".

Great projects will have driven product owners from the client side that have a dream, but just lack the capacity to back up those dreams. They energize the team, sell that vision, and you can really feel that energy from the dev team. You can really pick up a lot of forward momentum here, and if the project becomes technically challenging, the work becomes monotonous, or you lose a couple of people along the way, it's not a big deal. It's not great, don't get me wrong here, but you can use that to roll over those humps.

The not-so-great projects are ones where you've sort-of convinced the client that you can do things for them in a hype based market and they don't want to miss the boat on insert amazing technology here. The crypto wave was a big part of this, but some people definitely got really, really rich off of that grift. AI is the current madness, and while being significantly more "real" than crypto ever was, it's still a lot of grifters out there selling a very weak wrapper around OpenAI's API. Now you've got a client that doesn't know what they want, a sales person who has closed a deal on the value of the hype, and a development team that can struggle to find direction and meaning in their work, but also get stopped by small obstacles in their path.

This is not dissimilar to what people working at product companies can encounter, but it's definitely amplified. Dead projects, proof of concepts, failed software firms, derisking by your company on hires, churn on the team because of project needs and resourcing, etc. all seem to be at that next level of shit. At product firms you've got your baby to kind of take care of, hopefully existing long term and new customers to respond to, and a steady team of coworkers to develop real dynamics with.

I don't think there is a solution for this unless your company is strong(?) enough to basically have a lot of long-term partnerships where your average project length is something like a year and a half. Maybe someone breaks off from a team for a short bit to cover a smaller project, but overall, you've got pretty steady teams that are mostly upper intermediate to senior level developers, self-driven, and it trends "beyond the hype".

To be continued (I know I haven't really gotten in to the "leading" part yet)

Authored by: Mal
Written: 2023-11-03