Releasing is not a success
A few months ago, in my previous company, we were spinning off a new idea of my boss — let’s create a technology team that would build new frameworks for other teams to use. This was a tempting idea to some extent as most of the teams were using old tech stack which made the development slow and developers sad. Other teams would pick the new frameworks, SDKs and libraries and build their product with the use of the new tools. We were putting over 15 people on this team, including some of the smartest and experienced developers from our department. This work would shape the future of other teams, that’s why it was crucial to build technology that would support many use cases and could be used by other teams. This required a lot of collaboration and understanding of the roadmaps of other products.
Just before the team was supposed to start we got together with my manager, the architect and the PO (well, it was “sort of PO”, but this is a subject of its own and it deserves its own post) to discuss our approach and strategy. We started discussing what is the aim of the team, how requirements would be communicated and basically what do we want to achieve. When would we know that the was successful? As soon as this question was asked you could observe 3 different attitudes in the room:
- “I don’t care attitude as long as we follow my plan” where my boss didn’t think it was important at all and we should worry about this later. For him, it was important to have the team started as this was what he had promised his boss and following the plan was the most important thing ever.
- “Releasing is everything” attitude expressed by the Architect and the PO. For them, the success of the team could be measured by making sure the team release the framework. If the first version had been released within first 6 months, we would have called this a success and reported it to our big boss.
- “ Uptake of out frameworks by other teams” or even more radical “Success of other products which uses our frameworks” attitude expressed humbly by me. I tried to explain that releasing the software is not a success if nobody wants to use it and if it does not help our clients (in our case other teams) fulfil their goals. Obviously taking this approach, we would need to constantly talk to other teams, make sure we work in a transparent way, seek feedback from other teams and incorporate it into our backlog. And all this could mean that we might need to change the technical approach. This, of course, was the last thing our Architect wanted — the technology he came up with was the best ever, right?
How did we resolve this? As usual, the person who has the most power decided what to do, so we parked this subject with the comment that we would come back to it later. In this case (as in most of the cases) later meant never. The team started without any way to measure its success and the only thing that was discussed by the leadership team was when the framework would be released, not how it would be used.
What happened to this team? After 4 months it was dismantled and the idea of creating new framework was suspended due to the more urgent work.
What’s the lesson for me here? Always think what value you deliver in everything you do. What is the purpose of your work? What do you want to achieve? Being busy and producing SOMETHING is not enough! I expect that if we had defined a proper success measure for the team, closely collaborated with other teams, taken their feedback into account, our team would have keep working. Why? They would have been protected by other teams who would have seen that they could use our framework for their own success.
If you’re reading this, ask yourself: “why am I reading this? what is the value of this?”. Is it only to kill time, feel busy or is it to find ideas to use in my company, or is it to discover a network of similarly thinking people? What it your reason?
What is the success measure of your team, product, company?