Elevate Spring Summit has been announced (Thu, Mar 11th)

🔥

Plato

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

How to Establish and Manage Expectations with the Business

Managing Expectations
Internal Communication
Collaboration

17 December, 2020

Aurélien Pelletier, CTO at PrestaShop, details how to establish and manage expectations with the business and their often unrealistic requests.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

A Founder’s Dilemma: Choosing Between Technology and Customers
27 February

Amitav Chakravartty, ex-CTO at Vaycayhero, dissects a common founder’s dilemma: should they focus on the latest technology or their customers’ needs.

Managing Expectations
Product
Users Feedback
Amitav Chakravartty

Amitav Chakravartty

Ex CTO at Vaycayhero

Two Key Elements of a New Manager’s Mindset
27 February

Amitav Chakravartty, ex-CTO at Vaycayhero, highlights two key elements of a new manager’s mindset -- being in the driving seat and not going with a flow.

Managing Expectations
New Manager
Amitav Chakravartty

Amitav Chakravartty

Ex CTO at Vaycayhero

When Words Bear More Weight
27 February

Wissam Abirached, Senior Engineering Manager at GitHub, tells of his transition from an IC to a manager on the same team and how that impacted his participation in technical discussions.

Internal Communication
Collaboration
Team processes
New Manager
Wissam Abirached

Wissam Abirached

Senior Engineering Manager at GitHub

How to Be Acquired
16 February

Benjamin De Point, Sr. Director of Engineering at Coupa Software, outlines what to do -- and what not to do -- when acquired and going through challenging times.

Changing company
Managing Expectations
Company Culture
Team processes
Benjamin De Point

Benjamin De Point

Sr. Director of Engineering at Coupa Software

When Being Helpful Backfires
3 February

Andrew Schamp, Software Engineer at Dropbox, recalls recommending a risky and time-consuming solution that he couldn’t take back without talking to his team first.

Internal Communication
Andrew Schamp

Andrew Schamp

Software Engineer at Dropbox

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.