I need to adapt some kind of system to my work and work of my team

Question

I work in a small company for 4 years now. My goal was to develop a geographic information system (GIS) website from scratch, which I gradually fulfilled. Today the page is online, with traffic, we are getting offers and challenges what to develop there next, and I have a small team of junior developers.

The problem is that the work is stacking (because our salesman likes to promise everything to everybody) and at the same time I have to coordinate or even teach my team members about the existing system. It's very hard to keep focused on the most complex parts of development, when you hear your name every five minutes.

Does somebody know this pattern? What would you suggest to do?

Answer 1

I see two problems here.

our salesman likes to promise everything to everybody

This is a clear example of siloing. The salesman is putting the Sales department's goals before the business's goals. That needs to stop.

There are various ways you could approach this. The simplest (and what I would suggest trying first) being simply approaching the salesman and having an open discussion.

If that doesn't work, consider having a developer on the Sales team. This developer's job would be two-fold. First, to be the on-hand technical expert. Second, to rein in the salesman should he start promising the sun and the moon.

Alternately, have the salesman start experiencing the pain that he causes. When he's promised too much and something needs to be cut, make sure he's the one to inform the customer that the expected delivery date for that new feature is 2 years from now.

It's very hard to keep focused on the most complex parts of development, when you hear your name every five minutes.

It sounds like you need a better change management process. Also a closed door (or, failing that, headphones) to show I'm working right now, don't bother me unless something's on fire. Are most of the requests that come in fires that need to be dealt with immediately?

If not, then you should set up a process for dealing with them. One possible approach to this is for requests to be put into a ticketing system (e.g. JIRA) and to then review them on a time that makes sense (1/day, 1/week, etc.)

If so, then you should consider splitting your team in two. Half will deal with fires, while the other will deal with the 'slower'/'more complex' development. Those designated as fire-fighters are standing-by to deal with the fires, while the others are focused and do not get disturbed. I recommend shifting these roles over time (e.g. 1/week), so that no one gets burnt out.

Answer 2

This is a very common problem. The first thing I would consider is to establish a sustainable pace - find the number of features you can consistently deliver in a month (or quarter or whatever works for you). Then you need to know what the most important features to develop are. Your sales person can be really helpful here, but if they start telling you that the most important thing is whatever the person on the phone is asking for, you might need a middle-man to manage the priorities. In Scrum, they'd call this the Product Owner.

Henrik Kniberg describes this really well in his video: Product Ownership in a Nutshell. I share this particular video because he is not speaking about Scrum specifically, but more the underlying concepts, so it is applicable with or without Scrum.

It is always important to find your sustainable pace before trying to modify it. Once you've found it and can deliver on the most important items, then you can start looking at what your biggest slowing factors are and start addressing them. For example, it sounds like your team is very inexperienced and lacks the domain knowledge that you have, so getting them improved as fast as possible may be the most important thing to do. Practices like pair programming or even mob programming might be good things to look at. These practices forego utilization in favor of knowledge sharing. Fully utilizing programmers who don't have the skills needed to independently do the work is pretty useless, so this focus may pay off really well for you.