Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

How to Establish and Manage Expectations with the Business

Managing Expectations
Internal Communication
Collaboration

17 December, 2020

Aurélien Pelletier
Aurélien Pelletier

CTO at ex PrestaShop

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

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

The art of managing up

19 November

James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.

Mission / Vision / Charter
Managing Up
Internal Communication
Strategy
Stakeholders
Cross-Functional Collaboration
James Engelbert

James Engelbert

Head of Product at BT

How to Build Rapport With an Introverted Manager

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.

Managing Expectations
Internal Communication
Collaboration
Coaching / Training / Mentorship
Juniors
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

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.