Software engineering notes

Archive for the ‘org’ Category

Politically-charged projects

with one comment

I attended a talk yesterday that shared best-practices from managing two large projects that suffered from competing priorities:

  • prioritize, prioritize, prioritize <– reminds me of 4DX
  • put goals, tasks, vocabulary, agreements, engineering guidance, etc in writing to clarify communication
  • use pilot programs to clarify requirements
  • hold regular cadence meetings <– reminds me of 4DX
  • focus cadence meetings on clarifying requirements and getting help more than status updates
  • have periodic summits to build team cohesion
  • invite folks from different teams and with different roles to the summits to get a diversity of perspectives
  • identify and support “influencers” in the teams you need help from

One of the problems involved signing a contract before performing any engineering feasibility analysis and then having to turn the org on a dime to meet the deadline. 🦶🔫 I have experience being on the other side of abrupt changes and wondering what was going on, so it was validating to hear the context.

Written by Erik

October 3, 2019 at 8:02 pm

Posted in org

Tagged with

Saying yes to important things

with one comment

I attended a talk today on the art of saying no and a couple things stood out:

  • saying yes to important things makes it easier to say no to less important things, ie prioritize
  • if the impact of requested work is unclear, request clarification before agreeing to do the work

This reminded me of something a colleague once mentioned: part of the art of saying no effectively is making everyone aware of the costs

Written by Erik

October 3, 2019 at 7:00 pm

Posted in org

Tagged with

Entropy

leave a comment »

A colleague once relayed to me someone else’s observation that every syntax variation allowed by a language will eventually appear in a code base. Resisting the process of breaking down into what’s possible requires energy. The idea that “naming things is hard” seems a variation of this. If I could remember the originator, I’d call it ___’s Law. In the meantime, I think “entropy” is the general form.

With its Greek prefix en-, meaning “within”, and the trop- root here meaning “change”, entropy basically means “change within (a closed system)”

https://www.merriam-webster.com/dictionary/entropy

In this context, static analysis tools like linters help limit what’s possible.

An organizational approach I’ve seen a couple times is to embrace the range of possibility. For example, given a camp in favor of Java and another in favor of Scala, a former team avoided endless debate by supporting both until there was an obvious reason not to. Another example is Google Cloud’s reconciliation of REST and gRPC:

All our Cloud APIs expose a simple JSON REST interface that you can call directly or via our client libraries. Some of our latest generation of APIs also provide an RPC interface that lets clients make calls to the API using gRPC: many of our client libraries use this to provide even better performance when you use these APIs

https://cloud.google.com/apis/docs/overview#multiple-surfaces-rest-and-grpc

Another organizational strategy David Poll brilliantly described: products will express the org structure that created them (Conway’s Law); we can expend energy resisting this, eg review processes, and/or we can create orgs in the shape of the products we intend.

Written by Erik

September 25, 2019 at 10:35 pm

Posted in org, pattern

Praise for a task tracker 📉

leave a comment »

I just wrapped up a three month project in a new tech stack. From the beginning to the end, I was regularly asked: “Will this be done in time?” I was new to the tech, so it was difficult to estimate. The best I could do was document tasks as they revealed themselves, and then point at the percentage of tasks complete as a measure of progress.

For the first couple months, I added more tasks than I closed. The scope of the project seemed like it would grow unbounded, but then it leveled off. Today, I closed the last task. Amazing, and it wasn’t that hard, because we at least had an agreed-upon task tracker. I just needed to feed it.

Some features I like:

  • Using the same system used for tracking bugs. This frees folks to use whatever tracker they prefer. One colleague prefers a simple spreadsheet of tasks in descending priority, for example. It also enabled folks to use familiar bug tracking tools, like subscribing to updates, assigning ownership, commenting, etc, to communicate about tasks
  • At least trying to present a burn-down chart, though it doesn’t yet know how to work with nested milestones. A burn-down chart is the most accurate tool I’ve found for estimation; even if we can’t estimate the completion time, we can say the job will be done when the number of tasks drops to zero, and easily follow along on the chart.
  • Organizing tasks in a variety of ways, notably, differentiating organization by project from organization by week
  • Organizing tasks by blocking relationship. In other words, enabling me to specify this task depends on that task. Identifying branch nodes in this tree as milestones is helpful for maintaining a sense of momentum

Some usage patterns I like:

  • Presenting the tracker in a periodic (agile, 4DX) cadence meeting and using it to structure discussion. Avoiding tracker maintenance was helpful for maintaining meeting pace
  • Agreeing on one approach to tracking helped focus attention and minimize maintenance cost, though an alternative popped in and out mid-project, and the project launch used a different tracker

Written by Erik

September 25, 2019 at 10:01 pm

Posted in org, tool

Better together SDK pattern

leave a comment »

I’m a fan of an SDK product pattern I’ve heard people call “better together”. The idea is for SDKs to be decoupled, but complementary.

An example is an SDK that needs telemetry. One approach would be to add telemetry to the SDK, but this has a few problems: bloat, opacity, redundancy and coupling. An app may already have a telemetry SDK installed, so bundling another with an unrelated SDK bloats the app. Data logged inside the SDK is opaque to the app, which also complicates any SDK billing story. If the SDK does want to export telemetry data, it will need to build telemetry-specific logic redundant to the app’s telemetry provider. Any telemetry logic built by the SDK is coupled to the SDK.

The better-together pattern provides an alternative. To continue with the example above, an SDK requiring telemetry could detect if a telemetry provider is installed and publish events to it. A simplistic example would be to provide a method on the SDK to set a telemetry provider, eg:

class SDK {
   constructor(telemetry = null);
   …
   sayHi(){
     if (telemetry) {
       telemetry.logEvent(‘said_hi’);
     }
   }
 }
 …
 telemetry = new Telemetry();
 sdk = new SDK(telemetry);
 sdk.sayHi();

With this approach telemetry is only included in the app if the app owner wants it, minimizing bloat. Telemetry from the SDK is visible alongside the app’s other telemetry. The SDK can focus on whatever it does best. Telemetry is reusable elsewhere in the app.

One potential downside with this pattern concerns differentiating “internal” use-cases. Continuing with the telemetry example, the SDK may want to log events that are unrelated to the app’s functionality. I’ve seen three approaches: don’t differentiate, differentiate throughout, or don’t use the better-together pattern. The first approach treated all data as belonging to the app and namespaced all events published by the SDK, which worked well. The second approach was expensive due to technical complexity and eventually discontinued. The third approach was expensive due to redundant staffing, infra, UX, etc, but necessary so long as some parties don’t buy into the better-together pattern. I guess this stresses the “together” part of better-together 🙂

Written by Erik

September 25, 2019 at 8:20 am

Posted in org, pattern

4DX

with 3 comments

The book Deep Work, by Cal Newport, introduced me to The Four Disciplines of Execution (4DX):

  1. Focus on the Wildly Important, aka Prioritize
  2. Act on the Lead Measures
  3. Keep a Compelling Scoreboard, aka Measure progress
  4. Create a Cadence of Accountability, aka Have cadence meetings

I’ve found each of these practices helpful, but hadn’t seen them listed succinctly.

I think the second point (“Act on Lead Measures”) provides interesting context for OKRs, which several teams I’ve been on have used. 4DX describes lead vs lag metrics. For example, we have to wait thirty days to know if we’ve increased thirty-day active users, so there’s a thirty day lag in the metric. As opposed to other metrics, e.g., signups per day, features built, etc., that can be measured on a smaller scale and correlate with increasing thirty-day actives. Objectives seem like lag metrics, and KRs like lead metrics.

Written by Erik

September 17, 2019 at 6:35 am

Posted in org

Tagged with ,

Batch interviewing

leave a comment »

Problem

Interviewing can be expensive for a number of reasons.

For interviewees:

  • Traditional hiring pipelines are at risk of institutional bias, which decreases efficiency when sourcing candidates from diverse backgrounds.
  • Accumulating experience interviewing, a key factor for success, is hard when each company has a different process.

For interviewers:

For recruiters:

  • Scheduling several people at arbitrary times is also costly (unless interviews have top priority, in which case this cost is pushed onto the interviewer).
  • Motivating everyone on an interview panel to submit feedback quickly is hard, which delays hiring decisions.

(Thx, Megha, for feedback regarding problem/solution presentation!)

Solution

Schedule interviews in blocks, eg 5 back-to-back interviews in a day.

Perform a quick evaluation after each interview, eg 45 minutes of interview, 10 minutes of eval, 5 minutes to transition.

Huddle at the end of the day, ask each interviewer to vote, stack rank candidates, and make hiring decisions.

Benefits

Enable interviewees to efficiently gain experience, and administrators and recruiters to efficiently schedule, by adding interview blocks to a standard process.

Eliminate a source of institutional bias in the hiring pipeline by moving interviews to the candidate.

Amortize warm-up cost and increase evaluation accuracy by asking the same question repeatedly.

Discussion

Batch interviewing, aka on-campus interviewing, is common at some schools, notably Waterloo, which in my experience consistently produces high-performing candidates. (Students also gain an uncommon amount of practical experience through their co-op program.)

Uber runs a day of batch interviews at CSUMB in the spring for summer internships.

My experience with batch interviewing came from a two-day interview batch in Japan.

All these examples involve travel, which may have an impact on the value, ie would batch interviews provide the same cost/benefit when used at a business’ location?

One of the primary concerns I’ve heard expressed is the cost of finding a time that works for candidates, ie traditional scheduling seems optimized for meeting candidates when they’re ready. I’m curious to experiment with publishing a interview block, eg we hire on Fridays, to test this.

Ashwin Raghav shared his experience (thx!):

  • I have participated (as an interviewer and as an interviewee) in batch interviews in India. Very common practice in engineering schools.
  • I did not go to an elite school, which meant that everyone wanted to participate in any company’s recruitment drive.
  • This was often tiring for the interviewers because of the sheer number of interviews and for the interviewees because giving them accurate time slots to take interviews was not easy – meaning they waited for their turn.
  • A lot of the candidates are friends among themselves. They share their interview experience once they exit the interview. This forced us to keep changing questions as interviewers to keep up the difficulty level.
  • I always remember these being very intense emotional experiences compared to industry hire interviews because of the scale of participation. It helped if interviewers were “nice” / “not assholes”
  • Always helps to have a college alumni in the team. I would have never known about sharing interview questions if I did not go back to interview as an alumni.

Written by Erik

September 29, 2017 at 5:15 pm