Tag: management

Posted on

Managing through aphorisms

They’re clichés, sure, but are for a reason. And in a sound-byte driven world, having a punchy phrase to summarize what is often full of nuance is useful. I find myself returning to these as mantras, rallying cries and whatnot repeatedly as I lead a team, pull in collaborators and stakeholders, and generally try to make better software in better ways.

Default To Open

In what is probably the most surprising 180 from my early career, I lean deeply on this idea, across several ways:

  • open source your code. This has a few effects: write all your code like someone else is going to read it, that you don’t know. Make sure your code is functional. More basically, thinking in an open-source mind changes some approaches.
  • Talk about your work openly. Learn in the open. Share your learning, your success, your failures. Write about it. talking about. Let anyone who wants to follow along follow along. This helps remove some barriers to being vulnerable in my experience, and can help sharpen thinking by actively, consistently reflecting on work in progress.
  • Give access to your work. Open your backlog for others to see. Keep tickets available to submitters so there’s no back-channel. Talk in open channels not private messages. All of this can help drive a practice of asking questions, being respectful of others’ learning, a safe space for vulnerability, and being kind to clients/stakeholders.

Aim for Less Wrong

At all times, assume you’re wrong. Your goal is to get to be less wrong. You can only validate how wrong you are by talking/sharing with others, and being humble about that. And understand that everyone is wrong at the start, and constantly working to get to less wrong. I’ve found that by repeating this over and over, it can help lead to some changes:

  • asking more questions
  • being kinder in response to “dumb” questions
  • putting something into existence to work on/against, vs being paralyzed by choice to start. It’s easier to talk about something in particular vs a general idea “let’s do X” rather than “we should do something” gives an opportunity to change X.
  • It removes the stigma and potential shame about being wrong – you’re already wrong. Know this, accept this, and aim to be less wrong.

Writing software is a team sport

This is sort of the corollary of go alone to go fast, go together to go further. You need others to be successful, because everyone is full of biases, and other people help you get around them. And people with different skills are required for a good team. I’ve found this is a helpful gentle nudge away from individuals who constantly want to be a hero and take everything on by themselves too.

Write less software

Perhaps ironic for a software team, but the best software is the software you don’t write. Much like how a car loses half its value as you drive it off the lot, All production software is legacy someone needs to deal with in the future. So write less of it. If you can use someone else’s software? if your default position is “I don’t need to write this”, it can really give focus to the decision that, indeed, you do need to write it. Can you justify why you haven’t just used someone else’s software? it is worth the effort, the cost of maintenance?

Write boring software

This goes along with the above. We all want to write super-brilliant, complex software that’s on the cutting edge of everything because we’re that awesome. But guess what. Chances are that you’re only going to be responsible for 10% of that software’s life. OTHER people – OTHER systems will have to be able to work with in in the future. So if you follow common patterns, you lower the cognitive overhead to learn it. and maintain it. Resumé-driven Development should be avoided in almost all instances, because software needs to live in teams, not individual’s heads. It also means to, more often than not, move cautiously. Don’t adopt that rad new framework just because it is there. The larger the organization, the more important this is. Human ability to share immense code-bases because of predictable patterns is major advantage.

Progress is more important than excellence

Everyone wants to be the best. Strive for that. But perfectionism is the enemy of good (is that another aphorism to live by?). What’s important is consistent progress towards better on all plans. experiment, iterate, improve. Fail one time? that’s fine. learn and do it better next time. If you’re the best, if everything is excellent, you’re in the wrong job – because you’re not being challenged. Similarly, if you can no longer progress, you’re in the wrong job – because you either don’t care or you’re in the wrong role for your skills.

There’s of course and endless list of these. These few keep cropping in conversations over the past year or so. Other things I’m trying to find good wording for is around the concept of how good software is living, or like a plant, or something – that you have to maintain it, update it, let it adapt to the world around it, etc.

Posted on

Creating a win

In my job, I do a mix of project work (larger bits, building sites, etc), tickets (service requests from clients) & management (running a company). Historically, I would spend my mornings doing the latter two tasks – they’re all piecemeal items that take anywhere from 5 minutes to 2 hours to complete, then I’d switch over to project work in the afternoon before wrapping up with a little management action – mostly status updates from staff/contractors.

This was ok, except that it really left only 3-4 hours a day to do project work, and in the afternoons which have *always* been less productive than mornings & evenings for me. I felt like I always had a huge pile of tickets and wasn’t keeping up with project work. Partially because we’re so busy, but partially just a sense because with such a short timeframe, I often wasn’t reaching a milestone within a day. And I like checking things off my to-do list.

