2

In the last 10 years with the spread of Agile, I've seen developers taking more and more responsibility in the make of the software. Usually the implementation decisions are a team job and not anymore a single person task. But... is there still space for managers?

Now I'm starting my own company and I started putting together a small team, and it's interesting to notice that the more a developer is skilled, the more he pretends to have a say in the implementation. However, considered the investment is mine, I'd like to take important decisions about the implementation myself. Today this has become impossible without getting people upset. Is there a solution to all of this? Or should I limit my decisions to the functionality and leave all the implementation details to the team?

  • I'm not sure that this question as phrased is a practical problem in project management. – Mark C. Wallace Jun 29 '17 at 10:46
  • As I understand it, the question is: "should management dictate technical implementation?". So in my eyes it is the right place to ask. – ppasler Jun 29 '17 at 11:14
  • 2
    Is your goal to "be in charge" or to "deliver the right product?" They aren't necessarily orthogonal, but they aren't the same thing either. – Todd A. Jacobs Jun 29 '17 at 14:56
  • You now have 4 answers, please consider accepting one to show others your problem is solved. If not, provide some more details. – ppasler Jul 23 '17 at 18:17
5

TL;DR

The golden rule is "he who has the gold makes the rules." However, that doesn't mean he-who-makes-the-rules is necessarily right or is acting in his own best interests. You can have what you want, but it may not get you where you really need to go.

Control Isn't Leadership

I'm starting my own company and I started putting together a small team, and it's interesting to notice that the more a developer is skilled, the more he pretends to have a say in the implementation. However, considered the investment is mine, I'd like to take important decisions about the implementation myself.

While your question might be a better fit for The Workplace, there are certainly project managers (on-topic here) and business owners (off-topic here) who have similar concerns. However, the problem is more often one of role definitions and personality traits than anything else.

Without intending to be pejorative, your quoted statement above is fairly common among people who are:

  • relatively new to business or technology leadership.
  • engineers or architects, rather than managers or leaders. NB: Despite common usage, "manager" and "leader" aren't synonyms.
  • micromanagers or technocrats, rather than strategic leaders.
  • controlling personalities who are unable or unwilling to delegate effectively.
  • perfectionists or command-and-control types who have a hard time trusting others.

There is absolutely nothing wrong with wanting a product or service to be salable and fit-for-purpose, but embedded in your statement is the implicit belief that others can't be relied on to implement something the way you would yourself. Rather than measuring outcomes (e.g. the software works and is it easy to maintain) you're focused on the implementation, which is usually a business anti-pattern.

The main problem with being a "control freak" in a knowledge-based industry like I.T. is that is drives away creative and talented people. Micromanagement stifles innovation and independent thinking. The only folks who will tolerate fear-based management—an environment where an authority figure wants to control everything—are typically those who prefer a highly-directive management style because they aren't self-starters, or workers who are themselves fearful people. This typically results in a "team" where people do only what they're told and no more. Pragmatically, this often results in slower development and less innovation because the micromanager is really doing all the work, but at the additional cost of having to delegate it out and then verify it afterwards.

Agile frameworks have principles and values that aim to solve many of these problems by replacing inefficient command-and-control techniques with collaborative processes, iterative development, quality control feedback loops, and self-organizing teams that value (rather than stifle) creative solutions that you may not have thought of yourself. There are definitely use cases for more directive approaches, but your original post is not really one of them.

Hire for Fit

In the end, as the project manager or business owner, you can hire for cultural fit. If you prefer to hire people who aren't agilists, or who prefer a more directive style of management, that's fine. However, you own the interview and selection process, and you also largely own the results of picking good or bad hires.

In other words, if you hire people based primarily on their willingness to be managed closely then you can't complain that they aren't people who enjoy working independently. Conversely, if you hire people who are self-starters, you shouldn't complain that they bring their own perspectives to bear on a problem.

Neither extreme is good for development, business, or team-building. Your job is to identify the best balance of collaboration and independence for your objectives, and then deliberately select for that in your hiring process. You'll make mistakes, because everyone does, but if you aren't attracting the talent you want or consistently making bad hires then you need to inspect-and-adapt your organizational culture and management style rather than blaming everyone else.

4

The agile movement arised due to fact, that many, many software projects failed, didn't meet their deadlines or costs exploeded. All parties (customers, developers and even some managers) were dissatisfied with the way projects were run (See: agilemanifesto.org/history.html). Working together as a team makes software better, implementation decisions should be made by the ones doing it (as well as estimating the effort). Maybe your colleagues think of other things you might forget? 8 eyes might see more than 2, it is a advantage to disucss implmentation details - I don't think you want stupid "Code Monkeys"?

As a manager (or product owner or however you want to call it - I know they are not quite the same), the task is to find out what the users of your software need and explain the customer's value to the team. User Stories for example may not contain implementation details and thats an important thing as they should meet the INVEST criteria!

In Scrum there are meetings where you, let's assume you're the PO, can contribute your opinion about implementation details (at this point some might disagree), p.e. Task Breakdown. For me the key fact is, that you trust your team enough, to let them make their own decisions and not dictate solutions.

You might start with a Sprint Zero, where some architectural decisions are made and you can discuss with your team mates. Whereas Sprint Zero is not recommended by all Scrum organizations (Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint...)

As the projects grows (which would be the goal I guess), you won't be able to know all the details, so you HAVE to let the team make their own decisions.

  • 1
    It's heartbreaking to see the use of the term Sprint Zero . . . especially on a Scrum site . . . especially Jeff Sutherland's organization . . . There is no such thing as a Sprint Zero: the team is either delivering a product increment or not. The Scrum Guide – Alan Larimer Jul 1 '17 at 16:57
  • @AlanLarimer I didn't know there is such a big controverse about sprint zero :) Just to correct you, the link that recommended sprint zero is not from Jeff Sutherland, it's Ken Schwabers organisation. I've added another opinion about sprint zero. – ppasler Jul 1 '17 at 18:51
  • A lot of people use the term Sprint Zero as a period without anything that makes a Sprint a Sprint: an increment, the events, a time-box, etc.. It is not Jeff's site, you are correct. Thanks for the correction! But it's not Ken's site. He left SA and founded scrum.org in 2009. – Alan Larimer Jul 1 '17 at 19:29
  • I was upset for a short moment too about the Sprint 0 mention, but thanks for putting an extra note! – yclian Jul 2 '17 at 15:46
1

As a businessman, I do not care about technical implementation unless it affects my wallet. I reserve the right to tell the team, "No. I'm not paying for that. What are the other options?", but I honestly don't really care how they get the work done. All I care is that they do it in a timely and cost effective manner. I'm going to hire people to do a job and trust them to do it.

If I don't trust technical people to make technical decisions, then why did I hire them to begin with? It's not my job to make those decisions. It's my job to set a vision, goals, and strategies to reach them. It's their job to implement, let them implement. They're the experts, not me. I understand, regardless of the fact that I'm also a software developer and could do their job, that I don't understand the details as well as they do and will likely get in their way. If I get in their way, I will slow things down, demoralize the team, and lose my best developers. Will they do things differently than I would and make some mistakes? Sure, but I would make more because I'm not as intimately familiar with the problem space as they are. Getting overly involved with implementation does a disservice to myself, my team, and my company.

That said, you're the man signing the paycheck. It's your company and it's your right to do what you like. If you want to be successful however, I would let the team do what you pay them to do.

  • I just want to note that I intentionally avoided mentioning Agile and Scrum. This isn't about what development methodology you're using. It's about sound business practices. – RubberDuck Jul 2 '17 at 12:17
0

Agile (and many methods proposed) has its root in lean thinking, and if we start tracing backward, you can find such relevance in TQM (including Deming's teaching) and TPS (what Womack and Jones studied).

I can't give you a straightforward answer what you can do, but my personal favorite to become a better manager is to read Workplace Management by Toyota's manufacturing genius Taiichi Ohno. His teaching puts immense amount of emphasis on leaders at the gemba doing kaizen (continuous improvement). The book comes with an article by Jeffrey Liker, which in some way sums up the responsibilities of a manager: 1) learn at the gemba, 2) stay ahead of your students, 3) keep a high standard, 4) love your students, and 5) be passionate and obsessed with kaizen.

With that said, your presence as a teacher (or guru, or servant leader as some would call it) at the shop floor to learn together with the people, such as asking the 5 Whys, as opposed to directing, will build better trust and a more positive culture.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.