How to be in production
Get your development team to the peak without having them climb the mountain
A few years ago we started building something from scratch with a completely new team. It was a big product, and as some things go, its delivery was delayed a number of times. Even when we actually delivered, there was a very long test phase, followed by a soft launch that lasted months. At one point we had to rush a few features and as a result, we urged our engineers to step up and make it happen. And it didn’t. We missed our milestone. looking back, we missed quite a few of them, actually.
And then it hit us — we don’t know what it means to be in production.
What we were calling Agile wasn’t so agile after all. Our Scrum was just a sequence of so-called sprints in which nothing was really delivered and nobody really seemed to care. While that is a problem by itself, I’d like to put its reasons aside for now and discuss the implications of it on our development team.
It was amazing to see how absolutely everyone from the development team was suffering from the same numbness towards our goals. With no users in our system it was easy to simply delay everything and invest time on whatever grand ideas they had at the moment.
Most of them didn’t even have an idea how the business is doing and what are our main milestones for the upcoming quarter, let alone the next year.
And then, as our milestones drew closer, stakeholders started to complain and shout. And the development team? They didn’t understand what’s all the fuss about. We needed some features for a user acceptance test with one of our customers, and they didn’t understand why we interrupted their quiet sprint with some silly little defects that are suddenly critical priority. We wanted to fix some urgent production issues and they would take their time with the defect, make the build slowly, test even slower and neglect to notify the operations team in time. Surely, we lacked communication and processes, but most of all we lacked a sense of achievement.
How do you fix the problem? There are no magic tricks — it requires a long, tedious process that takes effort from the product team, and is more difficult with big development teams.
You’re not doing your team any favors by hiding production defects from them. Even if all you need in order to solve the problem is one developer and one QA, it’s always better to let everybody know that something is wrong. This will help unite the team around solving production defects or any kind of emergency that requires immediate action.
Always have a well prioritized and maintained roadmap. This is very useful for product and management, but also allows for clear goals to be communicated to developers. And this communication should be frequent and accurate. It’s best to place the roadmap in clear view for everyone to see at any time.
Show me the money
A company exists to make money. Most of the decisions by management or the requirements by product are made for that sole goal. Developers understand that, so all you gotta do is lead them through the money trail.
When presenting a required feature, it’s sometimes easy for the manager or product person to justify it by uttering “because we need it”. But you won’t gather any respect by avoiding an explanation. Tell the team why you’re asking them for something. Who knows, maybe they’ll even change your mind…
Stay the course
If you change goals every week and react hysterically to inputs from management or innovations from competitors, your development team will suffer. Of course, you want to be agile and react quickly, but you also don’t want to put unnecessary stress on the system and place everyone on edge.
Use weekly meetings with the teams to remind about goals and where they stand. Most importantly — don’t neglect to mention successes. A new feature finally launched? A surge in users? A new contract with a customer? All are important. Even good things that happen outside the scope of the team, maybe in a different division of the company.
Working on something new, it’s easy to not pay attention to what’s already out there. Create some kind of information radiator screen with interesting numbers like amount of online users, or a list of features and functionalities that are currently in production. Place it in front of the team’s faces and see how their interest rises.
Real world problems
If you are in contact with customers, or any type of real users of your system, make sure to get their feedback from time to time and involve your development team. You can even gather real problems or complaints that came through your operations team, and explain how they were solved.
When facing huge obstacles, most people feel lost. That’s not what you want from your development team. Don’t ask them to climb a mountain — ask them to get to that point over there, that they can see with their eyes. And then to get to the next one, and the next, and the next. It won’t be long until they find themselves standing on the peak (hopefully, not wondering “how did we get here?”).