4

I work in a small software company in a team of 5 people. We currently handle a good number of customers but as we onboard more it's becoming apparent that some of our policies are quite outdated and need improvement to be more efficient and less of a time sink. Areas of possible improvement include:

  • Introducing productivity tools: New team members have taken these on board (Slack, Trello, Basecamp) and it's a significant improvement with day-to-day communication and workflow.
  • Erratic version control practices: Only one branch per project, releasing breaking changes to the branch used for production code rather than branching, with no communication that there are breaking changes.
  • Not being strict enough with scope creep: A lot of our business relies on word-of-mouth so some scope creep is accomodated to give good PR, but sometimes the line is drawn too late and it leads to project delays which our customers have commented on.
  • Lack of visibility on hours allocated to projects: Makes it difficult to know how to prioritise and pace work. Sometimes smaller projects with larger budgets are done with time to spare, but other times larger projects with tight budgets aren't communicated until it's becoming an issue and we're rapidly approaching the time allocation with more work still to do.

I've spoken to my boss about things in the past and had procedures implemented which have been useful (for example, close of project meetings which have helped future projects go more smoothly), but the noted bulletpoints, especially use of productivity tools and version control practices seem to be a sticking point. My boss is very hands-on and gets involved in the delivery of projects, and as such is very busy. Team members have mentioned this in passing as well as colleagues that have since left the team, but it still didn't really incite any permanent change. It's apparent that improving on these points will help the team, as between myself and the team members that have taken on the productivity tools, it's really made day-to-day work more efficient. The problem is that my senior and my boss are reluctant to take this on when I'm trying to lead by example.

Points 3-4 are really out of my control as I have no say in management, so I can't lead by example, especially as they're more of a team effort, but they are points that I think could be addressed.


My Question

How do I address procedural concerns and improvements with my boss and senior in a way that they'll be receptive to the suggestions?

I worry about bringing this up because I don't want to come across as confrontational or causing issues, but I think this needs to be addressed as our client base grows. They are sticking points that we kind of just muddled through in the past, but I foresee them becoming more of an issue the longer it goes on and the busier we become.

5
  • You say that other team members have been using the same tools as you are attempting to make normal. How would your boss feel about the dev team collectively suggesting your ideas rather than it only coming from you? Have your colleagues ever made such suggestions to your boss in the past?
    – user34587
    May 2, 2019 at 14:00
  • @Kozaky a colleague who has now left was constantly trying to push better practices in the past. I've mentioned using productivity tools in our team meetings which we have weekly. A while ago we had a big meeting about this sort of thing and started using JIRA as a result, but that became abandoned a couple of months later as not everyone was using it (the senior and boss), so it fell through a bit.
    – Longisland
    May 2, 2019 at 14:19
  • If there is nobody more senior that is willing to overrule them, then seems to me the only options are: 1) put time and effort into creating a strong business case with advantages, costs, risk analysis etc that's hard to argue with 2) leave... If you superiors wont take on good advice and refuse to be convinced, then you have to lump it or leave it really. That's the power they deserve for being the ones ultimately accountable for things.
    – HelloWorld
    May 2, 2019 at 14:30
  • @HelloWorld I think leaving is a bit headstrong for this. In general I'm happy with my job and how things are going. It's just a matter of getting better practices in place to make it easier for everyone going forward :)
    – Longisland
    May 2, 2019 at 14:33
  • 1
    @Longisland yeah i know what you mean, but I mean, it's an option ;) It's hard to persuade people sometimes unless they're open to it. Working in IT, I have the charisma of a plank of wood anyway aha
    – HelloWorld
    May 2, 2019 at 14:36

2 Answers 2

4

People hate change… And that’s because people hate change… I want to be sure that you get my point. People really hate change. They really, really do.

– Steve McMenamin

(This is from "Peopleware", not "The art of project management", I recommend reading both)

Now, I have been in your situation, and I really don't think you can successfully manage upwards here. Even if your boss will agree "we need X, Y, Z changes" but without commitment, it will not stay.

The only thing you can reasonably do is to improve your own life. Create a "pocket of excellence" around your personal responsibilities.

Start writing more things down, for example at the end of each meeting. At the end of meetings, say out loud: "so what are the actionable decisions?" Make a list somewhere online (I use Basecamp).

Not being strict enough with scope creep

When meeting with boss or just doing project update, you can always open up laptop and say: "folks, as I see it here, 3 months ago we decided to not do X, are we changing that decision? Why?" The open-laptop-read-out-loud is very effective tactic.

Try to ask proactively, whether feature X is more important than Y. Create written ordered lists of tasks, so you can refer to them later.

Lack of visibility on hours allocated to projects

You will benefit by getting an ability to ask: "last time we allocated X time, it took us X*2 (or X/2). Are we sure this estimate is correct?" Then it is your manager's job to juggle tasks to fit in all the schedules. You can provide real-world data from developer on how long something can take. And you can also remind boss to prioritize items for you.

Making life easier for you in long term

It would be great if tomorrow your boss would see error of their ways and start telling people to write things down. Not going to happen. But you can repeat, probably to the point of being annoying, "please could you write this down on Basecamp".

When teaching someone something, or being taught, try to write some of that info in publicly available way. I personally like creating "HOWTO: do X" threads on Basecamp. Even little notes will help you remember stuff.

3
  • Yes, there ARE people who hate change. They will only accept change if they're forced to do it by a boss and some can't even do that. There are others, however, that have different levels of tolerance ranging from "will try it if there's an advantage" to people that make test-pilots look like sissies. Most folks are in the "what's in it for me" camp. (see diffusion of innovation theory: en.wikipedia.org/wiki/Diffusion_of_innovations).
    – teego1967
    May 2, 2019 at 18:51
  • Thanks for all the info on these points. It's a lot to go from. I'm trying to do as you suggested already in creating a pocket of excellence. I'll try to be more vocal about that and see if that helps it catch on. Looks like it's time to dust off Basecamp/JIRA and try to get the ball rolling with it again!
    – Longisland
    May 3, 2019 at 12:17
  • 1
    @Longisland i think it is worth remembering that managers don't have to be on Basecamp, only developer group. And you can make your work more efficient by asking management questions ("what is most important?"), instead of just providing them with answers ("here is what you asked for, boss"). That change did help me May 3, 2019 at 17:05
2

I find it helpful with thing like this to step outside of my developer mindset and instead focus on the problem in business terms.

For example, one of your concerns is with version control. Estimate what it costs every time changes break something. Do a calculation of time (person hours) times what your employer is paying should give a rough estimate. 12 hours x $45/hour = $540 each time this happens. If 3 times a month then it's just under $20k for a year. Numbers like this should get someone attention.

Do the same for upgrading development tools. If it's improving communications and workflow calculate what these will save your company - in increased productivity and/or lower costs.

1
  • That's an interesting approach. An instance of this has actually just come up so I'll try documenting each time this happens over a period of X weeks/months and run the numbers.
    – Longisland
    May 3, 2019 at 8:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .