Category Archives: Organizing Systems

Deadlines are a Clarity Crutch

Agile, Idle Speculation, Organizing Systems, Software Development, Thoughts on Thoughts, Words!, Writing

I have a love/hate relationship with deadlines. At one point I said that the amount of work I do is proportional only to the number of deadlines I have, not proportional to anything else. (I think this is one of the reasons I favour daily 5-minute standups. They allow a daily reset of expectations, along with a deadline to work towards each day.)

So, deadlines proportional to accomplishment. Daily blogging something to show for your year something something etcetera[1]. But today I wanted to talk about the mental clarity that arrives as you’re approaching a deadline.

You have a task/deed to accomplish, you have a fixed time when it is due. As the time gets closer, the light cone[2] of possible ways to solve the problem shrinks. You push aside a large number of extraneous things[3], choose how solved you can get the problem in the time alloted, and get it done.

There’s the standard ‘good, fast, and cheap…pick two’. It feels like a lot of this clarity comes from having chosen the speed. As the time grows shorter, the number of ways you can now spend your mental focus budget on the task becomes manageable.

So, knowing this, how do we compensate? More frequent deadlines do actually seem to help, but that’s more of a forcing a solution, rather than relaxing into a solution.

What is it about the problem that is making you pause? Is your brain working on it in the background? (Does this mean the fallow time is necessary?) Are there parts you can hive off? Can you draw a large diagram? Can you put it in a spreadsheet or table?

Or perhaps the elephant in the room: If it is so difficult to find mental focus, what do you need to change about your environment?

[1]Until writing this I didn’t know that the ampersand ‘&’ was a ligature of ‘et’, and ‘etcetera’ was often written ‘&c.’

[2]Light Cones are also fascinating. I use them often in my mental model.

[3]In undergrad, we used to say that we enjoyed exam time, because we could push everything else away and focus, and not face opprobrium.

Draw a LARGE Diagram

Engineering, Nostalgia, Organizing Systems, Teaching, Thoughts on Thoughts, Visualizations

Draw a LARGE diagram. When you start, you have no idea which part you’ll be focusing on, so draw it large to start.

In undergrad, we had a Structures and Materials course with Prof. Collins. I owe a lot to that class. It was first year, first term, and it was our first experience with ‘real Engineering’ (with a capital ‘E’).

Collins talked about (along with how to build bridges and other structures) a number of things which you would actually use every day, no matter what types of things you were designing or calculating or planning.

The biggest[1] one is indubitably ‘draw a Large diagram’. Every time I do this, whether it’s on a whiteboard at work, or in my journal[2] at home, it helps far more often than I expect, especially when you’re drawing a teaching diagram, and people are asking questions.

It helps when you’re drawing a semicircle intersected by many lines, with some angles known, some angles not known, and you need to do a bunch of fancy figuring to get the answer[3].

Next time, we’ll talk about some other useful tidbits I learned in that class. Stay tuned!

[1]Ha!

[2]I use notebooks with blank pages. It helps me draw diagrams without extraneous lines, feels freer for thinking.

[3]I think this was a GRE question.

Five Management Roles

Agile, Analysis, Organizing Systems, Software Development

I was talking with my best friend earlier today, and we were comparing notes on some different management roles. Traditional hierarchical management theory[1] tends to have all of the management roles embodied in one person. This can be problematic, as very few people are good at all of the management roles.

This has led to a number of different techniques for dividing these roles among people. To start, we’ll talk about five of these roles, using Agile software development language, as that’s what I’m most familiar with:

Performance Manager (Worker Evaluation):

The ‘Performance Manager’ is probably the most traditional of the roles. When someone talks about their ‘boss’, it is generally the person who evaluates their performance, gives them performance reviews, and decides if they should get a bonus, a raise, or be fired[2].

Estimatrix (Estimator):

The ‘Estimatrix[3]’ is in charge of estimating the amount of effort required to perform a task or set of tasks. This role is often spread out over multiple people, even in traditional hierarchies.

Product Owner (Prioritization):

The ‘Product Owner’ is the other half of ‘traditional’ management. They are in charge of prioritization of the work being done, once it has been assigned to a team and estimated.

Scrum Master (Removing Obstacles):

The ‘Scrum Master’ (my favourite) is charged with removing obstacles. Once the team knows what it is working on, things will get in the way. Some of the obstacles are acute issues, associated with work being done, some of the obstacles are chronic issues, which are generally solved by trying to change habits, and many ‘restrospectives’.

(People) Development Manager (Development Conversations):

As a retention technique (and because it’s the right thing to do), many organizations spend time on development of their employees, helping them figure out what they want to do with their careers, and helping to find them ways to develop while doing their job.

Tomorrow, we’ll look at some ways these roles are remixed.

[1]It’s really more of a default.

[2]Like user stories, anytime your description includes the word ‘and’ or ‘or’, it means you can subdivide it further. That is left as an exercise to the reader, if they are so inclined.

[3]I really enjoy this suffix.

What are your Non-Negotiables?

Agile, Idle Speculation, Organizing Systems, Programming, Thoughts on Thoughts

What are your Non-Negotiables? Most recently, I was talking to someone[1] about my New Year’s resolutions, and we were discussing why I had done one of them, but not the other two. It eventually came out that the resolution that worked (writing every day this year[2]), worked because I had made it a Non-Negotiable[3]. I had resolved that no matter what, every day this year, I would write something. Somehow, every day, I would carve out an hour or two, pushing other things aside so that I could focus and write.

(Incidentally, this practice focusing has done wonders for me, helping me find ‘the zone’, or ‘flow’ much more consciously and easily.)

Sometimes I would push aside a computer game, or facebook, sometimes sleep, but those things didn’t matter compared to the commitment I had made (mostly to myself) to write every day.

Interestingly, the other Non-Negotiable that came to mind today was the 5-minute standup. I was talking to someone about it today, and they started to say ‘5-10 minutes’, and I had to interject, with talk of Non-Negotiables, how if you let something like that slip, pretty soon you’re having daily half-hour sit down ‘stand-up’ meetings.

Interestingly, biking to work every day is not quite a Non-Negotiable. I take probably a couple of weeks off each year, some for snow, some for rain, some for events. It’s pretty close, though, and I’m not so worried, because I’ve been doing it for long enough (14 years, I think), that it’s a pretty deep-seated habit.

So, what are your Non-Negotiables? What is the one thing you want to change this year?

[1]Pretty sure it was G at a life coaching session, but my brain has this annoying tendency to abstract things away, but that’s another post. I also remember it from a speech by the head counselor at music camp many years ago, but that’s another story…

[2]At least so far…

[3]This is a good precis from a life coach on Non-Negotiables.

Technology and the Evolution of Diplomacy

Idle Speculation, Organizing Systems, Politics

How has diplomacy[1] evolved through the eons? We postulate that humans have changed, but do you think that a Roman senator would feel that out of place in the U.S. Senate? That the job of an ambassador has really changed in the last three thousand years?

It feels like the largest difference has been in the speed of communication. It used to be that the phrase ‘I have to go consult with my government. This may take some days.’ meant travel time. Now it means ‘We need to get used to this idea’ exclusively.

Advances in dentistry and water fluoridation probably mean that people are less cranky because their teeth hurt, advances in chemistry mean that we no longer sprinkle lead on our food. Advances in travel and communications mean that larger empires are more governable and longer-range diplomacy and trade are more viable.

But have any of these really fundamentally changed diplomacy? It remains, as they say ‘the art of letting someone else have your way‘[2]. Even the techniques of ‘Getting to Yes‘ must have been known in some form to the ancients.

Perhaps the spread of democracy[3] has had the greatest effect. If you look at human history (especially the relatively recent colonialism), those nations or organizations which were the most stable and had the greatest longevity tended to become the most powerful (provided they had the desire and resources/room to expand). But once you control for that, once countries reach that higher stability plateau, they end up competing with each other in very familiar ways.

But most probably, the spread of nuclear weapons has actually had the greatest effect. Great powers have warred with each other since time immemorial. The relative power of offensive and defensive technology has waxed and waned throughout history, but Mutually Assured Destruction was never present absent a larger third party.

Maybe we’ll use this opportunity to talk a little bit more, and understand each other a little bit better.

[1]Diplomacy has remained largely unchanged, except for the use of plastic game pieces in some editions.

[2]Attributed to Daniel Varè an Italian diplomat and author from the early 20th century.

[3]Many would argue for ‘Representative Democracy‘, ‘Constitutional Monarchy‘, or ‘Republic‘. These are all valid positions, and this discussion is out of scope.

Toy Boxes and Connections

Internet Culture, Nostalgia, Organizing Systems, Space!, Things We've Built

Recently, I spent a few hours going through my old toy box from my childhood. I found a number of curiosities (which I’ll share later), but I wanted to give my first impressions.

The toybox my dad made for me so many years ago.
The toybox my dad made for me so many years ago.

Above is the toybox my dad made for me so many years ago. It was a lot of fun, even going through and unpacking all the things inside.

Interestingly, all the way through, I was thinking about all of the connections I could make with people based on the things in the box. Finally sorting my Lego pieces so that S and I could download instructions (or use the classic instructions still in the box!) and make things together. Taking all of the various parts of games and toys and putting them up on this blog or on fb, to see if people could help me figure out what they were (thinking they might enjoy that challenge (and the nostalgia) too).

Perhaps most poignantly, I came across the numbers ‘1’, ‘2’, and ‘8’, written on tape, attached to Lego pieces. I think that they were part of that one time I brought the miniature city I had built[1] and was so proud of, and labeled parts of it. Anyways, I was going to use this as an excuse to ask my dad if he had any pictures of that, or other things I/we had built, so we could bond over that.

And perhaps I could bond a little with that child from so long ago. One of the things I found was a mint. S mentioned that young me was eating mints, and had somehow left one for me, some way of communicating across the decades.

One of the things I want to do there is to build again my favourite spaceship (it had three parts which were each their own ship!), and my favourite town set, the classic fire station.

The toybox all sorted, with Spaceship! (And Fire Station! (And Space Station!))
The toybox all sorted, with Spaceship! (And Fire Station! (And Space Station!))

Happily, it seems that most of (or at least a lot of) the space parts are still there. Sadly, it seems that many of the essential parts for the fire station are not present. It had a really cool slidy-up-and-down front door to each of the fire truck bays. Of the 46 pieces involved, I was only able to find about 10 of the grooves, and three of the roll-top-desk-like part things. But then I remembered the internet! So, brickinstructions.com has a parts list for the fire hall, and they link to Bricklink, where you can purchase the part! And not even that expensive! I love online communities.

Maybe I’ll connect with other people about this, too.

Here’s to connecting with ourselves from so long ago, and maybe helping us connect with ourselves and each other right now.

[1]It even included a hockey rink! With a swimming pool underneath, with real water in it! Lego is surprisingly water-tight. Or maybe there was a lining. I don’t remember. I just remember the paper rink surface getting wet. 😀

Sufficiently Complex Systems

Analysis, Engineering, Organizing Systems, Science!, Software Development

“Any sufficiently complex computer system is indistinguishable from a biological system.” -Me

So, I like to joke that I find all computer languages equally difficult[1]. The interesting corollary to this is that this also seems to apply to complex systems in general. I approach a complex computer (or other) systems in the same way that I would approach a biological system:

1) Look at the visible behaviour/symptoms/phenotype of the system[2]
2) Assume that there are some number of internal processes in the system, each doing the job they ‘think’ is correct
3) Build a mental model which describes the visible behaviour
4) If debugging a problem, this should greatly narrow down where you investigate

Steps 2) and 3) above are where I think my school training (engineering and science) were the most useful. Our engineering program seemed to focus on the fundamentals and underlying systems, so that one would have a pretty good idea of what individual system components are capable of[3] (and some idea of what the system as a whole is capable of).

The systems I understood most intuitively[4] were chemical systems, probably because my dad and his dad were both chemical engineers. You have a huge number of molecules[5], each doing its own thing, and in aggregate, they exhibit complex behaviour. When you’re dealing with inorganic compounds, you can (most of the time), simulate them in bulk, but when you’re dealing with organic compounds, the complexity explodes and all kinds of strange boundary effects become important.

At this point, you need to switch abstraction levels, also something I remember from engineering, from the micro- level to a level of slightly or substantially more abstraction. At this point, having an intuition about biological systems becomes much more useful.

I’ll use an example to illustrate. At one point, a number of years ago, I and my team were trying to debug why throughput on a system seemed to be capped at a number below the theoretical maximum. Like any flow system, there must be a number of sequential steps that your data or fluid or what have you must flow through. After we built this mental model, it was a matter of looking at readouts and logs to find the graph that had an asymptotic curve showing at which step the system was maxing out. Then we had to fix it, but that’s another story.

[1]This is probably not strictly true. I remember finding Fortran 77 more difficult than usual, and Javascript mind-bendy.

[2]I use ‘behaviour/symptoms/phenotype’, because we might be debugging a problem, or we could just be trying to better understand the system.

[3]This could be why so much of technological advancement is characterized by the advancement in materials. You can only get so far by using a specific set of building blocks. At some point, you need better blocks.

[4]There is a larger article here about how it’s important to follow the things that love the most, whether this is in hobby form or if you’re lucky, work form. You will work harder at doing them better, more importantly, working harder at understanding yourself and removing your mental blocks, which will help you in all the other parts of your life.

[5]Huge.

Focusing Meetings

Agile, Idle Speculation, Organizing Systems, Software Development, Thoughts on Thoughts

What kinds of meetings do you actually need in an organization? I don’t really know the answer to this. What I do know are the meetings that work for me on an ongoing basis. I would call my process ‘Scrum-like’, in that I think it takes the best features of Scrum, but I’m sure I’m not doing it exactly by-the-book.

1) Daily 5-minute standups. When I say ‘5 minutes’, I mean 5 minutes. I have said much more on this here: http://nayrb.org/~blog/2016/01/15/the-5-minute-standup/ They keep people up to date, and should spawn whatever conversations you need to keep things flowing

2) Bi-weekly* planning and retrospective meetings. You may be able to get this down to 1 hour every two weeks for both if your team is well defined and has been working together for a while. You may need an hour each plus one hour for backlog grooming every two weeks. Again, depending on how defined the work is that your team is doing, YMMV.

3) One-on-one weekly meetings with each of your direct reports. Long term, probably the most important of any of these. This is where you find what is actually happening, how your people are actually feeling. ‘Managing Humans’ by Michael Lopp has multiple chapters on this. Fundamentally, you want to establish trust with your reports. This includes listening, asking them about what they want (both now and in the future), followed by more listening, then following up to actually get them what they want and need as much as you can.

4) Broadcast meetings. I’m talking about town halls, other meetings where you want to get news out to a lot of people quickly. Best to keep these reasonably short, and choose your most interesting public speakers. If you have a CEO that can hold a room and answer questions, this is a great opportunity for them to shine. Many of these meetings can be avoided by a fanout leading to 30s announcements by leads in your daily standups (or email).

5) This last category is more fuzzy. It includes all those meetings outside your regular schedule. These are generally a mix of long term planning meetings (vision/strategy/etc…), short term planning meetings (figuring out what we’re doing with this project so we can make it into bite-sized tickets), and unblocking meetings (this project is behind, these people disagree, this thing you want us to do is physically impossible, etc…).

It is this fuzziness that that can be the death of a meeting. The first four types have pretty defined schedules and agendas**. This last type is pretty free form. Here are some things we’ve found that help:

A) Make sure the meeting is ‘Ready’

In Agile, there is the concept of a ticket being ‘Ready’, where before someone starts work on something, that something has to reach a certain level of definition. Generally, this would include things like ‘Acceptance Critera’ (how you know it’s done), and a ‘Why’, ‘What’, and some idea of ‘How’ you are going to do it***.

For our meetings, we had a pretty simple of ‘Ready’:
– Someone is in charge of running the meeting
– The meeting has a stated purpose
– The meeting has an agenda

B) Make sure the person**** in charge of running the meeting can run a meeting

This generally means:
– They are familiar and can follow the purpose and agenda described above
– They can tell when a conversation is going off topic or over time
– They can bring the conversation back

This last point can be as simple as ‘in the interest of time’. Having a written agenda on a whiteboard or flipchart can help a lot with this. If you include time allotments, this will give your meeting runner something to point to to get people back on track.

C) Have plans for action items

– Assign action items

Often, this is the role of the meeting runner (chairperson, really), but could be some other person in the room with the gravitas/authority to persuade/compel people to do the required/decided on things.

– Track action items and follow up if necessary

You want the follow up assignments to be in a place where everyone in the meeting can track their progress (whatever ticketing system you have is ideal, or perhaps whatever wiki system your organization uses).

– Avoid a further meeting on this topic

Depending on your particular participants, someone may need to be assigned to follow up, or it could be ‘homework’ for the next meeting. Ideally, you want to make these meetings as infrequent as possible, so subsuming the action items into your regular ticketing and tracking system is ideal and obviates the need for a specific follow-up meeting.

And that’s it! If you follow these simple steps, your meetings should be much more focused and productive!

Let me know what you think in the comments (as well as if you want me to delve deeper into parts of this).

*I say bi-weekly because we do two week sprints. YMMV.

**If you want me to talk more about agendas for planning meetings, retros, one-on-ones, and broadcast meetings, I can do so, but this is out of scope.

***The exact contents of this definition of ‘Ready’ are generally defined on a team-by-team basis.

****There are a bunch of specific skills here which are out of scope. Comment if you want more on this.

Resisting Regulatory Capture

Economics, Nostalgia, Organizing Systems, Politics

Most people, if you asked them, would agree that corruption is a bad thing, and should be reduced or avoided. Most of them will not have heard about Regulatory Capture, though.

‘Regulatory Capture’ is the process by which an industry ‘captures’ the governmental bodies which are assigned to regulate that industry. It is generally thought to happen because of two factors:
– The people who are assigned to perform the regulatory tasks spend most of their time talking to people in the industry they’re regulating
– There are huge financial incentives for the industry to persuade the regulators to change the rules in their favour

These rule changes can take many forms. They can be laws, regulations, even constitutional changes.

The rule changes can diminish penalties, replace jail time with company-paid fines, make it more difficult for new competitors to disrupt oligopolies or monopolies, lessen oversight or protections against fraud, and many other forms.

The bribery or coercion of regulators can also take many forms. Most countries have rules in place which make it difficult to perform the obvious ‘money in brown paper bags’, but there are many other ways to induce regulators to rule* in your favour:
– Many industries have laws about the amount of time between when you can work in an industry and when you can regulate it (and vice versa), but this does not seem to have stopped anyone
– Many industry consortia write the regulations** which regulate them, so the regulator (who may feel overworked and underpaid) doesn’t have to spend the time to do so.
– Most people have family or other tribal associations of some sort. A spouse’s job has been suggested to influence even supreme court justices
– The politicians who are in charge of the regulators are often persuaded by campaign contributions
– Various illegal inducements such as drugs or ‘favours’
– Threats, extortion, etc. may also come into play

So, how do we solve this? The closest we seem to have come to this is an interlocking set of checks and balances, including freedom of speech, lobbying laws, freedom of information acts, and the occasional incorruptible investigator.

We haven’t solved this yet, and it might not be solvable, given the power dynamics. Next time, we’ll talk about some current and possible solutions.

*Ha!

**There is a lot to be said for including industry as major stakeholders when regulations are written, as for the same goal, there may be very different ways to implement them, which would have vastly different costs.

The 5-Minute Standup

Agile, Organizing Systems, Software Development, Thoughts on Thoughts

Many people have written about daily standups*, and many people have written about the benefits of short meetings**.

I want to talk today about the idea of the 5-minute standup. This is an evolution of the daily standup that is part of the Scrum*** Agile methodology. I’m writing this from a Development perspective, but this could just as easily be applied to many other types of organizations.

The purpose of the daily standup as I see it is twofold:
1) Let everyone know what everyone else is working on
2) Let everyone know when someone is in trouble/blocked, so they can help

Classically, the daily Scrum standup has three questions:
A) What did you do yesterday?
B) What are you planning to do today?
C) What is blocking you right now****?

In my (limited) experience, people are pretty good about the status update part of things (what did you do yesterday?), and the forecasting part (what are you planning to do next?). You may need to explicitly ask the blocking question for a while until your team fully trusts you and the rest of the team to listen to their (often embarrassing) blockers and actually help them.

For me, I’m very much a proponent of short meetings. I love being as concise as possible (Think Ulath*****). I have an acute sensitivity for people who are uncomfortable with a situation or have checked out, and I try to do everything I can to fix that. (This makes me a good host, but it can be very tiring.) If I’m running a meeting, it will have a defined purpose, and it will be only as long as it needs to be.

I’ve found that developers especially will check out of a standup within minutes. Having a meeting of 5 minutes or less was the only way I could find to keep people engaged in a status meeting.

The way we’ve found best to run these meetings is to have the current set of tickets up on the screen, and we go through them in order. People are generally only working on one or two at a time, so it’s effectively the same as going around the circle, but with the added benefit of the visual aid. You can also do all of your ticket status changing at this time, along with asking for code reviews. Anyone who was missed then gives their update, then you break out to whatever after-meeting conversations were deemed necessary during the meeting. This way, only the people who need to be in those conversations are, and everyone else can get back to whatever else they were doing.

Some tips:
– If you find your standups routinely taking longer than 5 minutes (or 1 minute per person, max 10 people in a standup******!), try giving the most ‘detail-oriented’/rules-based person on your team the timer, and telling them to give each person no more than 1 minute to talk. It worked wonders for us. (I often do this myself, by being the most impatient one in the meeting.)
– Announcements should happen very quickly (max 30s), or over email. Discussions can happen after the standup is over.

To Recap:

Pros of the 5-minute daily standup:
– Less time
– No time spent on details, just high level, in depth discussions pushed to smaller groups
– Devs are much less likely to check out
– Not dreaded like interminable meetings
– A good outlet for the detail-oriented member of your team who cares about process, and wants to time things

Cons of the 5-minute daily standup:
– Still takes devs out of the flow, distracting them for much time before and after
– You still have to have all the one-on-one meetings to resolve things afterwards…
– It can make you think you’re having full communication when you’re not

*Interestingly, this is a very old tradition, as the UK privy council only has meetings where all members stand https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Kingdom#Meetings

**Randy Pausch gave an excellent lecture on Time Management https://www.youtube.com/watch?v=oTugjssqOT0 and the benefits of making meetings as short as your scheduling software will allow.

***https://en.wikipedia.org/wiki/Scrum_%28software_development%29

****Many people would say “Is anything blocking you right now? I mostly avoid yes or no questions, as they’re too easy to dodge with a one word answer, and a lot of having effective meetings is getting people to be present and trust you and not dodge.

*****http://davideddings.wikia.com/wiki/Ulath

******If you have more than 10 people on your team, your team is too big. Note that more than 10 people can be listening or watching, if they also want an update, but there should be no more than 10 people talking, at 1 minute each.