Monthly Archives: January 2020

What is Management?

Economics, Idle Speculation, Organizing Systems

So, I’ve been thinking about management training recently[0], and while I’m collecting my thoughts, I thought it would be good to talk about what ‘management’ is, at its most fundamental.

I’m going to make some assumptions here:
– Management is about the art of helping[1] people to work together towards a common goal
– We’re talking about ‘good’ management, which is trying to do the above in a positive and sustainable way
– The things we’re going to talk about will be relevant to all[2] organizations with some sort of hierarchy, and perhaps some without

“Those who can, do. Those who can’t, manage.’
– A paraphrase of a quote from George Bernard Shaw

The quote above, while flip, has some interesting truth to it. I would argue that, beyond perverse financial incentives[3], those who decide to go into management from an individual contributor (IC) role do so because of some competitive advantage pushing that choice. Likely one of:
– They are better at managing then at being an individual contributor (leading to the quote above)
– They are better as an IC than as a manager, but they are better than anyone else at being a manager (competitive advantage)
– They are better as an IC than as a manager, but they are afraid that any one other than them chosen to be manager will be worse (and/or they want control over their work environment/process)

So, having some idea of why people ‘get into’ management, what is ‘management’?

Like we said above, ‘management’ is the art of helping people work together towards a common goal, in a positive and sustainable way.

To me, this includes the following components:
– Helping people work together towards the goals of one’s team
– Helping people work together towards the goals of the larger organization
– Helping people and the organization as a whole improve goals and process[4]
– Helping your team (and yourself[5]) achieve career goals
– Keeping your team (and yourself) happy

Now that we have some categories, we’ll continue next time going into a little more detail. Thanks for listening. 🙂

[0] And feeling super-pompous about it. Luckily, I have good friends who will tell me when I’m full of it. 🙂

[1] I use the word ‘helping’ here, a relatively positive word, and probably suitable for working with one’s direct reports, or in a truly psychologically safe environment. Sadly, most environments are not that, and people must often be convinced to do what is in the best interests of the organization (and often must be convinced to do what is in their own best interest, too). ‘Convincing’, or ‘getting’ might be used in other environments, but even in those environments, I think ‘helping’ is still a healthier and more productive choice.

[2] Public, private, etc…

[3] There are some organizations where the structure is such that one can only advance in one’s career (read payscale) by advancing in ‘management’. Some would say that most large organizations are like this to some extent. This discussion, while important, is out of scope.

[4] I have much to say (and many books have been written) about the ways in which organizations do non-optimal things, decide on non-optimal goals, or otherwise lose their way. (My favourite book which touches on this is ‘The Goal’, by Eliyahu M. Goldratt.)

[5] It’s incredibly important to support your team, and do the best you can to ensure their success. In general, you become successful when your team is successful. There will be points where this diverges, though, and it’s important to know when those are, as you and your team members will be healthier with healthier boundaries.

Some More Management Roles

Agile, Engineering, Organizing Systems, Software Development

A few years ago, I talked about some management roles, specifically how the traditional ‘Team Lead’ role could be de-convolved into five different roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

At the time, while I’d been running important teams in my organization, it was still a relatively small organization (each CEO knew me by name), so the role and significance of each team was more clear (or at least had been justified by someone before me).

Since then, I’ve learned a little more about what is important in a large organization, and I have some more roles to add. The above management roles have more to do with day-to-day management of a team, and assume that managing upwards and managing long-term are taken care of elsewhere. (Theoretically, they are probably most likely part of the ‘Product Owner’, but most likely they would be part of the ‘reserve power‘, and would devolve to whomever was considered ‘highest’ in whatever organizational hierarchy was present.)

I had also been blessed with excellent technical leads on all of my teams at all of the places I’ve worked, enough so that I didn’t think to explicitly call out ‘Technical Lead’ as one of the ‘traditional’ management roles.

(So now, we have six):

Technical Lead (Software Architecture & Implementation Decisions)
Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

(There are also some questions about the exact line between ‘roles’ and ‘skills, for example: ‘Running a Meeting’ ‘Presenting engaging presentations’), so I will include them for completeness, even though they bleed into many of the other ‘roles’.

As mentioned above, the roles below would fall under some combination of:
– ‘Product Owner’ (because they involve working with people or groups outside/above the team in question)
– ‘Scrum Master’ (because the team would notice that they were blocked or impeded by not paying attention to a certain type of issue, and might be perceptive enough to up-level the discussion to a more general/role-based one)
– ‘Reserve Power’ (roles or tasks that are automatically put under a traditional ‘Team Lead’, but no one really considers them separately, even though they take real time and effort)

Anyways, here are some other longer-term and/or more upward-facing roles to add to the above:

Milestone setter
Team Vision & Planning
Recruiting, Interviewing, & Hiring
Team compositions planning/Team Development (this is development of the team as a whole)
Building relationships (travel, phone, random 1:1s)
Running Meetings
Preparing & presenting engaging presentations
Tech architect (Longer-term decisions about code structure)
Code reviews (this would likely fall under ‘Tech Lead’ above, but ‘what is good enough’ would likely fall under the next line, ‘Quality decision-making’)
Quality decision-making (how good is ‘good enough to ship’?)
Quality Assurance & testing
Asking for resources
Team Champion, in charge of Dog & Pony shows[1] (Why is the work that the team does important?)

Some of the above roles are systematized, automated, or otherwise circumscribed by processes in larger organizations, for example, they may have specific processes for project planning, or for recruiting or development conversations.

But still, there are a lot of these. This suggests that either teamwork is super-complex, and requires too many different things to easily handle without tools[2], or there must be some way of grouping them into meaningful ‘roles’.

So, how do we group them? We could group them into the familiar Agile ‘Technical Lead’, ‘Scrum Master’, and ‘Product Owner’, but that just really puts us back where we started, shoehorning roles into boxes that don’t quite fit, or with a bunch left over.

Fundamentally, all of the above roles are some combination of tasks and making different kinds of decisions.

I’ll do what I can to define, codify, and group them tomorrow.

[1] I am somewhat flip in my naming here, but in any large organization, any team should have a story for how they are planning to remind the management structure of why they are important. This serves a number of functions:
0) The obvious ‘remember who we are and what we do’
1) It’s a good check-in, to make sure that what they are doing is actually perceived as important
2) It’s good practice for the inevitable re-orgs in any large organization, or even if one’s boss changes because they leave for another position or organization

[2] Like checklists, or more advanced tools like JIRA and wikis.

Sriracha & Potato Stir-Fry

Cooking

So, we were experimenting with stir-fry composition, and happened upon a new favourite: Sriracha & (Rosemary) Potato.

It goes as follows:

Total preparation and cooking time: 25-30 mins.
Serves 2.

Recommended music: https://www.youtube.com/watch?v=UkSr9Lw5Gm8
(Because cooking is very much like building things.)

Equipment required:
– Some sort of stove
– Some sort of frying pan
– Some sort of stirring/spatuling instrument

Ingredients required:
– Some sort of cooking oil (we’ve been using grape oil, which is actually super-tasty)
– Two medium potatoes
– One medium onion (I prefer yellow) or 1/2 bunch of green onion
– Three half peppers
– Two cloves of garlic
– Sriracha sauce
– Some sort of soy sauce (we used Kikkoman low sodium)
– Rosemary (cf. Rosemary Potatoes)
– Some sort of herbs/spices (we used Oregano & Basil)

Pairs well with rice & greek salad, as seen here:

The delicious stirfry from today:
The delicious stirfry from today:

Directions:
– Turn on the stove to medium-low (I do 3/10 on our stove’s large burner, with both parts of the burner turned on)
–
– Thin-slice the potatoes, and cut these slices in four (I cut the potatoes in half, cut them into thin slices, and then put the pile on the cutting board, and cut again in four.)
– Add the potatoes and some cooking oil to the frying pan.
– You are going to want to stir on a regular basis. Potatoes are frying pan-sticky
– If you’re using a medium/cooking onion (not green onion), chop up the medium onion and add it to the frying pan. (I top and tail the onion, remove the outer layer or two, then slice it, then chop the stack of slices in four or six. I usually rinse the onion before chopping, but that was not enough to protect me today.)
– Chop up the garlic and add it to the mix (I do garlic the same way I do onions, top & tail ,then remove outer layer, and then slice, then cut stack of slices in two or four.)
– You may need or want to add a little more cooking oil, to prevent burning or sticking.
– This is a good time to add the herbs (rosemary is the most important), and the sriracha & soy sauce. For the sriracha, enough to go back and forth in the frying pan a few times, and perhaps 3-5 splashes of soy sauce.
– Chop up the peppers (I chop three in half, so I can get red/orange/yellow, and save the other halves for tomorrow’s meal). I wash them, remove the tops, rinse them, cut them in half, remove the bottom center part, then slice and then dice them. Throw them into the mix.
– You’re still stirring, right?
– Keep stirring until the potatoes are soft enough that you want to eat them. Total elapsed time was about 30 mins today. (Total time yesterday was about 25 mins at a stove setting of 4/10, but I was worried about burning the mix throughout the entire process.)

Serves 2.

On the Importance of ‘Technical Debt’

Agile, Economics, Engineering, Organizing Systems, Programming, Software Development

A couple of years ago, I was talking with a good friend of mine, we were talking about the difficulties of prioritizing the maintainability of software in a large organization development context.

And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before[1], although as soon as he heard it, he grasped the importance.

(I remember it as being a really inspiring conversation, but sadly, my notes from that day don’t well capture what I found so inspiring about it. 🙁 )

Although the concepts of ‘clean up after yourself’ and ‘do it the right way’ are likely as old as human civilization, it was likely only after systems reached a certain level of complexity that the concept of ‘Technical Debt’ was really useful. There is a limit to how complex a mechanical system can get[2], and most other systems are amenable to human factors and psychological safety solutions.

It’s also interesting to think about what is different about software, that makes it: A) possible to make a working product with large (including conceptual) defects, B) Useful to ‘go into debt’ to get a product out the door faster (or more cheaply).

One wonders how much it is the sheer complexity of software systems, the number of interacting modules, or perhaps the number of layers involved, from OS to dev_tools, to language, to standard libraries, to 3rd party libraries, to user-made helper functions. Perhaps it is just that one can ‘go into debt’ in the uppermost layer, because there exists a good foundation.

It could also simply be that software is an automation of so many smaller tasks, that any human system as complex would have similar useful concepts of debt[3].

Doing a little bit of digging, it seems that the concept was first termed ‘debt’ sometime in 1992[4], but it was not until later that it was termed ‘Technical Debt’.

Articulating the concept of ‘Technical Debt’ has a number of important benefits:

1) It puts a name on the category of ‘things we want to clean up in our code’, adds an urgency, and calls out more precisely why this is important.

2) It links the concept of ‘do things the right way’ with ‘Business’ concepts of money. This enables much better CTO-CFO conversations, allows better and more informed project funding decision making, and (hopefully) enables better and more structured funding for Technical Debt reduction[5].

3) It enables conversations in the moment, during architecture conversations and code reviews (and everything in between), where the parties involved can directly weigh/balance the time/resource costs of proper implementation with the opportunity costs of delaying time to market (or MVI/MVP[6]).

It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.

[1] We theorized that this was because he had grown up in Hardware companies.

[2] I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… 🙂

[3] Such as ‘Organizational Debt‘.

[4] https://www.martinfowler.com/bliki/TechnicalDebt.html “As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki http://wiki.c2.com/?ComplexityAsDebt.”

[5] My favourite label for this is the ‘FBI’ list[7], as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.

[6] ‘Minimum Viable Increment/Minimum Viable Product‘, from various implementations of Agile theory.

[7] Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.