Antoine Boulanger

We have been acquired by Stripe! techcrunch.com/2023/05/31/oka…

@der_mit_ph @nathenharvey @trahec If using Github, you can use Github Actions to record the relationship between commits and PRs at various boundaries (e.g new commit added, merge, etc.)

@danielbryantuk Slow builds / flaky CI / long code review cycles / noisy pages / too many meetings. More examples here: okayhq.com/handbook

@tonioab Great thinking points, Antoine! Can you help by providing specific examples of the bottlenecks and process inefficiencies, please? I'm thinking onboarding time (time to 10th commit etc), downtime in staging envs, number of meetings, etc, but would be keen to hear others

This is a great thinking point, and I constantly find myself struggling with measuring dev productivity 🤔 At a high level we all know it's about business impact and time to value, but how can you measure this fairly and objectively from a dev perspective?

🚀 We just released our plugin for #backstageio , the most popular developer portal platform! You can now embed your Okay charts in your team/service pages, including DORA Metrics, Incident Dashboards, CI/CD Performance charts, and many more. #devops #cicd

@beyang Great article - really believe in feedback loops and focusing on unblocking engineers. The set of metrics to use is highly contextual and cannot be forced into e.g. DORA. You might want to check martinfowler.com/articles/devel… and our section in the EE handbook: okayhq.com/handbook/feedb…

Wrote up some thoughts on my mental model of how developers work and how I differ from some of the more popular frameworks for developer productivity like DORA, trying to map out my own intuition with systems thinking. Curious what others think! about.sourcegraph.com/blog/developer…

@utsav_sha @beyang @ediardo Ex-devs turned managers, but @tomasrb and I recently put together the following handbook: github.com/OkayHQ/ee-hand…. Contributions are welcome since it's open-source.

@beyang @ediardo There are so many topics that I want to write about - productivity metrics, synchronous vs async workflows, but there's not enough time :-( I've always found Mike Bland's posts mike-bland.com/tags/ interesting - especially the ones that talk about cultural change.

How many posts about or frameworks for “developer productivity” were written by actual developers? 🤔

What causes developer survey fatigue? Lack of follow-up by the leadership. Surveys are not data gathering tools, they are communication channels - from developers to managers. If managers don't "answer" with actions, surveys get ignored. TCP >> UDP 😉

@GergelyOrosz Examples of such "developer productivity metrics": - how long do you have to wait on CI - how long does it take to receive feedback on your PR - how many recurring meetings do you have to attend - latency of code search, hot-reload, etc.

@GergelyOrosz Developer productivity is an outcome of how well the organization functions. It measures manager performance, not developer performance. The goal of management is to remove blockers such as bad tools or processes, and these problems are measurable

Incredible how most engineering managers don't realize how measuring developer productivity by visualizing JIRA+git stats is a dead-end if you want truly high-performing teams. This path works just like mandating that teams use Scrum. Yes: it helps bad teams get better.

@rhein_wein @dimiterbak I find it easier to measure bottlenecks / things that are getting in the way of being productive. It also puts the accountability on the leadership, and not on the developer. Meeting load, broken processes, slow tools, etc.

@dimiterbak I think we can all agree it's hard to measure something that we can't concretely define (or agree on a definition), which is why measuring developer productivity is so challenging.

Metrics from GitHub and JIRA can't tell you how productive an engineering team is.

@dimiterbak @rhein_wein My co-founder and I recently wrote a handbook about this topic: github.com/OkayHQ/ee-hand…, the first chapter tries to answer the "definition" question in detail.

@rhein_wein I am not able to find a definition of productivity neither in your thread, not in the article you are referring to. Can you share a definition?

Managing Time & Interruptions is arguably the most important input to create high performing software teams. Read more at okayhq.com/handbook/time/… #engineeringleadership #engops #productivity

Read and contribute to our new open-source handbook about #EngineeringEffectiveness! okayhq.com/handbook/ (Github: github.com/OkayHQ/ee-hand…)

We raised $4.4M from @kleinerperkins to amplify our momentum and provide engineering effectiveness and visibility to every software company! techcrunch.com/2022/02/16/sti…

Incredibly excited to be partnering with @mParticle ! Okay enables mParticle engineers to find their flow: okayhq.com/customers/mpar…

Teaching people — directly and through cultural norms — that they are powerful, not powerless, to change and fix broken processes is key okayhq.com/blog/learned-h…

@anjuan We follow this approach at @OkayHQ. I shared some examples at okayhq.com/blog/engineeri…. The biggest drags we are seeing are: meeting/interview load, code review practices that introduce too much friction, and after-hours interruptions like noisy pages

I've measured "engineering velocity" for a very long time, but I'm starting to focus more on "engineering drag". These are the things that slow down engineering teams. This includes product discovery, local dev environments, CI/CD pipelines, etc. Reduce drag to go faster.

"Most engineers care deeply about optimization and suboptimal processes can drive them crazy." review.firstround.com/hiring-a-vp-of… Library