Pages

Perfection and Details 28 December, 2023

I spend time on tasks all day long. When attempting to be as complete and polished as possible on a task, it's easy to get too far into the details. The time spent on a small detail of a task can overwhelm the allotted time for the whole task and put more pressure on following days. How can you tell if too much time is being spent on a specific detail?

If you've spent enough time tuning a detail that you're pausing to ask if it is good enough, here's a question to ponder. Is the detail critical to solving the overall problem? If not, go back to the larger task. Here's an example.

I create capacity plans for engineering teams. The real task and overall problem is to understand how much work teams can take on. At one point in my process I found myself calculating holidays and adding it to the equation. Accounting for this could make capacity more accurate. This was a detail of the overall problem. The overall problem was to understand how much teams could take on. There were so many variables in the small details that the general velocity of the team was lost when compared to every other detail taken into account. Visually, you can see the difference in how much time was being spent on a detail vs the overall problem.

Focusing on certain capacity details led to spending time on this way of thinking.


While these kinds of details can be important, they are important to questions about why capacity is what it is instead of answering the overall question of what future capacity is.


This second graph speaks more to what future capacity will probably be than the previous more comprehensive calculations.

More examples of perfection and details could be in my normal workflow. How does the perfection and details issue affect your tasks?



Evolving 1-on-1s 28 February, 2018



A few years ago, teams where I work made the move from semi-annual performance reviews to having 1-on-1s every two weeks. Don't let the benefit of meeting frequently overshadow the fact that you can have bad or unhelpful 1-on-1s.

Everyone should have some idea of what to expect in a 1-on-1. Here some things I've learned.

1 - Figure out how each peer, team member, direct report, and leader is different. 
Understand what is important to them. These differences should be available to you at any time. If you’re not sure how to start, find out what the most recent book they’ve read is. That will tell you a lot.

2 - Negotiate personalized goals.
Although it is great to have team goals, most of the growth in people will come from personal goals. Some people may not even know the good that goals can do for them. Create goals for where they want to be as well as where you see their potential being. These goals should be easily available to both you and them. Goals should have a great deal to do with super-boss theory. Caring about the future of the business and the person equally.

3 - Understand expectations of each other.
No matter the roles of each person, there should be an understanding of what each person expects of the other. It is very revealing what some will limit or expand their expectations to.

4 - Always be upfront about excellent or poor.
It is much easier to have this steady and trusting line of communication than to ignore it for a long time and then have someone shocked when they are asked to set a goal, improve, or try something different. There are few things worse than thinking you're doing great and nobody caring to help you know otherwise.

5 - Be cognizant of the time each person needs.
Some people will only want 20 minutes. Others will need an hour. That is okay. The more that people trust you and feel like you care enough to make time for them and listen, the better.

6 - Understand the non-technical roadblocks.
Something I recently learned is there is a big difference in a person saying they can’t do something and they won’t do something. This can also give you insight into their state of mind. Some are willing, others are afraid to try, some really dislike change.

7 - Informally follow up between 1-on-1s
You can send a note to people between 1-on-1s as a non-intrusive reminder of the most recent 1-on-1. This helps avoid scenarios where action items were discussed in a 1-on-1 but nobody remembers until the next meeting.

Whether you’re running it or being invited, I hope you have a few more helpful ideas going into your next 1-on-1.

Arguing and Alignment 26 January, 2018

Often in a company or team, there is an individual that does a great job of shouting the loudest. Sometimes groups rely on someone being very opinionated in order to make a decision. If you find yourself in this kind of situation, your group may not be aligned towards the same goals or strategy.

Probably the biggest indicator that this is happening is the loss of priority of an idea because its advocate is not there to defend it. It means that the members of a group aren't aligned on what the most important things are. This is a different manifestation of the classic company values test. If you publish a list of company values, and there is laughter or mocking, the values won't affect the work.

What can you do to help combat this problem? Here are some ideas.
  • Before you publish a strategy, make sure all your influencers are aligned with it.
  • Make sure your organizational structure supports the strategy.
  • Be transparent in what teams are excited about, and what teams are alarmed about.
  • Make sure everyone has a way to propose ideas and be heard.
  • Teach everyone some strategy fundamentals.


The Pitch 28 February, 2017

The Pitch

Most people think of a pitch as a rehearsed reason someone gives when they need help making a new idea come to life. I think it should be recognized more widely as a good way to communicate in business. People should be pitching much more often than they are.

Here are a few situations that I think it applies to.

  • Hackathons
  • Raise Meetings
  • Feature Requests
  • One-on-One Meetings
  • Team Meetings
  • Planning
  • Anything you're working on - What if someone comes up to you and says "That looks interesting. How will it actually help us?"

Here is a simple way to organize a pitch. Be able to explain the following.

  • A problem that exists
  • Why the problem matters to the listener
  • How you're trying to solve it
  • Why your idea matters to the listener

Give it a shot.

Sprint Length Heuristics 31 January, 2017

If you're thinking of changing your sprint length, but aren't sure if you should run shorter or longer sprints, here are some heuristics that I've observed. First, I'll give you some background on what I've tried.

At a previous startup, we had 1 week sprints. That worked fine at a startup because everyone did everything. Devs were devs, but they were also client services, designers, DBAs, and devOps. Later, while working at a more established company, we ran three week sprints because there wasn't a pressing reason to change. Let me rephrase that last comment. The established company was used to running sprints like every other established company and 'best practice' was equivalent to whatever was in standard training materials. Now, after switching from a Kanban style (for reasons I won't discuss here,) I am back to 1 week sprints. I feel like that's currently the best match for the company I'm at.

I understand that there are trade-offs in the sprint length that is chosen. So I'll get on with the actual heuristics I'm using to set my sprint lengths.


<------------------------------------------------>
SHORTER                                             LONGER
smaller feedback loop                       You know your strategy
Forces you to break up issues          Priority of features doesn't change often
You may be reactive                          You're just starting out and going with historical opinion


I hope you can use this scale to better match up your circumstances to an appropriate sprint length for your company.

Growing from 360 Reviews 18 September, 2015

  Improving in your career is often difficult. Most of the time, people won't tell you what you could be doing better. What's worse, as long as you're doing okay in some area, you have no idea that you're just okay. Being mediocre doesn't elicit response or comment. There's also been a growing trend to focus solely on strengths and not on weaknesses. I understand their arguments, but it's still damaging when a person doesn't know they are weak in an important area. Obviously, based on the title of this post, I'm describing problems that 360 reviews aim to solve.

  I've been toying around with 360 reviews, and like them. From a tools perspective, there are probably many out there that do a great job. Unfortunately, it can take a great deal of time to investigate several solutions, especially if you need to contact the companies, or pay upfront without seeing the systems in action. I wasn't able to find one that I could easily try without signing up, so I created one.

  Take a look at CircleStats. It facilitates the 360 review process and presents the results in a very visual way.


  If not for your team, you should at least know if there's a discrepancy between how you think you're doing in an area, and how others think you're doing in that same area. If taken with a grain of salt, you can learn more about how you're doing from 360 review feedback than you can in talking to peers, direct reports, and managers, even if you talk often.

Pattern Recipes 10 March, 2015

Patterns are mechanisms that invoke an instant understanding of what's happening. At least they're supposed to be. In many scenarios, devs pause blankly for a moment trying to remember what processes that pattern name is supposed to represent.

I wonder if how we index software development patterns is one reason that many people don't remember and use them more often. For example, the Visitor pattern obviously implies that something goes and visits something else. Presumably this happens for decoupling reasons, but other than these basic assumptions, I can't really derive from the pattern name what the pattern really does, or what an optimal use case for it is.

I'm going to propose better names for several well known patterns. The names are longer, but I believe they do a much better job of explaining the pattern. I'll also give a tweet sized explanation. I call these pattern recipes.

Encapsulate a Task == Command
Make an object that can run a task, maybe even undo the task it ran, etc.

Register for Notifications == Observer
Registering and unregistering for notifications by letting an object call a known methods on you.

Algorithm delivery truck == Visitor
Visit me and run an algorithm or method on my data.

Composition over Inheritance == Strategy
Add behaviors by adding objects that encapsulate those behaviors.

Choose Implementation at Runtime == Factory
A class that manages creation, teardown, and resources of related implementations(subclasses).

Choose Implementation Groups at Runtime == Abstract Factory
A class that manages creation, teardown, and resources of implementation groups(factories).

Adapt One Call to Another == Adapter
With API mismatches, create a class that can converts data and bridge any mismatches.

Hide Complex Behavior == Facade
Make code easier to read and use by encapsulating more and hiding dependencies.

Template == Template :)
Like a mix of facade pattern and using an interface or subclasses
one easy call exists, which runs some more complex code.  when that one simple call is running, there is the possiblity for it to ask some subclass or implementing class whether it should execute certain steps.
the simplest version is just a superclass and set of subclasses.
the more complex version then may or may not run specific parts of the complex code.

Mix Composition and Inheritance == Bridge pattern
By using both inheritance and composition, you can decouple more
if you have a long chain of subclasses, try keeping some as subclasses and turn others into a strategy of those subclasses
it also helps when you are mixing and matching classes instead of a Cartesian number of classes, you have just the number needed to represent different objects/behavior instead of objects X behavior.

Prototype == Prototype pattern
A polymorphic version of the copy constructor
deep copy an object in hopes of avoiding lots of init-calc code to recreate the same object

Add One Piece at a Time == Builder
Use if there are too many combinations for constructors...
return self to keep calling setters

Linked Wrappers == Decorator
Create a class for each attribute, rather than for all combination of attributes

Iterator == Iterator
separate algorithm and structure traversal from data container

A Tree with Branches and Leaves == Composite
Treat individual objects and groups of those objects in a similar fashion, like trees with branch and leaf nodes
interface -> both individual and group
this lets you iterate over a mixed hierarchy of this kind smoothly

Reuse Object Parts == Flyweight
Reuse the immutable parts of objects to save memory

I Know My Options == State
An object can change its behavior by changing its internal state. At a simple level, an object knows its state and the options for getting to a new state. Specifically, its state points to different subclasses of some interface dynamically during runtime.

Proxy == Proxy :)
Exactly what it says it is... it sits in front of some class, both the class and proxy implement the same method. The proxy can limit, change, or do whatever it wants to the call. It probably implements all the same methods as the class it is acting as proxy for. no changes to the original object are needed

Push the Problem Up the Ladder == Chain of Responsibility
Several classes that can handle a specific but different case to a problem all implement an interface. Each of these handlers knows about a sibling handler it can pass the problem to if it can't handle the problem.

Language Interpreter == Interpreter
Uses the composite pattern along with a context(parsing) class to process language.

Middleware == Mediator
When objects want to interact, a mediator can encapsulate this activity if there are too many relationships between objects.

Remember States at Points in Time == Momento
Snapshots, some managing class(could store a list of states) that interacts with some state class.

I hope this helps you remember what patterns really mean.