So earlier this year, I started to push things around, and watch how things fell out. I don’t work fridays, and I don’t launch projects on thursdays (because I don’t work fridays), so I tried to do tickets & non-daily management tasks on Thursdays. This worked out ok for me, but less so for clients – they wanted tickets done before thursdays so that they could review them too. So now I’ve moved my “tickets” day to Mondays. And this has been an epic win.

I discovered that no one minded if I told them that their request would be completed the following Monday – even though they minded when I used to say Thursdays. I think that’s because mentally, Mondays are the start of something, even if it’s the next something, whereas Thursdays are near the end, so people are feeling rushed to finish before the end of the week. And because I’m not in the office on Fridays, there was always an extra dose of staff management, partner meetings & ticket requests to deal with anyways.

So now on Mondays I do tickets, I buy supplies, I check on staff, I check in on clients. I spend all day doing little 5 minute-1 hour tasks. By the end of the day, generally, my to-dos for the week have dropped to only the projects I’m working on and 1 or 2 others. And, rather than feeling stressed because I’m already behind after 1 day, I instead feel accomplished because I’ve cleared my slate and now have 3 solid days of “real” development ahead of me. Days with few interruptions where I can knock off milestones and get that satisfying tick on my to do list.

So I’m not doing any less work, or any different work. But just by examining how I worked, and looking at what clients were expecting, I’ve been able to shift my week around to be, on the whole, markedly more productive than it was prior to my making this shift. I’ve created a win for myself where previously there was generally only failure and “close”. This month we’re experimenting by putting everyone on this schedule. We now have enough staff that every day but Friday has 1 staff member knocking out service requests, freeing the rest of us to just to project work the rest of the week. I’m hoping that we’ll not only maintain our current turn-around-times for service requests, but potentially actually get a little faster with this system, even though each staff is spending only 1 day a week, rather than little bits of everyday.

 

Posted on

Learning to celebrate success

I’ve been thinking a lot about this topic recently, because in my ongoing goal to emote more, this is a real easy arena to do something about, one would think – how hard can it be to take a moment to reflect on an accomplishment and self-congratulate? Very hard apparently. And why? Because I’m nothing if not an eternal Devil’s Advocate. Show me something good, and it’ll take all of 10 seconds to find something to quibble about – a counter-argument to a statement, an oversight, a mistake, a not-quite-perfect element. But it’ll take minutes, if not hours for me to come to the conclusion that none of those things matter, and what you’ve shown me is in fact, really quite good.

At work, this was never an issue when I was working by myself, or just with Jeff. I’m only ever as good as the project I’m currently working on. We didn’t stop to celebrate our success because we were always driving so hard for our next success. And, to be frank, because I’m leary of success. Looking at a finished website, and I don’t see a great project, I see a site that could load 0.2 milliseconds faster, or a function that’ll only work in these 15 scenarios, and not in these other 2, or a datbase that could be further optimized, or could have just a few more accessibility features, or … etc. You see the point. This doesn’t extend (generally) to other people’s work – I love seeing what other people do, and unless asked, generally approach it with an appreciative, rather than a critical eye. But I cannot turn my critical eye away from myself. I’ve discovered that as an owner and manager of a software company that my critical eye extends to everything produced by staff because whatever they produce is implicitly approved/produced by myself (I’m only as good as the software my team is currently working on). I’ve tried to do things as little as a fist-pump, or shouting “yes!” when I solve a particularly troublesome piece of code, which, actually, is very satisfying, but I mean on a larger scale.

Celebrating success is, however, important for corporate success. For both morale and for brand-building. I often encounter people who know our work, but don’t know that we were the producers of the work. This is largely because we at Pencilneck don’t have a great track history of celebrating our success. We haven’t been good about thanking our clients, or celebrating with them, despite feeling great about launching a project for them. We haven’t written press releases to puff out our chests so everyone can see what awesome work we’ve done, even when we’ve really deserved to. And I haven’t taken the time to pause and celebrate the completion of a project with my staff. And this, I think, can lead to problems down the road. So I’m committing myself to start to do this. I don’t know what exactly we’re going to do, but I’m going to make a point of pausing, with my team, when we complete a project, to celebrate. This won’t be a time to review the project with a critical eye to see how we could have done better. This will be an event, perhaps as quick as a meeting around the water-cooler, perhaps an evening out, to sit around, thank the team and let them bask in their well-deserved glory.

And how will we celebrate with our clients & partners? I don’t know. But we’ll do something this year to better mark the end of a project then simply saying “we’re live!”, and then turn around and start in on something else.

How do you celebrate your success?

%d bloggers like this: