Category Archives: Project Management

Where to file an issue?

Posted on by
Reply

Recently, the Fedora Engineering Steering Committee (FESCo) entertained a proposal to allow people to file issues in the repo where Fedora RPM spec files live. They ultimately rejected the proposal in favor of keeping those issues in Red Hat Bugzilla. I didn’t weigh in on that thread because I don’t have a set opinion one way or another, but it raised some interesting points.

First, I’d argue that Bugzilla is hostile for end users. There are a lot of fields, many of which aren’t meaningful to non-developers. It can be overwhelming. Then again, there probably aren’t too many end users filing bugs against spec files.

On the other hand, having multiple places to file bugs is hostile for users, too. “Where do I file this particular bug? I don’t know, I just want things to work!”

Having multiple places for bugs can be helpful to developers, so long as the bugs are filed in the right place. Spec file bugs make sense to be filed in the same place as the spec files generally. But they might make more sense elsewhere if they block another bug or fit into another workflow. And the odds of a bug being filed in the right place isn’t great to begin with.

This is a question for more than just Fedora though. Any project that has multiple pieces, particularly upstream dependencies, needs to think about how this will work. My take is that the place the user interfaces with the code is where the issue should be filed. It can then be passed upstream if appropriate, but the user shouldn’t have to chase the issue around. So if an issue manifests in my project, but the fault lies in upstream code, it’s my responsibility to get it fixed, not the user’s.

So now that I’ve typed all this out, I suppose I would argue that issues should be enabled on src.fedoraproject.org and that it’s the package maintainer’s responsibility to make the connection to Bugzilla where required.

Don’t celebrate feeling stupid

Posted on by
Reply

I recently saw a tweet that offered advice to new Microsoft employees:

My initial reaction was that this is very true and also bad. I said it was a sign that the onboarding process is broken. But there’s more nuance to it. I want to draw a distinction between not knowing all of the pointy ends of a job and not knowing how to do the tasks necessary.

The former is good for personal growth. I wouldn’t want to take a job that I already know exactly how to do; I won’t learn that way. And even when you’ve done the job somewhere else, each organization has unique nuances that it takes time to learn.

Where it gets troublesome is when the difference between what you’re asked to do things you haven’t been taught how to do. Here I mean the internal processes and tooling, not the general act of doing it. It’s reasonable to expect a marketing person to know how to write a blog post; it’s not reasonable to expect them to know how to submit it through your internal tooling.

Perhaps that’s not what Carmen meant, but it’s certainly what came to mind for me. When I joined Microsoft, we had no documentation for what was expected of people in my role and no documentation for how to execute those tasks. So I would have people coming to me for things that I had no idea how to do — or even what they were. In my time there, I tried to document as much as I could so that the next person who joined the team would have a less stressful onboarding experience than I did.

But even if Carmen was talking more about the “not knowing the pointy ends” scenario, it occurs to me that this may not be healthy. Personal growth is great, but if the difference between what you know how to do and what you’re expected to do gets too large, it’s no longer growth — just stress. People I spoke to at Microsoft seemed to embrace the “you’ll feel stupid” part, and maybe that’s unavoidable, but it’s not a good thing to embrace.

In a talk at the Southern California Linux Expo last week, Jono Bacon said something that really stuck out to me. “[Burnout and stress] is a topic that isn’t talked about enough. In our industry, particularly in Silicon Valley, stress is glorified and that’s stupid.” If you’re in a position to help with onboarding new hires, give them the tools to know how to do their job so they can learn how to do their jobs.

Are team building exercises a waste?

Posted on by
Reply

Carlos Valdes-Dapena thinks so. In an article for Harvard Business Review, he argues that most team building events are a waste of time and money. He has research to back it up, but I think most people who have participated in hokey corporate team building events would say “duh”. But there’s a difference between Team Building™ and team building.

Team Building™ often consists of contrived situations that seek to forge bonds within a few hours. They’re expensive and elaborate. They may involve cheesy, forced metaphors. Participants feel uncomfortable and coerced.

Team building is not something that can be forced. It can be encouraged, given conditions to thrive. Ultimately, though, it must happen organically. So any team building exercise that’s worthwhile has to be a slow burn. Relaxed, informal lunches can do a lot for helping people work together. I’ve enjoyed trips to a bowling alley and to a cave system.

The key part is “we’re going to spend some time together away from work”, not “we’re going to lock you away so that you become a team”. Even though the goal is to improve team cohesion, you can’t just sit there and expect it. Give people space to socialize and interact on their own terms so that they can form bonds on their own.

This is particularly important for distributed teams. In my experience, even brief face-to-face meetings dramatically improve how I work with others. When I visit offices or run into colleagues at conferences, I try to spend as much time as I can being social. I ended up skipping several sessions at DevConf because I figured the opportunity to have a cup of coffee with a project contributor was more valuable than attending a talk that I could watch on YouTube later.

Good team building exercises are cheap and easy. They aren’t a burden on your team. But they take time.

Bureaucracy survival skills

Posted on by
Reply

I began my professional career working for a large university. In the first three years, I worked in a small department, but I later spent three years in the central IT organization. I got a lot of exposure to the bureaucratic machinery. Then I went to work for a 25-person company for five years. When Microsoft — a company of over 130k employees — acquired my employer, I was thrown back into the bureaucratic machine. But it turns out my bureaucracy survival skills had atrophied a little bit.

It took about three months before I got my footing and was able to start navigating the bureaucracy again. I like to think that when I’m in shape, I’m pretty good at it. So I’ve collected some of the rules I’ve learned over the years.

  • There are meetings for everything. — You may even have a meeting to plan the real meeting. If your deity is particularly mad at you that day, you’ll have a post-meeting meeting, too. This happens in almost all large organizations. It becomes too large and impersonal for people to keep up on what’s going on, so they’ll have lots of meetings so everyone can stay informed. Even if the meeting could have been an email, it will still happen because that’s the safer option.
  • Meetings will always begin with 5-10 minutes of late arrivals and AV/conferencing troubleshooting. — Computers are so much easier to use than in years past. So much just works. But somehow getting the projector to join the web meeting will continue to elude even the smartest people in the room. And because everyone is invited to all the meetings, they’ll probably be a few minutes late to yours.
  • The only thing worse than being in all those meetings is not being in those meetings. — It sucks spending all your time in meetings instead of doing your job. But decisions are (sometimes) made in meetings. If you’re not included, you’ll be left out of important decisions.
  • Conway’s Law is real. — Anything your organization designs will look a lot like the org chart.
  • People will take your responsibilities when it benefits them and give you responsibilities when it doesn’t. — In a large organization, you need to be visible to get rewarded. So if someone can benefit by doing your job for you, they will do it. But if it won’t benefit them, they’ll try to pass the task on to you.
  • People are more likely to ask for volunteers than to volunteer. — This is related to the last one. It’s easy to put out a call for volunteers. It’s harder to step up and volunteer. This is in part because people will often not volunteer and if you step up every time, you’ll have way too much work on your plate. The solution here is to assign tasks instead of asking or hoping for volunteers.
  • You can say no. In fact, you should. (to travel, to working outside of business hours, etc). — It won’t hurt your performance and it will help your sanity. I wrote about this in greater length last month.
  • Everyone will agree about broken processes, but no one knows how to fix them. — Large bureaucracies will have a lot of processes that probably made sense at one point, but grew or decayed to the point where they are inarguably broken. But how do you fix them? Nobody seems to have a good answer. Sometimes there are people with a vested interest in maintaining the status quo. Other times, it’s just a really big ship to try to turn around and no one has the time to devote the necessary work to it.
  • The only way to find out how to do something is to ask. There will be no documentation, and if there is it won’t be discoverable. — Every once in a while your predecessor will be someone like me who leaves the documentation in a better state than they found it. But for the most part, people don’t even bother writing documentation because they don’t want to, they’re not required to, and it will be out of date by the time someone reads it.
  • References to products will survive a lot longer than the products themselves. — For months, I would hear people at Microsoft talk about “S+”. I figured out from context that it meant a meeting invitation, but I couldn’t figure out why. Turns out Schedule Plus was a product in the 1990s. I was there 20 years after the functionality was merged into Outlook, but I still heard references to it.
  • Interpersonal relationships are how things get done. — Make friends. Make lots of friends. Make friends with people in other departments. Keep in touch with them as they and you move around the organization. Whenever you need something done, it’s much more likely to happen if you know someone you can talk to personally. Relying on official channels will, unfortunately, result only in waiting and inaction.

Those are the lessons I’ve learned. I’m sure there are plenty more. If you have lessons for surviving bureaucracy, let me know in the comments.

What’s routine to you is interesting to others

Posted on by
Reply

One thing about humans is that we’re really good at habituating. It doesn’t take long for something new to become normal. This really came to mind last month when I presented a pair of talks at the DevConf.cz conference in Brno, Czech Republic.

One of my talks was a 25-minute presentation on project management in community projects. As I was putting the talk together, I started thinking “this is a nothingburger.” Twenty-five minutes isn’t enough to give any useful depth of information. So all I’m doing is giving a basic description of my job.

As it turns out, “nothingburger” was the exact hunger level of the audience. When I asked the room, only three people or so said they were professional project or program managers. An intro-level talk was exactly the right target. Doing the work every day, I forgot that it’s not everyday for other people. Even people who do related work might find something worthwhile out of it.

l should have known better. Even in my own company, I’m the only program manager who works directly in upstream projects. The rest are focused on the company’s products. Unless they served in my role previously, the people on my team don’t necessarily know how my job is different from theirs.

I left DevConf.cz feeling inspired to seize the momentum and keep moving on some things I’ve wanted to do. And it’s a good reminder to myself and others that we’re not the best judges of what others will find interesting.

Can your bug tracker and support tickets be the same system?

Posted on by
Reply

I often see developers, both open source and proprietary, struggle with trying to use bug trackers as support tools (or sometimes support tools as bug trackers). I can see the appeal, since support issues often tie back to bugs and it’s simpler to have one thing than two. But the problem is that they’re really not the same thing, and I’m not sure there’s a tool that does both well.

In 2014 (which is when I originally added this idea to my to-do list according to Trello), Daniel Pocock wrote a blog post that addresses this issue. Daniel examined several different tools in this space and looked at trends and open questions.

My own opinions are colored by a few different things. First, I think about a former employer. The company originally used FogBugz for both bug tracking and customer support (via email). By the time I joined, the developers had largely moved off FogBugz for bug tracking, leaving us using what was largely designed as a bug tracker for our customer support efforts. Since customers largely interacted via email, it didn’t particularly matter what the system was.

On the other hand, because it was designed as a bug tracker, it lacked some of the features we wanted from a customer support tool. Customers couldn’t log in and view dashboards, so we had to manually build the reports they wanted and send them via email. And we couldn’t easily build a knowledge base into it, which reduced the ability for customers to get answers themselves more quickly. Shortly before I changed jobs, we began the process of moving to ZenDesk, which provided the features we needed.

The other experience that drove this was serving as a “bug concierge” on an open source project I used to be active in. Most of the user support happened via mailing list, and occasionally a legitimate bug would be discovered. The project’s Trac instance required the project team to create an account. Since I already had an account, I’d often file bugs on behalf of people. I also filed bugs in Fedora’s bugzilla instance when the issue was with the Fedora package specifically.

What I took away from these experiences is that bug trackers that are useful to developers are rarely useful to end users. Developers (or their managers) benefit from having a lot of metadata that can be used to filter and report on issues. But a large number of fields to fill in can overwhelm users. They want to be able to say what’s wrong and be told how to fix it.

In order for a tool to work as both a bug tracker and ticket system, the metadata should probably only be visible to developers. And the better solution is probably separate tools that integrate with each other.

Inclusion is a necessary part of good coding

Posted on by
2

Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code.

We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.

But it’s not like the tech industry has a history of bad decision making. Or soap dispensers not working with dark-skinned people. Or identifying black people as gorillas. Or voice recognition not responding to female voices. What could go wrong with automatically labeling “suspicious” people?

I’ll grant that not all of these issues are with the code itself. In fact a lot of it isn’t the code, it’s the inputs given to the code. So when I talk about “good coding” here, I’m being very loose with the wording as a shorthand for the technology we produce in general. The point holds because the code doesn’t exist in a vacuum.

It’s not just about the outputs and real world effect of what we make. There’s also the matter of wanting to build the best team. Inclusion opens you up to a broader base of talent that might self-select out.

Being inclusive takes effort. It sometimes requires self-examination and facing unpleasant truths. But it makes you a better person and if you don’t care about that, it makes your technology better, too.

Tech is a garbage industry filled with people making garbage decisions

Posted on by
1

I work with some great people in the tech space. But the fact that there are terrific people in tech is not a valid reason to ignore how garbage our industry can be. It’s not even that we do bad things intentionally, we’re just oblivious to the possible bad outcomes. There are a number of paths by which I could come to this conclusion, but two recent stories prompted this post.

Can you track me now?

The first was an article last Tuesday that revealed AT&T, T-Mobile, and Sprint made it really easy to track the location of a phone for just a few hundred dollars. They’ve all promised to cut off that service (of course, John Legere of T-Mobile has said that before) and Congress is taking an interest. But the question remains: who thought this was a good idea? Oh sure, I bet they made some money off of it. But did no one in a decision-making capacity stop and think “how might this be abused?” Could a domestic abuser fork over $300 to find the shelter their victim escaped to? This puts people’s lives in danger. Would you be surprised if we learned someone had died because their killer could track them in real time?

It just looks like AI

And then on Thursday, we learned that Ring’s security system is very insecure. As Sam Biddle reported, Ring kept unencrypted customer video in S3 buckets that were widely available across the company. All you needed was the customer’s email address and you could watch their videos. The decision to keep the videos unencrypted was deliberate because (pre-acquisition by Amazon), company leadership felt it would diminish the value of the company.

I haven’t seen any reporting that would indicate the S3 bucket was publicly viewable, but even if it wasn’t, it’s a huge risk to take with customer data. One configuration mistake and you could expose thousands of people’s homes to public viewing. Not to mention that anyone on the inside could still use their access to spy on the comings and goings of people they knew.

If that wasn’t bad enough, it turns out that much of the object recognition that Ring touted wasn’t done by AI at all. Workers in the Ukraine were manually labeling objects in the video. Showing customer video to employees wasn’t just a side effect of their design, it was an intentional choice.

This is bad in ways that extend beyond this example:

Bonus: move fast and brake things?

I’m a little hesitant to include this since the full story isn’t known yet, but I really love my twist on the “move fast and break things” mantra. Lime scooters in Switzerland were stopping abruptly and letting inertia carry the rider forward to unpleasant effect. Tech Crunch reported that it could be due to software updates happening mid-ride, rebooting the scooter. Did no one think that might happen, or did they just not test it?

Technology won’t save us

I’m hardly the first to say this, but we have to stop pretending that technology is inherently good. I’m not even sure we can say it’s neutral at this point. Once it gets into the hands of people, it is being used to make our lives worse in ways we don’t even understand. We cannot rely on technology to save us.

So how do we fix this? Computer science and similar programs (or really all academic programs) should include ethics courses as mandatory parts of the curriculum. Job interviews should include questions about ethics, not just technical questions. I commit to asking questions about ethical considerations in every job interview I conduct. Companies have to ask “how can this be abused?” as an early part of product design, and they must have diverse product teams so that they get more answers. And we must, as a society, pay for journalism that holds these companies to account.

The only thing that can save us is ourselves. We have to take out our own garbage.

Say “no” to advance your career

Posted on by
1

A few months ago, Bridget Gelms shared the worst professional advice she has heard:

Early-career people in particular are encouraged to take on all tasks in order to prove themselves and — to a lesser extent — discover what they do and don’t like to do. I suspect this is more true for women. I understand why people give that advice, and I understand even more why people take it. But it turns out, saying “no” can do more to advance your career than saying yes.

One thing I’ve observed is that over time, people who say “yes” to every request get a bunch of requests dropped on them. Some of them are good, but many are a waste of their talents. Being able to say “no” when the situation warrants can establish that your time — and thus you — are valuable.

Consider this: you’re asked at the last minute to fly to another continent to be in a meeting with a potential customer for a couple of hours. The potential customer is pretty unlikely to actually sign up, or they represent a small and not-strategic gain. You could go. Or you could find another way for the customer to get the 5 minutes worth of information that you’d end up providing. By not going, you save your company a few thousand dollars in airfare and you don’t lose two days to travel. What else more valuable can you do in that time?

