How to Establish and Manage Expectations with the Business

Problem

The business and Engineering frequently not only have divergent opinions but conflicting goals. As engineers, we not only think differently but we approach our work differently even within the same organization. The business always wants more and more features and the delivery to be faster and faster. Some business requests can be unrealistic and are creating a lot of pressure on Engineering that has its own pace and priorities.

Actions taken

Handling the pressure of unrealistic requests is essentially a matter of establishing and managing expectations. I try to reframe requests from the business to suit the interests and priorities of Engineering. For example, if you commit to delivering a new feature in two weeks and you end up delivering it in three weeks the business won’t be pleased. However, if you commit to delivering the same feature in four weeks and you do it in three, the business will be happy. I call this particular approach “the art of estimation”.

The business needs to get visibility and you will have to give them visibility into what is going on on the team. A CTO should regularly update the business on what is being delivered and what not. I prefer visual project management tools that would not only make tracking progress easier but are more persuasive in terms of presenting the results. A board in physical space is a particularly great tool because it is tangible and conveys a sense of realism. For example, if a new feature or a task is requested by the business before placing it on the board, you should ask them to remove something else. When the action needs to be performed physically it becomes more clear whether something new is worth adding and what are the consequences.

I am always very careful with time-commitments and prefer to extend the expected time of delivery and then deliver before that deadline than to be late. We are using Agile and we do the estimation using task sizes. I would make sure that the business understands the velocity at which the team is performing. For example, during one sprint we will be able to take on two large tasks, three medium ones or two medium ones, and four small ones. When you do the planning you should calculate how many tasks you can complete to accomplish your goals. Sometimes the requests handed over by the business won’t fit your plan and you will have to make some tradeoffs.

Every month or every two months we would have planning reviews that would include different stakeholders. We would do a projection of our work and would need to secure that the business would attend in spite of their busy schedule. This is the right time to negotiate with them what the priorities are and what tradeoffs need to be made. The planning should extend to two or three sprints ahead because it can be hard to deliver business value within one sprint.

The business is typically more directed toward short-term goals, while engineers think more long-term. The business often has to react quickly and use the brief window of opportunity to win a contract and sign a deal. While we, as engineers, are driven by the reliability and stability of the system and we understand that rushing to do quick fixes will come back to us.

Lessons learned

• Be realistic about what you can do and be open about it. Make the business aware of it and ensure their involvement in the planning process.
• One of the key challenges is to understand how much pressure could be put on the team. Some amount of pressure will be empowering and help the team go beyond their own limits and out of their comfort zone and a different amount could have a detrimental effect. There is an analogy with a gas -- an engineer will take as much space as given, but if you pressure them too much they will explode.
• Tech debt is a constant point of friction between Engineering and the business. Tech debt slows engineers down while the business finds removing tech debt an unnecessary cost. While refactoring changes the code inside, the work is not noticeable outside unlike the work on new features that generates tangible value for the business. Connecting tech debt with a concrete value that is brought to customers is the most efficient way to get buy-in from the business. Better performances and less bugs are obvious business value brought by refactoring and tech debt management.