“Too often we hold fast to the clichés of our forebears.” -JFK
We are not purists at LinearB. Certainly not when it comes to “methodologies” like Agile or Scrum. We’re not bothered with how things are “supposed” to be done. All of those rules are just dogma to us and we don’t care.
We believe in lean engineering and we buy-in to a lot of ideas from the Agile Manifesto. But some Agile principles are outdated. Like “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Not for us. We embrace asynchronous as the default form of communication within our dev team.
Same with Scrum. We generally follow Scrum but a lot of the common rules don’t work for us. Like the product manager is not allowed to attend daily stand-up or they can attend but not talk. We don’t think that makes sense. Our PM is an important member of our scrum team and plays a big role in unblocking developers and helping us deliver on time.
Another area where we challenge accepted norms is how we communicate engineering work and feature updates to our executive team.
Contrarian approach to presenting engineering work to execs
We’re a start-up so Boaz Dremer wears a lot of hats for us. He’s part tech lead, part product lead and part scrum lead.
Boaz communicates engineering work and feature updates differently than other tech leads I’ve worked with. In fact, some of the things he shares would probably be considered contrary to best practices at other companies.
Check out this 10 minute video of Boaz presenting at our CEO’s staff meeting on 9-30-2020.
If you watched the whole video, a few things probably jumped out at you. If you didn’t, no worries. I’ve highlighted the important takeaways below.
6 Things Boaz does differently
1. Educates execs on engineering vocab, process and success metrics
From day one, Boaz and our entire engineering organization have gone out of their way to teach our business about the software development process. Every person in our customer success, marketing and sales organizations know the terms branch, pull request, WIP, merged, refactor, continuous delivery… you name it. And they know what each means and how it all fits together.
Sure, some of the concepts behind the terms are technical. But, honestly, it’s not hard. If everyone can remember what an MQL and SQL is and where it fits in the marketing and sales funnel, they can learn what a PR is and where it fits into the dev funnel.
Boaz shares engineering updates with the whole company every single week and shows our Cycle Time which is our main engineering metric for efficiency.
So when it’s time to have a serious conversation about the status of a major project or how we’re going to invest engineering time for the next quarter, both engineering and business are set up for success and can have a highly productive conversation.
2. Brings data to the party
When it comes to sharing weekly status updates for features in progress, Boaz has a general rule: fewer words, more data.
You’ll notice as the video starts that he’s transitioning from a single roadmap slide to our live project board which we call Pulse. We use Jira for planning and prioritizing but, when planning ends and building begins, we use Pulse to track progress and communicate updates. It has a lot more data which gives our execs more confidence and actually keeps them more engaged.
Everyone agrees staring at PPT for an hour sucks and yet that is still the format of most meetings. I think it’s because it’s hard to get data. Most companies don’t have the resources to pull and format all the data they want. And the ones that do tend to have data gatekeepers – data engineers, system admins – who are bottlenecks.
We invested a massive amount of time building our dashboards because we are committed to making sure engineering data is available on-demand.
3. Gives lots of detail
I’ve heard countless dev leaders say they avoid sharing too much detail with non-technical execs using the excuse that “they don’t understand” and “they just want to know when the feature will be delivered.” This is a dangerous precedent to set. If your business stakeholders are kept at arm’s length, they are more likely to demand unreasonable things from your team.
You’ll notice in the first few minutes of the video, Boaz goes into great detail on every story. Instead of just showing the Jira “in progress” status, he highlights how the engineering work for specific branches and PRs are collectively leading to the features being on time or delayed.
Most business leaders know that the Jira board is not always up to date anyway. You might as well show them the real status based on the real work your devs are doing.
4. Shares the bad and the ugly
Skip to 2:12 in the video and watch how Boaz explains that our “multi-Git” feature is delayed. Instead of just saying, “we’re delayed and we think we’ll need two more weeks”, he shows the exact work that’s been completed so far and explains that our front-end dev has not started her tasks for this feature yet.
At 3:07 another person jumps in and says “Is that Keren? I see she’s tied up working with Zuki on the onboarding enhancements.” That’s our VP of Marketing – the absolute least technical person in our company. Instead of just being frustrated that the important new feature he’s been waiting on is delayed, he has a constructive conversation with Boaz because he can see with his eyes exactly what’s happening
5. Explains the “why” behind updates
Check out the moment at 6:11 in the video when Boaz talks about the “anonymous sign-in” feature. At 6:31, Rocco, our VP of Marketing jumps in again and says “why does this feature keep getting delayed?”
On other teams I’ve seen the response to a question like this be “we’re really busy and we just don’t have enough resources.” Instead, Boaz does three things A) He corrects Rocco that this feature was actually not a high priority until recently. B) He reminds Rocco that there were other high priority items ahead of it that the business wanted more. C) And he’s honest that it’s still at risk based on the amount of dev work invested in it this far into the iteration.
6. Explains the trade-offs
Fast-forward to 9:41 and you’ll see Boaz give an overview of all open bugs. Why?
Support really cares about bugs. And your exec team may care about P0 bugs affecting every customer. But most of the time you would not see run down of bugs in an exec meeting.
He’s doing this for two reasons. First, we care about customer experience and every little bit counts. Secondly, and just as important, sharing the bug backlog gives context for how much time we have to focus on new features. It’s easy for the exec team to say “just prioritize these new customer features, please.” But when they see the competing priorities visually laid out before them, they can have more empathy for the juggling act the dev team faces every day.
“The inclinations of our will determine the types of actions that we choose.” -S.J. Contreras
Boaz admits that the job of sharing feature updates was easier at past companies. But he likes the hard way better because it leads to a better relationship between engineer and business.
Boaz told me “…it’s more work but then again I’ve never seen a company more aligned around priorities.”
If you have any feedback or questions on how Boaz ran his update, he would love to hear from you. Email him directly (boaz@linearb.io) or connect on Linkedin.
Where did those dashboards come from?
You can get the Pulse board you saw in the video, plus all of the other metrics we use to run our business, completely free. Click here to sign up.
Dev leads use LinearB to identify project risks, predict delays and see who needs attention, so you can help your team ship on time.
Product leads use LinearB to get detailed, real-time updates, ensure priority projects are getting focus and communicate to the business more authoritatively.
CTOs & VPs of Engineering use LinearB to automate the product development metrics scorecard and translate engineering work to business results.
Oldest comments (0)