The example above isn’t contrived. I’ve seen it play out, and the person who said no established themselves as someone of value in the company. Of course, you can’t say “no” to everything. Sometimes a task has to be done and you’re the one that will do it, whether you like it or not. But knowing when to say “no” is a valuable skill for improving your career.

Picking communication tools for your community

Posted on by
Reply

Communication is key to the success of any project. The tools we use to communicate play a part in how effective our communication is. Recent discussions in Fedora and other projects have made me consider what tool selection looks like. Should Discourse replace mailing lists? Should Telegram replace IRC? I’m not going to answer those questions.

There’s no one right tool, just a set of considerations to think about in selecting communications tooling. Each community needs to arrive at a consensus about what works best for their workflow and culture, and keep in mind that the decision may attract some contributors while driving others away.

In this post, I’m going to broadly lump tools into two categories: synchronous and asynchronous. Many tools can be used for both to a decent approximation, but most will pretty obviously fall into one category or the other. Picking one tool to rule them all is a valid option, but be aware that it immediately favors one category of communication over the other. And keep in mind that for large projects, some sub-teams may choose different platforms. That’s fine so long as people who want to participate know where to look.

Considerations for all tools

Self-hosted or externally-hosted. Do you have the resources to maintain the tool? If you do, that’s a way to save money and maintain control, but it’s also time that your community members can’t spend working on whatever your community is doing. Externally-hosted tooling (either free or paid) might give you less flexibility, but it can also be more isolated from internal infrastructure outages.

Open source or proprietary. This is entirely a value judgement for your community. For some communities, anything that’s not open source is a non-starter. Others might not care at all one way or another. Most will fall somewhere on the spectrum between.

Federated or centralized. Can the community connect their own tools together (e.g. like with email) or is it a centralized system (like most social media platforms)? The trend is definitely toward centralized systems these days, so you may have to work harder to find a federated system that meets your needs.

Public or private. Can outsiders see what you’re saying? For many open source projects, public visibility is important. But even in those communities, some conversations may need to take place in private or semi-private.

Archived or ephemeral. Do you want to be able to go back and see what was said last month, last year, or last decade? Some conversations aren’t worth keeping, but records of important decisions probably are. Does your tool allow you to meet your archival needs?

Considerations for synchronous tools

Sometimes you really need to talk to people in real time.

Mobile experience. It’s 2019. People do a lot on their phones, especially if their contribution to your community happens during their workday or if they travel frequently. What is the mobile experience like for the tools you’re evaluating? It’s not just a matter of if clients exist, but what’s the whole experience. If they disconnect while on an airplane, do they lose all the messages that were sent in their absence?

Status and alerting. What happens if someone stays logged in and goes away for a little bit? Do they have the ability to suppress notifications? Is there any way to let others know “I’m away or busy, don’t expect an immediate reply”?

Audio, video, and screen sharing. Sometimes you need the high-bandwidth modes of communication in order to get your full message across (or just shortcut a lot of back-and-forth). Does the tool you’re looking at provide this? Is it usable for those who can’t participate due to bandwidth or other constraints?

Integrations. Can you display GIFs? The ability to speak entirely in animated images can be either a feature or a bug, depending on the community’s culture. But if it’s important one way or another, you’ll want to make sure your tool matches your needs. Of course, there are other integrations that might matter to. Can your build system post alerts? Does the tool automatically recognize certain links and display them in an particular manner?

Considerations for asynchronous tools

Of course, you’re not all going to be sitting at your computer at the same time. People go on vacation. They live in different time zones. They step away for 10 minutes to get a cup of coffee. Whatever the reason, you’ll need to communicate asynchronously sometimes.

Push or pull. Email is a push mechanism. Your message arrives in my inbox whether I’ve asked it to or not. Web fora are a pull mechanism. I have to go check them (yes, some forum tools provide an email interface). Which works better for your workflow and community? Pull mechanisms are easier to ignore when you want to step away for a little while, but they also mean you might forget to check when you do want to pay attention.

Is it a ticket system? I haven’t really talked about ticket systems/issue trackers because I don’t consider them a general communication tool. But for some projects, all the discussion that needs to happen happens in GitHub issues or another ticket tracker. If that works for you, there’s no point in adding a new tool to the mix.